- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Feb 2022 18:57:04 -0500
- 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 Color
---------
- RESOLVED: Will add this to the color-4 module, after forking to a
new issue (Issue #6741: Support all existing
(non-legacy?) formats in color()?)
- There is interest in exploring issue 7035 (color-interpolation
inherited property to set default interpolation space) further to
see if it can be solved with focused properties. Discussion will
continue on github.
CSS Color & Color Adjust
------------------------
- There was still some concern about the effect of issue #6773
(Consider reversing the resolution of #3847) so the group will
take a week to review and then revisit the issue next week.
CSS Easing
----------
- RESOLVED: Accept this as L2 Editor's Draft. (Pull Request #6533:
Some ideas for linear() easing)
- RESOLVED: Add Jake Archibald as editor/co-editor of that Editor's
Draft.
CSS UI
------
- RESOLVED: Will not add an inertness property for now. (Issue #7021:
Should inertness be exposed as CSS property?)
- Examples will be added to issue #6981 (Outline rects of an inline)
in order to understand the current state and determine a possible
solution.
CSS Contain
-----------
- RESOLVED: Keep style queries in level 3. (Issue #7020: Defer style
queries to level 4?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Feb/0007.html
Present:
Jake Archibald
Adam Argyle
Rossen Atanassov
Tab Atkins Bittner
David Baron
Mike Bremford
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Megan Gardner
Daniel Holbert
Jonathan Kew
Vladimir Levin
Daniel Libby
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Eric Meyer
Morgan Reschenberg
Jen Simmons
Miriam Suzanne
Lea Verou
Regrets:
Florian Rivoal
Zheng Xu
Scribe: emeyer
Rossen: Any last-minute agenda changes? I saw Lea wants to swap 2 and
3. Anything else?
CSS Color
=========
Support all existing (non-legacy?) formats in color()?
------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/6741
lea: Looking for consensus for our plan on percentages. Right now
they're aliased to 0-1 ranges.
lea: We were thinking of using them for a reference range based on p3
so people can use absolute coordinates if they want, or use
percentages if they want something close enough.
<lea> https://github.com/w3c/csswg-drafts/issues/6741#issuecomment-1028141623
chris: Mostly I wanted more feedback just to be sure this is what we
want to do.
lea: What's unclear is whether this about the color() function or is
it about other things?
chris: It's about the other things.
Lea: We really need a new issue.
Rossen: We can definitely get a different issue. Chris, you framed
this as a question toward implementers, so let's hear from
them.
Mike Bremford: Changing it isn't a big deal either way.
TabAtkins: +1 from me as well. I like this from the perspective of
“all color models accept the same input space”.
<lea> Note that this means that color(rec2020 50% 100% 50%) will NOT
be equal to color(rec2020 .5 1 .5)
<lea> (+1 from me too, in case it's not clear)
* fantasai defers to the color experts
Rossen: Any objections?
RESOLVED: Will add this to the color-4 module, after forking to a new
issue
Rossen: As next steps, we'll break this out into its own issue, build
consensus, and get it into a spec.
color-interpolation inherited property to set default interpolation
space
-------------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/7035
Lea: We're been going through spec and adding interpolation space in
gradients, other things. Don't have a way to add to animations
or mixing yet.
lea: When it comes to augmenting gradients, this will make them
invalid in older browsers. Authors would need @supports or
variables. It's kind of tedious.
<chris> comparison of this proposal with the other one:
https://github.com/w3c/csswg-drafts/issues/7035#issuecomment-1041850688
lea: It also means any new spec with interpolation lacks control
until we add this.
lea: There is no quick easy way for authors to say they want
interpolation without dealing with browser issues. So maybe a
color-interpolation property would help here.
lea: That way it can be set and inherited and overridden. You can set
it at root and all your gradients become better.
lea: Chris pointed out you probably want different interpolation
spaces for different use cases.
chris: You may want different interpolations for different
operations. I can imagine you'd want different interpolations
on different transitions.
chris: The question is, is it useful to set a default for an entire
document or subtree.
chris: SVG has two properties that deal with this sort of thing.
chris: I don't think it adds enough value to justify the complexities.
<smfr> css filters are in sRGB
JakeA: I have similar concerns. You could set this property and it
makes all the gradients look great, but then later we add it
to mix-blend-mode or whatever and they all look ugly.
fantasai: If different interpolations for different operations are
expected, it would make sense to have focused longhand
properties (color-interpolation-gradient, etc.).
fantasai: I also don't think we should have an in keyword.
<lea> +1 to almost everything fantasai just said (except re: in
keyword)
dbaron: I was wondering about a global property: is it possible to
have two global properties? Is it the case that there's a set
of things that make sense to interpolate in linear light and
another set of things that need gamma correction?
dbaron: Does it make more sense to have those two rather than seven
or eight properties?
chris: I think that's correct; some want to be linear and some want
to be perceptual.
faceless: I think this would be confusing if it didn't include the
SVG properties as legacy syntax. I don't see a reason we
couldn't do that.
Rossen: Sounds like there's an interest in exploring this in terms of
focused properties like color-interpolation-gradient, which
is safer. Is that the path we want to take?
chris: I think there's interest in further exploration.
<TabAtkins> +1 to Chris and Jake's concern about a single global
default
<TabAtkins> But I'm fine with longhands like fantasai mentioned
Rossen: Let's take the conversation back into the issue.
CSS Color & Color Adjust
========================
Consider reversing the resolution of #3847
------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/6773
emilio: I think this is the right thing to do, otherwise
interpolation becomes very messy.
TabAtkins: After review, I agree with Emilio and it would be best to
reverse the decision.
TabAtkins: We should resolve that system colors should compute at
computed style time.
chris: So this is reversing for system colors but not currentColor.
alisonmaher: What will this mean for use value time?
emilio: The only reason I started looking into this is because of the
preserve keyword. If you force colors at use value time, it's
bad.
Rossen: We have a resolution for forced colors that they resolve in
used value time. That meant we could avoid the color mix
function.
emilio: Where was it required? Just for backgrounds and alpha?
emilio: Otherwise, system colors are preserved. Backgrounds are a
special case.
emilio: Gecko implements this with magic, not color mix. Could
implement with color mix as well.
alisonmaher: This could re-raise an issue around forced-color-adjust.
emilio: I don't see why that would be a problem.
<dlibby> this was the issue alison mentioned re: forced-color-adjust
interpolation https://github.com/w3c/csswg-drafts/issues/5419
fantasai: I think one problem would be that with the default color on
the canvas, if you change the color scheme at any point
lower than root, it would have no effect.
TabAtkins: Because background colors aren't inherited, if you change
color scheme to the opposite, if the background is
transparent, you end up with black on black or white on
white.
TabAtkins: If you explicitly set colors with the scheme, you get what
you expect. But it's not reasonable to expect that
flipping scheme will make things unreadable.
(silence)
Rossen: Anyone who is still concerned about the effect of this change
or the handling of forced-color-adjust, if this is something
that doesn't sound right yet, we can take another week to
consider so we don't end up flipping back and forth.
dlibby: I wouldn't mind more time to think through, given Blink has
shipped this behavior for a year or so.
TabAtkins: We did ship, but other things we're doing don't match the
spec, so changing this wouldn't have an enormous effect, I
believe. There are still details to work out with
forced-colors mode, though, so happy to delay a week as
well
Rossen: Let's give it a week. We'll prioritize this next week.
CSS Easing
==========
Some ideas for linear() easing
------------------------------
Github: https://github.com/w3c/csswg-drafts/pull/6533#issuecomment-1023455165
JakeA: (presents slides)
<JakeA> My slides were all from https://www.youtube.com/watch?v=8FuafvJLDpM
JakeA: Idea is why not let people define a bunch of points in the
easing space and we'll interpolate between them?
JakeA: `linear-spline()` would permit more complex easing patterns
<argyle> +1
<TabAtkins> Big +1
<TabAtkins> Probably still want to extend cubic-bezier() later, yeah,
but this is perfectly acceptable and reasonable on its own
<flackr> +1
JakeA: This would leave the door open to a nicer system later on, and
in the meantime we can allow elastic easing (including bounce
easing)
chris: Overall I think this is a good thing. It's a nice balance
between complexity and usability. I'd like to see this move
forward. Is there a volunteer to edit this level 2 easing
spec? Jake?
JakeA: What would that mean?
chris: It means handling feedback and pushing things forward to get
to implementation.
JakeA: Yeah, I'll give it a go.
Rossen: Great, thanks for being a good sport.
<TabAtkins> More than happy to help Jake out fwiw
fantasai: I think we need two resolutions. One to create easing-2 and
the other to incorporate this proposal. I'd also like to
suggest FPWD as soon as it's in.
<smfr> https://github.com/w3c/csswg-drafts/issues/280
smfr: There is a proposal for spring timing functions. I do think we
should continue with the current suggestion.
<argyle> been in safari for ages too right?!
Rossen: Sounds like it will be great to start this as ED, put the
work in, move it to L2. We can go to FPWD as soon as there's
enough support. We'll see if Dino's spring function effort
can go in as well.
RESOLVED: Accept this as L2 Editor's Draft.
* fantasai will create the L2 draft
RESOLVED: Add Jake Archibald as editor/co-editor of that Editor's
Draft.
<JakeA> Reporting for duty!
CSS UI
======
Should inertness be exposed as CSS property?
--------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/7021
oriol: This is something that appeared in discussions about
inertness. The main thing of inertness is it sets events.
oriol: Proposing that inertness should be exposed as a CSS property.
It could be like the ‘hidden' attribute to ‘display: none'.
oriol: Argument in favor is that inert sets certain kinds of styling.
This would allow authors to use selectors to make elements
inert.
oriol: Argument against is that implementations are tracking
inertness by way of unexposed inherited properties. If we
expose it, then we should probably change this to be
non-inherited that propagates by means other than inheritance.
oriol: I don't have a strong opinion, but would like a resolution one
way or the other.
oriol: emilio and annevk expressed opposition.
emilio: I think this can be added if we want, but given that once an
element is inert, it can't be not-inert, the usefulness of
the property seems limited.
emilio: I also don't like the idea of making a thing propagate
outside of inheritance.
Rossen: Does anyone object to waiting until better use cases or
louder voices appear?
RESOLVED: Will not add an inertness property for now.
Outline rects of an inline
--------------------------
Github: https://github.com/w3c/csswg-drafts/issues/6981
emilio: When you have an outline around inlines, the spec was
ambiguous about what an outline should draw around. We've
changed Gecko to match WebKit, but missed a case where Blink
does something different.
emilio: There is a special code path for outlines of inlines. Can we
resolve on what outline actually does and fully spec it?
<smfr> I'd love to see some pictures in the issue
iank: Does this cover auto outlines?
iank: I think engines have different code paths.
emilio: How do they differ?
smfr: What I remember is we only respect border radius for auto
outlines.
iank: I believe things differ for auto versus non-auto. If you have
an inline block, we do something different to capture more of
the visual overflow.
iank: The special case we had for non-auto outlines, I agree our
behavior looks broken for one of the cases on the issue.
smfr: I'd love to see these and web platform tests.
iank: I'll try to create test cases where everyone does different
things. I'll be reluctant to change the auto outline case
because of accessibility, but the non-auto outline case is
difficult because people often force the outlines to be
different.
emilio: I find the auto versus non-auto distinction quite weird. It
should be about whether the element is focused. If we want to
have focus outlines versus non-focus outlines, that's another
topic. But documenting the differences would be great, so we
can agree on behavior.
Rossen: Let's take this back to the issue and create as many test
cases as we can. I'll +1 smfr's suggestion to make the test
cases WPT test cases.
CSS Contain
===========
Defer style queries to level 4?
-------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/7020
miriam: Jen Simmons raised this to me, so I posted it here. Elika and
I feel that the spec as it is is direct and simple, not a lot
of questions. We might as well ship it with the rest of the
spec. If there are implementer concerns, we can hold it back.
Rossen: Miriam, which do you want?
miriam: Let's keep it in L3 since it's already defined.
Rossen: Any objections?
(silence)
RESOLVED: Keep style queries in level 3.
Received on Wednesday, 16 February 2022 23:58:46 UTC