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://
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
Republishing
Rossen_: css-fonts-4 and css-fonts-5
github: https://
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://
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://
emilio and chris will look into it
Rossen_: Any objections to republishing?
Resolution: Republish CSSOM
Highlight API
Multiple Document Highlights
github: https://
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: https://
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://
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://
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://
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://
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> OKAY I CAN'T MAKE A CALL ANY MORE
<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://
<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://
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+
end
<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://
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://
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: 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() 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://
<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://
<chris> https://
lea: right now all mutable, but that's under discussion
lea: Color spaces are represented by ColorSpace objects
<chris> Draft explainer: https://
<Rossen_> Color Object draft: https://
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://
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://
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
end
<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://