[Blama]

Hi Isomorphic,

I played around with it, this is amazing. No flashing and no network requests.
And I just checked, FontAwesome offers their icons in a sprites-svg with named symbols inside as well.

A really cool feature.

Best regards
Blama

[Isomorphic]

We briefly tested some output like that from FontAwesome some time ago - one thing we noticed in our quick test with default export options was that it would correctly extract each symbol's styles to a new external css class, and apply the style-name to each symbol - but it always used the same class-name, something like .cls-1. Since some graphics had different combinations of values for fill and stroke, this meant the styles it exported were just clobbering each other in the same .cls-1 class.

Of course, it seems pretty likely that FontAwesome can export a different class-name for each symbol if you find the right export options.

[claudiobosticco]

Hi Blama I'm playing around with fontawesome and the svg support in latest 13.1. It's working while I include the sprites files in my project, did you succeed while using the fontawesome kit, by chance?

[Blama]

Hi claudiobosticco,

no, I haven't tried it yet.

Best regards
Blama

[claudiobosticco]

Blama if I understand correctly, seems not possible: https://docs.fontawesome.com/web/add...th-svg-sprites

[Blama]

Hi claudiobosticco,

do you mean it works if you serve them from your domain, but not when including them from FontAwesome?
If so, what sprite-file are you using? fontawesome-free-6.5.1-web.zip/sprites/solid.svg? Is this also available unpacked to link it directly?

Did you see this advice? Perhaps you need to include them from your server.

Best regards
Blama

[Blama]

Blama if I understand correctly, seems not possible: https://docs.fontawesome.com/web/add...th-svg-sprites

Haha, yes.

[claudiobosticco]

yes, exactly, it works only when serving it from my domain. And yes, that's the file I'm using.

[Isomorphic]

You may be able to use the file remotely if you preload it in your page with anonymous crossorigin, as we do with font-files in the Showcases - something like:

<link rel="preload" href="path/to/your/icons.svg" as="image" type="image/svg+xml" crossorigin="anonymous">

[claudiobosticco]

Hi Isomorphic, thanks for the hint, I'll try.

just noticed: maybe the fill color for the svgIcon in Twilight skin is a bit too dark? Seems similar to the color of buttonDisabled for instance.

[Isomorphic]

Thanks - we'll check on the default .svgIcon colors in each skin.

[Isomorphic]

We've tweaked the default icon-color to match the FormItem text-color in Twilight and Obsidian.

We did a quick test with the FontAwesome sprites and they work fine - however, because they all use "fill" constructs and are unstyled, you're having to use SVG "fill" to affect the colors. If you have the right to modify the file, you can switch them to using regular CSS color by adding fill="currentColor" in each opening <symbol> tag. Then, if you use these icons *without* a cssClass, they'll naturally get the same color as surrounding text - in a formItem vs a Button, for example. This isn't necessary, these icons work fine applying SVG fill via CSS, but using CSS color makes it easier to re-use the icons in different contexts, without having to litter the CSS or src-strings with additional "fill" settings.

[claudiobosticco]

Thanks, now the svgIcon looks much better.

I've tried your suggestion of adding fill="currentColor" to the fontawesome file and it works. But when using the svgIcon style I don't see the Over and Down state (which I saw without fill="currentColor"). It seems because in the svgIcon style there is fill (if I use a style with color it still works).

There's a reason to use fill instead of color? Sorry for the naive questions but I'm not an expert.

Also, I've tried to use cssClass, and I see the Img flickering in my application....which I don't understand as I don't see flickering in the showcase sample svgSymbols.

But then in that svgSymbols sample I tried to replace chatStyle with svgIcon and flickering appeared...so I'm confused, what am I missing?

[Isomorphic]

Forgive the lengthy response. Yes, at the moment the .svgIcon class only sets "fill" and "stroke" (which are both SVG attributes that you can affect from CSS and require there be no inline-styling in the SVG), whereas the .chatStyle only sets CSS color (which requires that fill or stroke be set to "currentColor" inline in the SVG) - so the two are not interchangeable. We'll either update the .svgIcon class to also set CSS color, or add a separate class aimed at "currentColor" usage.

In the case of fontawesome SVGs (and the ones we've seen from other font-sources, such as all of Google's MaterialIcons and MaterialSymbols SVG sets, coming soon), the SVGs are always composed such that they use only "fill" constructs (filled shapes) and not strokes (lines or borders around shapes), but they don't specify the "fill" paint-color inline. So, browsers will show it in their default SVG "fill" color (black), and you can set "fill" in a CSS class to affect it.

If one or more of the icons happened to also include "stroke" constructs, you would have to 1) know about that and 2) also set the "stroke" paint-color and stroke-width accordingly, which might require separate classes if the icons came from different sources with different designs or weights - you'd probably want it to match the "fill" color, but setting stroke details can have unexpected effects, such as adding an outline to filled-shapes that shouldn't have one.

Then, when you use .svgIcon or a similar class to modify fill and stroke, you will need multiple such classes to support .svgIconInAButton, for example, where you'd likely need different colors from a formItem. In Tahoe, for example, you would want white icons in a button, but grey ones in a FormItem.

Instead, to make single-color images (or parts of multi-color images) mutable, you can set fill or stroke, or both, to "currentColor" in the SVG. Then, it doesn't matter if the icons use strokes or fills, you just set CSS color in a class or src-string - if you don't set a color, then when you use the icons, they will inherit color from the CSS cascade of whatever container you put them in - in Tahoe, for example, you would automatically get white icons in buttons, because buttons set a CSS color, and grey icons that turn white on rollover in Menus, because menu-cells are stateful and set CSS colors.

It's true that "fill" would be inherited in the same way but, in our framework at least, the vast majority of widgets have CSS classes with likely colors already set, where almost none of those classes currently apply fill or stroke.

We don't see an advantage to using "fill" except that, in this case, the sprite file is already constructed that way, so you can change color by setting "fill".

Finally - we're not aware of a reason that you'd get flickering from attempting to cross-use these CSS classes in your tests, but we'll take a look and see if we can reproduce.

[Isomorphic]

On the icons flickering - it's worth confirming that caching is enabled for SVGs, although we wouldn't expect visible flickering even if it isn't.