Adopt Feather/Lucide icons

Feathericons are an open source library of very nicely drawn SVG icons published under the MIT license. They have the interesting property that they are designed by used at varying line widths. I think this is helpful for accommodating personal taste and accessibility needs.

I propose that TiddlyWiki 5 adopt the Feathericons for the core, replacing the current icons. Where necessary we might need to create additional icons in the Feathericons style, which we will offer to upstream.

https://feathericons.com/%0A

I did have a fast look. It seems not all icon elements are paths. So they will not work with our current hover CSS states, without adjustments. So we'll basically need to create them ourself using that style as a template.

@pmario

Thanks @pmario do give a link to anything problematic if you can.

@pmario

I think a refreshment of TW icons is a very good idea. While each fits its own purpose very well in TW, there are some inconsistencies between them. I was considering proposing some changes to amend these, but moving to a new base might be worth the additional efforts.

I happen to have briefly explored the idea of creating custom icon sets for TW recently. I didn't have time to really do anything useful, but hopefully my observations will offer some additional insight. I will be referring to two large open source icon collections from "big tech" that I looked into, that is Google Material Symbols and IBM UI Icons. There are certainly many other open source sets worthy of consideration, before making the decision to move.

Lucide instead? The Feather set seems to have no active development since some time. I have found some comments that it is considered abandoned. There is its fork, Lucide, on a similar license, with > 1200 icons (Feather has < 300), and it seems to be under active development.

SVG code consistency. This is a huge advantage of Feather/Lucide. As far as I have checked, all icons consist only of strokes, with stroke-width, stroke-linecap, and stroke-linejoin defined in the opening svg tag. This should allow to programmatically "tiddlify" them, and even offer sharp line ends as an option. The same cannot be said about IBM icons - their SVG code is all over the place, using different names and svg elements for identical things. Material Symbols are at least consistent in the code structure, it would be possible to programmatically tiddlify them, but they are offered only as expanded paths, not strokes, even though they mostly consist of lines and are available in many line width options. So each "weight" or "stroke width" option is actually a separate path.

Well, as @pmario mentioned above while I was writing this, this design of Feather/Lucide might not be so good after all. Is rearranging TW to work with stroke-only icons as well as path-only a reasonable thing?

Stroke-only design. In my opinion some icons simply look better when using filled shapes as well, not only strokes (e.g. image with mountains and sun, hexagons with Motovun/puzzle/tools inside, to name a few). The caveats are: I don't know if icons with filled shapes could be as easily adaptable as the stroke-only ones, it would be more difficult to keep them consistent, and merging with upstream would probably not be accepted.

Summing up: I think refreshing TW icons and making them more consistent is a good objective. Lucide offers a wide choice with a good code quality (allowing for easy user customization). There is the issue of support for stroke-only icons in TW, and design issue of sticking to stroke-only icons. These issues and other available open source icon sets should be explored.

Our concept is different. Eg: alert-triangle looks like this. Feathericons uses stroke-width parameter to define the stroke width, which seems to be one reason, why you want to switch.

TW icons do not have a stroke-width atm.

The fill parameter defines the icon colour. The feathericons use it differently

fill and stroke redefined. We would need to completely change our CSS rules, which will cause problems with 3rd party plugins.

It seems, that several sets contained in https://morosanuae.github.io/tw-icons/ do meet the TW affordances and can be directly used.

The only difference is, that the will need the new <<size>> parameter. They use the hardcoded width and size values at the moment.

There is its fork, Lucide, on a similar license, with > 1200 icons

I do like this project. They look good. If we could find a way to "batch convert" them into a format, that is compatible with ours that would be nice.

There seems to be a possibility to use InkScape from the CLI

See: https://github.com/leifgehrmann/svg-stroke-to-path/tree/master
and: https://dev.to/saulodias/convert-svgs-from-stroke-to-path-420j

So using Lucide as-is (in the stroke-only form, with ability to change stroke-width on the go) requires a lot of changes in the core and introduces incompatibilities.

If Lucide can be dependably converted from strokes to paths, and if we could also automate the process of "tiddlifying" it (parametrizing size, removing eventual unnecessary metadata, changing to usable TID or JSON format, packing into a plugin), then we could easily offer the icons at a couple of different preset stroke widths as core plugins. Not as adaptable on the go as the stroke-only icons, but also within reach without breaking anything.

But the question is, if it is worth going that far at all for the stroke width variability. If we are to convert Lucide to paths, we may just as well use another icon set, that is already available in path form. The Material Symbols are already available at different stroke widths/ weights, maybe there are other interesting sets like that?

The Material Symbols are already available at different stroke widths/ weights, maybe there are other interesting sets like that?

I did have a look at them from https://morosanuae.github.io/tw-icons/ -- IMO the only one, where the whole set looks OK and has paths, is: Zwicon (565 icons). The last one -- But -- It needs to be optimized in size. The icon set has way more path elements than needed for small sizes we use them. If used as they are, they will need 960 kByte. SVGOMG can probably strip it down to about 30% or more of that size. I only tested it with 4 random complex icons.

Since v5.3.0 SVGs are already backwards incompatible for 3rd party plugins, IMO there would be a chance to change the way core icons work.

In my earlier comments I did not take parametrized transclusions into account, which may make it possible to improve backwards compatibility. Even with stroke-like SVGs

I personally do have a Font Awesome 5 Pro license, which is sufficient for my needs. They have 1852 path icons in 4 versions: Solid, Regular, Light and Duotone. -- It would be sad if I'd need to throw them into the bin.

Conclusion

Whatever we decide, we will never be able to use an existing icon set out of the box, because of the flexibility we want to have. 3rd party icons sets will never allow us to use TW macro calls to define width and height=<<size>>

Even if we introduce a "hard dependency" and contribute to that icon set upstream, we will probably need a "build step".

So using the same mechanism https://morosanuae.github.io/tw-icons/ already provides with an official TW icon set seems to be manageable.

There could be some predefined sets like: Solid, Regular and Light that contain the TW core icons
With the rest of the icons, users will be able to download user defined sets
If the configurations would be stored in browser local storage it would also be easy to extend existing sets

Just a thought.

@pmario

Thanks @pmario @mateuszwilczek for the interesting points.

I wasn't aware of Lucide, which does seem a much better candidate.

I agree that the backwards compatibility implications of switching from fills to strokes are tiresome.

I wonder if we can stick with the fill approach, but parameterise the designs to give even more axes of variability than just the stroke width. We'd add a "stroke-width" parameter to the existing TW core icons that would do the maths to vary the stroke width. We might also add a "colour" parameter for easily overriding the colour of the icon without having to use CSS.

I also agree that we're likely to need a build process of some kind.

We'd add a "stroke-width" parameter to the existing TW core icons that would do the maths to vary the stroke width.

Generating filled paths from strokes at arbitrary widths inside TW would be very convenient, but from what (little) I have read (here or here), outlining strokes is not a trivial operation, it requires some dedicated libraries or programs (the Inkscape CLI mentioned above). As said, I haven't researched it much, but this might be problematic.

If so, we would have to revert to outlining outside of TW and offering separate icon sets outlined at different stroke widths.

[. . .] outlining strokes is not a trivial operation, it requires some dedicated libraries or programs (the Inkscape CLI mentioned above). As said, I haven't researched it much, but this might be problematic.

Yea I did find similar posts and found the links to the InkScape CLI, which would probably provide us with parts of the "build steps" needed.

We would first need to set stroke-width to 1
Create / download the SVGs with that setting
Convert them to paths
Add our TW specific classes
Add our width and height settings
Add our parameters
Optimize file size
Start from the beginning with stroke-width 2 and 3

We already have a step, that optimizes the size of SVGs. I do not know where it is called but probably somewhere in the build steps

We would need run some test, if that workflow would create 3 reasonable icon sets.

Generating filled paths from strokes at arbitrary widths inside TW would be very convenient, but from what (little) I have read (here or here), outlining strokes is not a trivial operation, it requires some dedicated libraries or programs (the Inkscape CLI mentioned above). As said, I haven't researched it much, but this might be problematic.

I agree. This is highly speculative but I wasn't thinking that we'd generate the filled SVGs from the paths, but rather than we'd parameterise our filled-style SVGs. We'd make the images out of transformed rectangles for the lines and circles for the line joins and caps.

We'd make the images out of transformed rectangles for the lines and circles for the line joins and caps.

This seems like a lot of manual work and there is the issue of more complex shapes not composable using only straight lines and circles.

What we would ideally want sounds a lot like the variable fonts, that is fluid adjustment of the "weight" of complex filled paths. But I have no idea how it's done internally in VFs (interpolation between edge cases would be the simplest, but I have a feeling it is more complex), or whether this analogy helps in anything at all.

In any case, the only icon set that I know with similar properties are the Material Symbols mentioned above. They are distributed as static paths or variable font in 7 weights × 3 grades (sub-weights) = 21 actual weights. It would be interesting to know what are the internals of generating all those variants. I wonder if the webfont does anything more clever than simply storing all those variants as static paths. It is intended to be used over the web and weights 10 MB, so maybe it is just a store of static paths. If so, then this ends up being not a much different workflow than the one described by Mario.

@Jermolene

@Jermolene ...

Do you want to adopt Lucide icons as they are. Line based -- Which is not compatible at the moment.
Or do you want to add the "outline" based icons, that we have at the moment?
- See: https://pmario.github.io/lucide-tiddlywiki-plugin/lucide-all.html#%24%3A%2Fplugins%2Ftiddlywiki%2Flucide-core

I'm now creating a stylesheet to disable fill rules and use stroke rules for svg with luicide class. This will allow us to use lucide icons without converting it to use fill rules while being backward compatible.

Stylesheet (currently incomplete): luicide.txt

I did have a fast look a the CSS txt file. The main problem I see, is that those rules are extremely specific. So it will be impossible for our users to create their own styles.

If we want to use "line based" SVGs we should break compatibility and create completely new CSS rules, that are easy to handle for our users.

Vanilla/base is already so complex and "uber specific", so creating new UI templates is close to impossible in a backwards compatible way.

The CSS "knows" about the UI structure, which should not be the case. CSS and DOM should be independent. That's how it was invented. Our CSS did organically grow and is way to interlinked with the UI already.

I think we need to make is simpler and not more complex.

I did have a fast look a the CSS txt file. The main problem I see, is that those rules are extremely specific. So it will be impossible for our users to create their own styles.

I believe this is a general problem of the vanilla stylesheet. It does add complexity for us to support luicide icons, because fill properties are scattered in the stylesheet. I found that many fill properties uses the same color as color, perhaps replacing them with one fill: currentColor rule can simplify them, then we can use:

svg {
fill: currentColor;
}

svg.luicide {
fill: none;
stroke: currentColor;
}

to style most luicide and tiddlywiki svgs properly.

@Leilei332

Thank you @Leilei332. Apologies if I have missed it, but have you made a PR for this?

@pmario

@pmario what is the current status of this PR considering the stylesheet changes made by @Leilei332 ? Can we adopt the line based icons, or do we still need to do use the outline based ones due to backwards compatibility?

@pmario what is the current status of this PR considering the stylesheet changes made by @Leilei332 ? Can we adopt the line based icons, or do we still need to do use the outline based ones due to backwards compatibility?

Line based icons and outline based ones can coexist now. We can support most line icons by adding:

svg.lucide, svg.icon-tabler {
	fill: none;
	stroke: currentColor;
}

Note that the bold, italic, list and quote icons are all line based:

@saqimtiaz

Long post warning. But I think it is needed.

saqimtiaz wrote:

Can we adopt the line based icons, or do we still need to do use the outline based ones due to backwards compatibility?

@saqimtiaz, @Jermolene ... That's a decision Jeremy has to make.

IMO "line based" icons will need more work, since not everything TW needs is available yet. See details below.

Leilie332 wrote:

Line based icons and outline based ones can coexist now.

@Leilei332 ... For many icons that may be true. But for all "filled" icons like: that's not true.

That's why

I did create Lucide Core Plugin

This plugin contains an outline based TW v5.3.x compatible core icon set
It should be a "drop-in" replacement for the core icons
- Core plugin icons are not included atm - But can be added

Pros TW Outline Based Icons

IMO the outline based Lucide-Core Plugin has one killer feature

It's a fully compatible drop in replacement for all existing v5.3.x editions.
- No browser reload needed
To test
- open tiddlywiki.com
- drag & drop import lucide-core plugin into tiddlywiki.com
- Done. -> All core icons are switched
- Or open any other TW v5.3.x compatible wiki:
  - https://tiddlywiki.com/dev/
  - https://kookma.github.io/TW-PluginLibrary/ (v5.3.5)
  - https://erwanm.github.io/Projectify/demo.htm (v5.3.6)
  - https://wikilabs.github.io/ (v5.3.6)
  - I did even test it with tiddlytools.com (v5.3.8 - downloaded, since online blocks import)
Most icons are used form the lucide.dev icon set
But 36 icons are TW custom made according to the lucide.dev rules.
- Some of them may be contributed back in the future
- The custom TW icons can be seen in the plugin readme tab

I did also create the Custom Icons Edition

This edition allows users to create their own Custiom Lucide Icon Sets as plugins
Users can:
- Create new plugins
- Update existing plugins
- Manage several plugins with the edition, since it uses the browser local storage to remember stuff

Cons - TW Outline Based Icons

Even if "outlined" SVGs are optimised, they are huge compared to "line based" icons
Creating them needs TW specific build steps
- see: https://github.com/pmario/lucide-tiddlywiki-plugin/tree/main
- Currently I build the editions manually, but it should be possible to automate it
- I will need some help with the GH automatic build system

The biggest contra for outline based icons is: Changing the icon thickness is "kind of" a hack

Pros Lucide Line Based Icons

SVG's are small eg: a-arrow-down.svg or ferris-wheel a more complex one
Changing the line width is easy. eg: dynamically change the stroke-width in CSS

Cons Lucide Line Based Icons

Filling icons is impossible by design
- Changing line color with CSS is possible
At the moment we need 36 custom icons, since there is no real equivalent in the lucide library
They are not fully backwards compatible with existing editions in the wild
- We may be able to make them coexist for future versions according to Leilei's comment

That's it for the moment. I hope that helps

There is one thin I forgot. Lucide Line Based Icons will have no transclusion parameter support by default. eg: {{$:/core/images/done-button|10em}}{{$:/core/images/close-button|10em}}{{$:/core/images/close-all-button|10em}}

Lucide icons has updated many new icons. These may be the candidate for fold related icons:

Navigation Menu

Repository navigation