- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 May 2021 16:21:46 +0000
- To: public-houdini-archive@w3.org
The CSS Working Group just discussed `[css-typed-om] CSSColorValue section needs WG review`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-typed-om] CSSColorValue section needs WG review<br> <dael> github: https://github.com/w3c/css-houdini-drafts/issues/1039<br> <dael> leaverou: This was committed in Dec 2020 as editorial. Has stayed in spec and adds a new API. We thought needs wider review. Esp b/c referenced by other groups and prop as accepting inputs for color<br> <dael> leaverou: Back in Dec when posted w/o spec was an API for css syntax. At time had concerns but assured it was not a color object. Chris and I have been working on color object since July<br> <TabAtkins> q+<br> <dael> leaverou: Now saying it should be used as a color object. After review seems unsuitable. need to review if we want this as API for css syntax and what is the scope of the API; syntax or generic color manipulation<br> <dael> leaverou: For second one I have more strong opinions and arguments.<br> <dael> leaverou: Posted some thoughts in issue. Side dsicussion with plinss and chris_ which is fairly long and misleading title. It eveolved into what should this API do<br> <chris_> Lea's comment: https://github.com/w3c/css-houdini-drafts/issues/1039#issuecomment-844185998<br> <dael> leaverou: Using this as a color API for the web I would object. Not focusing on missing functionality, though there are issues. They can be fixed. Not sure a typedOM should be used. Exampe, color object should allow adding color spaces by adding color code<br> <dael> leaverou: css color needs to use numeric objects, not numbers, which makes api clumsy. As input accepts numbers but get output you have to use .value and convert angles<br> <dael> leaverou: Worse, not always concrete. Could be a css math value which is calculations<br> <dael> leaverou: Unclear to me when writing code snippit how I would do a simple color manipulation like lightness if you get back a css math value. What happens when you can't resolve into a number?<br> <dael> leaverou: If we use this object as general color object this complixity needs to be accounted for in author code<br> <chris_> q+ to say this CSS-internals stuff would be inapproriate for WebGPU WebGL, Canvas<br> <dael> leaverou: And because it's css format it needs complex. css rgb or css color object have different shapes. In order to read the color you use different methods. Atuthor code needs to branch<br> <dael> leaverou: Even as API it's awk and that can't change as typedOM object. It's trying to have an API do 2 things<br> <astearns> ack TabAtkins<br> <dael> TabAtkins: First thing, would love wider review. Review from leaverou and chris_ has lead to nice changes. More eyes is always great<br> <chris_> q2+<br> <dael> TabAtkins: For the rest, I think this was too much of an info dump to be done as a late agenda+ or a single issue on the call. I would love to do this as a structured F2F where people can review. I think people tuned out with the list and I want to handle invidivually<br> <dael> astearns: It is a lot of information. Are you interested in arguing for this should be a general color object?<br> <dael> TabAtkins: certainly<br> <lea> q?<br> <astearns> ack chris_<br> <Zakim> chris_, you wanted to say this CSS-internals stuff would be inapproriate for WebGPU WebGL, Canvas<br> <dael> astearns: We could have ahd a quick resolution if generally agreed, but yes would need point by point<br> <lea> q+<br> <dael> chris_: Agree with leaverou about web gpu and type things where this type of css internals don't want this. I don't think they realized an object can be complicated and how many of the details they don't care about as an input. Espe when extended to be an output<br> <dael> chris_: Also feel somewhat mislead b/c lot of discussions about what this is and consensus was this is not a color object and hold back. but then TabAtkins has been promoting this as the color object for the web and even if another was needed it would be complex and no one would impl. Being told to sit back and wait b/c we're not designing it and then whoops it is what we're designing doesn't feel like how it should be designed<br> <dael> chris_: I have a lot of specific concerns about things like color gamut handling which I guess is under general review<br> <dael> TabAtkins: I dispute that I have been disingeuous.<br> <dael> astearns: I would like us to center on technical issues and not on personal issues<br> <dael> chris_: You're right astearns<br> <astearns> ack lea<br> <dael> astearns: Let's just talk about the API itself<br> <fantasai> I think it's fair to say that it's inappropriate to commit an entire API under an editorial commit message and then pretend it was always in the spec without asking the CSSWG for review, though...<br> <dael> leaverou: When it comes to using css color values as input to other apis there doesn't need to be mention in spec. If they stringify they can accept color objects. This isn't about accepting as inputs, but about other uses<br> <chris_> q+<br> <dael> astearns: I apprciate you brought it to the agenda to get more eyes. I do agree this is a little much for a single issue. I'd like to see a lot of this broken out into particular issues that we can discuss separately and not re-work the whole deal<br> <astearns> ack fantasai<br> <dael> astearns: I would appreciate concerns with use on canvas apis to bring it up in those venues<br> <plinss> q+<br> <astearns> ack chris_<br> <dael> fantasai: If we have major concerns with API it should be marked in the draft so it's clear to anyone reading the intended scope and if there are major issues. Maybe if chris_ and lea and TabAtkins can work out a summary of the major points of concern or confusion it would help people reading understand what's in contention<br> <dael> chris_: You're right there are many intertwined issues. Crucial question is what are we designing. Are we designing a color object for the web or a thing specific to css parts of which can be used elsewhere. Without a clear sense of what we're designing it's hard to scope other technical comments<br> <dael> astearns: Can you open an issue specifically on that saying are we designing csscolorvalue as a color object for the web? And particular issues that crop up there will need to be spun out and thye may depend on the general answer.<br> <dael> chris_: Happy to do that<br> <astearns> ack plinss<br> <lea> plinss +1<br> <TabAtkins> q+<br> <dael> plinss: chris_ said a lot of what I want to say. I accep thtis is bigger and needs more discussion and eyes. I'm concerns if we push this to next F2F or a long term period that a lot of work will be done in a direction without us picking one and I don't want to get to where we're stuck<br> <chris_> plinss++<br> <fantasai> plinss++<br> <florian> plins++<br> <dael> plinss: I want to address the meta issue about purpose of these classes before more work gets done leading us down that path<br> <dael> astearns: Happy to convine a meeting specifically on this as well.<br> <astearns> ack TabAtkins<br> <chris_> The more up to date Canvas proposal for WCG and HDR is here https://github.com/w3c/ColorWeb-CG/blob/master/hdr_html_canvas_element.md<br> <plinss> q+<br> <dael> TabAtkins: Wanted to say the scope of current work people are building on is about an input to canvas apis. Accept css values as strings and want to accept as typedOM. Everything you can express in typedOM is possible by putting it in string form so any of those concerns have been present since canvas was introduced. Anything further about this being a general color object should be discussed, but not as pressing b/c no one is building on that in the sh[CUT]<br> <florian> s/plins++/plinss++/<br> <dael> TabAtkins: Let's have the larger discussion when we can prepare and have time for it. No reason to be afraid we're setting anything by not discussing b/c nothing you can do now that can't do in strings<br> <astearns> ack plinss<br> <dael> plinss: I want to agree with TabAtkins in part and rebut<br> <dael> plinss: typedom objects as inputs is non-controversial<br> <TabAtkins> Oooh, I wasn't aware of those impinging on this work. Sure.<br> <TabAtkins> (Our next f2f is sooner than 6 months ^_^)<br> <dael> plinss: Problem is what are we using as the output and that is more pressing. There's eyedroppers and color inputs that tag is reviewing and they output colors and we need to tell they how to input. Need shorter than 6 month answer<br> <dael> astearns: Please continue discussions. New issues will be opened and we'll come back<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/1039#issuecomment-844262116 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 May 2021 16:21:50 UTC