The following slide deck was assembled using

reveal.js and actual SVG

by the guy standing and talking right now

• I want to point out that this deck is running in Chrome
• Any animations and examples are actual SVG

• When I'd started, we'd already begun our shared hallucination of a "fixed width" web
• And the browser wars were still in their last throes

Now:

And yet…

Art direction example via Jason Grigsby, frame photo by Stephen Clulow

• Our crisp icons, logos and vector imagery looked fine
• Until we saw it on high-res displays

• My reaction at the time

So we got creative…

• So got creative, in several ways

• We learned to rely on CSS for some simple shapes

• And slightly less simple shapes

• And this is already getting ridiculous
• But by far the most common hack we adopted at the time...

Icon Fonts

• My first exposure was John Hicks' article for 24 ways
• Where I learned the concept of embedding icons as characters in a font

• But GitHub did a lot with their octicons to legitimize the technique

• And especially Font Awesome really took off in popularity

• Start with some SVG files (already weird)
• Assign these to unicode characters (private-use, fallbacks, or let a robot decide)
• A tool compiles into files, most based on PostScript (34 years old)

@font-face {
  font-family: "IconFont";
  src: url("iconfont.eot");
  src: url("iconfont.eot#iefix") format("embedded-opentype"),
    url("iconfont.woff2") format("woff2"),
    url("iconfont.woff") format("woff"),
    url("iconfont.ttf") format("truetype"),
    url("iconfont.svg#iconfontregular") format("svg");
  font-weight: normal;
  font-style: normal;
}
          

• We define this font using a chunk of CSS we don't understand

.icon {
  display: inline-block;
  font: normal normal normal 16px/1 IconFont;
  font-size: inherit;
  text-rendering: auto;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}
          

• We style the eventual icon element, being sure to include whatever proprietary font styles we can to make them display less like fonts and more like icons

.icon-add:before {
  content: "\f000";
}
.icon-arrow-up:before {
  content: "\f001";
}
.icon-arrow-down:before {
  content: "\f002";
}
.icon-arrow-right:before {
  content: "\f003";
}
.icon-arrow-left:before {
  content: "\f004";
}
            

.icon-bookmark:before {
  content: "\f005";
}
.icon-caret:before {
  content: "\f006";
}
.icon-cog:before {
  content: "\f007";
}
.icon-envelope:before {
  content: "\f008";
}
.icon-headphones:before {
  content: "\f009";
}
            

.icon-heart:before {
  content: "\f00a";
}
.icon-home:before {
  content: "\f00b";
}
.icon-power:before {
  content: "\f00c";
}
.icon-search:before {
  content: "\f00d";
}
.icon-x:before {
  content: "\f00e";
}
            

• We then define additional classes
• Human-readable class names (since characters are not)
• Inject unicode characters via a pseudo element

<span class="icon icon-foo"></span>
          

• Only then can we reference said icon in our HTML from a meaningless element
• But at this point, what we've written is still not accessible
• I won't go into those steps now...

• But like a lot of hacks, what may be brilliant at the time...

• Tends to age rather poorly

• There are also many visual issues
• They are monochromatic, a problem we've creatively attempted to sidestep

• But thanks to font hinting built for letterforms
• It never looked that great

Soon…

• For me, the most compelling argument against icon fonts

• I was emboldened to ditch icon fonts by Seren Davies' talk
• Challenges for dyslexic users

• Interfaces that relied on icon fonts to communicate important info

• Any part of the UI that relied on icon fonts is now unintelligible

• In certain situations, assistive devices may read certain characters aloud
• Icon fonts can fail poorly, showing "missing character" blocks or even emojis

• Your users could conceivable see horse emojis littering their star ratings...
• Which is what happened to Etsy back in 2014

There’s already a better way…

• Was that there's already a better way

…and it’s not even very new

• And it's already more than a decade old
• To learn more about it, let's jump back to the bygone days

1982

• Of 1982
• Dexy's Midnight Runners burned up the charts
• Also the year...

• Adobe released PostScript
• A programming language for vector images and fonts for print
• But soon found a digital home with the introduction of graphical user interfaces
• Expanded upon by Apple and later Microsoft with TrueType in 1991
• And in 1994 when Microsoft introduced what would become OpenType

1998

• By 1998, more and more of us were using our computers to access the internet

• And we were designing these things called webpages
• And decreasingly dependent on images
• Yet our choices were limited when it came to flat imagery (logos, etc.)

• JPG lacked alpha, compressed poorly
• GIF had limited color palette, limited alpha
• PNG existed but support was years away
• Even PNG assets are unnecessarily large

• The problem was our bitmap imagery
• Defined using a grid of pixels
• Instead of vector imagery, which

PostScript

• Browsers could already render PostScript vectors
• But these standards were never developed with the web in mind
• Brought years of complexity
• What we really needed...

A vector image format created specifically for the web

• A vector image format created specifically for the web
• Apparently, organizations thought so, too

• By 1998, six separate proposals were submitted to the W3C
• PGML and VML were the clear front-runners

• A working group was formed in 1998
• 3 years later, 1.0 recommendation for "Scalable Vector Graphics"
• Followed swiftly by 1.1, the current version

• Konqueror was the first browser to add SVG support
• Followed swiftly by most other major browsers
• With IE lagging predictably behind

What is SVG?

• So what is this exotic not-so-new format?
• It's really three things in one...

“Scalable Vector Graphics”

• It is predictably a vector image format
• But it's also a document format, similar to XHTML
• And a valid subset of HTML5 as well
• But let's focus on that first part for now

• Every major vector graphics application supports SVG
• Both reading and writing

• By selecting a different file format to export...

<img src="example.svg" alt="...">
          

.example {
  background-image: url("example.svg");
}
          

<svg> ... </svg>
          

<object data="example.svg" type="image/svg+xml">
  <img src="fallback.png" alt="..."/>
</object>
          

• And embedding the asset as you would any other image...
• Or a couple of new ways, which may come in handy later

• You'll have vector assets that look crystal-clear at various sizes
• With a reduced filesize to boot

• I already mentioned earlier that basic browser support is really high
• What I didn't mention is that it's higher than @font-face
• (Or fixed-position, FWIW)
• SVG support is lower for some features, like external references

• Mission accomplished, right??
• Maybe! Perhaps even most of the time

…can we do more?

• But can we do more?

• Traditionally, images and other media are cornerstones of our expeirences
• But they're also black boxes once they leave our editors

iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAMAAABg3Am1AAAAKl
BMVEVMaXEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABqfk8+AAAADXRSTlMA7zCv32BQIBDPcI+fXsg3kA
AAAOhJREFUeNrVldsOhDAIRGlptRf5/99dEy+pOsRMNtlk51UP
A5RS+U6xabVVVVuUd+Vkg1J++X1KdlOaxFdRA9IijuZqUHV2/g
/mKECinPFTn+aVn3o6PVBWeoTLQ8sOUwX9OUuEbXj2ardf5KZl
T/NxXq717pGhQQDFlYAs4hgGm1/nql2iQPcGEu0Y6KC8OvYOd7
zKqC1Nb2a2rwAQR18AVEp00XRb6YOjR4MdPnq82QvEXtFGLgEL
kVkzmPAXmU9UlijKEXjdt4AJ/0GJkPCfLEj4+g9ChSWEJYQkVA
gCF+0TaqZRfqEPfwwidjiHyZkAAAAASUVORK5CYII=
					

• Try to inspect the contents of an image (even one base64'd)
• Might as well be looking at the Matrix
• Hopelessly static

<img src="…" alt=" (╯°□°)╯︵ ┻┻ ">
					

• The "alt" attribute being our only window in
• But SVG might be different...

“Scalable Vector Graphics”

• If we return to those aspects of SVG
• This time focusing on those last two elements
• XML-based, a subset of HTML5

<svg>

</svg>

<svg>

</svg>

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
  <g fill="none" stroke="currentColor" stroke-linecap="round">
    <circle cx="9.5" cy="9.5" r="7.5" stroke-width="3"/>
    <line x1="16" y1="16" x2="21" y2="21" stroke-width="4"/>
  </g>
</svg>
					

• If we inspect an SVG, it appears so different
• We can identify each element of the image
• The lens, the handle
• These elements are just as transparent to us in the browser as they were in our editor

Possibilities

• What possibilities exist when the elements of an image remain accessible to us?

.fave-icon {
  fill: currentColor;
}
          

• A big selling point of icon fonts is that they can inherit text color
• Including our SVGs in HTML gives us that ability
• But is that all we ever want or need?

.fave-icon-base {
  fill: none; stroke: currentColor;
}

.fave[aria-pressed="true"] .fave-icon-base {
  fill: #E041B0; stroke: none;
}

.fave-icon-highlight {
  fill: #F995D1; visibility: hidden;
}

.fave[aria-pressed="true"] .fave-icon-highlight {
  visibility: visible;
}
          

• Or are there greater opportunities to communicate state to the user
• Dramatically altering appearances with simple CSS

• Could our assets become smarter?
• This logo looks nicely proportioned for narrow screens
• But any wider and it feels like an island

<svg>
  <style>
    /* defaults */
    @media all and (min-aspect-ratio: 3/1) {
      /* wide aspect ratio */
    }
  </style>
</svg>
          

• We can give the SVG an awareness of its composition
• Using styles and media queries

• Which makes our logo just as smart as the page it resides in
• But what's possible if the elements of our imagery coexist with the rest of our HTML?

<polyline points="130 250 280 130 …"/>
<circle cx="130" cy="250"/>
<circle cx="280" cy="130"/>
<!-- etc. -->
          

• With the points of this chart accessible
• We can update the data dynamically
• The image's destiny is not fixed in our editors
• Its life is just beginning

<defs>
  <filter id="outline">
    <feMorphology operator="dilate" in="SourceAlpha" radius="4"/>
    <feComposite in="SourceGraphic"/>
  </filter>
</defs>
<text class="sfx" x="400" y="190" text-anchor="middle"
  dx="0, -12, -10, -16, -18" dy="0, 5, -10, 5, 0"
  filter="url(#outline)">Splat!</text>
          

Source: Dudley Storey

• What if we use text instead?
• With fine-tuned but dynamic control of style and kerning
• Leaving the content accessible, reusable

<svg>
  <defs>
    <clipPath id="cloud">
      <path d="…"/>
    </clipPath>
  </defs>
  <image xlink:href="foo.jpg" clip-path="url(#cloud)"
    width="200" height="200"/>
</svg>
          

• You can also define and use shapes as masks

<svg>
  <defs>
    <filter id="half-tone">
      <!-- effects, composites, etc. -->
    </filter>
  </defs>
  <image xlink:href="foo.jpg" filter="url(#half-tone)"
    width="200" height="200"/>
</svg>
            

• Or even complex transformations using the "filter" tag

@keyframes spin {
  to { transform: rotate(180deg); }
}

.spinner {
  transform-origin: 50px 50px;
  animation: spin 1.3s
    cubic-bezier(0.175, 0.885, 0.32, 1.275) infinite;
}
          

• You can animate SVGs using CSS

// Using GreenSock GSAP (https://greensock.com)
TweenMax.to(element, 1.3, {
  repeat: -1,
  transformOrigin: '50% 50%',
  rotation: 180,
  ease: Back.easeOut.config(1.8)
});
          

Alternatives: Anime, Velocity.js, Snap.svg, KUTE.js

• Or JavaScript, which may be better for complex animations
• Growing number of SVG-friendly animation libraries to choose from

• Will we just design buttons?
• Or something more expressive and exciting?

• Are new navigation paradigms possible
• When content and visual elements coexist transparently

• The fact that SVG is XML-based and a subset of HTML5
• Means it can play nice with all our favorite web technologies
• And that's really where it becomes magic

The Future

• But what about tomorrow?
• SVG is pretty cool now, but does it have a future?
• While it's impossible to say with certainty, signs point to yes.

• Our existing design tools seem committed to SVG
• Illustrator and Sketch both improved SVG export in recent updates

• Firefox and Chrome introducing more and more animation-related tools (bezier curve adjustments, timeline control, etc.) to their developer tools

• And the SVG 2 spec is coming along nicely
• Blurs the line even further between SVG, HTML and CSS
• Improvements for composition and interactivity

The Point

• So here's my point
• The web has a very specific cycle for new techniques and featuers

Lack of vector images

• Our design intent encounters an obstacle

Icon fonts, Flash, crazy CSS shapes, etc.

• We hack our way around that through any number of open or proprietary solutions

SVG!

• Until a more robust, performant and predictable solution is standardized
• SVG is that tool, and in a tremendous stroke of luck, it's actually better than what we thought we wanted (vector images)

• "But SVG is hard" some say
• No...

Change is hard

• ...change is hard
• When we're entrenched in a certain way of doing things, it can be tough to see just how crazy it actually is

• Compare that to icon fonts. Filament Group's seminal blog post outlined the steps necessary to make icon fonts accessible
• It's over 2,000 words long
• Its author had this to say about my post in November...

<img src="my-icon.svg" alt="…">
              

<svg>
  <!-- icon data or reference -->
</svg>
              

• SVGs, on the other hand, can be used directly
• Embedded as an image
• Or in HTML (either the path data or a reference to a symbol)

• "You can follow [our] guide to Bulletproof Icon Fonts OR you can use SVG and go home early"

• Some say SVG isn't performant
• It's true that SVGs take a tiny bit longer to render than a font
• As a technology, it's less than half the age of PostScript

• So when GitHub switched their octicons to SVG earlier this year, I took notice
• We lack data on high-traffic SVG icon solutions
• I was pleased by what I read...

We’ve found there were no adverse effects on pageload or performance when switching to SVG.

By switching from icon fonts, we can serve our icons more easily, more quickly, and more accessibly. And they look better. Enjoy.

• I've heard dozens of other excuses for why SVG is just not ready for primetime
• Why it's inferior to icon fonts
• Or why it's apparently unworkable from a workflow standpoint

• And I just don't get it

SVG is useful

SVG is accessible

SVG is powerful

SVG is responsive

SVG is the future

• But if I'm honest, the biggest reason I've embrace SVG...

• ...is that it's so much fun

• So go have fun!