W3C home > Mailing lists > Public > www-style@w3.org > July 2021

[CSSWG] Web Platform Color API Discussion

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 26 Jul 2021 14:55:27 -0700
To: www-style@w3.org
Message-ID: <c767ff09-cad6-2d08-de49-338dfaf85c35@inkedblade.net>
=========================================
   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

This archive was generated by hypermail 2.4.0 : Monday, 26 July 2021 21:55:48 UTC