There have been a couple of viral tweets about this lately, one from Adam Argyle and one from Mathias Bynes. This is a nice change that makes CSS a bit more clear. Before, every single color function actually needs two functions, one for transparency and one without, this eliminates that need and brings the syntax more-inline with CSS grammar overall.
Lemme remake the code blocks from Mathias’ tweet here:
/* Old Syntax */
rgb(0, 128, 255)
rgba(0, 128, 255, 0.5)
hsl(198, 38% 50%)
hsla(198, 28%, 50%, 0.5)/* New Syntax */
rgb(0 128 255)
rgb(0 128 255 / 50%)
hsl(198deg 28% 50%)
hsl(198deg 28% 50% / 50%)
lab(56.29% -10.93 16.58 / 50%)
lch(56.29% 19.86 236.62 / 50%)
color(sRGB 0 0.50 1 / 50%)Thought party:
- The browser support is pretty good: everything but IE 11.
- If you need IE 11 support, you can preprocess it (or not use it). PostCSS’s preset-env does it as well as the very specific plugin postcss-color-rgb (weird it doesn’t do HSL also).
- If you don’t like it, you literally never need to use it. No browser will ever pull support for such an important feature.
- The reason to switch is muscle memory and consistent-looking codebases as new color functions (e.g,
lab,lch, andcolor) will only support this new syntax. - There is a weird hybrid between old and new. You can pass an opacity value to
rgb()and it still works likergb(255, 0, 0, 0.5);. - If you need it in Sass (which is apparently a pain to support), there is a weird workaround. I would guess Sass will get around to supporting it. If they can’t, this is the kind of barb that drives people away from projects.
- Prettier, which is in the business of cleaning up your code from the perspective of spacing and syntax, could intervene here and convert syntax, but it’s not going to (the Prettier stance is to not change the AST).
- I imagine DevTools will start showing colors in this format, which will drive adoption.
- Remember even hex code colors have a fancy new format.
I am really liking the new syntax.
Have been using it with post-css-env.
It is sad Sass getting harder to use with new css syntaxes.
Same as with css variables I am using the escape method.
Instead the wierd case solution.
CSS selector nesting is incoming and it’ll render SASS obsolete. It feels like it’s a trap to invest in SASS nowadays.
Internet Explorer 11 does not support the comma-free syntax, nor will IE11 support the new color spaces. I have not tested old Android devices.
The point is, if your audience (or your client’s audience) supports IE11 at all, then keep the commas on the RGB syntax. Don’t go through the hassle of re-writing your CSS or your pre-processors for the color spaces IE11 supports (RGB only?).
Instead, rely on progressive enhancement to set comma-laden RGB values that you can then override with comma-free Lab or HSL or whatever.
I am annoyed by this new format.
It is not more clear at all.
Yet another unnecessary change that brings chaos, deprecations, confusions and unnecessary adding/removing commas when copying.
There is no reason why the new format is better. Simply another generation who wanted a change in a wrong place.
Whoa there, friend. It’s all good. No one’s forcing ya to use the new syntax and the others will continue to be supported. Keep calm and color on!
This simplifies stuff quite a bit. No need to add an extra, superfluous, ‘a’ to a color function. I would point out that in hsl the first parameter is in degrees, so the first example shoulder read “hsl(198deg 38% 50%)”. Why is that important? It shows what valid values are expected here (0-360) just as the “%” indicates a value 0-100.