W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2016

[csswg-drafts] [cssom][css-color]

From: Daniel Holbert via GitHub <sysbot+gh@w3.org>
Date: Mon, 10 Oct 2016 19:02:25 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-182089959-1476126143-sysbot+gh@w3.org>
dholbert has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [cssom][css-color] ==
CSSOM has an explicit algorithm for how to serialize CSS values. For 
colors, it says to serialize as `rgb()` vs `rgba()` depending on 
whether they have an alpha of one:

> <color>
>    If <color> is a component of a resolved or computed value, then 
return the color using the `rgb()` or `rgba()` functional notation as 
follows: 
>    1. If the alpha component of the color is equal to one, then 
return the serialization of the `rgb()` functional equivalent of the 
opaque color.
>    2. If the alpha component of the color is not equal to one, then 
return the serialization of the `rgba()` functional equivalent of the 
non-opaque color. 

https://drafts.csswg.org/cssom/#serializing-css-values

This makes perfect sense, in a world where rgb/rgba() syntax differ 
(and where only rgba() allows for transparency).

HOWEVER, css-color-4 is broadening the `rgb()` syntax so that it 
accepts transparent colors.  It only mentions `rgba()` as an 
afterthought, as an alias "with identical grammar" to `rgb`, which 
only exists "for legacy reasons":
https://drafts.csswg.org/css-color-4/#rgb-functions

Now that it's technically possible to serialize transparent colors as 
`rgb()`, should we simplify the CSSOM serialization algorithm to 
always use `rgb()`?  Or should we hold onto its dependence on 
`rgba()`?

And in particular, if an author specifies e.g. `color: 
rgb(10,20,30,0.5)`, are implementations expected to serialize that 
with `rgba` even though the author used `rgb`?

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/585 using your GitHub 
account
Received on Monday, 10 October 2016 19:02:32 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:04 UTC