[Isomorphic]

Apologies, this one slipped a bit - we'll punt it up the list and take a look today

[claudiobosticco]

Hi, were you able to reproduce the problem?
It occurs for me when using a relative path, ie "images/solid.svg". It doesn't happen with an absolute path. Essentially, when the Button is created, the icon URL is correct, but on hover, "/images" is added to the path. I would say it happens with every type of Button.

[claudiobosticco]

No, that's not an intentional change - we'll take a look. Are you using path shortcuts like [SKIN] or [SKINIMG] in your src strings?

nope, just the path of my webjar

[Isomorphic]

No, that's not an intentional change - we'll take a look. Are you using path shortcuts like [SKIN] or [SKINIMG] in your src strings?

[claudiobosticco]

SNAPSHOT_v13.1d_2024-05-14/Enterprise Deployment

Hello, I've just noticed that with the latest builds, in my ToolStripButton where I'm using svg spriting, I get a '/images' added before the path of my svg file, is it an intended change?

[claudiobosticco]

We've never used WebJars. The FileDownload servlet will discover static files on either the filesystem or discoverable via the classpath (ClassLoader.getResource()).

From a conversation with ChatGPT, it looks like we are meant to translate "/webjars" to "META-INF/resources/webjars". We can add that.

Hello, will you please update this thread if you'll add the translation for webjars? TIA

[claudiobosticco]

In the meantime - we've added a new class, .icon, which sets CSS color, rather than SVG fill and stroke - you should see that in tomorrow's builds, dated March 30 and later.

SmartClient Version: SNAPSHOT_v13.1d_2024-03-30/AllModules Development Only (built 2024-03-30)

I can confirm it's working with fontawesome svg sprites after adding fill="currentColor", thank you very much

[Isomorphic]

We've never used WebJars. The FileDownload servlet will discover static files on either the filesystem or discoverable via the classpath (ClassLoader.getResource()).

From a conversation with ChatGPT, it looks like we are meant to translate "/webjars" to "META-INF/resources/webjars". We can add that.

[claudiobosticco]

Hello, thank you very much for your detailed explanations, much appreciated.

I can confirm that after enabling the caching via FileDownload servlet the flickering is gone.

About caching I must say that I've tried to use a webjar to pack the sprites files, but in this way I can't map the URLs in the FileDownload servlet, I mean, if I add:

   
    <servlet-mapping>
        <servlet-name>FileDownload</servlet-name>
        <url-pattern>/webjars/FontAwesome/*</url-pattern>
    </servlet-mapping>

then I get a 404. Is it not supported by the FileDownload servlet?

[Isomorphic]

A quick update - it occurred to us that, probably in conjunction with a lack of caching, an issue with flickering might arise from there being ~1000 symbols in the sprite - symbols are shadow DOM elements, so vast numbers of them would take time for the browser to process. But we tested showing symbols directly from solid.svg (once mapped to currentColor) in a local Showcase and we still see no flickering.

If you only saw the flickering when using .svgIcon (ie, when setting SVG fill directly, rather than CSS color), there's a vague possibility that using CSS to set SVG attributes directly, rather than just CSS color, might behave differently enough that it can cause a flicker - we don't see that in testing or in the Showcase samples, though, so it seems unlikely.

In the meantime - we've added a new class, .icon, which sets CSS color, rather than SVG fill and stroke - you should see that in tomorrow's builds, dated March 30 and later.

[EDIT]

Note that, on further testing, we find that if your setup is not configured to cache SVG, then a sprite with hundreds of symbols may indeed cause flickering when applying stateful modifications to individual symbols, as a result of the browser re-loading and processing the entire sprite.

The solution is to ensure that image/svg+xml is cacheable.

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

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

[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]

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.

[Isomorphic]

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