Icons are often used in interface design to convey a concept in a small pictogram, especially in areas where describing the idea in words would take up much more room than a single character. In a perfect world, icons would be designed alongside the typography as best practices indicate to include both an icon and related text together. This is clear any ambiguity that may occur with the image and keep a consistent style.

Icons are also tedious to create and difficult to keep consistent without clear guidelines. Things become more challenging when icons are meant to be presented with states, such as filled stars for ratings or battery level indicators.

One of the most robust icon systems is Google’s Material Icons. This library is special for a few reasons:

  • The library is delivered as a variable font, where each axis can affect different icon attributes such as fill and weight. This allows for the icon set to be aligned to the related typography more than most other icon sets.
  • An icon can be rendered using a ligature, so providing the text chevron_right to an element with the icon styles will render an icon in place of the text. The use of chevron_right over dropdown_arrow is done to describe the shape over the usage as it might be used for multiple reasons.

Creating a system like this takes an incredible amount of patience and planning to execute. However, there is a serious drawback to this approach which is performance. For this system to work, the font with all of this data must be served to the client. While you might be able to prepare a subset of the font, specifically one that has the metrics curated, all the ligature combinations must be served to render.

Another issue is reference, as people refer to these symbols with different words. As mentioned above, a chevron could have various names, which may also have variations for orientation, roundness, and other stylistic choices. Being unable to find the intended icon can lead to the duplication of assets.

In most performant systems serving icons, assets are rendered as needed so that an entire library’s worth of assets isn’t served for only a few icons. To do this requires some templating framework that allows for the ability to reference an HTML snippet to be rendered as an icon. Even this isn’t perfect, as there are techniques to render SVGs by referencing a single sprite sheet in the page which reduces nodes in the DOM tree. This requires that files be analyzed for SVGs to determine what icons should be placed in the single sprite sheet. A system such as this would also need to catch icons added after hydration as well to be added to the sheet over the page lifecycle.

In an attempt to avoid templating, we can reference external SVGs which won’t request the same asset twice. This is still client-side which will have the same downfalls as the web component approach. Additionally, these SVGs cannot be targeted with styles across documents so using fill=currentColor won’t work. Also, URLs to assets can be easily mistyped causing failures and updates to the library can break against hard-coded SVG URLs.

The closest option here is a combination of web components and some registration scripting to help reduce duplication. This is still client-side dependent and bad network connections and JavaScript dependencies blocking the main thread could cause icons to not appear making some UI elements unusable.


The first major problem of creating a cohesive icon system to match selected typography could be solved with artificial intelligence. An input could be a chosen font and a process could determine all of the defining features of the font to create a set of guidelines that draws icons as needed based on the font properties. This will aim to match typography to iconography as needed on a per-font basis.

To determine which icons to support, research could be done to discover what universal icons might be to inform this work. Each icon could have a confidence level attached to inform designers how likely someone might be confused about the meaning; passively recommending another treatment instead of an icon.

Identifying an icon in a library could be done by image over recalling a name or use.

As for delivery, imagine system icons like system fonts so that as the desired assets are loading, placeholders could be shown as needed. Perhaps a Unicode character could act as a standard for this default.

<ds-icon aria-hidden>×</ds-icon>

In the above, we place the “Multiplication sign” Unicode character as the required fallback.1 Internally, the <ds-icon/> could read the slot value and complete a lookup for the custom asset based on the theme or fonts on the page then do a visual update. If an icon is not found, no update occurs and only displays the fallback.


  1. In reality, we would consider the “Cancellation X” instead, however support for the character is limited.