About those vector icons

But doesn't SVG support CSS Media Queries? That would make it more than possible to support showing/ hiding appropriate elements/ layers according to the current dpi, width/ height, orientation or whatever?

The answer is to use HTML5 canvas instead of SVG, and create your icons as a JavaScript algorithm. Canvas code can become vector if you utilize the scale() function. I've done this for the icons in one of my web apps and it's a superb solution.

If there was some way to export a vector drawing as a JavaScript algorithm, or some semi-standard way to process an SVG image to Canvas then it'll become the defacto icon solution for the forseeable future.

Author of the article here.

If you read the closing paragraphs of the article, you will see that I do talk about the physical size of the final representation of the pixel-based icon. However, just because you can use more pixels on higher-resolution displays, it does not mean that you can just take a highly detailed vector artwork and display it.

Being able to display very intricate details for each icon is not necessarily the end goal. The end goal is to preserve the clarity, which is why smaller icons (physically, not pixelwise) should have smaller amount of detail compared to larger ones.

In your example, a 128x128px icon that occupies the same physical size on an extra-high DPI screen as a 16x16px icon on a lower-end screen can (mathematically) have 8 times as much detail along each axis. Just because this is possible to do without losing the signal quality on the level of individual pixels, does not mean that it is desirable from the UX / UI perspective.

Great, detailed post. I think situations exist today where vector icons can be a good solution; however, the promise of design once, deploy everywhere for artwork and UI that requires attention to every detail ... the rendering/display tech is not yet available at scale.

I think an orthogonal challenge is convincing cross-functional peers that visual execution and all of the design details have a huge affect on the user experience, the product, and therefore the business. In my experience, it's rarely a straight-forward or painless debate.

You're right that in a world with varying pixel densities, it's not enough to just design an icon for a given pixel size. But physical size isn't the right design target either. An icon designed for a given physical size on a display close to the user's eyes won't work if the display is much further away.

So when you go from thinking about pixel size to thinking about physical size, you're going in the right direction, but you're not going far enough. The relevant metric is more like "the angle subtended at the user's eyes", kinda like how the "CSS pixel" unit works.

Now, given that it's almost impossible for software on the device to know how far away the user is, trying to design up front for that metric (angle subtended by the icon) is also almost impossible.

And even if you did know both the pixel density and the distance to the display, that still doesn't take into account the fact that users will vary in their visual acuity. The right design choice for a 20-year-old user holding the display close to their face is going to be dramatically different from the right choice for a 70-year-old holding the display at arms length.

You can't really design well for all those possibilities up front. The right answer has to involve allowing the user to adjust the "zoom level" to their liking. And that level of flexibility means that automated approaches (possibly something like freetype's autohinting, extended to work in color) are probably going to be a better approach than manual pixel tweaking.