- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Jul 2021 18:14:01 +0000
- To: public-houdini-archive@w3.org
The CSS Working Group just discussed `Color API discussion`, and agreed to the following: * `RESOLVED: Add Color API for representing color points, separate from CSSColorValue to represent CSS color values` * `RESOLVED: Color API should handle all the color spaces currently specced for the web platform.` <details><summary>The full IRC log of that discussion</summary> <Rossen__> Topic: Color API discussion<br> <Rossen__> github: https://github.com/w3c/css-houdini-drafts/issues/1047<br> <fantasai> scribenick: fantasai<br> <fantasai> Rossen_: Do we have a list of issues to resolve on?<br> <fantasai> lea: Chris and I prepared some slides<br> <fantasai> lea: since last time we discussed was confusing<br> <fantasai> lea: Tab, feel free to interject<br> <fantasai> Rossen_: Do we have something we want to resolve?<br> <fantasai> lea: I think it's, do we want to have a separate color API, or do we want to use the CSS color value api for everything in the Web platform<br> <fantasai> lea: Where should work be done, do we have one or two APIs<br> <chris> The readme has some more overview stuff: https://github.com/LeaVerou/color-api/blob/main/README.md<br> <fantasai> Rossen_: Motivation kicking off these things was, we had another review of color-related things with the TAG<br> <fantasai> Rossen_: at the time it was very apparent that we have more and more color discussion<br> <fantasai> Rossen_: they all seem to circle around whether we use color functionality vs type of color vs who is responsible for converting things, who is responsible for caring whether a particular type is safe to take from HTML to Canvas and still making sense<br> <fantasai> Rossen_: Hey, can we take a step back and define<br> <fantasai> Rossen_: First, there's a lot of science and calculations going into color and defining the functionality of color<br> <fantasai> Rossen_: having one place where this is made available to platform would be great<br> <fantasai> Rossen_: Then, if we have this functionality and it is well encapuslated with good APIs, how do we create a type of this and where does it go?<br> <fantasai> Rossen_: Is it a CSS value, is it an object, etc.<br> <fantasai> Rossen_: I'm hoping that here we'll at least arrive and all agree that well, we need all of this stuff<br> <fantasai> Rossen_: and also figure out where it all goes<br> <fantasai> lea: Current situation in Web platform is basically passing around strings, so I think we all agree it needs to be improved and become object-oriented<br> <fantasai> chris: worse actually, it was originall srgb, and now trying to pass around wider-gamut colors as srgb strings<br> <fantasai> Rossen_: let's start with functionality first<br> <fantasai> Rossen_: Chris and lea did a bunch of work to define functionality of color conversion<br> <fantasai> Rossen_: and different color spaces<br> <fantasai> Rossen_: one of the major functional requirements from this effort<br> <fantasai> Rossen_: where is this work currently?<br> <fantasai> lea: Can i switch to the slides?<br> <fantasai> florian: Can you send a copy to www-archive?<br> <fantasai> [slide 2]<br> <fantasai> lea: Colors need to be used as input and output for various APIs (canvas, cssom, input type=color, etc.)<br> <fantasai> lea: also authors themselves want to do things with colors<br> <fantasai> lea: and do many different kinds of color calculations<br> <fantasai> lea: ideally color API would cover all this<br> <fantasai> pierre: Who wants to do this? I think most authors don't want to do this.<br> <fantasai> pal: Likely to be doing wrong, even with API<br> <fantasai> pal: so want to establish who wants this<br> <fantasai> s/pierre/pal/<br> <fantasai> lea: some requirements that Chris and I think important for such API<br> <fantasai> lea: It should be color-space agnostic, not privilege e.g. sRGB<br> <fantasai> lea: It should be compatible with HDR<br> <fantasai> lea: It needs to be extensible<br> <fantasai> lea: a native API is less extensible than a library, but good ot add extensibility<br> <fantasai> lea: And API should follow layered design<br> <fantasai> lea: so usable by non-experts<br> <fantasai> lea: but also useful for experts<br> <fantasai> chris: This is difference between color library we wrote, and color API for the platform<br> <fantasai> chris: our library had everything we could think of that could be useful<br> <fantasai> chris: tries to do everything out of the box<br> <fantasai> chris: but for color API, should be core set, that you can extend if needed<br> <fantasai> lea: Whole debate started a few months ago because there was a proposal by Canvas to accept and produce CSSColorValue objects<br> <fantasai> lea: This is an abstract CSSColorValue that inherits from CSSStyleValue<br> <fantasai> lea: part of typed OM<br> <fantasai> lea: Multiple subclasses that correspond to specific CSS syntactic constructs<br> <fantasai> lea: e.g. CSSRGB that corresponds to rgb()<br> <fantasai> lea: CSSHSL<br> <fantasai> lea: CSSColor that's a color() function<br> <fantasai> lea: each has different API shapes, getters for each argument<br> <fantasai> lea: also different constructors<br> <fantasai> lea: e.g. accepting red/green/blue positional arguments for rgb<br> <fantasai> lea: There's a color space conversion function<br> <fantasai> lea: it's an early-stage spec, no impls yet<br> <fantasai> lea: Advantage of using it everywhere is there would be only one object<br> <fantasai> lea: and good integration with CSS out of the box<br> <fantasai> lea: downsides revolve around the issue that CSS Color Value is designed to represent syntactic constructs<br> <fantasai> lea: not actual color points<br> <fantasai> lea: e.g. there are two variants for rgb<br> <fantasai> lea: one for rgb() fucntion, one for color() function<br> <fantasai> lea: you get diferent objects for these<br> <fantasai> lea: also it's not a string, but csskeywordvalue<br> <fantasai> lea: and coordinates are values, so need to do color.r.value to read the value<br> <fantasai> lea: because this is all for represnting parsed syntax<br> <fantasai> lea: these are not issues that can be solved by iterating on the API design<br> <fantasai> lea: although it has improved a lot since original<br> <fantasai> lea: because it is exiting for syntactic purpsose<br> <fantasai> lea: if we make it easier to use for color points, it will become more difficult for the uses it was designed for<br> <fantasai> lea: Stepping back, chris and I designed a library for color<br> <fantasai> lea: There was CSS meeting where we resolved to learn from this work and design a color API<br> <fantasai> lea: We drafted a spec [links here]<br> <fantasai> lea: ...<br> <fantasai> lea: API has improved quite a lot, even this week, since Tab sent us some very nice feedback<br> <fantasai> lea: Review the design<br> <fantasai> [slide 10]<br> <Rossen_> https://docs.google.com/presentation/d/1Pkcxwdej2nWqYr0F6dYHpxcMaUMb11w_YmbZmcUV6Gc/edit?usp=sharing<br> <chris> links are in the slides which will be sent after the call<br> <fantasai> lea: ...<br> <fantasai> lea: Color spaces represented by colorspace object<br> <fantasai> lea: color.alpha is a number<br> <Rossen_> CSS Color Value draft: https://drafts.css-houdini.org/css-typed-om/#colorvalue-objects<br> <chris> https://projects.verou.me/color-api/<br> <fantasai> lea: right now all mutable, but that's under discussion<br> <fantasai> lea: Color spaces are represented by ColorSpace objects<br> <chris> Draft explainer: https://github.com/LeaVerou/color-api<br> <Rossen_> Color Object draft: https://projects.verou.me/color-api/<br> <fantasai> lea: registried in ColroSpace.register() or can be anonymous<br> <fantasai> lea: would be nice to make happen<br> <fantasai> lea: but difficult to design API to not be less usable for common case<br> <fantasai> lea: color spaces are represnted by ID so don't have to look up objects<br> <fantasai> lea: color spaces declare their white point, coords, gamut, and conversion code to/from existing space<br> <fantasai> lea: so you delcare your base, and provide functions to base and from base<br> <fantasai> lea: this could create a tree of conversions, but in practice it's one or two hops<br> <fantasai> lea: e.g. hsl has base of srgb, but srgb would have a base of xyz<br> <fantasai> lea: I originaly designed to have an ICC profile, but that would make everything async<br> <fantasai> lea: so have a separate API that returns a promise to load profile<br> <fantasai> lea: once registered, cannot unregister color profile<br> <fantasai> [slide 12]<br> <fantasai> lea: have getters to get coordinates<br> <fantasai> lea: and set functions to maniuplate in any color space, which can be relative<br> <fantasai> lea: can be provided by object literal as well<br> <fantasai> lea: Gamut mapping is optional. Every is lossless by default<br> <fantasai> lea: shoudl be able to roundtrip without losses<br> <fantasai> chris: This is needed for ??? e.g. WebGPU<br> <fantasai> chris: if you set up canvas in P3, things might be out of gamut, but need to calculate<br> <fantasai> chris: can always ask to put in gamut if you want<br> <fantasai> lea: There are functions for toGamut mapping<br> <fantasai> lea: by default use LCH chroma, but can be any coordiante in any coordinate space<br> <fantasai> lea: unsure what to do with nonsensical<br> <fantasai> [slide 14]<br> <fantasai> lea: How do declare polar color space?<br> <fantasai> lea: What is a color space?<br> <fantasai> lea: various representations of srgb are all in the same color space, but treated differently...<br> <fantasai> lea: should there be some API level distinction between that and different color spaces?<br> <fantasai> lea: ...<br> <fantasai> lea: But there are some benefits to mutability as well<br> <fantasai> lea: also how to do HDR tone mapping?<br> <fantasai> lea: and what would be interaction between Color API and CSS<br> <fantasai> lea: would registered color spaces become available to CSS?<br> <fantasai> lea: do color spaces declared via @color-profile become registered ColorSpace objects once profile loads?<br> <fantasai> Rossen_: Thanks for clarifying discussion here and providing a lot of synthesized ifno<br> <fantasai> Rossen_: There's a lot of density<br> <florian> q+<br> <Rossen__> Why/who really needs this? Is CSSColorValue of Color object the right way for exposure?<br> <fantasai> Rossen_: The two primary questions that I took away from the discussion and overview are<br> <fantasai> Rossen_: challenge by pal, do we really need this?<br> <fantasai> Rossen_: that's one we can cover quickly<br> <fantasai> Rossen_: other one is, if we can walk away from this discussion with defining if CSS Color Value or Color Object is the right way to move forward<br> <fantasai> Rossen_: details can be worked through in GH issues<br> <fantasai> TabAtkins: Earlier I was a pretty big proponent of doing this all in CSS Typed OM space<br> <fantasai> TabAtkins: after more thought and seeing this proposal<br> <fantasai> TabAtkins: I am convinced that, while we have some open issues that I think those are solvable<br> <fantasai> TabAtkins: I think this would present a substantially more usable API to people<br> <fantasai> TabAtkins: than trying to do it all within TypedOM<br> <fantasai> TabAtkins: And as Lea said, means don't have to contort TypedOM to fit use cases<br> <fantasai> TabAtkins: I've done a bunch of work with color, would have loved to have an API like this<br> <fantasai> Rossen_: One question, does this render CSS Color Value out of the conversation?<br> <chris> Lea's slides: https://lists.w3.org/Archives/Public/www-archive/2021Jul/att-0004/Towards_a_Color_API_for_the_Web_Platform.pdf<br> <fantasai> TabAtkins: We still need to represent color values in CSS via TypedOM<br> <fantasai> TabAtkins: there's just less pressure to do convenience methods in TypedOM<br> <fantasai> TabAtkins: Some things like converting between functions might still do, but don't have to worry about extensibility to author color spaces. Can leave that to Color API<br> <Rossen__> ack florian<br> <fantasai> florian: To me the motivation for this makes complete sense<br> <fantasai> florian: but if have both, will they step on each others toes?<br> <plinss> q+<br> <fantasai> florian: There's other parts of platform also that consume colors, and we'll need to define what kind of colors they consume. Will it be one kind, both? Do we need conversion functions?<br> <fantasai> florian: If every API consumes both and have conversion functiosn.. should one be a library of the other?<br> <fantasai> TabAtkins: What is the preferred shape for color-consuming functions is a key question<br> <fantasai> TabAtkins: wrt conversions, already define how to create one from the other<br> <fantasai> TabAtkins: but whether we end up preferring one for APIs like eydropper or whatever<br> <fantasai> TabAtkins: or say that APIs should handle both, is something need to still answer<br> <fantasai> TabAtkins: make sure TAG is aware of this question<br> <chris> s/for ???/for non colormanaged APIs/<br> <fantasai> TabAtkins: If we only do one, I suspect color api is the one we want to do<br> <fantasai> TabAtkins: but might want to accept both<br> <fantasai> chris: Also point out that while we think of CSS as main consumer, there's also Canvas<br> <fantasai> chris: which has some color spaces not in CSS<br> <Rossen__> q?<br> <fantasai> lea: Also ....<br> <fantasai> lea: You can't always derive specific numbers for a CSS color, e.g. can have a calc() expression<br> <fantasai> florian: Can it be resolved down to a single value?<br> <chris> sRGB-linear and rec2020-linear are the two I am thinking of here<br> <fantasai> lea: What if you have a number that's viewport units divided by pixels?<br> <fantasai> TabAtkins: and if you use 'em' it's element-specific context<br> <fantasai> florian: So you'd need to throw if try to convert and it needs a context but doesn't have one<br> <chris> q?<br> <smfr> q+<br> <hober> q?<br> <fantasai> plinss: Wrt API used in other places in the platform, don't have to solve here, can take to TAG<br> <fantasai> plinss: My take is any input probably fine, but output must be Color API<br> <fantasai> plinss: I'm glad to see both these APIs being developed<br> <fantasai> plinss: What I really want is one object that really focuses on doing color right, and one object that does CSS right<br> <fantasai> plinss: overlap, later<br> <fantasai> plinss: I'm fine with one set of classes if it would be good fit for both uses, but I don't think this is the case<br> <fantasai> plinss: ...<br> <fantasai> plinss: color object should be underlying object for doing the work<br> <Rossen__> ack smfr<br> <smfr> my audio is broken<br> <smfr> will type<br> <smfr> first comment:<br> <smfr> yes<br> <smfr> can hear<br> <smfr> 1. should color objects be immutable?<br> <smfr> must less ambiguity about what happens when live color obejcts change<br> <smfr> maybe design the api initially with immutable colors<br> <smfr> mutability brings lots of complexity<br> <fantasai> TabAtkins: what do you mean?<br> <smfr> i will try to call back in<br> <fantasai> lea: you get a reference to a color object, use it, and someone else changes it, what happens<br> <fantasai> ??: might be useful actually<br> <fantasai> ???: does it animate or what?<br> <smfr> (lost the link)<br> <fantasai> pal: meta question, a lot of this stuff sounds cool and fun, but I'd like to better undertand the target applications and users<br> <fantasai> pal: otherwise black hole<br> <fantasai> chris: ...<br> <fantasai> chris: Risk is we get shipping subsets that are useful only for this or that which is shipping<br> <fantasai> pal: Question of mutable vs immutable, how can we answer the question without understanding the use cases?<br> <fantasai> Rossen__: So question is, is this behind the Color API itself or CSS Color<br> <fantasai> Rossen__: I think we have a pretty good answer<br> <fantasai> Rossen__: once this is answered then we can go after your question<br> <chris> rossen, please suggest a resolution because as you said we are close<br> <fantasai> smfr: If color objects are long-lived and assign them to different things [cut]<br> <fantasai> TabAtkins: API that bends a color, or ... hold a reference to that color<br> <fantasai> TabAtkins: automatically changes the color used<br> <fantasai> TabAtkins: we very specifically didn't do that for TypedOM<br> <fantasai> TabAtkins: and I expect we would conclude the same here<br> <TabAtkins> s/bends/vends/<br> <fantasai> [smfr continues to have audio problems; fantasai suggests dialing in by phone, possibly using the dial-in code in the video app audio options menu]<br> <fantasai> Rossen__: What I'm hearing is the Color object in the way that was proposed by Lea and Chris in that spec and explainer is the preferred path forward<br> <fantasai> Rossen__: Anyone objecting to that path forward?<br> <fantasai> florian: is the use case question about should we have this at all or about design?<br> <fantasai> Rossen__: ok let's take that resolution<br> <fantasai> RESOLVED: Add Color API for representing color points, separate from CSSColorValue to represent CSS color values<br> <fantasai> Rossen__: Next question is do we actually need this<br> <fantasai> pal: That's not my question. My question is who are the users? what are the use cases being targetted?<br> <fantasai> florian: Do you question that there are any? or that if we don't understand the users, we can't do it right?<br> <fantasai> pal: The latter<br> <fantasai> pal: There's many color spaces<br> <fantasai> pal: there's a complete zoo of this stuff<br> <fantasai> pal: NxN issue<br> <fantasai> chris: No, it's not<br> <fantasai> pal: to convert from any space to any other space<br> <fantasai> TabAtkins: That's what the interconnect space is for<br> <fantasai> pal: [gives some complicated example]<br> <fantasai> pal: How can you go through a connecter space?<br> <smfr> q+<br> <fantasai> pal: Lke REC709 are defined from camera, so optical to electrical transfer function<br> <fantasai> pal: but inverse is not defined<br> <fantasai> pal: depends on context<br> <fantasai> pal: not just only math<br> <fantasai> pal: all I'm asking is what are the use cases?<br> <fantasai> pal: what are we trying to do?<br> <fantasai> Rossen__: one obvious use case is to ahve an actual object so we don't pass strings which are typeless and lose meaning from one object to the other<br> <chris> image referred vs scene referred is what Pierre is refering to here, I think<br> <fantasai> Rossen__: I hope we all agree that this is neede for user point of view and perf<br> <fantasai> pal: no question there<br> <chris> There are some taks at the Color workshop about this by the way<br> <fantasai> Rossen__: whether or not this object needs to cover all possible color spaces and their interaction, I think this is more of your line of questioning<br> <fantasai> pal: wrt string vs object, definitely want an object<br> <fantasai> pal: I think that sounds like a great idea<br> <chris> s/taks/talks/<br> <fantasai> Rossen__: so remaining question is, do we have enough use cases that support having color spaces as an API functionality, what are these color spaces, where do we star/tend<br> <fantasai> pal: you define the object<br> <fantasai> pal: question is, do you define reference transformation<br> <fantasai> pal: assume this object has a color space and coords<br> <fantasai> pal: should the web platform define reference transforms between istances of this class associated with various color spaces, and what are they<br> <fantasai> pal: until we've answered what use cases we're targetting will be hard to answer that question<br> <fantasai> pal: easy to go crazy<br> <fantasai> chris: that's why we made this library<br> <fantasai> chris: if just talking about color metric conversion, can have singel transform<br> <fantasai> chris: as soon as ... e.g. hdr to sgr, then ...<br> <fantasai> pal: I don't agree, in case of 709 there's not a singe inverse transfer function used today<br> <chris> q+<br> <fantasai> pal: so web could decide to just pick one. And actually that might really help the world.<br> <fantasai> pal: but not something to do lightly<br> <fantasai> pal: really need to understand retargetting<br> <fantasai> lea: it's OK to restrict the scope at first<br> <fantasai> lea: maybe we decide that some color spaces are out of scope for L1<br> <fantasai> lea: some are already out of scope for current design, e.g. index colors<br> <fantasai> pal: I really like the suggestion<br> <fantasai> pal: maybe for first pass, just replicate everything in srgb<br> <fantasai> pal: make sure everything works there<br> <fantasai> TabAtkins: CSS is already past SRGB, so already need more<br> <fantasai> pal: ok, then pick that<br> <fantasai> pal: If we all agree to moving from string to object, then validate that and grow from there<br> <fantasai> florian: need object we can do something with<br> <chris> https://www.w3.org/Graphics/Color/Workshop/talks.html<br> <fantasai> chris: In few seconds remaininng, questions pal raised, many were covered in the color workshop ^<br> <fantasai> Rossen__: proposed path forward of scoping what we can do here<br> <chris> s/were/will be/<br> <fantasai> Rossen__: scoping to CSS is valid path forward, start from there<br> <smfr> q-<br> <fantasai> Rossen__: where is this work going to happen?<br> <smfr> out of time<br> <fantasai> chris: currently in private repo...<br> <pal> q+<br> <fantasai> Rossen__: ok, open in WICG<br> <chris> q-<br> <Rossen__> ack pal<br> <TabAtkins> It sounds like the hard part of Pierre's question is around more exotic spaces anyway, which are *not* going to be supported as built-ins; they could just be added as author-defined ones, where these choices presumably can be made by the author, right?<br> <fantasai> pal: I think if the goal is to include video and image applications<br> <fantasai> pal: WICG isn't the right place, won't get the right people<br> <fantasai> pal: any color cg or whatever would be good<br> <fantasai> lea: what about a task force?<br> <Rossen__> q?<br> <fantasai> TabAtkins: Point of WICG is to gather the people you need before you choose a venue<br> <fantasai> pal: But WICG is way too high bandwidth<br> <fantasai> TabAtkins: you don't subscribe to everything, you subscribe to the specific repo<br> <fantasai> lea: We don't need all video people, just a few<br> <fantasai> pal: Happy to point ppl to the repo, but they'll also want to discuss it<br> <fantasai> pal: some issues best discussed live<br> <chris> color cg had a lot of good discussion on related topics already<br> <fantasai> florian: Point of WICG is to be a place for "I haven't created a group yet"<br> <Rossen__> q?<br> <fantasai> chris: ... already has the right people<br> <fantasai> chris: but can't do spec work<br> <fantasai> Rossen__: so let's pursue WICG and if it doesn't work, can transition out of there<br> <TabAtkins> fantasai: Seems like we wanna start with at least covering all the CSS and canvas color spaces<br> <TabAtkins> fantasai: So we can resolve on that at least<br> <TabAtkins> fantasai: Even without drafting up a more extensive use-cases doc<br> <TabAtkins> fantasai: and then maybe chris, lea, pierre can draft up the explanation of use-cases that pierre is looking for<br> <TabAtkins> Rossen_: Perfect, TAG loves to see use-cases right at front<br> <TabAtkins> fantasai: So take a resolution?<br> <TabAtkins> Rossen_: objections?<br> <TabAtkins> RESOLVED: Color API should handle all the color spaces currently specced for the web platform.<br> <TabAtkins> fantasai: On process, when do you spin out of WICG?<br> <TabAtkins> Rossen_: when we have impl interest<br> <fantasai> fantasai: We often have the case that things spin up in WICG and never spin out<br> <fantasai> florian: Implementer isn't strictly required, just need a community that is happy to charter the work, however you manage to get that<br> <florian> s/that/that. Implementer interest certainly helps with that, but it's not a formal condition/<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/1047#issuecomment-884390785 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 July 2021 18:14:04 UTC