svg icons

Bobby Grace, on the Dropbox Paper team:

On the engineering side, we use inline SVGs. These have many advantages. One advantage is that SVG is a well-structured format that we can manipulate with code. Paper is also using React and has a component for inserting icons.

They:

1. Use a single Sketch file, checked into the repo, as the place to design and house all the icons.
2. Use gulp-sketch to extract them all individually.
3. The build script continues by optimizing them all and building a source of data with all the icons and their properties.
4. That data fuels the their <SvgIcon /> React component. (Also see our article).

They call it Papercons.

Now, whenever someone asks for an icon, we can just share a link to all the latest production icons. No more hunting, context switching, and long conversation threads.

There is an interesting gotcha about the fill-rule attribute of SVG, detailed here by Anthony Collurafici.

Fill-Rule is an SVG property that basically defines how to determine what shapes are filled or subtracted from the shape. The default SVG value is "nonzero", and this is what Android requires. Unfortunately, Sketch uses "evenodd". Luckily Sketch provides all the features we need to convert our shapes from "evenodd" to "nonzero". And its now even easier in Sketch 42.

The direction you draw the points in nested shapes affects the fill.

Another day, another design system deciding an SVG icon system is the way to go.

Everybody has their own set of considerations when making a choice like this. Scott Mathis documents the major considerations for Clarity: Opting-out, sizing, multi-colors, interactivity, scale, and the future. Based on these, they actually ended up on a custom element (<clr-icon>, which is inline <svg> under the hood), just like Etsy.

Etsy moves away from an icon font in production to using SVG. It's going to be an inline <svg> system, but abstracted as a <etsy-icon> custom element for ease of use.

Two cents:

• I could see the need for that abstraction going away if we had a more convient syntax for <use> available, like: <svg use="icons.svg#cart" />
• I like how dedicated they are to icon consistency. I struggle with this a lot. An SVG icon process can be so easy to work with, and new icons so easy to find and drop in, that consistency can suffer. That grid, with the examples, is gold.
• They are still building an icon font as part of the build process, for the designers to use in design software.

That last one is surprising to me, as I would think it would be a pain in the butt to find the right icon to design with when the one you need is assigned to some random character in the font. I would think the concept of "Symbols" in Sketch or Illustrator would make the way to make those icons super easy to find and use for designers. Which makes me think what the font actually has to offer is interoperability between design software. I wonder if software like Lingo or Iconjar would be helpful here.

High five to Dave Gandy and the Font Awesome team:

The Font Awesome 5 Kickstarter raised $1,076,940 with 35,549 backers, making it the most funded and most backed software Kickstarter of all time.

What's do the funders get? 1,000 more icons, icon font ligatures (a uniquely cool thing fonts can do, like turn "right arrow" into ➡, which can be an accessibility win), and, drum roll please, an SVG framework that will be open sourced.

Solid basics of an SVG icon system in this guide from Florens Verschelde, mixed with some good tricks: the two-color trick, pre-loading the sprite, and using custom properties for unlimited color variations. Also an interesting bit about using multiple methods for sprite insertion:

I like mixing both methods, building two sprites:

1. A small one with essential icons (e.g. main icons used in the page header), to be inlined on each page. Target size: 5KB or less.
2. A bigger one with all the project’s icons, kept as an external file. Target size: 50KB or less.

"Critical Icons", as it were.