Resolving colors #871
Resolving colors #871
Conversation
|
Agenda+ to discuss if this is the way to go, and if tweaks are needed. |
| 4 and 8 digits <a>hex colors</a>, | ||
| comma separated ''rgba()'' colors with an alpha channel, | ||
| and comma separated ''hsla()'' colors with an alpha channel, | ||
| is the equivalent numeric value in comma separated ''rgba()'' notation with the alpha value. |
There was a problem hiding this comment.
This doesn't match what browsers currently do. Browsers use rgb() for opaque colors even if the color is specified from rgba(). See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4780
There was a problem hiding this comment.
Thanks. Added a new commit to reflect that.
css-color/Overview.bs
Outdated
| so descendants will use their own 'color' property to resolve it. | ||
|
|
||
| <li> | ||
| The computed value and used value of ''<color>/transparent'' is ''rgba(0,0,0,0)''. |
There was a problem hiding this comment.
Should be rgba(0, 0, 0, 0).
FWIW, it seems for all colors whose alpha channel is zero, Gecko returns transparent as the resolve value, which may make some sense given they are effectively the same for rendering. But other browsers' behavior that returns the rgba value seems to be better regarding consistency.
There was a problem hiding this comment.
I am not a huge fan of that behavior, but that's indeed what gecko does. Added an issue to call it out, so that we don't loose track of this difference and remember to resolve it later.
There was a problem hiding this comment.
Oh, probably I should use "BTW" instead of "FWIW" here. The main issue I want to raise here is a small editoral issue that there should be a whitespace after each comma. rgba(0,0,0,0) without whitespaces doesn't match any browser, and could cause confusing.
| Percentages: N/A | ||
| Media: visual | ||
| Computed value: an RGBA color | ||
| Computed value: See <a>resolving color values</a> |
There was a problem hiding this comment.
I think this is actually wrong for the color property, since for color, currentColor should be resolved at computed value time. (I can't think of how this is observable today, but I'd much prefer it be defined this way.)
There was a problem hiding this comment.
I've fixed the definition now, so this reference should now be fine.
svgeesus
left a comment
There was a problem hiding this comment.
Please don't add inline issues; issues should be on GitHub and just linked from the spec.
| Note: Multi-word keywords in CSS usually separate their component words with hyphens. | ||
| ''currentcolor'' doesn't, because it was originally introduced in SVG | ||
| ''<color>/currentcolor'' doesn't, because it was originally introduced in SVG | ||
| as a special attribute value spelled "currentColor", |
There was a problem hiding this comment.
No, it was introduced as a property value (and properties in SVG can be expressed in presentational attributes, as well as in style attributes, style elements, and external stylesheets).
|
|
||
| <li> | ||
| The computed value and used value of ''<color>/transparent'' is ''rgba(0,0,0,0)''. | ||
| The computed value and used value of ''<color>/transparent'' is ''rgba(0, 0, 0, 0)''. |
There was a problem hiding this comment.
Maybe worth calling out explicitly that the serialization syntax (with commas) differs - for historical reasons - from the comma-less syntax which CSS4 color is now using (commas now being reserved for lists of alternatives).
|
Merging because reviews seem generally positive and review comments have been addressed. My comments about inline issues can easily be fixed later and should not hold up a merge. |
This is a proposal to resolve the lack of a generally usable definition for how colors, and in particular
currentcolorare turned into computed values, used values, inherited...This should help address #741, #480, and #867 (and maybe other issues I am not aware of).
If we agree on the concept, we should probably try to backport the relevant subset of this to css-colors-3. I can do this as an update to this PR or as a separate one, as the WG / editors prefer.
I have for now left undefined (and marked as an issue) the computed values of the functions that are not yet implemented. We should have that discussion as well, but it need not delay the introduction of the general concept and anchoring terminology.
For the functions that are implemented, the definition I provided is based on my observations of current inter-operable behavior.