Guidelines vs Rules
See original GitHub issueThis is a problem that has been here since the beginning and after seeing more icons being “fixed” (and doing so myself) I feel the need to get this out of my head. Please keep in mind, that this is only my opinion and I understand that not everybody will feel the same but maybe this can at least spark some discussion:
In my opinion, our guidelines should not be declared as rules.
I feel the guidelines have been interpreted too much as rules, instead of guiding principles. I understand that trying to define the “feather” look in text is difficult, but this is even more reason to not put too much weight on our design guide. This is also reflected in Coles answer when asked to declare guidelines which used the words constraints and guidelines and put a clear distinction between them.
Let’s take for example the shopping-cart
and the shopping-bag
icons:
To me one icon looks smaller than the other. Now let’s take a look at the feather icons:
To me, these feel much more balanced, even though the sides of the cart poke out of the “safe-zone”. In the world of typography this is better known as overshoot and over at feathericons.com similar decisions have been made along a lot of icons in order to keep a consistent visual size between icons. Now we can’t be as exact with it as type designers, after all we are constraint to a 24x24 (mostly) pixel-perfect grid, however I believe that this was the main motivation for what Cole Bemis called “similar optical volumes”. In fact, this principle hasn’t even made it into our rules and I would understand why: It is practically impossible to measure. It cannot be a rule because it is inherently just a blurry guideline. But as undefined it may be, I believe it is the main driver to keep a consistent set of icons.
Please do not take this as personal criticism of anybody. I myself have “verschlimmbessert” some icons in a very similar way but I thought I could at least write down my thoughts on this.
Issue Analytics
- State:
- Created a year ago
- Comments:7 (7 by maintainers)
Top GitHub Comments
@karsa-mistmere Sorry my wording wasn’t clear there: I meant the 3px stroke width not the icon itself, this effect can be seen in a lot of icons, everywhere two lines intersect/touch. My guess is that Chrome renders each SVG element and then simply adds each pixel layer on another.
Agreed, maintaining a consistent stroke width across different is a valid use-case but note that fonts also don’t do this and the density of each icon actually increases dramatically. Additionally at least the 12px example looks blurry on my screen (if you wanted to stay on the pixel grid, you’d have to use this formula:
48 / desiredWidth = strokeWidth
).However considering that GitHub doesn’t use pixel perfect icons at all and keeps a consistent stroke width between its 16px and 24px icons I might be putting way too much emphasis on that point.
Also:
image
actually is still pixel perfect, the rendering issue you experience is unrelated to Lucide and is equally present in Feather:(left: Feather, right: Lucide)
p.s.: or sometimes it’s not, Figma renders both versions without any hiccups: