- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Oct 2019 16:52:54 +0000
- To: public-houdini-archive@w3.org
The CSS Working Group just discussed `Current Color as an input to paint worklets`, and agreed to the following: * `RESOLVED: Specify that the PaintWorklet's canvas-ish methods can take color keywords and do the right thing` * `RESOLVED: Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Current Color as an input to paint worklets<br> <dael> github: https://github.com/w3c/css-houdini-drafts/issues/921#issuecomment-546459060<br> <dael> AmeliaBR: Related to what we talked about earlier. About CurrentColor having a computed value of the keyword<br> <dael> AmeliaBR: For typedOM it's supposed to expose computed values, not resolved. TypedOM doens't have a proper model for a color value so for the Houdini APIs that are getting computed values using TypedOM objects they're jsut getting the superclass version.<br> <dael> AmeliaBR: The issue is what happens if your Paint API relies upon a color property and author uses CurrentCOlor. Example: Use Paint API for a fancy border and relying on border color property. What happens if border color is default currentColor?<br> <dael> AmeliaBR: IN Houdini currently that's exposed as a keyword and then in your Paint worklet you'd need to depend on color to get the keyword's value<br> <dael> AmeliaBR: IN shipped Chrome the value exposed isn't a keyword but it's where two string is rgb function which means current Paint worklets are happily using that as a color string they can pass to canvas. but it doesn't match spec<br> <dael> AmeliaBR: Suggestions are first we change the spec to not talk about currentColor as a keyword which means for now currentColor is treated as a vague superclass where all youg et is a string. Eventually when we have a color value class defined currentColor would be represented in the class same as any other color type.<br> <dael> AmeliaBR: Somehow at time we define this we make sure two string value always gives us rgb function when applied to computed style object<br> <dael> TabAtkins: Want to avoid inventing new resolved style. As much as possible I'd like to keep computed style map returning computed styles. That means Chrome impl is wrong and needs to be changed<br> <dael> TabAtkins: Happy with currentColor becoming a CSS color value. It's compat with that. I don't want to have the value coming out of computed style map be a used value.<br> <dael> TabAtkins: It is clunky, but I prefer to provide a function that lets you resolve color values in Paint worklets<br> <dael> AmeliaBR: Other option is to say Paint worklet knows how to resolve keyword values. Covers most cases where someone grabs computed style and uses it directly in the Paint commands. So long as whatever string from typed OM is valid in Paint commands covers most use cases. Wouldn't cover parse and do math, but that's rarer<br> <dael> TabAtkins: Sounds good too. WE can cover all use cases by having Paint API canvas painting methods be able to take contextual keywprds directly and have Paint worklet have a function to manuallyr esolve colors into rgb for you. Then keep computed style map actually a computed style<br> <dael> AmeliaBR: Are you okay...right now there's text in Typed OM that curretnColor is a css value keyword object can we say it returns as superclass css value type even if string reflects string of keyword until color models are specced?<br> <dael> TabAtkins: Yes, I think we should<br> <dael> TabAtkins: Need to make sure system colors do same thing<br> <TabAtkins> 1. Specify that the PaintWorklet's canvas-ish methods can take color keywords and do the right thing.<br> <dael> AmeliaBR: Actual change at this point would be remove all property specific rules in typed om that require currentColor to be returned as a css key value<br> <TabAtkins> 2. Add a PaintWorklet global function that can resolve color keywords into RGB.<br> <dael> AmeliaBR: Separate note for Chrome impl to match spec as far as returning computed values which happens at same time as change to paint API which allows keywords to be used in the paint color properties. That's the other normative change<br> <TabAtkins> 3. Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.<br> <dael> smfr: Other cases where authors want to convert currentColor to rgb? Only Paint worklets sounds limited<br> <dael> TabAtkins: Problem is that if we want computedStyleMap to return computedStyles we're going to have these cases where some values at time being passed can't be resolved further because of state. Layout worklets might want this. OTher worklets are in the same boat.<br> <dael> TabAtkins: Similar to resolving % and other use time values that are useful.<br> <dael> TabAtkins: Colors are resolvable jsut after inheritience so might be a special case that's handled badly by concept of computed values<br> <dael> TabAtkins: UNless we define a 4th value mode and say computed style map returns that I'd rather less conevnient but consistent rather then arbitrary mismatch<br> <dael> AmeliaBR: smfr had good point about universal way to get resolved color keywords relative to context elements<br> <dael> AmeliaBR: WOuld expect that's part of spec how colros work in TypedOM and also part of other color format conversations<br> <dael> AmeliaBR: With that in mind maybe don't do gloabl function in Paint worklet.<br> <dael> AmeliaBR: What we do need in short term is simple case within PAint workelt if you use currentColor it works correctly<br> <dael> TabAtkins: Issue with resolve agaisnt element wedon't pass anything that's an element into a worklet. Can implicitly resolve with a context. I think works for custom Functions<br> <dael> AmeliaBR: Model I suggested in issue for resolving values is that the computed color value object is associated with a palette that defines what color values represent for keywords so it's passed in at that time<br> <dael> TabAtkins: At computedv alue time we don't know that yet. You could say here's the possible values, but you don't know what it ends up as. Unless we have anothe value stage between computed and used we can't express that in a meaningful way<br> <dael> AmeliaBR: When you know computed values you also know value for color and color shceme. From those you know the palatte that desc what kewyrods mean for any other color property<br> <dael> TabAtkins: I think you're right. I take it back. We can call this a computed value that knows it's a keyword, but it knows what it will turn into b/c we know other valyes<br> <dael> TabAtkins: Implies new dependency edges and need to think about how to do those<br> <dael> TabAtkins: I do think there's a path forward<br> <dael> TabAtkins: THe used value time colors should downgrade to generic supercalss. Paint API takes those and acts appropriately. I'll work on how to solve getting you the colors properly<br> <TabAtkins> 1. Specify that the PaintWorklet's canvas-ish methods can take color keywords and do the right thing.<br> <dael> TabAtkins: I listed several things, I'll put 2 to resolve on<br> <TabAtkins> 2. Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.<br> <dael> AmeliaBR: Do the right thing means when you use...<br> <dael> Rossen_: I jsut wanted to know if we were resolving. If not, we can just resolve on these<br> <dael> Rossen_: propsed resolution 1 is Specify that the PaintWorklet's canvas-ish methods can take color keywords and do the right thing<br> <dael> Rossen_: Objections?<br> <dael> AmeliaBR: Do we understand do the right thing in this context? It's using context of element you're painting<br> <dael> RESOLVED: Specify that the PaintWorklet's canvas-ish methods can take color keywords and do the right thing<br> <dael> Rossen_: Second is Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.<br> <dael> fantasai:This is change to typed OM?<br> <dael> TabAtkins: Yes. Currently says it's css keyword and we're going to superclass instead<br> <dael> fantasai: Wasn't point of typed OM is when you ask for comptued you get computed<br> <AmeliaBR> s/css keyword/CSSKeywordValue/<br> <dael> TabAtkins: Yes, which is currentColor keyword. But we used the superclass when we don't have something represented specifically<br> <dael> fantasai: It's a keyword but expose as somethign else?<br> <dael> AmeliaBR: As a generic css computed value where all you can do is expose the string<br> <dael> fantasai: Okay, gotcha.<br> <dael> Rossen_: Prop: Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.<br> <dael> AmeliaBR: All other things will turn into a proposal for L2<br> <dael> TabAtkins: Or L1, but later.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/921#issuecomment-548005719 using your GitHub account
Received on Wednesday, 30 October 2019 16:52:55 UTC