W3C home > Mailing lists > Public > public-css-archive@w3.org > January 2017

Re: [csswg-drafts] [css-ui] Computed value of currentColor

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Wed, 25 Jan 2017 03:14:50 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-275008169-1485314088-sysbot+gh@w3.org>
@svgeesus 

As discussed at the Seattle F2F, there is some overlap between 
https://drafts.csswg.org/cssom/#serialize-a-css-component-value and 
the definition introduced by #871.

#871 is more specific / clear about which color should resolve to what
 at what time, but cssom is more specific about how to serialize the 
various functions once you've decided to do that.

Fixing this redundancy by having css-color-4 just keep the high level 
logic, and defer to cssom for the string level details of how to 
serialize the value does not seem particularly good to me, as 
presumably the new functions added to css-color-4 (and later) will 
have their serialization in css-color-4 (and later), and then you need
 to look up to multiple specs to have the full picture.

What I think would be nicer is:
* inline the the details that currently live in cssom into css-color-4
* have css-color-4 normatively state that it supersedes cssom on this 
topic
* leave cssom as is, so that more mature specs along TR that refer to 
it and don't want to switch css-color-4 can keep on doing so (and 
maybe add a note informatively pointing back to color-4).

The remaining question is then how to port that back to css-color-3, 
which I think we need to for two reasons:
* what css-color-3 says about color computed values and serialization 
is inaccurate and contradicts level 4 / cssom / implementations
* specs like CSS-UI which wants to refer to this just need the 
anchoring terminology, not the new color functions, and for TR 
progress purposes would rather depend on color-3 (which is a REC) than
 color-4 (which is an ED).

The easiest way to do that is to duplicate the level 4 definition, 
simply omitting references to notations that don't yet exist in level 
3. But I am not sure what that means in terms of process. Is an errata
 enough? do we need to cycle back to CR/PR/REC? Errata sound 
sufficient for correcting the serialization, but not for introducing 
the new anchor terminology.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/741#issuecomment-275008169 
using your GitHub account
Received on Wednesday, 25 January 2017 03:14:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:37 UTC