Use of the <i> element in the wild

[LJWatson]

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

In reality the <i> element most often seems to be used to represent icons or emojis, which does not seem to fall strictly into this definition. Can we update this definition to reflect reality better?

[chaals]

Hmm. In my anecdotal experience I generally come across it being used as described. We probably need more data to make a rational decision here...

[stevefaulkner]

did a quick grep of the latest webdev data dump (from january this year.
https://dl.dropboxusercontent.com/u/377471/i.html

[ZoeBijl]

Bootstrap now uses span elements in its documentation for icons.

FontAwesome uses i elements in its documentation.

[LJWatson]

Some back/packet analysis of the data @stevefaulkner grabbed...

There are 16,878 instances of the <i> element across that sample of 2,048 html.txt files.

8,198 instances use class names that include sprite", "icon", "ico", "glyph", "glyphicon", "fa-", ss-", fp-" or variations on those themes, or are entirely empty.

That number is likely to be on the conservative side because the search did not include <i> elements containing Unicode characters. Constructing a search that reliably differentiates emoji characters from other Unicode character use would take considerable time and effort.

[chaals]

OK, so the usage is common. Some of it might be treating stuff as a span that uses fewer characters to write.

I think that using icons or emoji fits into the "in a different voice or mood" idea. This ignores the technical grammar meaning of those terms, but it seems the text itself uses them in their common meaning rather than as terms of art for grammar. Which is itself unfortunate.

The element is not used for e.g. text in the imperative or passive voice, nor in the subjunctive mood.

Do you have a proposal?

[ianthedev]

FontAwesome uses i elements in its documentation.

@MichielBijl FontAwesome in its examples page and single icon page also recommends that aria-hidden="true" be used to improve web accessibility.

[cheshrkat]

In the broader lifespan of the element, the usage of <i> for icons seems like a minor trend magnified by a couple of libraries rather than being a choice made by a large number of authors.

Using it for emoji fits with the longer-term usage to enclose an alternative language - the same emoji used across sites is identifiably the same thing, even if the combination and context changes.

I don't think general iconography fits the usage though. While the glyphs of popular icon libraries are re-used a lot, they are not used by authors according to a shared lexicon nor are they synced in a reliable manner between different libraries. Some glyphs have strong consensus, but others vary wildly.

[iandevlin]

I agree with @cheshrkat here, the trend was due to library usage and not due to a majority of developers making an informed choice on which element to use. Twitter Bootstrap was the main culprit, but they have since moved to using span (as mentioned above).

I also think that using i for icons does not fit with the specification's definition and should not be changed.

[AmeliaBR]

I agree with @chaals (#732 (comment)) that inline icons and emoji fit with the "separate voice or mood" semantic.

If I was reading aloud a text that included an emoji, I would pause and emphasize it to indicate that I've switched from reading words to describing an icon. I think that is consistent with the way I would read italic text used to set off a foreign language phrase, or a term being used as a term, or poetic allusions, or all the other uses of <i>.

Now, if an icon is completely stand-alone (not part of a sentence), then it would be better to properly mark it up as an image. But if the image is created via text content or background images, the relevant markup is role="img", and I'm not sure whether it really matters too much at that point whether the base element is i or span.

Regardless: if marking up inline icons is an established use of the i element, it wouldn't hurt to clearly say so in the definition, with an example. And the re-write could also clear up what "voice or mood" means, since as Chaals notes, those words have specific technical meaning in English grammar that is separate from the semantics being discussed.

[aardrian]

If the font libraries that are primarily responsible for this are moving away from using <i>, does it much matter if we just leave it as is? One could argue (me if pressed, though I would rather not) that an icon or emoji generally is an "idiomatic phrase from another language" and so is valid use.

[russmaxdesign]

Keep as is

[patrickhlauke]

Leave definition as is. Misuse of <i> for "icon" is/was a pervasive perversion (tm) of semantic markup. No point in retconning it and giving it some sort of validity.

The common rationalisation I see most often about why people/libraries use <i> is "it's shorter...PERF!". trying to retrospectively argue for any deeper semantic reasoning for why authors may have used this ("an icon is a different voice...") is pointless, IMO.

[SelenIT]

I wonder if there is any possibility to gather the stats of usage of <i> for "alternate voice or mood" on purpose, not erroneously instead of <em> because of wrongly set up visual authoring tools etc.? Maybe it would make sense to change the definition to something like "text intended for alternate presentation, usually italicisation or visual replacement with image" as more realistic?

[chaals]

@patrickhlauke opined:

trying to retrospectively argue for any deeper semantic reasoning for why authors may have used this ("an icon is a different voice...") is pointless, IMO.

I agree that span is marginally better. I would also agree that we should consider a change, if the usage was egregious. But to be honest, I think it's probably not perfect, but good enough with what we have, and I really don't see the need for a change to the spec.

[alastc]

Unless user-agents (primarily screenreaders) consistently voiced i, em, b, and strong differently, I don't see much benefit to updating the spec on this point.

[SelenIT]

Apart from <i> being shorter (and therefore marginally faster to load/parse) than <span>, it is also easier to memorize as kind of abbreviation for 'icon'. It might look like even more natural interpretation for people who hasn't worked with HTML3-4 and doesn't know the presentational history of this tag.

[LJWatson]

@SelenIT has a point. In the data analysis mentioned previously, a chunk of the instances of <i> were used as hooks for sprites (at least had class="sprite"). AFAIK that is not a library driven use - but it does suggest people are thinking of <i> as "icon" rather than "italic" (or whatever monicker applies to it these days).

[patrickhlauke]

it does suggest people are thinking of <i> as "icon"

I'd say it's not that they're "thinking" that, they're just post-rationalising it. people also "think" that <div class="heading1"> is perfectly fine for headings, but i don't see that being written anywhere in the spec... ;)

[russmaxdesign]

I'd say it's not that they're "thinking" that...

Most are not thinking about semantics, accessibility etc at all. They are using the library because it solves a problem. And that would happen if some of these libraries suddenly changed their mind and used <span> instead of <i> elements, the spec would have changed for no good reason.

[SelenIT]

IMO, divs for headings and i for icons are not the same case. Purely non-semantic divs are used in purely presentational approach, while people who choose i for icons still take semantics into account, even in form of post-rationalisation. And one of the reasons for it is that those people know that in HTML5 the i element has some semantics, but the current definition is too vague and not very helpful in defining it. The semantic difference between i and span is too subtle from the developer's perspective. On the other hand, i is really shorter, and its name fits one of the common use cases very well (even if it's just coincidence). Are there any practical reasons for the library authors to switch from i to less convenient span, apart from the 'semantic purity' per the existing spec?

[cheshrkat]

I don't agree that span is materially less convenient than i. The only time I can see that there would be a measurable difference is someone typing the element, longhand, from memory... which I don't believe is the majority use case. With libraries, most consumers will be either copy&pasting the markup from docs, or using a template/abstraction which masks the element anyway.

In terms of semantics, the two examples given (bootstrap and font awesome) both go into some detail about how the accessibility of icons should be handled. The solutions relate to ARIA attributes, alternative text and how CSS-generated content is announced. I didn't see any reference to the actual element providing meaning (naturally I could have missed something). The point is I don't think they strongly support a need to alter the HTML spec.

Another thing to consider here is if we ARE trying to follow the trends in libraries, I've seen a lot of people pushing to use SVG instead of span+font now that support is improving... which would bypass this situation entirely.

[stevefaulkner]

In my opinion, the <i> element is an element in search of a meaning, like <b> and a few others. They should have been obsoleted as were other presentational elements. Instead they were given mirage like semantic meaning, which when usage is looked at doesn't wash.

anyway...

Current definition:

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.

if we were to change 'a span of text' to content and 'a different quality of text' to a different quality of content, then it would be fitting to do the following as an example:

<i>LOL</i>
<i><img src="lol.png" alt="LOL"></i>
<i class="lol-icon"></i>

It should be noted that while the current definition appears to confine the content to text: its content model allows any of the following:

a abbr area (if it is a descendant of a map element) audio b bdi bdo br button canvas cite code datalist del dfn em embed i iframe img input ins kbd label link (if it is allowed in the body) map mark mathml math meter noscript object output picture progress q ruby s samp script select small span strong sub sup svg svg template textarea time u var video wbr text

[Acts7]

Leave it as it.
People that will use it - use it. Those that do are less concerned about semantics and more about speed. In cases where a framework is used, it is for ease and speed of build. And in that case is much faster to type than . Why change the rules to fit the sample?

[iandevlin]

In my opinion, the <i> element is an element in search of a meaning, like <b> and a few others. They should have been obsoleted as were other presentational elements. Instead they were given mirage like semantic meaning, which when usage is looked at doesn't wash.

In that case, allowing <i> to be used as an icon will make it even less likely that <i> will eventually disappear from the spec.

Also, since icons are graphical, how can an alternative for them be provided for in the same way that <img> has the alt attribute? I appreciated that not all icons will require a non-graphical equivalent, but when they do, there is no "ideal" way of providing it via the <i> tag (other than perhaps adding a graphically hidden <span> within the <i>)

As for the reason "because it's shorter" from some people, often the very same people use BEM, and end up with multiple, long class names making the excuse moot.

I strongly think we should leave it as it is.

[aardrian]

Some assumptions are being made that anyone who uses <i> knows it has a meaning and just maybe knows or knew what it was. I disagree but I also think it is mostly moot.

Leave as is. No change to definition needed. The current definition can be argued to already fit better than the arguments that <i> was the right element for sprites and icons because of reasons (character count, the letter, whatever).

As for the accessibility Ian mentions, off-screen / visually hidden text already provides that text equivalent (when included, like an alt). Again, providing the library and demo makers remind devs to include it and those devs do so.

[nerone]

Icon usually is a decorative graphic and semantically neutral element (without implicit native role) like <span> should be used.
If icon is content, then appropriate graphics element should be used (e.g. <img>, <svg>) with a text alternative to describe the information that is displayed visually.

<i> does not stand for "icon". Leave it as it is.

[LJWatson]

Closing with consensus that the definition can be left "as is".