[icon] Semantic HTML element <icon>

#1

This is 1/3 of the original topic of the CSS isn’t used for icons topic. I took the liberty to use SebastianZ’s list of downsides of current implementation.

The idea behind this is to start using proper ways of handling icons instead of other “hackish” ways of doing it. Consider the three main ways of using icons (font-based, svg-based, bitmap-based):

  1. Font-based icons / icon fonts (There’s a great article about why icon fonts are often considered hacks written by Tyler Sticka back in 2015.)
  • Accessibility issues
  • Error prone (because of relying on specific Unicode characters referring to specific icons)
  • Poor fallbacks
  1. SVG icons
  1. Pixel image icons
  • No styling possible
  • Alignment within text difficult
  • Poor display on zooming or high dpi displays

So given these shortcomings I suggest the following. And this particular thread is about the <icon> element.

  • The icon element is by design always NxN in size and will (if not override) obey the size (height) of the font scope it’s part of.
  • Overflow is by design hidden within the icon element.
1 Like
CSS isn't used for icons - it should be
#2

Thanks for taking the time to add extra details!

It would be useful to clarify how your proposal addresses each of the downsides of the other technologies that you list here. While some are clear (e.g. pixel images can’t be styled much), it’s not obvious (at least to me) how it addresses many of the other downsides listed there. For example, from your original post, I didn’t fully understand how it addresses text alignment better than SVG.

#3

The idea is to use the point-size of the font size to compute the N value which is then the height and weight of the <icon> element.

You may over ride this for the element itself by adding the font size attribute to it but the icon is always considered to be of font type in terms of size.

ntg5f
ntg5f.png1050×700 22.6 KB

N is the size of the element, how much of that area that is used for visible figures and such is up to the designer.

#4

Just for the record, there was an icon attribute for the img element in HDML.

I believe the idea behind using the i element for symbol fonts with PUA characters was that the single-letter element name could stand for icon or image instead of italic (or alternate voice or mood, different quality of text, taxonomic designation, technical term, idiomatic phrase, transliteration, thought, ship name).

#5

What would a specific icon element do internally that we can’t achieve today? The Extensible Web Manifesto puts forward that we should primarily be focusing on new low level capabilities, for the most part.

Can you describe what needs to be provided with this element? How would it function? What are the accessibility needs for it to operate? Where in any of this do browsers fail to provide what is required?

The only requirements I see are:

So, size wise we can achieve this many ways currently. And overflow is just one CSS rule. This isn’t much in the way of requirements to define how it should work to discuss. You may want to give creating an explainer a shot to propel the idea forward.

#6

Thanks for the feedback. I will try to explain why we need this instead of hardcoding elements and fonts that cannot be included in a CSS framework. Plus doing it “yourself” using whatever method available isn’t going to help the visually impared stubling upon these elements. They are a big part of our community and icons are glyphs as well as text and emojis. So even if it’s 100% doable with current web techonolgy I don’t see why it should be using these hackish (in the sense of icons) ways… Please see the closely related topics for a good understanding on the HTML element <icon>.

#7

Here’s the other topics:

[icon] Semantic HTML element HTML

[icon] CSS properties relating suggested semantic HTML element CSS

[icon] Layers @rule to create icons based on multiple “keyframes” CSS