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