- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Oct 2020 14:51:13 +0000
- To: public-css-archive@w3.org
All dealt with, CSSWG resolutions implemented, see see [Serializing alpha values](https://drafts.csswg.org/css-color-4/#serializing-alpha-values) and [Serializing sRGB values](https://drafts.csswg.org/css-color-4/#serializing-sRGB-values) > SO: now that rgba() is a legacy alias, and it's trivial to serialize transparent colors with rgb(), should we simplify the CSSOM serialization algorithm to always use rgb()? Or should we hold onto its dependence on rgba(), for backwards-compat purposes with websites that might expect the old serialization behavior? CSS WG decided to go with legacy compat as much as possible. So values with a fully opaque alpha are output as `rgb()` while any other alpha value is output as `rgba()`. Also for compat, the serialization uses the older, comma-based syntax. Again for compat, values are output in a 0 to 255 range, but as `number` so 127.5 is legal; and with mandatory trimming of trailing zeroes and any trailing decimal point. Thus `32.000` gets output as `23` which is fully backwards compatible for values originally specified with 0-255 integer components; while still allowing higher precision for values originally specified as the percent form. > 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? They are now, yes. @dholbert do these edits resolve all of your concerns? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/585#issuecomment-718805090 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 October 2020 14:51:16 UTC