[HN Gopher] Stop Using Icon Fonts
___________________________________________________________________
Stop Using Icon Fonts
Author : feross
Score : 94 points
Date : 2021-02-24 17:03 UTC (5 hours ago)
(HTM) web link (www.irigoyen.dev)
(TXT) w3m dump (www.irigoyen.dev)
| bilekas wrote:
| For each of the `Accessibility` he listed, he suggests problems
| are external or just plain misleading.
|
| 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.
| ravenstine wrote:
| 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.
| ChrisLTD wrote:
| What's bad about Typekit?
| ravenstine wrote:
| It requires JavaScript and, in my experience, it can be
| unnecessarily slow.
| josefresco wrote:
| 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.
| brabel wrote:
| I use icon fonts in my JavaFX application because JavaFX doesn't
| support SVG (facepalm).
|
| https://stackoverflow.com/questions/12436274/svg-image-in-ja...
| bartvk wrote:
| On iOS, it's basically the same. Since iOS 13, we have SF
| Symbols, basically the iOS version of Wingdings, to replace
| PNGs when appropriate.
| kitsunesoba wrote:
| 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?
| mablopoule wrote:
| 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)
| voldemort1968 wrote:
| Came here to recommend this approach. Lots of FE devs don't
| know about this.
|
| Nice overview here too http://tutorials.jenkov.com/svg/use-
| element.html
| city41 wrote:
| Is it possible to include the defs in perhaps a <link>, so they
| can be downloaded once and cached across all pages?
| kragen wrote:
| 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.
| mablopoule wrote:
| 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 :/
| chrismorgan wrote:
| 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.
| chrismorgan wrote:
| <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.
| deckard1 wrote:
| for what it's worth, my company was using this method and we
| were supporting, I think, ie10 at the time just fine. No
| issues that I know of.
|
| 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.
| kragen wrote:
| 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.
| draw_down wrote:
| Be careful with those IDs. They are global to the document, and
| bad things happen when they clash.
| skrebbel wrote:
| Oh wow, I did not know this one! And the browser compatibility
| seems top-notch [1], really nice, thanks! :-)
|
| https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use...
| shubhamjain wrote:
| 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.
|
| [1]: https://github.com/shubhamjain/svg-loader
| dvergeylen wrote:
| I use this approach all the time.
| chrismorgan wrote:
| 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
| 16x16 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.
| lukevp wrote:
| >> 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?
| chrismorgan wrote:
| 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.
| nickserv wrote:
| 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.
| bluefirebrand wrote:
| If IE6's longevity is any indication, you may need to support
| users on older browsers for all of time.
| soperj wrote:
| Considering Microsoft doesn't even support ie11 any more, no
| one else should.
| fedorareis wrote:
| 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.
| bluefirebrand wrote:
| And yet many places still probably do, because some
| corporate IT has refused to upgrade, and they are a core
| customer that needs to be supported.
| traveler01 wrote:
| So basically you're wasting your money supporting those
| outdated browsers because someone refused to waste their
| money upgrading their browsers?
|
| How about security?
| bluefirebrand wrote:
| From a business standpoint if it is earning more money
| than it costs, is it a waste of money?
|
| Security should absolutely be more of a concern but it's
| not. You're talking about business choices not
| engineering choices.
| Firehawke wrote:
| 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.
| JxLS-cpgbe0 wrote:
| If IE's (any version) longevity is any indication, you don't.
| Use feature detection, not user agent.
| hannob wrote:
| What old browsers are you talking about?
|
| 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.
| ehutch79 wrote:
| Yeaaaahhhh... Those computers are still in use at some
| enterprises. and by some home users who can't/won't upgrade
| reaperducer wrote:
| _the only browsers not supporting any SVG are ones you 'd
| expect in a computer museum_ Or in
| healthcare. Or in industrial systems. Or in
| kiosks. Or in much of the real world beyond social
| media and "disruptive" industries.
| MatmaRex wrote:
| 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.
| csours wrote:
| Windows 2000 Forever!
| lucasmullens wrote:
| 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.
| reaperducer wrote:
| _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?"
| Turing_Machine wrote:
| > 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."
| car wrote:
| You can use SVG image fallback [1] in older browsers.
|
| [1] https://css-tricks.com/a-complete-guide-to-svg-fallbacks/
| httpteapot wrote:
| 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.
| pseudosavant wrote:
| SVG can handle this situation. You can define the SVGs
| somewhere in the HTML document and reference them anywhere you
| want. https://css-tricks.com/lodge/svg/13-svg-icon-system-use-
| elem...
|
| 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-...
| car wrote:
| <use xlink> will accomplish what you want to do.
| JxLS-cpgbe0 wrote:
| Much better writeup of the a11y concerns here:
|
| https://github.blog/2016-02-22-delivering-octicons-with-svg/
| kragen wrote:
| 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.+
|
| Here's what the original page looks like in Lynx:
| ------
| Twitter Profile Irigoyen.dev irigoyen.dev
| (BUTTON) (BUTTON) Irigoyen.dev irigoyen.dev (BUTTON) about
| (BUTTON) resume (BUTTON) projects
| (BUTTON) talks (BUTTON) philanthropy (BUTTON) contact (BUTTON)
| blog
| One Moment Please...
| (c) 2021 Michael Irigoyen
| [Document has only hidden links. Use the 'l'ist command.]
|
| 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.
| bradhe wrote:
| It's a bit funny that the SVG logo image is a PNG.
| not_knuth wrote:
| 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/
| bluefirebrand wrote:
| Stop using [Stopgap solution born out of the past's limitations]
| and instead use [Cutting edge new thing that isn't fully
| supported everywhere yet]!
| lucasmullens wrote:
| The article goes into browser support, saying "SVGs have been
| supported in all browsers since 2012". SVG is far from a
| cutting edge new thing.
| bluefirebrand wrote:
| Fair enough. I genuinely didn't know that.
|
| Are there any open source SVG icon libraries I can use in any
| web app I want?
| oblio wrote:
| You made me curious. The initial SVG release was in 2001, so
| SVG is old enough to vote now :-D
| Sephr wrote:
| I'm against all icon fonts except icon fonts that literally only
| implement Unicode icon codepoints. That use-case is still
| technically accessible.
| draw_down wrote:
| Sure... but that just sounds like a font to me.
| tomaszs wrote:
| 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
| pdenton wrote:
| 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.
| inshadows wrote:
| Stop using JavaScript to render simple blog rants. Until then,
| I'll be using icon fonts, because I couldn't learn why I should
| not.
| gregoriol wrote:
| 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!
| merlinscholz wrote:
| Reading about accessibility on a website that uses JavaScript and
| <button>s for navigation is a tad ironic.
| cglong wrote:
| It also seems to break the "swipe to go back" functionality in
| Chrome and Edge?
| lucideer wrote:
| wth
|
| 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???
| traveler01 wrote:
| I don't now, people get insane when using JavaScript based
| frontends...
| dang wrote:
| " _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._"
|
| https://news.ycombinator.com/newsguidelines.html
| henriquez wrote:
| not to mention the page is completely broken (no content) with
| JavaScript disabled.
|
| The article still brings up good advice, for whatever it's
| worth.
| astura wrote:
| 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.
| slx26 wrote:
| 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.
| tomlagier wrote:
| This is a very good summary of the state of the front
| end.
| cglong wrote:
| I've considered doing this to make inlining of interactive
| components easier. Agree though that it seems like
| overkill.
| CivBase wrote:
| 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.
| coldpie wrote:
| 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.
| kevincox wrote:
| 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")
| Nadya wrote:
| 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.
|
| [1] https://ux.stackexchange.com/questions/36017/is-the-
| browser-...
| [deleted]
| greggturkington wrote:
| Much of the text color contrast is too low to pass WCAG 2 AA as
| well
| praestigiare wrote:
| 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.
| happymellon wrote:
| It is now. But we had broken SVG for so long, and people have
| long memories, and Google search has an even longer history.
|
| See also Linux users distrust of Microsoft.
| pluc wrote:
| Just tell your browser to ignore them, life does go on.
| system2 wrote:
| The concern is not the HN users.
| car wrote:
| Multicolor, gradients and animation are more reasons to use SVG.
| Pretty amazing what's doable nowadays.
|
| Edit: examples here [1]
|
| [1] https://www.hongkiat.com/blog/svg-animations/
| tablespoon wrote:
| > 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.
| flowerlad wrote:
| 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.
| ascom wrote:
| 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.
| kragen wrote:
| 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?
| Hackbraten wrote:
| 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?
| Klonoar wrote:
| 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.
| Ensorceled wrote:
| 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,
| jmull wrote:
| 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.)
| ourcat wrote:
| Useful for supporting `font-size` too, when inline with text
| (eg: for a label/button with an icon).
| kevincox wrote:
| You can do this by sizing via `em` which is based on the text
| size.
| pippy wrote:
| 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'.
| exabrial wrote:
| > Stop Using Icon Fonts
|
| Replaces it with a ton of Javascript, NPM packages, obscure
| languages, frameworks that will be out of popularity with
| 6months.
|
| Granted, SVG IS the way to go, but the recommendation above is
| ridiculous.
| zajio1am wrote:
| Icon fonts do not work for users that have browser configured to
| use specified system fonts. Either unrelated characters are
| displayed or browser tries to substitute a different font
| covering uncode private range.
| nayuki wrote:
| > 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.
| pwinnski wrote:
| "fully supported" and "across all major browsers" don't seem to
| be in conflict with partial support from various vendors in
| prior years.
| mod50ack wrote:
| Indeed, this didn't pass the sniff test --- SVG on the web was
| well-supported a year or two ago, too.
| dr-detroit wrote:
| 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.
| pseudosavant wrote:
| 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.
|
| 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...
| jackson1442 wrote:
| IBM has some nice ones in Carbon as well:
| https://www.carbondesignsystem.com/guidelines/icons/library/
| pseudosavant wrote:
| That looks like a great icon set. Flexible Apache 2.0
| license.
| system2 wrote:
| I use FA for most clients. Is there a problem with FA icon
| scaling?
| pseudosavant wrote:
| 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.
|
| https://developer.mozilla.org/en-
| US/docs/Web/SVG/Attribute/v...
| https://developer.mozilla.org/en-
| US/docs/Web/SVG/Attribute/p...
| villasv wrote:
| > [Icon Fonts] Treated like text > [SVGs] They are semantically
| image elements
|
| Sometimes that's exactly the opposite of what I want. What's
| next, "Stop using emoji, use SVG instead"?
| madeofpalk wrote:
| _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.
| villasv wrote:
| I'm aware. I just don't care. UI is not even what I'm
| interested in using emojis for.
___________________________________________________________________
(page generated 2021-02-24 23:02 UTC)