Closed (works as designed)
Project:
Drupal core
Version:
8.9.x-dev
Component:
Claro theme
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
21 May 2019 at 11:43 UTC
Updated:
11 Jun 2020 at 17:29 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
huzookaI'd say this is a YUI compressor issue: https://github.com/yui/yuicompressor/issues/304
Comment #3
saschaeggi@huzooka as the issue is open for quite some time, I'd rather find an solution on our end. we could use a PostCSS plugin to encode the inlined SVGs to base64. https://github.com/jelmerdemaat/postcss-base64
Comment #4
saschaeggi@huzooka found this https://www.npmjs.com/package/mini-svg-data-uri with an example as an overview of filesizes.
Comment #5
saschaeggi@huzooka: maybe even better we generate an svg spritemap (https://github.com/cascornelissen/svg-spritemap-webpack-plugin/blob/mast...) and use the fragment option. this would reduce the CSS file size drastically and fix the aggregation problem as well.
Comment #6
fhaeberle@saschaeggi This issue turns more into an evaluation of which preprocessing tool to use so maybe we should document the various ideas in other issues targeting icons / SVG handling or change the title and issue summary?
Comment #7
saschaeggi@fhaeberle yes I'd agree. It's still a bug so I'd keep this open to track it. but maybe you can open a new ticket for the evaluation and link this as a related issue.
Comment #8
fhaeberleI think we'll fix this with agreeing and implementing a general approach on how to handle svg / icons in our frontend. Therefore I linked the issue to make the icons more robust cross-browser, which is the ultimate goal which should be achieved by this issue also.
Comment #9
huzookaComment #10
martijn.cuppens commentedWhile base64 SVG images are smaller uncompressed, they tend to be larger when gzipped.
Imo, we should begin with linking to all SVGs like this:
If we do want to use inlined SVG, we can make use of tools like https://www.npmjs.com/package/postcss-svg to inline them. This has several benefits:
- We 'll have a uniform way of handling background images.
- We have a seperation between CSS and SVG
- We can easily tweak the original SVGs if needed
- If we really are convinced base64 is the way to go (personally I'm not), we can set `utf8: false` in the plugin options
Comment #11
bnjmnmIt looks like the PHP port of YUI Compressor fixed this in v2.4.8-p7 , which came out of this issue
According to https://git.drupalcode.org/project/advagg/-/blob/8.x-4.x/advagg_css_mini..., it looks like ADVAGG uses a slightly older version
I updated CSSMin.inc in Advagg and it fixed the issue.

So the best course of action would be to open an issue with Advagg to update
CSSMin.incA meta issue about overall SVG approach will be created shortly, which will reference some of the conversation that took place here.
Comment #12
lauriiiThank you for the research @bnjmnm! I opened #3127422: Update YUI Compressor to a more recent version for AdvAgg.
Comment #13
jwilson3Just adding a note here that I've just provided a minimal working patch to AdvAgg on the issue @lauriii opened above that should solve this problem for most people running a real site with advagg and using the experimental claro theme.