Re: [css-houdini-drafts] [css-paint-api] Current Color in context (#921)

> Btw, I tried to access to `styleMap` in Chrome but I don't get anything.

The name `styleMap` is just an example from the specs, the name you use will depend on how you name the parameters in your `paint` function. In the examples later in the spec, they are named `properties`.  Either way, it is the third parameter passed to your `paint` function.

That allows you to get a [`CSSStyleValue`](https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue) object representing the color value. _But_, the Typed OM spec doesn't yet define a specific type for a CSSColorValue object, so you need to parse the string value yourself.

I put together a demonstration, to test out how difficult it was to do (parsing the color string is the worst part) & to see how an explicit `currentColor` value messes things up: 

- Code: https://glitch.com/~obsidian-suit
- Result: https://obsidian-suit.glitch.me/

Chrome, it turns out, still returns RGB values for `currentColor`, so there's nothing special there.  (This isn't Paint-specific, you can also see it if you call `computedStyleMap()` on the element from the main document.) But, if they matched the spec and returned `currentColor` as a CSS keyword value, then you wouldn't be able to do any color math whatsoever.

Thinking over what to do about this when we actually _do_ define `CSSColorValue` types:

`currentColor` is defined to be a keyword at computed time so that it _inherits_ as a keyword. But there isn't any reason that the actual color value can't be known at computed time.  Maybe it would be better to think of `currentColor` in Typed OM as a full color object (e.g., that represents a specific RGB color) that _also_ has a flag that says "but this is a `currentColor` special color" for inheritance and serialization.

Until we figure out the best way to handle CSS colors that inherit as keywords (which may one day include [other keywords](https://github.com/w3c/csswg-drafts/issues/3847)), **I think we should remove all the property-specific rules in [CSS Typed OM](https://drafts.css-houdini.org/css-typed-om-1/#reify-property) that require `currentColor` to be returned as a `CSSKeywordValue` object.**

There's clearly no web-compat obstacle to changing it at this point. And we may have web compat problems in the future if Chrome tries to follow the current spec, since that would break paint worklets that are using `currentColor` as a value to regular CSS properties that are then input into the worklet.

I don't know what an ideal Typed OM representation of `currentColor` (or `buttonFace`) will be, but I think it should be a subclass of a `CSSColorValue` object, not a generic keyword. (Also, if the decision is to handle it as a keyword, that shouldn't be dealt with via "property-specific rules", but by general rules for handling computed values of colors.)

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/921#issuecomment-513961289 using your GitHub account

Received on Monday, 22 July 2019 21:26:24 UTC