Not even the links along the top work without JS, I guess the temptation to re-implement the <A> tag in JavaScript was too strong. Their re-implementation doesn't even support middle-clicking to open in new tabs.
This is one of my top three annoyances on the web. Soooo many people re-implement links but don't realize that you can do more with links than just follow them. What about copy url, open in new tab, open in new window, share, ...
Just use an <a> tag! And if you really need to carefully prevent only left clicks to do internal navigation. (I do wish that <a> tags had a better semantic event that could be used to override only "regular navigation")
A lot of issues like this are to solve problems for less tech-savvy people or are more about poorly thought and untested ideas about how to make browsing easier. Or at least, that's the intention/reasons given by the project managers and clients for why they want things done a certain way.
For example opening external links in a new tab is one such common practice. It is done so that people don't lose the page they were on (which is what the Back button is for) because clients are afraid once the user navigates away from their website they won't know how to return to it. But the back button is one of the most used browser features in the browser [1]. If users wanted to open the link in a new tab the browser has the functionality to let them control that behavior but "some people may not know to M3 click, shift+click, or right click->open in a new tab". So instead it is forced for everyone with no way to opt-out without running a userscript that strips out target="_blank" from all <a> elements.
And <a> elements are just one of the many cases where "We know how the user wants to interact with our site/the internet as a whole" is often and annoyingly wrong.
I can't even fathom what sort of though pattern leads to "I'll load my entire plaintext blog using javascript." I would really like to know why people do this.
The allure of the SPA. In theory it reduces load times (except for the inital page load) by preventing users from re-loading the same set of base resources for each subsequent page. In practice, it results in a bloated initial page request and requires devs to re-implement a ton of functionality normally handled by the browser (and they inevitably overlook things). I've worked on a couple projects where team members insisted we implement the web interface as a SPA and it has always resulted in an inferior user experience IMO.
Ideally, making efficient websites shouldn't be that crazy: you only want to minimize roadtrips, minimize the size of the content to transfer, and maximize caching. With http and html alone, you can't really do this. The caching is too coarse, and the html can't be parametrized and reused efficiently. If I dared to call myself an engineer, I'd be very angry with this situation. Anyway. With javascript you can get there. Not like most of these pages actually do this; in fact, they generally end up doing x500 more roadtrips, but hey... what I want to say is that I hate javascript and I still feel tempted to do things like this. Most frameworks end up at the middle of the road, using "reusable/parametrizable components" or whatever you want to call it, people use those frameworks and we call it a day.
Yeah, it was funny to see a complaint about the flash of unstyled content on a plain text page that needed a loading screen, too. That said, I can't argue with the conclusion, SVG is a better choice.
"Please don't complain about website formatting, back-button breakage, and similar annoyances. They're too common to be interesting. Exception: when the author is present. Then friendly feedback might be helpful."
I'd say go a step forward and stick to standard web fonts unless what you're doing really calls for something custom. The vast majority of sites don't actually need custom fonts IMO. At the very least, don't use garbage like TypeKit.
This aligns with my (albeit limited) experience with TypeKit. The only client project where I was forced to use it, was to appease the design agency who insisted on their font package being used. I still see (naked eye) a noticeable lag or hesitation when that website loads.
_Well actually_, using Emojis in your UI can be difficult due to the issue/feature that different systems have different artwork for Emojis.
While generally the platforms have gotten better at aligning on the meanings over time, the same emoji will sometimes have different meanings on different platforms.
This is why Twitter and Discord render custom emojis (using... pngs actually afact) so at least they have the same meaning everywhere.
Icon fonts were always a workaround for vector graphics, this because SVGs were not well supported. So good to hear newer browsers have better support. Unfortunately, one does generally need to support users on older browsers.
For internal use (e.g. inside a corporation that bought heavily into ActiveX, etc) you're going to have a hell of a time getting authorization to rewrite things because "it works just fine and we don't feel a need to spend money on this"
That's not changing any time soon; even with old IE ripped out of Windows 10 to a large extent, there are still multitudes of kiosks and other custom setups using XP/Vista out there that won't be getting any upgrade.
At that point would be like paying for insurance. I mean, don't they take into account that leaving their systems unsecure can be very bad for the company?
I would argue that if Microsoft was serious about not supporting IE11 they would stop shipping it with Windows 10. Until they do a lot of corporations will continue to use it and have it set as the default browser for their employees.
My Mum wont upgrade from windows 95, please keep supporting Internet Explorer 6 SP1, Stop it with any of your fancy tools/websites.
The flipside is that one just accept that the users who are not able to upgrade are not your target audience and will use other systems to get their work done.
Don't carry others burdens when they self impose their problems.
Please have a look at the browser lists linked in the parent post again. SVG enjoys better browser support than the web fonts being discussed here. I am also wondering which old browsers you're talking about.
More and more developers are deciding to give up on IE. The cost to support it is high, in large part because you have to not use any of these newer things like SVG that save a ton of time and improve performance.
More and more developers are deciding to give up on IE.
Developers almost never get to decide if they want to give up on IE, unless they're doing their own project. It's always the legal, security, and other departments and middle managers that make that decision.
I can imagine the response of a developer at an enterprise saying to the boss, "I'm going to stop supporting 2% of our customers, is that OK with you?"
> I can imagine the response of a developer at an enterprise saying to the boss, "I'm going to stop supporting 2% of our customers, is that OK with you?"
Depends on whether it's followed by "This will save 20-50% of development and maintenance costs."
About using svg images I wonder if there are some studies about inlining versus using a reference to an external URL.
I have a web page with the same icons repeated 20+ times, and I my intuition is that it it could be optimized by using a shared reference instead of repeated inlined svg sources in the html documention — which is font-awesome default behavior.
This page doesn't load for me; I just get a spinner. Someone had archived it with archive.whatever so I was able to read it anyway: https://archive.fo/m6jdd
However, that doesn't work with Lynx, because "archive.fo" is so concerned about preserving our intellectual heritage, the way archives do, that it serves a visual CAPTCHA to Lynx users and, presumably, anybody trying to save a copy of their page with wget.†
In this context I think it's terribly amusing that the author has taken it upon himself to lecture us about what's "notoriously bad for accessibility". What's worse: that your screen reader inserts a few "unpronounceables" at the beginning of your essay, or that it says "(BUTTON) (BUTTON) Irigoyen.dev irigoyen.dev (BUTTON) about (BUTTON) resume" and then fails to load your actual article? Except for the all-important copyright notice, of course.
At least the endless spinner is rendered in SVG instead of one of those godawful icon fonts.
Way to show us your "passion for user experience", Michael. I'd hate to see what it looks like when you don't care about user experience!
Why do I get a spinner? "RangeError: invalid time zone in DateTimeFormat(): AMERICA/CHICAGO", apparently, on line 1 of the JavaScript. In column 103224. How that results in the whole web page completely failing to load is anybody's guess. God forbid a timestamp on the page should be localized incorrectly. I guess that's just what passion looks like!
I gotta say, when I pioneered AJAX in the year 2000 (along with a number of other people, of course), this was not the fucking Web I was fucking hoping for.
_______
† Actually wget from a different IP address works fine on archive.fo, and it yields an HTML file that Lynx can render successfully, although you have to page down past five pages of base64-encoded SVG data: URLs. Why Lynx elects to show the data: URLs of archive.fo's SVG icons I have no idea. Somebody ask Foteos why it does that, if he isn't drinking himself into a stupor to forget the horror the web has become. I'd ask him myself but http://www.macridesweb.com/fote/ gives me a 403, apparently because I live in the wrong country.
He hasn't worked on Lynx since, uh, the late 90s (I forget the exact year but not long after 96-97.) You'll be wanting the lynx-dev mailing list (lynx-dev@nongnu.org) for questions and feature requests.
Don't know where you got the logo from, but it isn't a PNG on the W3C's SVG working group page (there it's an inline svg):
https://www.w3.org/Graphics/SVG/
Icons in font are not so expensive for business users. However they are important for various reasons for websites. However I still agree svg's are better because they are easier to manage. You don't have to risk converting to font will break the icon. Normally in projects I run usually there is a component that handles a set of icons in font if I use a lot of icons from one source, and also svg icons. Eventually I gives benefits from both worlds
> Considering that real SVG support across all major browsers didn't become stable until early 2020
> With the release of Chromium-powered version Microsoft's Edge browser in early 2020, Scalable Vector Graphics (SVG) became fully supported across all major browsers.
These are not good claims. I've tested Internet Explorer 11 (released in 2013) and it supports lots of SVG features already. I agree with the article that we should use SVG icons, but think it should have been done 5+ years earlier.
I recently started removing Font Awesome from a couple of projects and replaced the icons with inline SVG. This article at css-tricks.com is invaluable for learning how to deal with SVGs as they don't behave like rasterized images.
Not that I know of. SVGs can just be a bit tricky to scale. At least compared to a PNG/JPEG. The two main keys to making it work is understanding `viewBox` and `preserveAspectRatio`. viewBox is what sets what part of the SVG should be within the view. On a simple SVG that is 24x24 pixels it is just `viewBox="0 0 24 24"`. Changing it to "0 0 20 20" would crop 4 pixels off the right and bottom of the SVG.
Apart from font-icon, a nice way to handle icons in a website is to leverage the underutilized <use> SVG element:
<!-- Should be in all your pages -->
<svg style="display: none" aria-hidden="true">
<defs>
<symbol id="icon-circle" viewBox="0 0 20 20"><circle fill="currentColor" cx="10" cy="10" r="10" /></symbol>
<!-- other icons here -->
</defs>
</svg>
<!-- In some other template -->
<button>
<svg class="icon"><use xlink:href="#icon-circle"></use></svg>
<span>foobar</span>
</button>
<!-- in your CSS -->
.icon { width: 1em; height: 1em; }
This approach I feel has most of the advantages of inlined SVG (mostly context-dependent colors) while avoiding most of the clutter, and is not heavily reliant on a specific JS-based workflow (thought we do need to includes our <def> somewhere in all pages)
I like <use> but for the WWW I'm reluctant to stray from the absolute most common SVG elements and forms of combining them; I've had too many cases where what works on one browser fails in another, or sort of works but far too slowly to be usable. It's a lot like HTML in the 1990s that way.
Yeah, I've been saddened by the depreciation of SMIL for animation, for example. SVG can be rough around the edges sometime when it comes to cross-browser support of less-used features :/
Google wanted to deprecate and remove SMIL, but public outcry was sufficient that they suspended those plans indefinitely, and I haven’t heard anything against it in the years since.
Yeah, I don't remember which things I've run into trouble with—it's just enough that I'm very cautious about using any SVG features outside the bare minimum.
<use> and <symbol> have been an integral part of SVG for yonks. I remember it working robustly even in Adobe SVG Viewer days (my Dad made extensive use of them in some software), and although some small details have changed concerning how interaction-based styles apply (:hover and the likes) it’s always been dependable.
https://developer.mozilla.org/docs/Web/SVG/Element/use#brows... shows nearly complete green across the board, frontend tech years are like dog-years; without more info I'd suggest leaping forward to <use> <svg>; in other words it's not like the 1990s anymore--every modern browser have continuous updates, robust native APIs that make the majority of contemporary legacy tech workflows prior to 2017-ish obsolete, and Google's bot processes JavaScript as a mobile client by-default as I recall. Browsers are more consistent and robust in their implementations than ever before, making contemporary solutions easier to implement and performant both for consumers and developers--providing they know of these and use them.
You can reference elements from an external file just as well:
<use xlink:href='icons.svg#foo'/>
Theoretically the browser should only download that file once, just as with multiple img elements referencing the same image. I haven't seen that approach much in the wild, though.
Good to know. This has me thinking it'd be cool to have a babel plugin or something that extracts out svgs like this. I currently have a website that heavily uses svgs and for the bulk of them I resorted to img elements because embedding the svg so many times increased the size of the html significantly. This use approach seems like it might be better.
I have tried this, but adding symbols to the file becomes a giant PITA. Then, you also have to ensure that symbols are loaded on every page. I had some SVGs that were multiple kilobytes (logos and stuff), and this just increased the page weight.
You can give my library, svg-loader, [1] a try. It's a single line of javascript that makes it really easy to load external SVGs as inline elements. The syntax is even shorter and you avoid all the problems of external SVGs.
I'm not sure if this library is better. If you're making an XHR for each inline svg, then that's a lot of unnecessary network requests compared to a dynamically generated svg sprite-sheet at build time. The latter is definitely possible with a pre-defined sprite UI library like Material Design or Font Awesome mentioned in the blog post.
With HTTP2, the cost of making a request is incredibly low and almost.not worth optimizing for non blocking resources. Unless, you're loading hundreds of icons, you shouldn't notice that much of a difference.
> I have tried this, but adding symbols to the file becomes a giant PITA.
I use Affinity Designer for this. It exports artboards using a trivially detectable pattern, which can be easily turned into symbol elements in a compilation step.
I made a feature request for an option to do this natively, but it never got any traction.
Half the arguments are along the lines of "because you can use it wrong, don't use it all". And the argument about SVG being more crisp is wrong, I'm trying real hard to make my SVG icons look crisp but sometimes it's just too difficult and I end up with a partially blurry icon. "speak: never;" in the icon class should work for screen readers, although I'm not sure. Whenever the icon isn't just a design element, I use SVG of course. And lastly, gzip is the wrong compression nowadays. Compress text (be it html, xml, css...) with brotli and use content negotiation properly, for optimal compatibility.
Couldn't disagree with this article more. SVG is not as performant as fonts. Fonts are highly optimized by operating system and performs much better than SVG. Accessibility concerns mentioned are not valid because role and aria attributes can be used to solve those problems.
Even if you’re right and fonts are rendered much faster than SVG:
1. At that level, do you really believe anyone will notice?
2. How does the faster rendering even make a dent in the increased load times from which your users will suffer as their browser downloads the whole font with all its glyphs they don’t need?
Re: 2, it's very possible to just bundle the glyphs you use, at which point it's about the same amount of work as picking and bundling individual SVGs.
I prefer to use SVGs (I find animation and styling with them easier) but I agree with the OP of this thread that properly bundled icon fonts aren't that big a deal.
Agreed, font icons are almost always associated with actions (buttons etc.) or status (e.g. on/off/paused) which need their own appropriate roles and attributes. I lead a team that made a large website fully AODA[1] compliant and we used font icons EVERYWHERE.
[1] Accessibility for Ontarians with Disabilities Act,
For when you want to use your own fonts instead of the (sometimes horrifying) choices of the webpage author - e.g. if you're dyslexic, have sight issues, or just want to use a font you can read more easily.
Firefox calls it "Allow pages to choose their own fonts, instead of your selections above." Safari lets you use a custom stylesheet to enforce your font choices - Chrome did too but it sounds like they've removed that option. In all 3 cases, I think there's extensions which will also do this for you.
Not sure your performance claims are valid without (1) profiling the performance and (2) accounting for the different access patterns/performance concerns between rendering text and icons. (That is, the dominant pattern in rendering text is rendering strings of characters in a line/rectangle, while for icons it's a relatively much smaller number, one at a time.)
Can confirm - in a large React app, SVG Font Awesome icons constituted a disproportionate amount of time spent rendering. Switching to the icon font dramatically improved performance.
Hmm, that's really interesting! Does that mean we can get more efficient vector graphics in browsers by converting them into TrueType fonts with a single glyph, then displaying it in a huge font size?
rem and px won't be based on the size of the surrounding text. rem is based on the size of text on the HTML (IIRC) element and px is based on display pixels.
with tools like this: https://github.com/tancredi/fantasticon using font icons is pretty easy to use. The biggest issue I found with font icons was getting upskilling new devs. online tools are clunky and explaining how to use it was always a pain. sometimes i'd wind up just saying 'use an svg'.
No. 20H2 just came out not everyone is on Chromium based browsers that's incorrect. To me performance matters not to mention content I'm using content that's cached in everyone's browser already so leave me alone.
A lot of very good counter-arguments in the comments!
I'd like to add one: don't use full icon fonts, use only the icons you need with a tool like icomoon.io => it generates font files with only the icons you choose!
> All modern browsers and operating system employ anti-aliasing on text to some degree. Textual anti-aliasing is agnostic about whether or not your font is made up of letters and numbers or pictograms. This has the potential for negative side-effects in terms of visual quality, especially if you stack glyphs to make multicolor icons. Your icons may look blurry or misaligned.
To add to this point. On normal DPI screens, aliasing often just looks blurry, and the automatic font hinting that's used on most custom fonts is A T R O C I O U S, if you disable anti-aliasing. System default fonts are usually OK and look crisp without aliasing, since they've been expensively manually-hinted, but requiring icon fonts makes it difficult for the user to use them on your site.
I hate aliasing, so I hate all web fonts, not just icon fonts.
When developing for iOS/macOS, I've really enjoyed using SF Symbols. In code they're handled like images, but respond to text scale factor and weight like fonts. Custom symbols are supported too so you're not just limited to what Apple provides.
On the web, icon fonts seem like the natural parallel since they also "just work" when matching styles with text. To my knowledge, SVGs can't automatically match text size or weight which is a significant weakness, particularly when the user has specified overrides for accessibility reasons. But as the article states, icon fonts are bad because they're nonsense to screen readers.
Is the only way to get an SF Symbols equivalent on the web, then, with SVGs and some JS wizardry?
Although I agree with the conclusion entirely, a surprisingly large fraction of this article is unsound, incorrect or misleading. Here are most of my complaints:
> Cannot provide metadata
That was never the responsibility of the icon font, it was the responsibility of the thing placing the icon. You can still put ARIA attributes on the element that says “put the icon here”. (And if it’s just an extra class on an existing independently-meaningful element that says “put an icon before it”, then that icon is decorative and shouldn’t be exposed in the accessibility tree anyway.) Also ::before and ::after are not the only way of doing an icon font; you can style normal text nodes if you want to—it’s just not the most common way of doing it.
> Size and Maintainability
This is somewhere between unfair and incorrect. Most or all alternatives will experience the same or similar issues. (This is a common theme—each technology has its own advantages and disadvantages, and the author is pointing out the disadvantages of one that don’t affect another, without considering the tradeoffs made and the similar disadvantages in that other.)
> Degraded Visual Quality
This is nonsense. Size your glyphs correctly and you’ll have no trouble. (Though I will admit user stylesheets can mess with this, but you should expect that they’d be messing with all alternatives in much the same way as well, so I deem the quibble invalid.)
> Difficult to Style/Position
The monochromacy can’t be overcome, but icon fonts aren’t difficult to position, you just need to exercise a modicum of caution. Other techniques require just as much caution, just in different places; e.g. I’m fed up with inline <svg> elements lacking width and height attributes so that they end up filling the viewport when the stylesheets fail to load, rather than being 16×16 or whatever.
> SVGs are straight up vector images. Anti-aliasing methods employed by your browser or operating system have no effect and your icons will be noticeably sharper.
I… what!? I’m going to say it straight, this guy doesn’t understand what he’s talking about.
> Additionally, SVGs are simply the size they are.
This is drivel. They may have an inherent size, but they’re the size the document tells them to be—just like text is the size the document tells it to be. I’d actually say my experience with SVG icon sizing is substantially worse than my experience with icon font sizing, to do with the missing width and height attributes mentioned above, when rendered sans CSS.
>> SVGs are straight up vector images. Anti-aliasing methods employed by your browser or operating system have no effect and your icons will be noticeably sharper.
> I… what!? I’m going to say it straight, this guy doesn’t understand what he’s talking about.
Perhaps I am misunderstanding too, but I think what GP is saying is that icon fonts render through the font engine and are subject to sub pixel rendering (such as Microsoft ClearType) where an SVG is not. Sub pixel realignment is meant to make text more readable and not to make images more accurate, so I can imagine an SVG would render with less artifacting. What do you think?
At the very least, the author is conflating subpixel rendering and antialiasing in a way that shows a lack of understanding.
Subpixel rendering may have been part of the topic of the “degraded visual quality”, but that’s easily disabled if desired. (Whether you should disable it or not is another question.) And it still sounds like he’s talking about antialiasing rather than subpixel rendering.
Actually, this is now making me think of macOS’s glyph dilation. I suppose icon fonts will be degraded on most macOS devices (unless the user has turned off the misnamed “font smoothing” setting).
Then in this section you’re citing, well, SVG is certainly subject to antialiasing; no sharpness arguments will be won here. Subpixel rendering probably won’t apply (and I say only probably—the browser is at liberty to do subpixel rendering on everything if it wants to, and people have toyed with doing subpixel rendering of more vector graphics than just fonts—in fact, in theory you have less control of this rendering than you do of text, as there’s no CSS property for it, unlike with text), but subpixel rendering is all about making things sharper anyway, so again SVG “loses”, if anything. Remember also that icon fonts are more or less constrained to monochromacy, and that’s where subpixel rendering excels, at increasing the effective resolution in one axis.
> I'm against all icon fonts except icon fonts that literally only implement Unicode icon codepoints. That use-case is still technically accessible.
This seems like the appropriate solution, especially since those icon codepoints are quite extensive (they include all emoji, for example). Do you have examples of icon fonts that are implemented with this restriction?
137 comments
[ 4.2 ms ] story [ 218 ms ] threadThe article still brings up good advice, for whatever it's worth.
Just use an <a> tag! And if you really need to carefully prevent only left clicks to do internal navigation. (I do wish that <a> tags had a better semantic event that could be used to override only "regular navigation")
For example opening external links in a new tab is one such common practice. It is done so that people don't lose the page they were on (which is what the Back button is for) because clients are afraid once the user navigates away from their website they won't know how to return to it. But the back button is one of the most used browser features in the browser [1]. If users wanted to open the link in a new tab the browser has the functionality to let them control that behavior but "some people may not know to M3 click, shift+click, or right click->open in a new tab". So instead it is forced for everyone with no way to opt-out without running a userscript that strips out target="_blank" from all <a> elements.
And <a> elements are just one of the many cases where "We know how the user wants to interact with our site/the internet as a whole" is often and annoyingly wrong.
[1] https://ux.stackexchange.com/questions/36017/is-the-browser-...
See also Linux users distrust of Microsoft.
I've seen a lot of weird antipatterns on the web, but this is my first time seeing this. What's the point of doing this???
https://news.ycombinator.com/newsguidelines.html
Speech: use aria-hidden="true"
Stylesheet overrides: External to design & UI intention. Outside of control.
Cannot provide metadata: I can't think of a valid reason why this matters on a character..
> By themselves, these icons don't provide any semantical information about their contents; You cannot label them or describe them directly
Why would you ? Do you add context to individual strings in your content too ? No, you add to the container.
I'm all for other opinions, but demanding is just off-putting from the start.
Sometimes that's exactly the opposite of what I want. What's next, "Stop using emoji, use SVG instead"?
While generally the platforms have gotten better at aligning on the meanings over time, the same emoji will sometimes have different meanings on different platforms.
This is why Twitter and Discord render custom emojis (using... pngs actually afact) so at least they have the same meaning everywhere.
https://stackoverflow.com/questions/12436274/svg-image-in-ja...
How about security?
That's not changing any time soon; even with old IE ripped out of Windows 10 to a large extent, there are still multitudes of kiosks and other custom setups using XP/Vista out there that won't be getting any upgrade.
Security should absolutely be more of a concern but it's not. You're talking about business choices not engineering choices.
I think the plan is for Edge to one day have a way to display pages in IE compatibility mode.
https://caniuse.com/svg https://caniuse.com/svg-img
It seems to me the only browsers not supporting any SVG are ones you'd expect in a computer museum, but not in active use.
The flipside is that one just accept that the users who are not able to upgrade are not your target audience and will use other systems to get their work done.
Don't carry others burdens when they self impose their problems.
A healthcare provider using a browser that's too old to have SVG support is a patient data leak waiting to happen.
Developers almost never get to decide if they want to give up on IE, unless they're doing their own project. It's always the legal, security, and other departments and middle managers that make that decision.
I can imagine the response of a developer at an enterprise saying to the boss, "I'm going to stop supporting 2% of our customers, is that OK with you?"
Depends on whether it's followed by "This will save 20-50% of development and maintenance costs."
[1] https://css-tricks.com/a-complete-guide-to-svg-fallbacks/
I have a web page with the same icons repeated 20+ times, and I my intuition is that it it could be optimized by using a shared reference instead of repeated inlined svg sources in the html documention — which is font-awesome default behavior.
The syntax is like this:
<!-- Define the SVGs. I usually put them in an element with `display:none` --> <svg id='svgID12345'><path d="..."/></svg>
<!-- Use the SVG via `<use xlink>` anywhere you want to see it. --> <svg><use xlink:href='#svgID12345'></svg>
You can reference external SVGs in external files as well. Just use `<use xlink:href="defs.svg#icon-1"></use>`. https://css-tricks.com/svg-use-with-external-reference-take-...
However, that doesn't work with Lynx, because "archive.fo" is so concerned about preserving our intellectual heritage, the way archives do, that it serves a visual CAPTCHA to Lynx users and, presumably, anybody trying to save a copy of their page with wget.†
Here's what the original page looks like in Lynx:
In this context I think it's terribly amusing that the author has taken it upon himself to lecture us about what's "notoriously bad for accessibility". What's worse: that your screen reader inserts a few "unpronounceables" at the beginning of your essay, or that it says "(BUTTON) (BUTTON) Irigoyen.dev irigoyen.dev (BUTTON) about (BUTTON) resume" and then fails to load your actual article? Except for the all-important copyright notice, of course.At least the endless spinner is rendered in SVG instead of one of those godawful icon fonts.
Way to show us your "passion for user experience", Michael. I'd hate to see what it looks like when you don't care about user experience!
Why do I get a spinner? "RangeError: invalid time zone in DateTimeFormat(): AMERICA/CHICAGO", apparently, on line 1 of the JavaScript. In column 103224. How that results in the whole web page completely failing to load is anybody's guess. God forbid a timestamp on the page should be localized incorrectly. I guess that's just what passion looks like!
I gotta say, when I pioneered AJAX in the year 2000 (along with a number of other people, of course), this was not the fucking Web I was fucking hoping for.
_______
† Actually wget from a different IP address works fine on archive.fo, and it yields an HTML file that Lynx can render successfully, although you have to page down past five pages of base64-encoded SVG data: URLs. Why Lynx elects to show the data: URLs of archive.fo's SVG icons I have no idea. Somebody ask Foteos why it does that, if he isn't drinking himself into a stupor to forget the horror the web has become. I'd ask him myself but http://www.macridesweb.com/fote/ gives me a 403, apparently because I live in the wrong country.
He hasn't worked on Lynx since, uh, the late 90s (I forget the exact year but not long after 96-97.) You'll be wanting the lynx-dev mailing list (lynx-dev@nongnu.org) for questions and feature requests.
Are there any open source SVG icon libraries I can use in any web app I want?
IIRC, there was an aggregator/search engine for SVG icons posted on here a couple of weeks ago also.
Edit: examples here [1]
[1] https://www.hongkiat.com/blog/svg-animations/
> With the release of Chromium-powered version Microsoft's Edge browser in early 2020, Scalable Vector Graphics (SVG) became fully supported across all major browsers.
These are not good claims. I've tested Internet Explorer 11 (released in 2013) and it supports lots of SVG features already. I agree with the article that we should use SVG icons, but think it should have been done 5+ years earlier.
https://css-tricks.com/scale-svg/
Microsoft has a great "Fluent UI" icon pack in SVG: https://github.com/microsoft/fluentui-system-icons/blob/mast...
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/v... https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/p...
some advanced features of SVG, such as filters, are very much YMMV to this day. But for simple logos and icons there isn't much to worry about.
https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use...
Nice overview here too http://tutorials.jenkov.com/svg/use-element.html
You can give my library, svg-loader, [1] a try. It's a single line of javascript that makes it really easy to load external SVGs as inline elements. The syntax is even shorter and you avoid all the problems of external SVGs.
[1]: https://github.com/shubhamjain/svg-loader
I use Affinity Designer for this. It exports artboards using a trivially detectable pattern, which can be easily turned into symbol elements in a compilation step.
I made a feature request for an option to do this natively, but it never got any traction.
https://github.blog/2016-02-22-delivering-octicons-with-svg/
1. At that level, do you really believe anyone will notice?
2. How does the faster rendering even make a dent in the increased load times from which your users will suffer as their browser downloads the whole font with all its glyphs they don’t need?
I prefer to use SVGs (I find animation and styling with them easier) but I agree with the OP of this thread that properly bundled icon fonts aren't that big a deal.
[1] Accessibility for Ontarians with Disabilities Act,
How does that work with people who have "use my fonts" ticked for whatever reason? Is there some kind of override that applies?
Firefox calls it "Allow pages to choose their own fonts, instead of your selections above." Safari lets you use a custom stylesheet to enforce your font choices - Chrome did too but it sounds like they've removed that option. In all 3 cases, I think there's extensions which will also do this for you.
I'd like to add one: don't use full icon fonts, use only the icons you need with a tool like icomoon.io => it generates font files with only the icons you choose!
To add to this point. On normal DPI screens, aliasing often just looks blurry, and the automatic font hinting that's used on most custom fonts is A T R O C I O U S, if you disable anti-aliasing. System default fonts are usually OK and look crisp without aliasing, since they've been expensively manually-hinted, but requiring icon fonts makes it difficult for the user to use them on your site.
I hate aliasing, so I hate all web fonts, not just icon fonts.
On the web, icon fonts seem like the natural parallel since they also "just work" when matching styles with text. To my knowledge, SVGs can't automatically match text size or weight which is a significant weakness, particularly when the user has specified overrides for accessibility reasons. But as the article states, icon fonts are bad because they're nonsense to screen readers.
Is the only way to get an SF Symbols equivalent on the web, then, with SVGs and some JS wizardry?
> Cannot provide metadata
That was never the responsibility of the icon font, it was the responsibility of the thing placing the icon. You can still put ARIA attributes on the element that says “put the icon here”. (And if it’s just an extra class on an existing independently-meaningful element that says “put an icon before it”, then that icon is decorative and shouldn’t be exposed in the accessibility tree anyway.) Also ::before and ::after are not the only way of doing an icon font; you can style normal text nodes if you want to—it’s just not the most common way of doing it.
> Size and Maintainability
This is somewhere between unfair and incorrect. Most or all alternatives will experience the same or similar issues. (This is a common theme—each technology has its own advantages and disadvantages, and the author is pointing out the disadvantages of one that don’t affect another, without considering the tradeoffs made and the similar disadvantages in that other.)
> Degraded Visual Quality
This is nonsense. Size your glyphs correctly and you’ll have no trouble. (Though I will admit user stylesheets can mess with this, but you should expect that they’d be messing with all alternatives in much the same way as well, so I deem the quibble invalid.)
> Difficult to Style/Position
The monochromacy can’t be overcome, but icon fonts aren’t difficult to position, you just need to exercise a modicum of caution. Other techniques require just as much caution, just in different places; e.g. I’m fed up with inline <svg> elements lacking width and height attributes so that they end up filling the viewport when the stylesheets fail to load, rather than being 16×16 or whatever.
> SVGs are straight up vector images. Anti-aliasing methods employed by your browser or operating system have no effect and your icons will be noticeably sharper.
I… what!? I’m going to say it straight, this guy doesn’t understand what he’s talking about.
> Additionally, SVGs are simply the size they are.
This is drivel. They may have an inherent size, but they’re the size the document tells them to be—just like text is the size the document tells it to be. I’d actually say my experience with SVG icon sizing is substantially worse than my experience with icon font sizing, to do with the missing width and height attributes mentioned above, when rendered sans CSS.
> I… what!? I’m going to say it straight, this guy doesn’t understand what he’s talking about.
Perhaps I am misunderstanding too, but I think what GP is saying is that icon fonts render through the font engine and are subject to sub pixel rendering (such as Microsoft ClearType) where an SVG is not. Sub pixel realignment is meant to make text more readable and not to make images more accurate, so I can imagine an SVG would render with less artifacting. What do you think?
Subpixel rendering may have been part of the topic of the “degraded visual quality”, but that’s easily disabled if desired. (Whether you should disable it or not is another question.) And it still sounds like he’s talking about antialiasing rather than subpixel rendering.
Actually, this is now making me think of macOS’s glyph dilation. I suppose icon fonts will be degraded on most macOS devices (unless the user has turned off the misnamed “font smoothing” setting).
Then in this section you’re citing, well, SVG is certainly subject to antialiasing; no sharpness arguments will be won here. Subpixel rendering probably won’t apply (and I say only probably—the browser is at liberty to do subpixel rendering on everything if it wants to, and people have toyed with doing subpixel rendering of more vector graphics than just fonts—in fact, in theory you have less control of this rendering than you do of text, as there’s no CSS property for it, unlike with text), but subpixel rendering is all about making things sharper anyway, so again SVG “loses”, if anything. Remember also that icon fonts are more or less constrained to monochromacy, and that’s where subpixel rendering excels, at increasing the effective resolution in one axis.
This seems like the appropriate solution, especially since those icon codepoints are quite extensive (they include all emoji, for example). Do you have examples of icon fonts that are implemented with this restriction?