[css-???] Standardise a binary representation for CSS

[ExE-Boss]

JavaFX uses a binary stylesheet format to allow faster loading times when loading styles.

RFC 7049 defines a binary equivalent to JSON and WebAssembly is working to be the binary counterpart to JavaScript.

I’d like to see the CSSWG standarsise a binary format for CSS to complete the above mentioned binary representations.

Pros:

• Faster loading and parse times (as a binary format doesn’t require tokenisation, it’s easier to parse for low memory systems)

[plinss]

See https://github.com/EXIficient/exificient-for-css

Hasn't been much uptake.

[ExE-Boss]

The issue with using EXIficient for CSS is that it’s not as efficient as it could be, given that EXIficient is primarily a binary serialisation format for XML, and therefore it needs to be converted from the XML DOM to CSSOM before it can be used.

[emilio]

I guess a good thing to pitch this would be to prove that CSS parsing / downloading is a significant enough bottleneck for web applications (might or might not be). That's the premise that would justify adding such thing.

The next thing would be to propose a format that is both extensible, and proven more compact / efficient than CSS, and finally design a way to progressively enhance it, that is, that authors could specify a css file as a fallback for browsers not supporting the new thing or what not.

[dbaron]

@darobin might have an opinion here.

[svgeesus]

At least for XML, EXI is best with a tightly constrained vocabulary in terms of content models, attributes, and attribute values. The efficiency drops as soon as new values, attributes, or elements are added.

I guess the same would be true for a binary representation of a CSS stylesheet; it would need a complete list of property names, and the list of property values for each (plus at rules). Given the rate at which CSS changes, this would seem to call for weekly updates to the binary format.

A binary serialization of CSSOM could be interesting, but includes all the properties and values on each node. Selectors plus the cascade and inheritance are effectively a compression step, compared to explicitly listing for all nodes.

[litherum]

This proposal is for a performance optimization. I’d like to see the performance improvement numbers before we pursue this.

[darobin]

Whoa, talk about a blast from the past.

From a very quick look at EXIficient for CSS it does look like it is not as efficient as it could be, but not for the reason listed here. It looks like they made the decision to prepopulate a compression buffer with a number of property names rather than to make them an actual enumeration. This is probably less efficient, though it's more readily extensible. I believe EXI is robust enough to be more compact here while retaining extensibility but I've been out of the loop for almost twenty years. That EXI is Infoset based should not be the issue here; a PSVI view of CSS is probably not that far removed from a CSS AST. (I'm doing a lot of guessing using neurons I thought were dead — watch me move my arms around!)

Taking a step back: before you jump into any discussion of binarification, you want to know what it is that you're optimising for. Optmising network speed and processing speed for instance do not involve the same techniques, and some are in tension with one another. It's old, but I would recommend taking a good look (with goggles that forgive some of the worst injuries of time, a bit like those you use to watch an ABBA video) at the XBC framework:

First there are properties that define a format: https://www.w3.org/TR/xbc-properties/. I think a lot of these are more or less reusable as-is (and many you wouldn't care about for CSS) though it's worth taking a bit of time to think about properties that might make sense for CSS that aren't there.

Then there those properties are mapped onto a set of use cases: https://www.w3.org/TR/xbc-use-cases/. I think this would definitely be a lot simpler for CSS. This is just use cases as per usual, but having the language of properties available really makes thinking of the performance trade-offs easier (because perf questions trigger all kinds of instinctual knowledge in geeks that are almost always wrong).

We had a theory of how to measure all properties (https://www.w3.org/TR/xbc-measurement/). It's fun, but you can probably skip most if not all.

Finally you bring it all together: https://www.w3.org/TR/xbc-characterization/.

Now for the potential shortcuts:

• Have you considered a super simple TLV format? I would guess (but it really is a guess) that CSS's human-friendly syntax might contribute to making it slower. TLV formats tend to be stupidly fast to parse. You could look at prefixing it with a dictionary so as to internalise the strings but that might not gain you much. (In size, running gzip on top of TLVed CSS would almost certainly take care of that better than you will.) Note that TLV can still allow implementation to compete on compression: if they can be smart about how they group and reorder properties for instance, there could be differential gains from a gzip pass on top.
• WASM. I'm seriously out of the loop on this but nothing's faster than highly-optimised code you already have. Are there bits there that could be reused here?

Please take all of the above with a grain of salt. What I do these days is analyse how legal decisions impact marketing technology and pontificate about virtue ethics — I'm a bit rusty on the compression front.

But hey, if you're going to use EXI you might as well switch the whole thing to XSL:FO and — I'M JOKING!