Stop Using Icon Fonts | Hacker News Reader

Stop Using Icon Fonts

irigoyen.dev

150 pointsfeross132 comments

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.

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.

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.

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...

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

Is it possible to include the defs in perhaps a <link>, so they can be downloaded once and cached across all pages?

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.

This approach prevents CSS styling though since SVG referenced this way has its independent DOM and is not part of the current page DOM.

Yes, in that sense it's more like CSS sprites, just a bit easier to use.

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

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.

I use this approach all the time.

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,

> we used font icons EVERYWHERE.

How does that work with people who have "use my fonts" ticked for whatever reason? Is there some kind of override that applies?

What is "use my fonts"? I've never heard of such a thing.

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?

Useful for supporting `font-size` too, when inline with text (eg: for a label/button with an icon).

You can do this by sizing via `em` which is based on the text size.

That's right. `em`, `rem` or `px`.

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'.

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.

> 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.

"fully supported" and "across all major browsers" don't seem to be in conflict with partial support from various vendors in prior years.

Right, but the argument seems to be that "partial support" was good enough for this use case.

Indeed, this didn't pass the sniff test --- SVG on the web was well-supported a year or two ago, too.

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.

> 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.

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.

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?

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/

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...

IBM has some nice ones in Carbon as well: https://www.carbondesignsystem.com/guidelines/icons/library/

That looks like a great icon set. Flexible Apache 2.0 license.

I use FA for most clients. Is there a problem with FA icon scaling?

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...

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.

If IE6's longevity is any indication, you may need to support users on older browsers for all of time.

Considering Microsoft doesn't even support ie11 any more, no one else should.

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.

So basically you're wasting your money supporting those outdated browsers because someone refused to waste their money upgrading their browsers?

How about security?

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.

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.

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?

Many places do because they have people like yourself thinking they should. But really nobody would notice if you dropped support.

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.

They still ship it for intranet websites compatibility and for Silverlight.

I think the plan is for Edge to one day have a way to display pages in IE compatibility mode.

If IE's (any version) longevity is any indication, you don't. Use feature detection, not user agent.

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.

Yeaaaahhhh... Those computers are still in use at some enterprises. and by some home users who can't/won't upgrade

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.

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.

Windows 2000 Forever!

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.

Ah, all these locations where security is an afterthought

> Or in healthcare.

A healthcare provider using a browser that's too old to have SVG support is a patient data leak waiting to happen.

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."

You can use SVG image fallback [1] in older browsers.

[1] https://css-tricks.com/a-complete-guide-to-svg-fallbacks/

Much better writeup of the a11y concerns here:

https://github.blog/2016-02-22-delivering-octicons-with-svg/

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...                                                                    

       © 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.

> Somebody ask Foteos why it does that

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.

Fair point. Please don't pester Foteos.

I'm against all icon fonts except icon fonts that literally only implement Unicode icon codepoints. That use-case is still technically accessible.

> 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?

> [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"?

_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.

I'm aware. I just don't care. UI is not even what I'm interested in using emojis for.

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.

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]!

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.

You made me curious. The initial SVG release was in 2001, so SVG is old enough to vote now :-D

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?

Bootstrap? https://icons.getbootstrap.com

IIRC, there was an aggregator/search engine for SVG icons posted on here a couple of weeks ago also.

I think of icon fonts as being the SVG equivalent to image sprites. One download instead of dozens of tiny ones. This can improve performance.

Of course, if you only use a few icons from a huge font, thats bad. SVG is probably better for a few icons and fonts better for when you use many. Subsetting for fonts and lazy loading for images help too.

Both are valid solutions. Optimize and test for your use case.

You can also have SVG sprite sheets if you use the `use` tag.

I use icon fonts in my JavaFX application because JavaFX doesn't support SVG (facepalm).

https://stackoverflow.com/questions/12436274/svg-image-in-ja...

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.

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!

Icon fonts seem like a good idea for non-web/native apps. Apple rolled out SF Symbols as a standard icon font across all of their operating systems. As I understand it, a big advantage is that the accessibility subsystems automatically handle SF Symbols, and they also automatically adjust to dark mode and other display settings (and presumably any changes or adjustments in UI design over time.)

Of course it's a bad idea to use SF Symbols in web pages since the font won't be available on non-Apple devices.

> 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.

That's because he's using React, i'm using an svg sprite sheet in a simple html page, with native <svg> tag and works like a charm. If your svg set is small, you can even inline it: you lose cache, but you save a request so you can choose your tradeoff.

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

It's a bit funny that the SVG logo image is a PNG.

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/

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.

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:

<svg id='svgID12345'><path d="..."/></svg>

<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-...

<use xlink> will accomplish what you want to do.

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.

Hijacking my ability to get back in history of my browser by a swipe makes every argument about usability a straw man for me. Don't do that.

Wait until this guy learns about typesetters' ornaments, box characters, TeX, and emojis.

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.

What's bad about Typekit?

It requires JavaScript and, in my experience, it can be unnecessarily slow.

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.

Just tell your browser to ignore them, life does go on.

The concern is not the HN users.

Reading about accessibility on a website that uses JavaScript and <button>s for navigation is a tad ironic.

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.

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.

[1] https://ux.stackexchange.com/questions/36017/is-the-browser-...

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.

I've considered doing this to make inlining of interactive components easier. Agree though that it seems like overkill.

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.

This is a very good summary of the state of the front end.

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.

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.

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???

I don't now, people get insane when using JavaScript based frontends...

It also seems to break the "swipe to go back" functionality in Chrome and Edge?

Much of the text color contrast is too low to pass WCAG 2 AA as well

"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

Using these argument we all should write code in Rust for its performance and safety. But people keeps using JavaScript because it's very approachable and good enough.

Let's go to icon font. All I do is include a font and use it, I can set color and style it.

It's has 99% features that *I* need, I don't need advanced features that SVG offers and I don't like to embed SVG directly into our HTML code or has separate SVG files. Icon font is a great hack to me.

Reply on news.ycombinator.com