[IDEA] Create a few templates for styling icons

[twMat]

There's no simple wikitext way to style transcluded icons, at least I don't know how to do it. Instead resort to custom css. I typically go scavenging for css in the huge default stylesheets to recreate the "native appearences" that default icons show in the UI, e.g the gray color (as opposed to svg default black) and the shifting color effect that appears when hovering.

Describe the solution you'd like I wish for some "end user templates" that can be easily invoked as the icon is transcluded, e.g:

{{$:/core/images/advanced-search-button||pretty-1}}

I'm actually surprised we don't already have this. The user should not have to know CSS or SVG for this.

[CodaCodr]

Even <span class="this'll-fix-it">{{...}}</span>. I've spent far too many "this'll just take a minute" hours doing exactly that. Not complaining... just never thought to put the question out there. So, Thanks @twMat

[twMat]

Yeah, some templates could probably be sth as simple as

<span class="this'll-fix-it"><$transclude/></span>

If one wants to fiddle with html etc one can do that but IMO a user should not have to "face" such things when we even already have a wikitext interface that could be used, i.e the {{...||...}} syntax. This would also be way to highlight which styles that are appropriate for direct end use.

[Jermolene]

{{$:/core/images/advanced-search-button||pretty-1}}

The challenge is one we have discussed before: that we'd need to have shadow tiddlers called things like "pretty-1".

One thought is that things would be much more flexible if we didn't include the <svg> element itself within the image tiddler, but instead kept the viewBox in a field. Then we'd use a macro to display the icons that would add the <svg> element dynamically, and thus permit it to be sized dynamically.

We could actually make this change in a backwards compatible way. We'd define the new style icons with a different prefix like $:/core/svgs/, and then have the $:/core/images/* tiddlers each contain a single macro to instantiate the required icon with the default settings.

Alternately, and making things more generic, #5199 could give us a way to pass width and height parameters when rendering icons.

[twMat]

The challenge is one we have discussed before: that we'd need to have shadow tiddlers called things like "pretty-1".

Ah, right. Do non-$:/-prefixed shadows behave differently, e.g do they show in simple search or is it only for aesthetical purposes that it's inappropriate with such prefixed shadows?

... the <svg> element ... viewBox in a field

Interesting idea! You only mention width+height but it seems there's a wide range of attributes for the <svg> tag. Abstracting things with a macro could also save the user from facing basic-yet-confusing attributes like fill by renaming them to more intuitive names like color.

Off the top of my head, as an end user I want to control at least:

• height
• width
• the main stroke colour of the figure

For default colors and behaviours, it makes sense to have things to align as much as possible with the default display of native icons, including the on-hover gray-to-black effect.

[Jermolene]

Ah, right. Do non-$:/-prefixed shadows behave differently, e.g do they show in simple search or is it only for aesthetical purposes that it's inappropriate with such prefixed shadows?

No, shadow tiddlers that are not system tiddlers behave like any other shadow tiddler. The issue is more that there's nothing to stop end users creating their own tiddler called "pretty-1".

You only mention width+height but it seems there's a wide range of attributes for the <svg> tag. Abstracting things with a macro could also save the user from facing basic-yet-confusing attributes like fill by renaming them to more intuitive names like color.

Absolutely, we could inject any required attributes. I'm not sure that we wouldn't create more confusion by changing the names of the attributes. In any case, using "color" doesn't help distinguish the stroke from the fill.

For default colors and behaviours, it makes sense to have things to align as much as possible with the default display of native icons, including the on-hover gray-to-black effect.

Hover effects require CSS.

[twMat]

@Jermolene wrote

Hover effects require CSS.

Are you saying that's a problem? Isn't it just to bake it into the macro that displays the <svg> element? I think the "basic case" for someone wanting to use an icon is that it should stick to standard icon behaviour as displayed in native TW.

[Jermolene]

Are you saying that's a problem? Isn't it just to bake it into the macro that displays the <svg> element? I think the "basic case" for someone wanting to use an icon is that it should stick to standard icon behaviour as displayed in native TW.

It's not a problem that CSS is required for hover effects, it just means that there are two distinct places involved in styling such SVGs.

In fact, though, the hover effects in the core are applied to the button as a whole, not just to the SVG icons, so I think these two concerns can be separated cleanly into a new icon macro that can inject arbitrary attributes (including classes), and an SVG class for buttons which embodies the hovering.

[twMat]

Note:

5738 discusses a more general idea to allow for pretty titled templates in transclusions. It is not limited to icons and it is no longer relevant for @Jermolene 's idea here about putting viewBox in a separate field (an idea worthy of a separate discussion thread).