GNOME Bugzilla – Bug 783148
glib-compile-resources: Add preprocessor to minify CSS
Last modified: 2018-05-24 19:37:04 UTC
g-c-r already provides the xml-stripblanks option for the preprocess attribute, widely used to compress .ui files before embedding tem in the binary. Another common type of file put into GResources is CSS files. Like .ui files, often a substantial portion of their content is technically useless whitespace, comments, etc. Using the compress attribute helps, but it still has to compress all the cruft, and decompressing it takes extra time (probably not really an issue). Either way, the performance would be better if there was less to store. Currently, to get rid of the unnecessary and bloaty content in the GResource, we must use an external tool to strip the original CSS files and then compile the result of that. This requires a pile of extra stuff in the build system files. So it would be great if g-c-r itself had a built-in preprocessing option to strip superfluous content from CSS files before putting them in the GResource. As a reference, at the moment I use yui-compressor - http://yui.github.io/yuicompressor/ - which removes the following: * whitespace * comments * the final semicolon in any block * reduces 6-digit colours like #003366 down to #036 * trailing units on 0 quantities (IIRC), e.g. 0px => 0 I believe yui-compressor doesn't, but that leading zeros in decimal numbers can also be omitted: http://hey.georgie.nu/leadingzero/ A lot of this would boil down to simple regex removals, though I've not sat down and worked through it yet; possibly some parts are not so simple. But an example set of replacements of this form is shown here: http://madskristensen.net/post/efficient-stylesheet-minification-in-c
On a related note I've wanted the same for JS. If we gained an external (optional) dep on something like `yui-compressor` it looks like it supports both.
Oh yui-compressor seems like a fairly large Java dep so perhaps not that specific tool.
not sure we want to encode dependencies on tools outside the gtk stack in the syntax of gresource files. If we do something here, it should perhaps be a generic preprocess-with-this-tool option. But: are we sure it is really worth it for css files ? Does this show up on any profiles ? If so, we can probably speed up the gtk css parser
Thanks for the replies! (In reply to Matthias Clasen from comment #3) > not sure we want to encode dependencies on tools outside the gtk stack in > the syntax of gresource files. True, ideally this would be built into g-c-r or use functionality elsewhere in GLib/GIO. However, xml-stripblanks already introduces such a dependency by using xmllint. > If we do something here, it should perhaps be > a generic preprocess-with-this-tool option. That would certainly save a bit of hoopla in the Makefile, although all of these ways of delegating to external tools still complicate build setup. > But: are we sure it is really worth it for css files ? Does this show up on > any profiles ? If so, we can probably speed up the gtk css parser I would certainly be interested to hear from users who have larger and more resource-intensive applications, whether they detect any bottlenecks in de/compression or parsing. Since Patrick mentioned JavaScript, I wonder if that becomes relevant too. Still, I should state up front that I have no measurements. It's just a 'nice to have' idea, based on how we already (kind of) support stripping XML, and might conceivably be able to do so for other formats. For me, it's more of an abstract concept of reducing files to the minimum relevant content. That motivation might be uncommon and unimportant enough that g-c-r itself needn't handle this, so I should just carry on doing it myself, which is fine if so. However, since a precedent exists, and in case anyone else has some concrete rationale for it, then hopefully it was worth bringing up for discussion.
I do think JavaScript is the more interesting target since literally the entire codebase of a gjs application is in GResources. I imagine most of the CSS load is in the Adwaita theme itself rather than end applications so minification can happen at that central point.
I've updated the title to make this more general
We could just do what is already done with xml-stripblanks invoking xmllint - if there was a common, dependency-light minifying tool covering these formats. But from what I can find on a quick search, most/all such tools seem to require Java or node.JS or some similarly heavy framework. Hopefully that's not universally true and a good C/C++ one does exist in an accessible form for various platforms.
The original C implementation of jsmin is a few hundred lines of code, sadly it has an invalid license.
(In reply to Daniel Boles from comment #4) > True, ideally this would be built into g-c-r or use functionality elsewhere > in GLib/GIO. > > However, xml-stripblanks already introduces such a dependency by using > xmllint. Yes. But lets not go further down that road.
Bug #794284 handles JS. Let’s reappropriate this one for CSS only.
I was thinking of JS code overall. Doesn't that only cover the JSON subset?
(In reply to Daniel Boles from comment #11) > I was thinking of JS code overall. Doesn't that only cover the JSON subset? Correct. If you have a feasible plan for a way to minify JS as well, please open a separate bug. I don’t think combining all of the possible things we could minify into one bug report is going to help it get implemented.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1272.