I don't think there's anything wrong with assuming people are running a graphical browser.

We're at the point where, depending on your exact industry/usecase, earlier IE versions are less than 1% for a lot of 'mainstream' sites. The amount of people who aren't able to render a custom web font, let alone a non-graphical browser, would be in the extreme minority.

IMHO, that is not a use case that's not worth worrying about.

Well, of course there are those who are weird, like Mr. Stallman:

> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see git://git.gnu.org /womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it (using konqueror, which won't fetch from other sites in such a situation).

https://stallman.org/stallman-computing.html

But there are other groups of people for which this is relevant: Blind or otherwise visually impaired people depending on screen readers or similar. Those don't have a good choice and abusing text there makes the experience unbearable.

I received an accessibility report for a website made by a big reputable accessibility agency, and they had no problem with us using Font Awesome. It's ignored by screen readers, unless you put a title attribute, which you can do if the icon is more than decorative.

That said, I use NoScript with 'Forbid Font-Face' enabled, so a lot of the time I see squiggles instead of icons. But that's my choice, and I'm almost certainly in the minority, so I'm not angry about sites that use fonts instead. SVG probably will come to replace font icons, but for now, they've been really helpful for a lot of small sites.

Stallman isn't a group of people though, he's one very very extreme case that frankly doesn't matter in the big picture of web accessibility and it probably isn't going to hurt anyone if he can't see every bit of your site as perfectly as everyone else.

I don't understand this.

Most icon fonts use PUA codepoints to avoid issues with screen readers. If you're not going to use icon fonts, what are you going to use? Images? CSS Backgrounds? Inline SVGs?

Screen readers can't read any of them. Thankfully there are ways to make all of these accessible, with things like ARIA attributes.

We can use SVG images/sprites with an alt="" attribute.

While that is probably 'better' how in practice does it matter. SVG (esp with sprints) vs icon font are basically the same. Both are ways of embedding multiple vector images in one resource that you attribute meaning to using `title` attributes. In practice they will behave pretty much exactly the same.

There are still some issues with that – for example, it's easier to change attributes like text colour when using an icon font, something that becomes substantially more awkward with SVG. This is appropriate for things like buttons and other elements with hover effects.

Just inherit the colour, in the spritesheet use:

  fill: currentColor;

Same with stroke. Works great.

If you must use a magic font, why not use ligatures to replace words?

Somehow most web developers care a lot more about the ~3% of users that use IE 10 or lower than about the ~4% of users that are legally blind and can't use a graphical browser.

I can only hope that his is mostly ignorance.

> Somehow most web developers care a lot more about the ~3% of users that use IE 10 or lower than about the ~4% of users that are legally blind and can't use a graphical browser.

It's only correct to infer that web developers care less if the cost of supporting either is the same.

(Also many legally blind people use graphical browsers; legally blind is not the same as "unable to see anything").

I readily confess I don't know many legally blind users, but the handful I do know all use graphical browsers with screen readers.

Is that not typical?

(That said, if you're using webfonts for icons you should be using the unicode Private Use Area.)

Well there's also the fact that 100% of those 3% are definitely online loading website while the same can't be said for the 4% legally blind.

I tend to disregard the entire <7% (assuming overlap).

I like the idea of making a commitment to accessibility, simplicity, and universality.

<svg> may not work for people like me who disable javascript. It introduces potential security issues (in my understanding). It's complex, meaning it's hard to guess how it will interact with tools that want to access the page (like for visually impaired or for other purposes).

I don't like these things, so I'll try to make a stand and not use it. Of course, I only have that luxury because I don't make websites for a living.

> "<svg> may not work for people like me who disable javascript. It introduces potential security issues"

SVG works for me with JS disabled (using Firefox on OS-X). Do you have any pointers on when/why SVG wouldn't work without JS?

I looked into it further and I think I'm mostly wrong about <svg>. You can embed javascript into it, but if you don't, then as far as I can tell it works fine for me. Sorry!

That makes sense…and I think that's where the potential security vulnerability comes into play - if you allow untrusted users to upload SVGs, then they could potentially be uploading javascript to your site, offering a vector for XSS. As far as I can tell, adding your own SVGs to your site doesn't open up any novel security issues.

svg is no more accessible or simple than an icon font.

You have the same resources and APIs (can you call HTML attributes an 'API'?) available to make the usage of icon fonts friendly for screen readers.

SVG is considered more accessible because it's an image, not text. 'f' doesn't mean aeroplane (even though it looks like an aeroplane in a 2010-style graphical font) but img alt="plane" does.

That's an argument for not using an icon font which remaps normal characters but the most common ones use private-use characters which are ignored by screen readers. In which case are these not equally accessible?

    <i class="fa fa-globe" aria-label="Picture of a globe"></i>
    <img svg="globe.svg" alt="Picture of a globe">

Accessibility is more about process and testing than any particular technology since they all can be done poorly.

Apologies if this is a massively ignorant question, but isn't the <i> tag an inline text span? In which case, isn't it wrong to have it be empty?

    The i element represents a span of text offset from its
    surrounding content without conveying any extra emphasis or
    importance, and for which the conventional typographic
    presentation is italic text; for example, a taxonomic
    designation, a technical term, an idiomatic phrase from
    another language, a thought, or a ship name.

http://www.w3.org/TR/html-markup/i.html

Using it without text strikes me as a hack, and one that is hostile to usability, among other problems. I understand why it would work, but it's abusing the technology as far as I can tell.

Since I've seen this in at least two comments now, can somebody explain to me why it's not considered an anti-pattern in 2016?

[edit: formatting]

I would agree with that – it's a convention which the FontAwesome project uses for reasons I haven't looked into (I'm assuming not wanting to type 6 more characters).

I use <span> on all of my projects.

Yes but shouldn't a <span> also always have content? Am I missing something here?

There's nothing that requires it to have content, no. Absent other styles, an empty <span> would be invisible and have no effect though.

It has text content, merely inserted by CSS `content` instead of living in the HTML itself.

Your mailbox icon 'ſ' will be read aloud as 'latin small letter long s' or 'esss' if you're lucky.

But I can't really tell if you're actually saying that the ability for web pages to be read aloud coherently is 'a use case that's not worth worrying about'.

Attributes can be added to make screen readers ignore certain html elements like icons for exactly this reason.

    <i class="fa fa-pizza" aria-hidden="true"></i>

This is a good point. There is additionally ligatures used by the Google material icons. These let you put an actual textual representation of the icon and only replace it with an icon if the browser supports it: http://google.github.io/material-design-icons/

Why FA insists on abusing the Italics tag (repurposing it as "Icon") instead of leveraging the appropriate <span> is...specious at best.

The <i> tag in modern HTML does not mean "italics", though the examples given to illustrate its new semantics are all things conventionally set in italics.

"The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts." [0]

Its use for text-as-icon is arguably, despite obviously not being a use classically set in italics, within the defined semantics of the <i> tag.

EDIT: Though FAs use isn't actually text-as-icon, it uses empty tag as an icon. That's not consistent with the semantics of the tag.

[0] https://html.spec.whatwg.org/multipage/semantics.html#the-i-...

<i> is not the "Italics tag":

In earlier versions of the HTML specification, the <i> tag was merely a presentational element used to display text in italics, much like the <b> tag was used to display text in bold letters. This is no longer true, as these tags now define semantics rather than typographic appearance.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/i

You can use whatever <element> you want with FA. It's the class names that are important.

Or, y'know, one could just use an image instead of abusing HTML:

    <img src="pizza.png" alt="" />

Except that would require multiple web requests unless you were using an image sprite. Font Awesome and Glyphicons solve this by using a font file or sprite.

I do wish they didn't overwrite the traditional <i> tag, but I guess we're supposed to be using <em> for semantic HTML.

> Except that would require multiple web requests unless you were using an image sprite.

So … it can be made to work with a single request then.

Yup, and Glyphicons does that.

Unless you need to think about accessibility, which is a usecase many need to deal with.

Hear, hear. Web fonts are fine when used as fonts. They are not fine when used as images (unless the image corresponds to an actual Unicode character).

From a design perspective font icons are a very good solution when compared to sprite sheets or SVG. They are scalable, they load a single time, and contain nearly every iconic type of symbol you could want in a UI. That's not an anti-pattern.

> They are scalable, they load a single time, and contain nearly every iconic type of symbol you could want in a UI.

An SVG is scalable, cacheable and can contain any vector art you could wish for. And it doesn't use characters to represent images.

Are you aware of any of the recent actions of the Unicode consortium? You can start here. http://www.unicode.org/emoji/charts/emoji-released.html

Emoji are almost exclusively used embedded in regular text. Emoji work similar to our regular alphabet, only that they are typically used to express emotions and abstract concepts that are harder to express in regular words. Since we have regular text and emojis used in the same context (and often as part of the same sentence) it makes sense for unicode to support both.

This is fundamentally different from icon fonts. twitter icon or mailbox icon are not meant to be used inside of text, so they have no business in fonts.

Compounding mistakes doesn't make it right.

> An SVG is scalable

But fonts have hinting, so they look nice at low sizes and low resolutions. This is something that SVG is still missing.

GitHub recently switched to SVG and claimed the opposite: https://github.com/blog/2112-delivering-octicons-with-svg

Was their font just poorly designed?

That could be the case. Also, it may depend on the particular browser they used.

Web Fonts abuse HTML: they take text and give it a different meaning. The letter 'a' does not indicate a daisy with pink petals; it is the letter 'a,' the English word 'a' and so forth.

Think for a moment about what Web Font users do: sprinkle garbage throughout their pages; run JavaScript to dynamically load stuff (and possible destroy the privacy and/or security of the client); dynamically update the page — all when a simple, semantic image could have done the trick.

It's kinda insane, like rendering a page by loading JavaScript to slowly append characters to the DOM.

That's just inaccurate – AFAIK all modern icon fonts make use of the Unicode PUA, which is specifically intended for this sort of application. The characters used have no semantic meaning beyond what the application, including its fonts, intend.

> That's just inaccurate – AFAIK all modern icon fonts make use of the Unicode PUA, which is specifically intended for this sort of application.

Why, then, does one see all sorts of strange characters on web pages which use icon fonts?

Problem is we should be using ligatures not single letters. Guilty of the error as well. But it can be done e.g. http://webdesign.tutsplus.com/articles/your-logo-as-a-web-fo...

aria-hidden="true"

You'd rather see SVG XML?

Some day we should deprecate browsing the web with HTML 1.0 tools, apart from web crawlers who know what they are doing. Sticking with that is akin to sticking to horses on the road: It has its advantages, but you can require everyone to build horse-friendly roads for you in 2016. At least horse riders aren't vocal about their bad experience.

Screen readers, scrapers/crawlers, future readers (will your page be readable in 1000 years?), archiving...

> will your page be readable in 1000 years?

In entire fairness, the evolution of language may well make this impossible, or nearly so, regardless of how you structure your content. It's not unreasonable to shoot for 100 years, though.

> In entire fairness, the evolution of language may well make this impossible, or nearly so, regardless of how you structure your content.

Are you aware that we're completely able to read documents from thousands of years ago? C.f. Caesar's Bellum Gallicum, which is about 2,050 years old.

You're absolutely right, of course. I'm not even sure why I thought that made sense when I said it; thanks for catching the oversight.

Thank you for responding so nicely!

As to why you wrote it — heh, we've all been there.