- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 25 Mar 2023 16:02:13 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Cascade
-----------
- RESOLVED: Cascade proximity is weaker than specificity (Issue
#6790: Strong vs weak scoping proximity)
- RESOLVED: The combinator is deferred (Issue #8628: Do we want to
defer some or all of these scope extensions to level 7?)
- RESOLVED: The name will be @scope-siblings (Issue #7751: Handle
sibling-proximity in @scope)
CSS Animations
--------------
- RESOLVED: Include `overlay` property with values of `auto` and
`none` to position-4 with a note about concerns over
extensibility (Issue #8189: Entry and exit animations
for top-layer elements)
CSS Contain
-----------
- RESOLVED: Elements within a display:none subtree have no parents
that container queries can access (Issue #8197:
Container queries within display:none are difficult to
implement)
- RESOLVED: Add a function for every container query unit that
allows to reference a named container (Issue #7858:
Reference named containers for cq units)
- RESOLVED: Style queries can accept properties in boolean context;
false if matches initial value, true otherwise (Issue
#8127: Allow container query style features to evaluate
in a boolean?)
- It's unclear if the questions in issue #7875 (`overflow: auto`
incompatible with size containment and container queries) are
covered in the spec and need clarification or if there are
changes to be made to handle contain-intrinsic-size.
CSS Color
---------
- RESOLVED: Allow out-of-gamut HSL and HWB colors (Issue #8444:
Allow out-of-gamut HSL/HWB colors (previously "Move
gamut mapping to a future spec"))
- RESOLVED: Change specification say browsers MUST use OKLab color
interpolation for all colors, including legacy colors
(Issue #7948: What if legacy colors *also* interpolated
in Oklab by default?)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/37
Present:
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Chris Harrelson
Daniel Holbert
Brian Kardell
Chris Lilley
Peter Linss
Eric Meyer
François Remy
Khushal Sagar
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Lea Verou
Chairs: Rossen & astearns
Scribe: emeyer
CSS Cascade
===========
Strong vs weak scoping proximity
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6790
miriam: With @scope, there are two features that help avoid large
scoped things overriding smaller scoped things
miriam: One of those is pretty strong, which is the ability to set
lower boundaries
miriam: The other is somewhat weaker, which is a heuristic priority
for inner over outer
miriam: We're calling that cascade proximity; question is whether
that's more or less powerful that the specificity heuristic
miriam: Proposal is to have it be weaker than, because we're trying
to reduce specificity reliance
miriam: When these two heuristics conflict, specificity is easier to
change
astearns: I suggested people provide arguments in favor of stronger,
but all the comments in the issue argue for weaker
astearns: Comments?
<bramus> SGTM
RESOLVED: Cascade proximity is weaker than specificity
Do we want to defer some or all of these scope extensions to level 7?
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8628
miriam: Some tag-along features we can consider; all are useful,
question is whether we should be trying to cover them now or
defer to next spec level
miriam: If we don't defer them, next on the agenda is a scope
sibling feature
miriam: This would be horizontal in the DOM
miriam: A pretty straightforward thing to spec, we think, but it
hasn't been specced
miriam: The other is the scoped proximity combinators
miriam: We have a little less sense when people would use this
rather than @scope
miriam: For @scope you're trying to target several elements in the
DOM, and the at-rule does that neatly
miriam: In a single selector, it gets more complex
miriam: The real question is: defer, or no?
<TabAtkins> +1 to deferring, they're all nice but none are necessary
astearns: One concern with deferring is there may be feedback with
current-level features that could modify
astearns: If we're not considering these now, we may miss something
miriam: It's hard to know if that's too cautious
miriam: So far neither has caused major changes and will continue to
be in our heads, but I dunno
TabAtkins: My estimate is they shouldn't cause any problems, and
should be forward-compatible
astearns: Would it make sense to have a note about things we've
explicitly deferred?
miriam: Since one is partially-specced, it could be opening another
spec
bramus: I'm okay with deferring combinators due to complexity, but
was wondering if we can have sibling scope in level 6
<emilio> Implementation-wise they seem a bit trickier than
descendant scopes fwiw
<emilio> Because to change the descendant relationship you need to
remove from the DOM but that's not true for siblings
astearns: What use case are you concerned about with sibling
proximity?
bramus: So authors can style things like start and end dates on a
calendar and also styles things between them
miriam: Another example is to style everything between one header
and the next header
fantasai: Seems like those are use cases where you don't need scope
proximity effect, you just want the flooring effect, yes?
miriam: I think I've seen examples using both
miriam: They achieve the same goal, but at different levels of
explicitness and power
astearns: Can we resolve on deferring the combinator?
astearns: Proposing deferring 8380 with a note that it was deferred
to next level
RESOLVED: The combinator is deferred
Handle sibling-proximity in @scope
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7751
bramus: In regular scope, we can walk down the DOM tree
bramus: Suggestion here is to introduce sibling proximity where the
lower boundary is a sibling of the upper boundary element
bramus: Syntax would be the same as @scope rule; difference would be
the at-rule would be @sibling-scope
fantasai: With normal scoping, relationships are obvious, but here
we're only doing following siblings, so should make that a
little more obvious
fantasai: Because we're only going forwards in the tree
bramus: It's implied by the name, I think
bramus: The end boundary element should be a following sibling of
the start boundary element
bramus: It could be you style all the siblings from a certain
element down
<lea> +1 to @scope-sibling over @sibling-scope for the reason
fantasai mentioned
<lea> also typing @scope would bring both up in autocomplete
fantasai: I would go with @scope-siblings rather than @sibling-scope
so they sort together
bramus: Would it be @scope-sibling or @scope sibling?
lea: I agree with Elika on the naming; they sort together, they
autocomplete together
astearns: Should we resolve on that?
bramus: I'm fine with that
astearns: We do tend to go with non-plural syntax for things, so
@scope-sibling
fantasai: The non-plural form reads weirdly
astearns: Yeah, okay
miriam: You are creating a scope of siblings
florian: We do have precedent for a few plurals
RESOLVED: The name will be @scope-siblings
astearns: Anything else?
miriam: I think we're hoping things will carry over from the other
one
bramus: There's another CSS cascade issue at the bottom of the list
astearns: People have joined specifically for the animation issue,
so I want to do that next
CSS Animations
==============
Entry and exit animations for top-layer elements
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8189
plinss: There was TAG discussion about popover, which turned into
discussion about the top layer in general
plinss: TAG is concerned about the overall design of the top layer
plinss: It's done by monkey-patching CSS
plinss: It should be defined by the CSS WG, but hasn't been getting
a lot of love
plinss: There's room for declaratively creating not just the top
layer, but multiple layers
plinss: I think it should be controlled entirely in the CSS layer
plinss: Don't have a specific design, but the TAG feels it needs to
be done
TabAtkins: I've had this on my to-do list
TabAtkins: To pull out painting order and do a spec about that
TabAtkins: We have a resolution on file to put that into the
position spec
TabAtkins: Proper specification in CSS is on my task like
TabAtkins: In terms of authors being able to create layers other
than the top layer, completely agree
TabAtkins: This has come up with anchor positioning
TabAtkins: I definitely support authors being able to define
additional layers you can move things into
TabAtkins: In terms of making the top layer accessible, that's been
discussed and there are significant concerns
TabAtkins: Anything the UA is using the top layer for shouldn't be
able to be covered up
TabAtkins: That's a larger, separate conversation
TabAtkins: Doesn't have to prevent letting authors insert layers
between document and “top layer”
plinss: I understand the security concerns
plinss: We have precedence for letting the UA override author styles
and should use similar mechanisms for the top layer
plinss: While we should allow authors to create layers, the top
layer should just be another layer, not something special
and magic
plinss: The magic can come from the UA stylesheet
astearns: Please add a link to the proposal you referenced
chrishtr: We're going to do the work to move the top layer stuff
into the position spec
chrishtr: Can we go back to the thing in 8189, which is adding
transition control for developers entering and exiting top
layer?
<lea> how can we discuss entry/exit animations separately to whether
there will be author control of top-layeredness? These are
intrinsically related
masonf: In general, I'm in support of moving into positioning spec
masonf: I would be supportive of letting authors create a new top
layer under the existing top layer
masonf: Trying to do it with existing CSS in the existing top layer
are difficult
masonf: Like the top layer being an ordered set
masonf: So I'd be against allowing direct control of the existing
top layer
plinss: I'm not arguing the change how the top layer now works, I
just think it should be explained using CSS
plinss: Such as exposing the ordering via CSS
masonf: If that's possible, I'm in favor of it
plinss: I think so
plinss: It would also be great to fix all the z-index hackery that's
been done since day one
<lea> +1 to everything plinss is saying of course
astearns: I'm hearing a lot of agreement and a stated plan to work
on this in the position spec
chrishtr: That would be the first step, yeah
chrishtr: My proposal on 8189 is you can say transition and then a
CSS property that refers to the top layer behavior, and
then the usual transition delay
chrishtr: So you could push transitioning things into the top layer
chrishtr: My reading of issue commentary is that people are
generally positive about the mechanism
chrishtr: So if we're good and want to pick a name, I think overlay
would be fine
<masonf> +1 to `overlay`. `overlay-behavior` feels odd.
fantasai: I like the idea of using the word overlay, but think
overlay-behavior is a bit weird
fantasai: I'm open to thoughts
<bramus> +1 on just `overlay`
<masonf> `overlay-index` ? That feels bad too.
astearns: The analogy to z-index would make me wonder why there
aren't integers allowed in the syntax
fantasai: This should go into position-4, not -3
chrishtr: Agreed
astearns: I'm seeing more people in favor of `overlay` rather than
`overlay-index`
astearns: We could put it into position-4 and see what people say
astearns: So we propose to include `overlay` property with values of
`auto` and `none`
<dbaron> (maybe some other name thoughts might be overlay-layer or
overlay-level)
plinss: I have concerns this could conflict with other things we
might do very soon
astearns: Amended proposal to include `overlay` property with values
of `auto` and `none` to position-4 with a note about
concerns over extensibility
<masonf> +1
RESOLVED: Include `overlay` property with values of `auto` and
`none` to position-4 with a note about concerns over
extensibility
CSS Contain
===========
Container queries within display:none are difficult to implement
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8197
oriol: Problem is that browsers tend to avoid computing style of
elements inside a display:none subtree
oriol: You can still force the computation with JS
oriol: What should happen if one of these elements may have a
container which is applying some rules conditionally, which
may affect the computed style you get?
oriol: Gets more complicated if ancestor is a container or not
oriol: In Blink, I think this was easier to implement per spec since
it has some caching and first computation is cached
oriol: That way we know if ancestors are containers or not
oriol: Firefox doesn't have this caching, so when it computes, the
information isn't stored in the element
oriol: emilio didn't think my patch to pass information around was
the best
oriol: Discussion agreed it was reasonable that an element in a
display: none subtree should be treated as having no container
oriol: This might not be good for style queries
emilio: Some of this is complexity specific to Firefox, but in
general, some of this is very messy and not very
interoperable
emilio: I'm not a fan of adding complexity here
emilio: We do something similar where older browsers do transforms
on display: none elements as none
emilio: I'd rather do the easy-to-implement thing instead of having
extra complexity
emilio: I don't think it's particularly useful to check elements
based on container queries when the container isn't there
emilio: Any answer will be weird
astearns: Is there a way of having elements escape a display: none
ancestor using CSS?
emilio: No, which is why browsers optimize them away
astearns: Then I have no concerns
astearns: Proposed resolution: elements within a display:none
subtree have no parents that container queries can access
emilio: The wording could be they have no query containers, though
I'd like Rune to confirm this is fine
emilio: We can resolve and seek comment after
astearns: Anyone on the call want to wait for Rune's response?
(silence)
RESOLVED: Elements within a display:none subtree have no parents
that container queries can access
Reference named containers for cq units
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7858
miriam: There are two function proposal on this
miriam: There's concern about using actual lengths in these functions
miriam: Idea is to be able to query for a specific container
miriam: Could query for container 10cqi and a container name
miriam: Idea 1: a new function for each container unit
miriam: Would take the argument of a container name
miriam: Idea 2: Have a general container unit reference function
miriam: Something like `container-unit(<unit>,<container-name>)`
miriam: Could use this in calc() to do whatever math is needed
miriam: This is a little bit bulky that would help authors clean
this up a bit, but it's a good start
miriam: I like the second idea; probably needs some bikeshedding on
the name
astearns: Anyone with opinions or dislikes?
<TabAtkins> happy with either, honestly
<TabAtkins> latter is verbose but the functionality makes sense
emilio: There are units that don't make sense in a container
function, right?
miriam: Yeah
fantasai: The only relevant units are font-relative and
container-relative
emilio: I'm not particularly opposed, but some of these seem like
they could be handled differently
emilio: This feels a bit weird
emilio: I have a slight preference for the first option, but not
strong
fantasai: I like that the first idea is easier to type and is a
straightforward extension of existing syntax
TabAtkins: I agree with emilio that the general function is a little
funky
TabAtkins: We could make a cqem unit and corresponding function, so
I think I'd be happier with dedicated functions
TabAtkins: Plus a non-binding intent to always have a function that
goes with any new CQ unit
<emilio> +1
astearns: I'm a little excited about the more vague function — why
just units, why not custom properties?
TabAtkins: That wouldn't be the container unit function which needs
to be a math function
fantasai: I think we should start where we can with this syntax
which is easy to use and we'll want anyway, even if we
have a more generic function. Also I think it would be
nice if we could make it behave more like a unit...
miriam: The custom units proposal would let you wire that up
astearns: Sound like we're converging on idea one, where every unit
gets a corresponding function
<miriam> I will also open an issue for cqem
RESOLVED: Add a function for every container query unit that allows
to reference a named container
<fantasai> cqi(<container-name>)
<TabAtkins> right, it resolves to 1 of the corresponding unit
Allow container query style features to evaluate in a boolean?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8127
miriam: Container query style features can query custom properties,
so the question is, can you query without the value to see
if it has initial value
miriam: Thus getting true or false back
miriam: False if it's the default value, true if it's changed
<fantasai> sgtm
<fremy> +1
<lea> +1 obvs
dholbert: Would anything special be needed for Houdini registered
properties?
miriam: Yes, you'd be checking to see if it's the initial value, by
default that would be the guaranteed-invalid value
Rossen: Any questions or objections?
(silence)
RESOLVED: style queries can accept properties in boolean context;
false if matches initial value, true otherwise
`overflow: auto` incompatible with size containment and container
queries
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7875
oriol: We had a resolution but I'm not sure if that was the right
solution
oriol: Problem is that with overflow:auto, if the browser is using
classical scrollbars, those take up space
oriol: This can happen in two ways
oriol: Browser may behave a bit different, if the element is sized
intrinsically, the scrollbar size is added on top of content
size
oriol: If the size is explicit, then outer size of the element is
preserved and scrollbars go inside
oriol: We resolved the address the problem we don't want, having to
check to see if ancestors have to change size
oriol: We always want to stop at element with size containment
oriol: So we resolved to have scrollbars shrink content size
oriol: Question with this is, first, this addresses the auto case,
but what about the overflow:scroll case?
oriol: Second, even if we preserve outer size of the element, there
are features that depend on content size, like container
queries and contain-intrinsic-size:auto
oriol: By letting auto scrollbars affect content size, we have
instability with container queries and
contain-intrinsic-size:auto
oriol: Maybe it would be simpler to say that if an element has size
containment or contain-intrinsic-size:auto, then
overflow:auto would need to computer to overflow:scroll
oriol: By forcing the element to consistently get scrollbars, we'd
avoid problems, might not look as good
oriol: Open to ideas, but finding a solution that covers all
problems simultaneously is tricky
florian: I think your suggestion of getting stable scrollbars does
help
florian: I support that
florian: Maybe we could do indirection through scrollbar-gutter
properties
oriol: Those properties have the stable keyword, but I think it only
affects on axis
florian: Yeah, maybe that won't work
florian: Containment is magic enough already; I think we could make
it do strange things like this
iank: I do worry about web compatibility
iank: People throw overflow:auto on random elements
iank: Also, the optimization mentioned in the spec is on a best-case
scenario
iank: You aren't required to use it for whatever reason
florian: Ian, did you mean we should let the outer size with
overflow:auto change and that regains consistency at the
expense of optimization?
iank: Want to think about it a little more, but I would be fine with
that
iank: It's a little bit of a hairy area
miriam: Confused about the loop you mentioned of scrollbars getting
added due to content
miriam: That seems like the same loop we had to work through to get
container queries at all, how is this new/different?
oriol: You can make contents change size with container queries
iank: This falls into the you-always-move-forward pool
iank: We start assuming no scrollbars, then add if needed
oriol: It's not like browsers are freezing, but if you start forcing
things with JS or such, operations that should not affect
things visually can change things
oriol: I have some examples in the issue of things looking broken
iank: To me, those examples are browser bugs
oriol: Then we need to define the expected behavior
miriam: I thought we did
Rossen: Is it the case that when we start with no scrollbars, you
can only add scrollbars in the normal case, excluding
container queries?
Rossen: Is the proposal to make changing the scrollbar state once
per layout a defined behavior?
oriol: Yeah, I want to avoid circularities
oriol: Mia was saying we can already avoid them, so maybe I missed
something
oriol: Reading the specification, it seems there's a circularity
oriol: Was proposing a way to keep the content from affecting the
content size of the container
oriol: If there's another solution that only take a look at size at
one point and not others, that may be fine
<miriam> note and example here discuss this exact example:
https://www.w3.org/TR/css-contain-3/#containment-inline-size
iank: We said you're performing a layout and engines will try to
optimize, but can skip them
iank: You start with no scrollbars, then add a scrollbar or two if
needed, then finish
iank: So you only add scrollbars during layout
iank: It's tricky to get the optimization correct
iank: This circularity can arise with regular content, so this isn't
particularly new
Rossen: Is there a clarification or solution we need to record here,
or is there an added step that seems reasonable?
miriam: Not sure; I think this is covered and I see this exact case
mentioned in the spec, so I need to know what's unclear and
in need of clarification
oriol: Even if we use this approach on whether query styles apply or
not, there's a problem with contain-intrinsic-size:auto which
remembers the content size
oriol: We have some inconsistency here, and I think the other cases
are addressed in other ways, but I don't see this
contain-intrinsic-size problem addressed
miriam: It's likely we do need to clarify here
Rossen: Let's take the conversation back to the issue and work out a
solution there
CSS Color 4
===========
Allow out-of-gamut HSL/HWB colors (previously "Move gamut mapping to
a future spec")
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8444
chris: In the course of discussion about whether we should do gamut
mapping, it turns out to be observable through script in one
case
chris: That's when you convert to HSL or HWB
chris: That's not very helpful; worry is out-of-gamut colors could
return unusual results when converting
chris: Proposal is that colors should be round-tripped
chris: You'll get weird HSL values but it's okay because that's what
you asked for
chris: HSL and HWB are lossy
chris: I'm in favor of the proposal, but been waiting for
implementor input
Rossen: Any implementors here who want to provide input?
emilio: I need to look more carefully
Rossen: Are you opposed?
emilio: Not particularly
Rossen: This doesn't sound like it's raising an initial strong
reaction
emilio: I'd be fine resolving and I can come back if there's a
problem
chris: Proposal is to allow out-of-gamut HSL and HWB colors
Rossen: Objections?
(silence)
RESOLVED: Allow out-of-gamut HSL and HWB colors
What if legacy colors *also* interpolated in Oklab by default?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7948
chris: For non-legacy colors, implementation should interpolate in
oklab
chris: The spec says implementations MAY interpolate in sRGB if all
the colors are legacy colors
chris: Lea raised, why not make them all do it in oklab?
chris: We did some tests, and for some colors there's a big
difference
lea: I think it's an obvious improvement in every color pair we tried
lea: There is precedent for doing this in places like
text-decoration-skip
lea: It makes for an easier rule to learn and remember
lea: oklab produces better gradients
lea: The only problem I could think of is color pickers
lea: I can't remember the proposed solution to this
lea: The Chrome team has said they're kind of apprehensive because
they tried to do linear RGB and there were problems
lea: This isn't the same because linear RGB isn't perceptually
uniform
chris: In Chrome, the colors are stored in pre-multiplied linear RGB
chris: I wanted to know whether they said they can't change because
of that trial, or because of the proposal
lea: I heard from someone on Chrome team they tried linear RGB and
had poor results
chris: As expected
bramus: I don't think anyone here can address this directly, but
I'll poke the correct people for a response
<fremy> I would note that there might be images associated to the
gradients
Rossen: In absence of that, is there a resolution you want to take
here that will ideally be something that would work?
lea: Are there any objections to this, involving actual cases where
this would be worse?
emilio: Does this only affect gradients, or does it also affect
animation?
lea: That's up to us; I believe it's currently about gradients only
emilio: Applying to animations would be trickier because it affects
computed styles
<TabAtkins> yeah I'd be relatively bothered by interpolation and
gradients not working the same
chris: The spec is about interpolation, so it would apply to
everything
emilio: That's a bit trickier, but it might work
emilio: I'd be surprised if there are no pages that rely on this,
but it might be a better default
chris: Although it's true a gradient defined as a gradient is
better, I'm concerned we'll get “why is my page lighter?”
emilio: It's good to change the default consistently
emilio: I agree it's a better default, but compat is a concern
emilio: Gradients would be better regardless, I think
emilio: Changing the default for everything is probably worth a try
<ydaniv> what about filters?
<lea> ydaniv: filters are defined entirely differently, they don't
use interpolation
lea: I want to clarify that making this the default doesn't make it
mandatory
lea: There's a way to specify the interpolation space for gradients,
and will be able to apply to other things
lea: So there's an escape hatch
chris: This comes down to, is this an opt-in or an opt-out?
chris: For unmaintained pages, what happens?
Rossen: opt-in would be safer, yes?
chris: I agree
plinss: The issue of a page becoming lighter isn't a big deal except
in cases where CSS color needs to match image color
plinss: Want to be sure we're taking that into consideration
<fantasai> +1 from me to plinss's point, that it's important for the
endpoints and not so much for the middle
bramus: I vote for opt-in; authors will be surprised if colors change
Rossen: +1 from me
Rossen: colors can often be a branding issue
lea: This reminded me, we have a more relevant precedent where we
changed to interpret legacy CSS colors in sRGB, so what what
red meant changed (for example)
lea: That's a much bigger change than what we're discussing here
lea: only midpoints in a transition will change
<TabAtkins> color management only affected people with good screens,
though
fantasai: I support Lea's proposal; I think midpoint changes will be
an improvement
fantasai: There's a lot of shift in colors depending on monitor
calibration etc.
<florian> +1
<miriam> +1
Rossen: So do we make this opt-in, something we can drop later, or
make it opt-out?
lea: Opt-in basically means no change
fantasai: I think we should change the default for the web to be the
better interpolation
lea: Current language is that browsers MAY do this; proposal is to
change this to MUST ...or at least SHOULD?
Rossen: Or maybe SHOULD
lea: Also resolutions are not binding, we can always reverse if
investigations reveal it's a bad idea
florian: I'm not sure what we gain with a SHOULD
florian: If we have a good reason not to do something, we should
roll this back
florian: I think MUST is appropriate
lea: Maybe SHOULD is better for low-powered devices where oklab
computation is harder than calculating the RGB values on hand
plinss: I would argue devices like that probably won't support this
sort of thing
Rossen: Objections to using MUST on using oklab?
<astearns> +1 to MUST
<fantasai> +1 to requiring OKLab interpolation
(silence)
RESOLVED: change specification say browsers MUST use OKLab color
interpolation for all colors, including legacy colors
Received on Saturday, 25 March 2023 20:02:58 UTC