5 ms·

Because the hex for green (#00ff00) needs more letters than using the named color.

crehn 5y ago
> Because the hex for green (#00ff00) needs more letters than using the named color. But "#0f0" is fewer letters than "green"?
deleted 5y ago
[deleted]
rawling 5y ago
Wouldn't that shorten to #0f0? But "green" is #008000, which doesn't shorten?
- zamadatix 5y ago
  Hmm I wonder which approach is actually better overall when it comes to content-encoding like their own site uses (brotli compression) or client side parsing performance. It's all probably a bit off into the weeds over something like 0.05% performance though.
- chronogram 5y ago
  Ah thanks, I assumed ‘#0f0’ as well. I guess it is length based then.
- yencabulator 5y ago
  #080 is #008800, not #008000. https://en.wikipedia.org/wiki/Web_colors#Shorthand_hexadecimal_form https://en.wikipedia.org/wiki/Web_colors#Shorthand_hexadecim...
dymk 5y ago
That's an... interesting optimization, and one that might make sense if you only care about byte size, but intuition (which might be wrong!) tells me that this will be more expensive (especially if it saves only one or two bytes). I'd bet that browsers can more quickly parse a string like '0x00ff00' into its internal color representation than it can parse the string 'green'. It's probably faster to check for a '0x' prefix and convert hex-encoded ASCII to u8 values, than it is to normalize the string & do a lookup in a dictionary of 147 CSS3 color names, when taking into account the extra two bytes that need to be transferred.
- CognitiveLens 5y ago
  I don't get the sense that runtime CSS parsing is really much of a concern - it's more about build speed and asset size - since 'green' might be used hundreds of times in a large CSS bundle, the optimization might make sense even with an imperceptible speed cost in the browser.
- rattray 5y ago
  I don't have intuition here, but perhaps transferring two bytes over a slow network takes longer than the string normalization and dictionary lookup?
- robocat 5y ago
  More importantly, I would expect #00ff00 to compress better than green, because it would usually make the CSS file more predictably repetitive. Reducing network bytes is usually very important for speeding up loading (at least it is in the boondocks of the internet - out at the rim of the world).
  - ry4nolson 5y ago
    Someone else mentioned this already but "green" is not #00ff00. Tt's #008000.
  - chrismorgan 5y ago
    A related thing that I realised a few days ago about compression algorithms: <!doctype html><meta charset=utf-8> <!DOCTYPE html><meta charset="utf-8"> Compress these with gzip, and the first is smaller than the second (56 and 58 bytes): lowercase doctype because you’re using very few uppercase letters in your document (on slightly larger samples it tends to save a byte or two), and omit the quotes as unnecessary. On larger documents there will be some places where you need quotes around attribute values, but it’s still worth omitting them when you can. LZMA, similar: 60 and 63 bytes. But then compress these with Brotli, and it’s the other way around by a larger margin, 29 and 19 bytes, because Brotli ships a dictionary primed on arbitrary web content. And so it becomes a popularity contest, and an inferior but vastly more popular technique compresses better. In the case of #008000/green/#00ff00/#0f0/lime/#ffff00/#ff0/yellow, the dictionary doesn’t look to bee tainted, so traditional length and repetition wisdom still applies.

> Because the hex for green (#00ff00) needs more letters than using the named color. But "#0f0" is fewer letters than "green"?

deleted 5y ago

[deleted]

rawling 5y ago

Wouldn't that shorten to #0f0? But "green" is #008000, which doesn't shorten?

zamadatix 5y ago
Hmm I wonder which approach is actually better overall when it comes to content-encoding like their own site uses (brotli compression) or client side parsing performance. It's all probably a bit off into the weeds over something like 0.05% performance though.
chronogram 5y ago
Ah thanks, I assumed ‘#0f0’ as well. I guess it is length based then.
yencabulator 5y ago
#080 is #008800, not #008000. https://en.wikipedia.org/wiki/Web_colors#Shorthand_hexadecimal_form https://en.wikipedia.org/wiki/Web_colors#Shorthand_hexadecim...

dymk 5y ago

That's an... interesting optimization, and one that might make sense if you only care about byte size, but intuition (which might be wrong!) tells me that this will be more expensive (especially if it saves only one or two bytes). I'd bet that browsers can more quickly parse a string like '0x00ff00' into its internal color representation than it can parse the string 'green'. It's probably faster to check for a '0x' prefix and convert hex-encoded ASCII to u8 values, than it is to normalize the string & do a lookup in a dictionary of 147 CSS3 color names, when taking into account the extra two bytes that need to be transferred.

CognitiveLens 5y ago
I don't get the sense that runtime CSS parsing is really much of a concern - it's more about build speed and asset size - since 'green' might be used hundreds of times in a large CSS bundle, the optimization might make sense even with an imperceptible speed cost in the browser.
rattray 5y ago
I don't have intuition here, but perhaps transferring two bytes over a slow network takes longer than the string normalization and dictionary lookup?
robocat 5y ago
More importantly, I would expect #00ff00 to compress better than green, because it would usually make the CSS file more predictably repetitive. Reducing network bytes is usually very important for speeding up loading (at least it is in the boondocks of the internet - out at the rim of the world).
- ry4nolson 5y ago
  Someone else mentioned this already but "green" is not #00ff00. Tt's #008000.
- chrismorgan 5y ago
  A related thing that I realised a few days ago about compression algorithms: <!doctype html><meta charset=utf-8> <!DOCTYPE html><meta charset="utf-8"> Compress these with gzip, and the first is smaller than the second (56 and 58 bytes): lowercase doctype because you’re using very few uppercase letters in your document (on slightly larger samples it tends to save a byte or two), and omit the quotes as unnecessary. On larger documents there will be some places where you need quotes around attribute values, but it’s still worth omitting them when you can. LZMA, similar: 60 and 63 bytes. But then compress these with Brotli, and it’s the other way around by a larger margin, 29 and 19 bytes, because Brotli ships a dictionary primed on arbitrary web content. And so it becomes a popularity contest, and an inferior but vastly more popular technique compresses better. In the case of #008000/green/#00ff00/#0f0/lime/#ffff00/#ff0/yellow, the dictionary doesn’t look to bee tainted, so traditional length and repetition wisdom still applies.