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.
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.
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.
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.
136 comments
[ 4.1 ms ] story [ 154 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...
https://github.blog/2016-02-22-delivering-octicons-with-svg/
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...
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.
Nice overview here too http://tutorials.jenkov.com/svg/use-element.html
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.