Confirming, this also works well in IE11.
--------------------------------------------------------------------------------
Antonio McDeal wrote:
> Confirming, this also works well in IE11.

Thanks for writing the patch, but I think it's better first to refactor those elements in order to use the regular @icon-*@ classes. Please see #31433, #24313 or the related tickets.

After that, we should wait for a resolution regarding the font awesome icons (#23980) and if FA is not an option, we can explore alternatives (SVG, your solution, etc).
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> Thanks for writing the patch, but I think it's better first to refactor those elements in order to use the regular @icon-*@ classes. Please see #31433, #24313 or the related tickets.
B b b b but parts of gantt don't really fall into the actual category of UI icons, or do they, aren't those are just patterns? At least I don't see how they could potentially be reusable anywhere else, as those seem very specific. And with case of SVG primitives it wouldn't actually matter, because with the method I proposed you can just always generate your own base64 code and insert it anywhere :D
> After that, we should wait for a resolution regarding the font awesome icons (#23980) and if FA is not an option, we can explore alternatives (SVG, your solution, etc).
It's been too many years, I think the idea with font awesome should be forgotten for good, until either JPL will be active again or a more active head of the project would to take over the post. Meanwhile we could already now begin exploring alternatives for something less owner consent dependent, and preparing the ground which could at least serve as a decent temporary solution, then just switch later when and if the time comes.

Font icons anyway seems more like a hack to be very honest, and I came to that conclusion as well recently, so it's definitely either base64 CSS encoded method or SVG method that I think should be used.
I think even PurpleMine switched to SVG icons which are actually compile-encoded as base64 vectors into the output CSS style sheet.
--------------------------------------------------------------------------------
The subject says "vector", but the embedded Base64 encoded data looks PNG bitmap. Is it correct?
--------------------------------------------------------------------------------
Go MAEDA wrote:
> The subject says "vector", but the embedded Base64 encoded data looks PNG bitmap. Is it correct?
Yes, my bad, maybe vector should be removed from the title, it would be image/svg+xml for pure vector, and then base64 code should actually contain vector info, not raster, as in current patch. I could post an updated patch a tad later just in case, but then again, it's for the gantt, where icon scaling doesn't much matter anyway and raster in form of png would just work fine as well.
--------------------------------------------------------------------------------
Antonio McDeal wrote:
> Marius BALTEANU wrote:
> > Thanks for writing the patch, but I think it's better first to refactor those elements in order to use the regular @icon-*@ classes. Please see #31433, #24313 or the related tickets.
> B b b b but parts of gantt don't really fall into the actual category of UI icons, or do they, aren't those are just patterns? At least I don't see how they could potentially be reusable anywhere else, as those seem very specific. And with case of SVG primitives it wouldn't actually matter, because with the method I proposed you can just always generate your own base64 code and insert it anywhere :D
> > After that, we should wait for a resolution regarding the font awesome icons (#23980) and if FA is not an option, we can explore alternatives (SVG, your solution, etc).
> It's been too many years, I think the idea with font awesome should be forgotten for good, until either JPL will be active again or a more active head of the project would to take over the post. Meanwhile we could already now begin exploring alternatives for something less owner consent dependent, and preparing the ground which could at least serve as a decent temporary solution, then just switch later when and if the time comes.
>
> Font icons anyway seems more like a hack to be very honest, and I came to that conclusion as well recently, so it's definitely either base64 CSS encoded method or SVG method that I think should be used.
I'm confident that will have a positive reaction from Jean-Philippe. FA is not history and I agree with you that SVG are a better option, but in order to implement SVG icons, we need to touch almost every view file (maybe in a next iteration). IMHO, FA icons (or any other font icons) are a better option than base64 images, I'm interested in having available new icons for new features, to control the colour and the size without adding new images and in the end, to minimize the HTTP requests.
> I think even PurpleMine switched to SVG icons which are actually compile-encoded as base64 vectors into the output CSS style sheet.
Can you point me to those changes?

Anyway, it's just my opinion, if anyone else consider these changes useful, I won't opposite.
--------------------------------------------------------------------------------
I've looked at the patch and I think it only 'inlines' the images which are necessary for rendering the gantt chart itself. Background of bars, diamonds, markers, etc. I actually can't see a possibility to replace these images with the icon font proposed in #23980 or are there appropriate icons in FA? IMHO I think they could exist next to each other just fine.
--------------------------------------------------------------------------------