Re: proposal: css compression via aliasing specification

On Thu, Sep 12, 2013 at 2:24 AM, Barry van Oudtshoorn
<> wrote:
> On 12/09/13 16:38, Joey Bradshaw wrote:
>> I’d like to propose a fairly simple compression specification for CSS.
>> Statistics show that the majority of users to any site will have an empty
>> cache calling for a full download of assets like CSS. With the proliferation
>> of vendor specific prefixes along with the new CSS attributes it is very
>> easy to reach large file sizes (100+KB) causing an unnecessary bite into
>> bandwidth especially for “smart” hand held devices. GZip compression and
>> white-space removal goes a long way to reduce CSS file size but a
>> specification for further size reduction like below would cut sizes down
>> dramatically.
>> The proposal is simply to compress CSS properties and their values through
>> aliasing.
> Is this not what GZIP effectively does in any case? <plug>As someone who's
> written a CSS minifier (</plug>, I'd be
> interested to see what sort of reductions this approach would give over just
> gzipping the file.

Indeed.  Gzipping takes care of precisely this sort of thing already,
and works very well on CSS, as there's a lot of redundancy.  Even if
aliasing *did* help somewhat, I suspect the difference would be
relatively tiny, and probably not worth the large loss in readability.

> To be honest, this sort of sounds like CSS variable (simple substitution) on
> the properties, not just the values. I don't think that that's allowed in
> variables at present (of course, I may be mistaken), but if it were, you
> might be able to get reasonable results with a preprocessor that
> intelligently replaced properties that occur more than x times with a
> variable. You would, of course, have the overhead of having to encode the
> mapping in the file itself (like gzip), but on a large CSS file, the effect
> of that would probably be negligible.

Yes, using variables for property names is not valid.  We might do
something like that in the future, but there's no plans for it at the


Received on Thursday, 12 September 2013 11:12:08 UTC