Guidelines vs Rules

[lscheibel]

This 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.

[karsa-mistmere]

I think you're definitely onto something, my two pennies on the matter:

I think Feather and Lucide's guidelines are equally outdated. I completely agree that some guidelines should be marked as requirements/constraints and some should be marked as recommendations, and we do definitely need to add some extra guidelines for sake of consistency.

---

As for our current guidelines, I think we can all agree that the following are trivial and must be defined as requirements:

Lucide: 1. Icons must be designed on a 24 by 24 pixels canvas.
Lucide: 3. Icons must have a stroke width of 2 pixels.
Lucide: 4. Icons must use round joins.
Lucide: 5. Icons must use round caps.
Lucide: 6. Icons must use centered strokes.

aka:

Feather: Every icon fits in a 24x24 canvas.
Feather: Every line and shape has a 2px center-aligned stroke with round joins and round caps.

---

As for the rest:

Lucide: 2. Icons must have at least 1 pixel padding within the canvas
Feather: Icons should have a 1px empty “safe zone” on the edges of the canvas:

Since we're not dealing with typography here and in certain scenarios SVG images are simply unable to overflow to allow for overshoot (and accidental clipping is obviously not an option), for purely technical reasons we have two possible courses of action:
A) we keep support for a 3px stroke width and make this a solid requirement
B) we drop support for any stroke width above 2px and make this a recommendation

In scenario A we need to fix icons that violate the (new) guidelines.
In scenario B we lose backwards compatibility.

---

Lucide: 7. Shapes (such as rectangles) in icons must have border radius of 2 pixels
Feather: 90° corners should have a 2px radius:

This is currently treated as a pretty loose recommendation, and should probably remain as such, but some icons might need some overhauling nonetheless to comply with this guideline better. E.g. there's no real reason why eraser doesn't have a 2px rounding:

I also think a list of possible exceptions could be compiled, such as: "Exceptions may apply, e.g. when two separate objects meet at an angle, or when this added rounding would be highly detrimental to the perceptibility of the icon."

---

Lucide: 8. Distinct elements must have 2 pixels of spacing between each other.
Feather: Distinct elements of an icon should be separated by at least 2px of empty space

This is currently treated as a very strong recommendation, only allowing for incredibly minor violations (in the 0.1px range). Again, this is something that's obviously very necessary for proper support of either a 3px stroke width or a 12px size, otherwise separate elements would bleed into each other.

---

Feather also has a few extra constraints and guidelines compared to Lucide:

Feather: No fills.

I mean, yeah, we should probably also put this in writing. :)

---

Feather: Icons should have similar "optical volumes"

I agree with @lscheibel that this is something that should be at the very least a recommendation and something that we strive for.

---

Some other things I think would be worth putting in writing are:

Icons should aim to have their center point (12,12) as the center of gravity.

I think this should be a no brainer, when used in toolbars, icons should appear in line regardless of orientation.

---

Icons should have similar visual density and level of detail.

Like visual weight, this is hard to measure but would improve the overall harmony of the icon set.

---

p.s. I didn't dwell too much on your example, as shopping-bag doesn't quite comply with Feather's own guidelines to begin with, since it has noticeably more visual weight than square does:

But yeah, shopping-cart also needs to be bumped up a bit.

[karsa-mistmere]

For demonstration purposes, here's a screenshot of shopping-cart from Feather to illustrate why it needed to be fixed:

[ericfennis]

@lscheibel I agree partially with you on this. For how I see the guidelines is that we need to follow them much as possible but sometimes we can make exceptions. I think it is good we update some of the old icons. I agree on the part :

Feather: Icons should have similar "optical volumes"

But this was also not really the case with some of the "old" icons from feather.
For example the cog icon. I really loved the look of the feather cog icon, but it was really out off balance with the other icons. So we changed this. See for example this example, left: feather icons, right: lucide

So I think it is good we update them to improve visually balancing them out. aka "similar optical volumes"

I agree with @karsa-mistmere we should update the current guidelines. Maybe with with a section recommended and rules as what @karsa-mistmere mentioned.

What I not agree on is 1px save zone as a guideline instead of a rule.
The save zone makes sure the fully image of the icon will be shown, and the cases were the icon it need more space to render pixels it can take the save zone to show them. Sometimes on lower DPI screens the icon can look having trimmed edges.

For example this drawing I made (normal styling: lucide 24px, 2px stroke). 1st icon applied the save zone rule. 2nd and 3th icon are the same, but the second one is in a frame "cropped" like how svgs icons are displayed in browsers

On the 3th icons you can see that some pixels are rendered outside the canvas.

But overal I think it is good we discuss this, and I'm open to suggestions to change these guidelines/rules, the current ones I created quickly to have some to reference to. But we can improve this definitely. Maybe we can also add some 'Dos' and 'Dont's'. To make things more clear.

For the shopping-cart, I think we should update it to look better with others, I think we need to keep checking the icons side by side to keep consistency. So as we do in review for the new factory icon: #558

[lscheibel]

@karsa-mistmere I agree with almost all of your points. Btw I just chose the shopping-cart as an example because it was right next to the bigger one, the issue can be seen in quite a few places.

In scenario B we lose backwards compatibility.

It would be nice to know if anybody actually uses them with a 3px stroke-width especially considering, that a lot of icons were clipping at this size up until recently.

Icons should have similar visual density and level of detail.

Yes I agree here basically a 100%, however I think the example you chose also clearly shows where this rule/guideline meets its limits.

---

@ericfennis Yes, the feather icons are not perfect either and some changes were easy no-brainer fixes that simply made sense (like the triangles).

[...] some pixels are rendered outside the canvas.

However, in this example, doesn't this only happen when using the miter join? At least Chrome and Firefox (on Windows) seem to handle even circles that touch the edges of the svg viewbox nicely without clipping the interpolated pixel values.

These are screenshots taken of the feather "cloud" icon from a 1366x768 display in Chrome.

---

The other reason to make the "1px safe zone" a rule would be the 3px stroke variants.

I love the fact that one can use the icons at a larger scale and reduce the stroke-width to a value that still results in a pixel perfect display of the icon. In fact most of them are gorgeous at double the resolution, albeit not as practical.

When it comes to the 3px variant however, I've always thought of that as a gimmick. Most of the icons look pretty bad at 3px stroke width, beginning with actual interpolation issues where, due to the now not pixel perfect strokes, two touching lines add two half black pixels to a fully black one:

Lucide "image" 24px - This is actually pretty noticeable when viewed at 100%

I, therefore, would like to propose to disregard any issues stemming from increasing the stroke width above 2px. I would treat 3px as not officially supported but where it works, that's great. What do you think?

[karsa-mistmere]

@lscheibel: What I think is a pretty legit use case of a stroke width greater than 2px (it doesn't have to be 3px, anything greater than 2px will break) is using multiple sizes of icons while keeping the relative weights the same, e.g.:

I've actually used Feather in one particular project just like this (24px/1.5px for menu items and buttons, 16px/2.25px for badges).

[karsa-mistmere]

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:

[lscheibel]

@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.

[karsa-mistmere]

If and when the guidelines are rewritten this thread should also be considered: #935

[itsjavi]

IMHO, the guideline that says "Distinct elements must have 2 pixels of spacing between each other" is a too strict/restrictive rule.

Sometimes there are icons that work with 1px, 2px, 3px, and 4px strokes even if the spacing is 1px. So I would make it a recommendation instead of a strict rule. Or just split it into different rules:

• Distinct elements must not overlap/bleed over each other when using a size of 12px
• Distinct elements must not overlap/bleed over each other when using a stroke with of 3px

An example:

In this case, 3px+ can be used to make it look like a fill, but I agree that it makes the icon not look consistent in every size.

[karsa-mistmere]

In this case, 3px+ are used to make it look like a fill.

Imitating fills with strokes is something that we do not allow, so it's a bit of a stretch to say that these "work". I could see merit in being looser with this guideline but this is definitely not the way to go.

[itsjavi]

In this case, 3px+ are used to make it look like a fill.

Imitating fills with strokes is something that we do not allow, so it's a bit of a stretch to say that these "work". I could see merit in being looser with this guideline but this is definitely not the way to go.

I understand, because the visuals are not consistent then, and it may be an unwanted behavior.