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