-
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
I think this is one of those cases where (by design), you'd have to modify the code to fit your needs. Icons are quirky! 😄 The way to circumvent that on a library level would be to:
I'm obviously in camp #3, but if there's something inherent to ex solid icons vs outlined icons specifically, I would like to do some fix for that. Either way, I'll look into Lucid icons and how they do it, thanks for taking the time @Deufel ❤️ Do you have any thoughts on this? |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick response! Yeah I would say that 1 and 2 are not the best way to go nor maintainable. Im a bit new at all this stuff so I am usually unsure if the issue I am having is by design or if it is my poor implementation. I think that this boils down to stroke based icons vs fill based icons. Maybe something like the following would allow the library to be more general purpose with out over committing to support every icon under the sun. /* Icon */
&:where(:has(svg), &.icon-only) {
gap: 1ex;
& svg:not([fill="none"]) {
fill: currentColor;
}
& svg[stroke] {
stroke: currentColor;
}
} the log-in icon is a bit distorted because the fill is changed from none to currentColor |
Beta Was this translation helpful? Give feedback.
Thanks for the quick response! Yeah I would say that 1 and 2 are not the best way to go nor maintainable. Im a bit new at all this stuff so I am usually unsure if the issue I am having is by design or if it is my poor implementation. I think that this boils down to stroke based icons vs fill based icons.
Maybe something like the following would allow the library to be more general purpose with out over committing to support every icon under the sun.
With Change:
With Out …