Font icons vs inline svg - 2016

SVG vs. Font
Mohammad Bayat
Ok.Bayat@Hotmail.com

If you're building an icon system for a site,
you have some options. If you know the
icons need to be raster images, then you'll
likely be using CSS sprites. If the icons will
be vector images (much more common
these days), you have some options. Two
of those options are using inline SVG and
using icon fonts.
Let's compare.

Icons are
Vector*
resizable up and down without losing
quality, extra sharp on retina displays,
and small file size among them
*

Icons are Vector
Icon Font Inline SVG
Browsers consider it text, so the icons are anti-
aliased as such. Can lead to icons not being as
sharp as you might expect.
Straight up vector

CSS Control
You can control the size (via font-size), color,
shadows, rotation, etc. via CSS.
You have all the same CSS control as with a font,
but better, because you can 1) control individual
parts of a multi-part icon and 2) use SVG-specific
CSS like stroke properties.

CSS Control
Icon Font
<i class="fa fa-address-book" aria-hidden="true">
::befote
</i>
.fa-address-book:before {
content: "f2b9";
}
.fontawesome-icon-list .fa-hover a .fa {
font: normal normal normal 14px/1 FontAwesome;
font-size: 14px;
color: #222;
line-height: 32px;
white-space: nowrap;
text-rendering: auto;
-webkit-font-smoothing: antialiased;
text-align: right;
-moz-ox-font-smoothing: grayscale;
display: inline-block;
width: 32px;
margin-right: 10px;
...
}

CSS Control
Inline SVG
<svg viewBox="0 0 480 480">
<g>
<path d="M460.33,146.509c-12.187-26.311-29.332-50.578-50.961 ..."></path>
<path d="M391.68,267.909H219.717V67.355c0.345-1.699,0.253-3. ..."></path>
...
</g>
...
</svg>
svg {
fill: #c8cac8;
transition: transform ease-in 0.2s;
}
path[Attributes Style] {
d: path('M460.33,146.509c-12.187-26.311-29.332-50.578-50.961 ... ‘)
stroke: green;
stroke-width: 4;
fill: yellow;
...
}

Positioning
It can be frustrating to position a font icon. The
icons are inserted via pseudo element, and it
depends on line-height, vertical-align, letter-
spacing, word-spacing, how the font glyph is
designed (does it naturally have space around it?
does it have kerning information?). Then the
pseudo elements display type affects if those
properties have an effect or not.
SVG just is the size that it is.
See how the pseudo element box isn't quite
where the glyph actually is.
The SVG box is the size of the SVG.

Weird Failures
An icon font might fail because 1) it's being
loaded cross-domain without the proper CORS
headers and Firefox doesn't like that 2) for any
reason, the font file fails to load (network hiccup,
server failure, etc) 3) There is some weird
Chrome bug that dumps the @font-face and
shows a fallback font instead 4) Surprising
browserdoesn't support @font-face.
Font failures are pretty common for a variety of
reasons. Plus, if you try and do something clever
like map icons to "Private Use Area" of unicode
and the font fails, it may do something really
weird like show an unexpected emoji, because
the environment you're in uses that same area
for emoji. Or that emoji might even overrule
your glyphs!
Inline SVG is right in the document. If the
browser supports it, it displays it.

Forced Failures
• Proxy browsers like Opera Mini or UC
Browser don't support @font-face at all,
even though they sometimes report that
they do. So even if you try to feature detect,
it may fail.
• Some people force their own fonts over
yours, for example in a user stylesheet or a
browser extension specifically for applying
custom styles. For instance, one that applies
a font better for people with dyslexia. (More
on the issues with icon font
accessibility from Seren D.)
• Blocking technology can either automatically
or offer to block custom fonts. (reference)
Even those proxy browsers support SVG. Blockers
don't care about SVG.

Ad blocker offering to totally block
custom fonts.
Forcing a different font upon a page can destroy
an icon font system.

Semantics
To use responsibly, you're injecting the icon via a
pseudo element on an (empty) <span>. Either
bad or no semantics, depending on how you feel
about that kind of thing.
Icons are little images. The semantics
of <svg> says "I'm an image." Seems better to
me.

Accessibility
You have to be quite careful with icon fonts to
make sure you do it in an accessible way. You
should basically do everything in this article.
You're always fighting to make sure that the icon
itself isn't read (but something else is) and that
hard-to-detect fail states are handled.
I'm no expert, but research suggests using the
proper combination of elements and attributes
(<title>, <desc>, and aria-labelledby) you can
convey good information across the browser
specturm. Plus no weird fail states.

Ease of Use
Using a pre-created icon font was never
particularly responsible (too many unused
icons). Creating your own icon font was never
overly comfortable. I think the best were Pictos
Server (limited to Pictos icons)
and IcoMoon (free login to save projects).
Fontello has an API I didn't see it used to make a
good build tool.
The inline SVG system is easier because you can
do it all by hand if needed. Or use a tool like
IcoMoon (exports either way). Or use a build
tool.

Browser Support
Very deep. Even IE 6.
Decent, but problems are IE 8- and Android 2.3-.
Fallbacks doable but not wonderful.

Winner
It all comes down to browser support. If you can go IE 9+ / Android 3+, inline SVG is
better at pretty much everything than icon fonts. If you need the deeper browser
support, I feel like an inline SVG fallback would be too big of a pain to be worth it
(maintaining a PNG copy, inserting an additional element to display PNG version, hiding
SVG element... it's weighty).

Thank you!
Mohammad Bayat
Ok.Bayat@Hotmail.com

Font icons vs inline svg - 2016

Recommended

Recommended

More Related Content

Similar to Font icons vs inline svg - 2016

Similar to Font icons vs inline svg - 2016 (20)

Recently uploaded

Recently uploaded (20)

Font icons vs inline svg - 2016