Cascading Style Sheets (CSS) Working Group Teleconference

21 July 2021


alisonmaher, argyle, bkardell_, bradk, castastrophe, cbiesinger, chris, chrishtr, dandclark, dbaron[m], dholbert_, dlibby, emilio, fantasai, GameMaker, hober, jfkthame, lea, miriam, Morgan, oriol, plinss, rachelandrew, Rossen_, sanketj, smfr, TYLin

Meeting minutes

<Rossen_> Rossen: we'll give it couple of mins and start at :02

<Rossen_> dholbert_: it happens to all of us

<Rossen_> https://wiki.csswg.org/planning/virtual-july-2021

Rossen_: Reminder about the vF2F

Rossen_: Please add yourself to the wiki

Rossen_: and add items for agenda

Rossen_: Any changes to agenda?

lea: Reminder that Color API breakout is right after this call


Rossen_: css-fonts-4 and css-fonts-5

github: https://github.com/w3c/csswg-drafts/issues/6462

Rossen_: I looked over changes, seems fine

Rossen_: Any objections?

Resolution: Republish CSS Fonts L4 and L5

Rossen_: Next is updated WD for CSSOM

<chris> note some broken link issues that need to be fixed before publication https://github.com/w3c/csswg-drafts/issues/6463

Rossen_: some PR merged recently

Rossen_: emilio, chris any thing holding back?

chris: Some broken links, don't know what to replace with

github: https://github.com/w3c/csswg-drafts/issues/6446

emilio and chris will look into it

Rossen_: Any objections to republishing?

Resolution: Republish CSSOM

Highlight API

Multiple Document Highlights

github: https://github.com/w3c/csswg-drafts/issues/6417

dandclark: Issue is Highlight API doesn't cases where multiple highlight trees and multiple documents interact

dandclark: e.g. in same-origin iframes, ranges can be passed back and forth

dandclark: Should we be allowed to have highlight covering ranges in different windows?

dandclark: Can a single highlight cross documents?

dandclark: Could reject these cases by throwing

dandclark: I would propose something different

dandclark: I have a 3-part proposal

<GameMaker> Dan Clark is talking, not dandclark

dandclark: 1st, should allow highlight to contain ranges from multiple trees

dandclark: 2nd, allow highlight to be added to multiple registries

dandclark: might mean tracking multiple highlight registries for each highlight

dandclark: When a highlight registry painting, will only paint highlights associated with that document

dandclark: If it finds a range in another window/iframe, it does not reach over there and paint there. Only paints within its own document

dandclark: Wanted to get people's thoughts on this proposal

smfr: proposal seems to be the most complex version of the solution, allowing highlights to involve multiple documents and allowing them to live in multiple registries

smfr: What's the reason to avoid the simpler solution, of restricting to single document and single registry

dandclark: Philosophical whether to reject early or to be more permissive

dandclark: If I create a highlight but don't give it any ranges, is it associated with that document?

dandclark: ...

dandclark: Do I need to do comparison whether new ranges in another document?

dandclark: Some interesting cases there I don't know how to work through

dandclark: We could say something like highlight is associated with document that created it

dandclark: and registry associated with that document

dandclark: and if try to insert range from another document, throws

<TabAtkins> fantasai, stop associating all this with dandclark, it's dandclark

smfr: That would be my preference for the first version

sanketj: Seems fine, pref for first version. If necessary could add these abilities later.

sanketj: Need to define which exception to throw

sanketj: different documents, multiple registries, and multiple ranges to single highlight, need to define exception for each of those

sanketj: might be simpler to allow those cases and don't paint the ranges in different document

<emilio> (sorry, no mic) Strongly prefer associating it with the creator document and throwing on mismatches. There's precedent for this w/ constructable sheets, FontFace, etc

<TabAtkins> Agree with emilio - we already have a decent precedent to only allow same-document usage.

Rossen_: Any other comments/feedback?

<GameMaker> I also agree et. all with throwing

sanketj: If we are throwing, do we want just one exception or separate exceptions for each case? Seem like slightly different operations

TabAtkins: I think they all boil down to same category

TabAtkins: using something in a wrong context

Rossen_: if this proposed path forward works for you, suggest go back to GH and work out the details in terms of exceptions

Rossen_: once all happy, come back and we can resolve

Rossen_: unless you feel strongly on resolving this path forward now

dandclark: Sounds good, thanks

Rossen_: proposal is that we associate with creator document and throw on mismatches

<sanketj> SGTM

Rossen_: any objections?

<dandclark> +1 to resolution

Resolution: highlights associated with creator document. Throw on mismatches when registering ranges/etc.

highlights and default values for styles

github: https://github.com/w3c/csswg-drafts/issues/6417

github: https://github.com/w3c/csswg-drafts/issues/6375

dandclark: CSS Pseudo specifies default values for certain native highlights. Should there be any defaults for custom highlights?

sanketj: Since these are author-defined highlight, don't think should define any styles in UA styles

sanketj: also no way to do this

sanketj: Seems better to let it just inherit from originating element

sanketj: Might want to make explicit that UA should not give default styles

<TabAtkins> fantasai: I agree with this

fantasai: Doesn't make any sense for UA to add default styles to custom highlights

Rossen_: Any objections?

Resolution: UA does not add any default styles to custom highlights

Compressible Elements with Aspect Ratio

github: https://github.com/w3c/csswg-drafts/issues/6341

TabAtkins: Forgot to discuss this last week...

iank_: I won't be around next week

github: none

Rossen_: Anything urgent?

iank_: patch waiting in my queue is all

TabAtkins: I just haven't had a chance to think through it. Though you're probably right anyway

Order property definition

github: https://github.com/w3c/csswg-drafts/issues/5865

TabAtkins: Brought up that the definition of order only mentions flex items, but also applies to other layout modes (grid at least)

TabAtkins: so we should be generalizing this property, but then where should it live?

TabAtkins: We think Display is the most appropriate place for it

<rachelandrew> +1 for display

TabAtkins: Would like resolution to move it to Display, unless someone has a better idea

Rossen_: Feedback or other opinions?

smfr: Seems fine

<emilio> Display or maybe position sounds good

Rossen_: objections?

Resolution: Move order property to Display module

Indefiniteness when sizing grid track inside flex item

github: https://github.com/w3c/csswg-drafts/issues/4852

oriol: Case where we don't have interop between FF and Chrome

oriol: When have column flex container which has for example height set to some value bigger than the content

oriol: This flex item has a flex that causes it to expand

oriol: and this flex item is also a grid container

oriol: which contains an auto row

oriol: usually auto rows, if you have free space at end of track sizing, they are expanded to cover this extra space

oriol: specifically for the case where we set the height property, we have interop

oriol: but instead of setting height on flex container you set min-height, in Chrome the auto height doesn't grow

oriol: At first I was confused and thought Chrome was right, but actually after some feedback from iank_ I think it's actually Firefox which follows the spec

oriol: iank_ also said that he's willing to change Chrome to adapt to what FF is doing

oriol: So I guess we can close this no change, agreeing that Firefox is the right behavior

Rossen_: comments/objections?

iank_: ...

fantasai: I think authors would be happy with this resolution

Resolution: close no change, firefox is correct

Does definite flex-basis always cause main size definite?

github: https://github.com/w3c/csswg-drafts/issues/4311

TabAtkins: There's an example in the issue

TabAtkins: Column flexbox with a flexible child

TabAtkins: child has a definite height, but it is flexible so can become larger or smaller

TabAtkins: Flex item has a child with a percentage height

<TabAtkins> my phone hung up, one sec


<TabAtkins> welp

fantasai: Spec says this case is indefinite, and percentage won't resolve

fantasai: But implementations do resolve

fantasai: so should we change the spec to match implementations?

iank_: I think all of the implementations are following the spec here

iank_: in that they are not resolving ...

cbiesinger: Not true

cbiesinger: Testcase is red, which means it is resolving

cbiesinger: Interesting thing here is that the percentage would resolve outside a flexbox

cbiesinger: it doesn't resolve if you put it inside the flexbox (per spec)

cbiesinger: I doubt authors expect that

fantasai: Originaly definiteness was identifying cases where percentages are very simple to calculate

fantasai: and we restricted percentage resolution to these cases

fantasai: but authors would be happier to resolve more often

fantasai: so if implementers are already doing it, might as well match the spec

iank_: this seems fine to me

fantasai: does mean that concept of definiteness is more complicated

cbiesinger: Want to mention, in Chrome we only take into account the width/height property, not the flex-basis. But that's probably a Chrome bug

Rossen_: Do we know if this is safe to change?

fantasai: Planning to match spec to implementations, so shouldn't have any concerns

jensimmons: Seems folks doing a good job of raising flex bugs and addressing them

jensimmons: Would love to ask if filing bugs against WebKit as well, seems our implementation is same as Chrome

iank_: No bug required here, spec is aligning ot implementations

jensimmons: on this issue, but not last one

cbiesinger: should be a wpt test also

Rossen_: WPT tests should raise to webkit

<jensimmons> no

dholbert: Wanted to clarify what the proposed change is here. Are we making the spec match implementations in this case?

<cbiesinger> I think change is: definite flex-basis makes the size definite, even if the item is flexible

dholbert: I think that doesn't match what we do

dholbert: It might be that this case is triggering a more subtle situation

fantasai: That's interesting, we should investigate

dholbert: I think intent of our behavior is to match the spec

dholbert: We do check if flex item is flexible when testing for flexible flex-basis, to see if we want to make item definite

cbiesinger: I feel like you and I had a discussion about this years ago and you were going to match our behavior

dholbert: We fixed a number of bugs in last 6 months also

dholbert: so maybe previously did something more esoteric

fantasai, rossen: maybe need to go back to GH to figure out

single-color scrollbar-color

github: https://github.com/w3c/csswg-drafts/issues/5651

<lea> sorry, was muted

<TabAtkins> fantasai: so one thing discussed is whether scrollbar-color should accept a single color, auto-generating the second color from the first

<TabAtkins> fantasai: another is around allowing 'auto' as a keyword in the two-value syntax, explicitly triggering auto-generation of the other color

<TabAtkins> fantasai: We put it on the agenda to ask if there was interest in allowing this

<emilio> I'd prefer not to add this unless there's strong author demand for it

<emilio> Not opposed per se but...

lea: I think there should be some defined algorithm for UA to generate other color

lea: reasonable for authors to define which color they want to alter, and UA to define other color

lea: Would prefer that option rather than specifying only one color and having magic other color

TabAtkins: note that the spec currently requires two colors, so we'd first have to agree to allow only one color before the rest becomes relevant

lea: Should be possible to specify one color

smfr: Wanted emilio to clarify, want single color to be invalid?

emilio: So far, Firefox requires 2 colors, and I haven't seen anyone particularly complain about that

smfr: I'm not opposed to a single color, but some ambiguity around whether lightening or darkening to generate the other color

smfr: esp with dark mode

smfr: might need to specify somehow

<TabAtkins> I'm on the side of "just have the author provide both" (aka no spec change), I think

lea: wrt dark mode and whether UA darkens or lightens

lea: that has to depend on the color as well

lea: defined which direction to go, then what do you do when author specifies black?

smfr: That's my point, there has to be a defined threshold where UA flips lightening vs darkening

smfr: maybe dark mode is not relevant, mayb authors provide different colors

lea: I think we're discussing minutiae of specifying a single color

lea: but there's no consensus on whether this is desirable

emilio: Same issue that smfr mentions is already a thing with accent-color

emilio: Scrollbar-color already needs to synthesize other colors, e.g. for :hover effects

emilio: If there's a strong desire to auto-generate track color... I'd rather not

emilio: Authors might get what they want in some browsers and something different in other browser

smfr: Ideal way to specify would be to just use color-5 functions

smfr: Similar to ridge/groove situation

<TabAtkins> Yeah, unlike accent-color, this is a place where we absolutely know where and how each color is going to be used. Auto-generating colors would be purely a convenience, not a necessity like in accent-color.

fantasai: main question is, do we want to do this or do we want to defer

Rossen_: what's the consensus?

smfr: I think it's nice to have, but fine to defer to scrollbars-2

emilio: same

Rossen_: proposed to defer to l2, any objections?

Resolution: Defer to L2

Rossen_: Encourage folks to engage on the issue and continue discussion there

stick scrolbars

github: https://github.com/w3c/csswg-drafts/issues/2252

Rossen_: Asking if possible to have position:sticky horizontal scrollbar

<TabAtkins> fantasai: this issue is a clear case of an unofrutnatue user situation

<TabAtkins> fantasai: Very large code block, with overflow:scroll so you can scroll horizontally, but it's also tall enough that the horizontal scrollbar is off the screen

<TabAtkins> fantasai: Person trying to read has to scroll down to reach the scrollbar, scroll horizontally, then scroll up to see the content

<TabAtkins> fantasai: Which is a very bad UX

<TabAtkins> fantasai: So wondering if there's a way to make a horizontal scrollbar stay "above the fold"

<TabAtkins> fantasai: florian and i discussed this; you can't just position:sticky the scrollbar (it doesn't exist)

<TabAtkins> fantasai: Maybe we can do something else

<TabAtkins> fantasai: Or maybe it's just quality-of-implementation, and browsers could handle this themselves

smfr: seems only case for ...

TabAtkins: No, if the box is tall enough, this is a problem

smfr: That's 2 separate scrollers right? document scroller and inner scroll container

TabAtkins: right, but document scroller isn't caausing it

TabAtkins: the problem is the inner scroller is too tall to be visible within outer scroller

smfr: I understand the problem

smfr: quality of implementation seems difficult

smfr: UA wouldn't know whether to add sticky scrollbar, might obscure some other content

smfr: Other solution might involve...

smfr: need to think about it

Rossen_: maybe continue conversation back in issue, come back to it next week or afterwards

<florian> ε-present+


<argyle> can the zoom link get shared here? i just tested 2 i had and neither seemed correct

<smfr> zoom

<hober> I tried to join the color meeting, but zoom said the meeting was being recorded and by joining i would be consenting to it, so I had to hang up.

<lea> hober: are you not allowed to join recorded Zoom meetings? Should we not record?

<hober> (as a matter of policy, I do not consent)

<hober> I would like to join the call and can't so long as it's being recorded.

<florian> the recording has been stopped

<hober> thanks!

<lea> TabAtkins: we are waiting for you :)

<TabAtkins> yup, was getting coffee, one sec

<argyle> i keep joining an empty color group meeting

<argyle> cant find whatever is latest

It would be helpful if dial-in information was sent to the list

Color API discussion

<Rossen__> github: https://github.com/w3c/css-houdini-drafts/issues/1047

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 encapuslated 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 originall 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?

[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 ot 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: 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() fucntion, one for color() function

lea: you get diferent 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 represnting 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

lea: because it is exiting for syntactic purpsose

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 [links here]

lea: ...

lea: API has improved quite a lot, even this week, since Tab sent us some very nice feedback

lea: Review the design

[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

lea: ...

lea: Color spaces represented by colorspace object

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/

lea: right now all mutable, but that's under discussion

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/

lea: registried in ColroSpace.register() or can be anonymous

lea: would be nice to make happen

lea: but difficult to design API to not be less usable for common case

lea: color spaces are represnted 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 delcare 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 originaly 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 maniuplate in any color space, which can be relative

lea: can be provided by object literal as well

lea: Gamut mapping is optional. Every is lossless by default

lea: shoudl 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 coordiante in any coordinate space

lea: unsure what to do with nonsensical

[slide 14]

lea: How do 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: ...

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 ifno

Rossen_: There's a lot of density

<Rossen__> Why/who really needs this? Is CSSColorValue of Color object the right way for exposure?

Rossen_: The two primary questions that I took away from the discussion and overview are

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 to people

TabAtkins: than trying to do it all within TypedOM

TabAtkins: And as Lea said, means don't have to contort TypedOM to fit 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?

<chris> Lea's slides: https://lists.w3.org/Archives/Public/www-archive/2021Jul/att-0004/Towards_a_Color_API_for_the_Web_Platform.pdf

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 functiosn.. 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 eydropper 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

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?

<chris> sRGB-linear and rec2020-linear are the two I am thinking of here

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

<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

TabAtkins: what do you mean?

<smfr> i will try to call back in

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 undertand 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

<chris> rossen, please suggest a resolution because as you said we are close

smfr: If color objects are long-lived and assign them to different things [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; fantasai suggests dialing in by phone, possibly using the dial-in code in the video app audio options menu]

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

Resolution: 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 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

pal: 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: Lke REC709 are defined from camera, so optical to electrical transfer function

pal: but inverse is not defined

pal: depends on context

pal: not just only math

pal: all I'm asking is what are the use cases?

pal: what are we trying to do?

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

Rossen__: I hope we all agree that this is neede for user point of view and perf

pal: no question there

<chris> There are some talks at the Color workshop about this by the way

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 istances 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 singel 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 remaininng, questions pal raised, many will be covered in the color workshop ^

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?

<smfr> out of time

chris: currently in private repo...

Rossen__: ok, open in WICG

<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?

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?

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

<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?

Resolution: 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: 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. Implementer interest certainly helps with that, but it's not a formal condition is happy to charter the work, however you manage to get that


<TabAtkins> lea or chris: don't forgot to print the slides to PDF and send to www-archive, then comment the link in issue 1047

<chris> TabAtkins, already done during the call and link posted in irc

<hober> hours late with this one: https://w3cmemes.tumblr.com/post/144307853757/meanwhile-in-the-houdini-task-force

Summary of resolutions

  1. Republish CSS Fonts L4 and L5
  2. Republish CSSOM
  3. highlights associated with creator document. Throw on mismatches when registering ranges/etc.
  4. UA does not add any default styles to custom highlights
  5. Move order property to Display module
  6. close no change, firefox is correct
  7. Defer to L2
  8. Add Color API for representing color points, separate from CSSColorValue to represent CSS color values
  9. Color API should handle all the color spaces currently specced for the web platform.
Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).


Succeeded 12 times: s/sanketj/dandclark/g

Succeeded 11 times: s/sanketj/dandclark/g

Succeeded: s/first version/first version. If necessary could add these abilities later./

Succeeded: s/dandclark/sanketj

Succeeded: s/dandclark/sanketj

Succeeded: s/dandclark/sanketj

Succeeded: s/dandclark/sanketj

Succeeded: s/.../note that the spec currently requires two colors, so we'd first have to agree to allow only one color before the rest becomes relevant/

Succeeded: s/groove/groove situation

Succeeded: s/pierre/pal/

Succeeded: s/for ???/for non colormanaged APIs/

Succeeded: s/bends/vends/

Succeeded: s/taks/talks/

Succeeded: s/were/will be/

Succeeded: s/that/that. Implementer interest certainly helps with that, but it's not a formal condition/

Maybe present: ??, ???, dholbert, florian, iank_, jensimmons, pal, Rossen__, TabAtkins