W3C home > Mailing lists > Public > www-style@w3.org > February 2022

[CSSWG] Minutes Telecon 2022-02-16 [css-color] [css-color-adjust] [css-easing] [css-ui] [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 16 Feb 2022 18:57:04 -0500
Message-ID: <CADhPm3uRn6vHyUUc3ZsPy0QyFDBGQx-SKkLBmuMtr_s9_0mPwg@mail.gmail.com>
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


  - 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

CSS Contain

  - RESOLVED: Keep style queries in level 3. (Issue #7020: Defer style
              queries to level 4?)


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Feb/0007.html

  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

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

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

  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
  <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
  Rossen: We have a resolution for forced colors that they resolve in
          used value time. That meant we could avoid the color mix
  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
  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.

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

  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

  <JakeA> Reporting for duty!


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

  RESOLVED: Keep style queries in level 3.
Received on Wednesday, 16 February 2022 23:58:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:20 UTC