W3C home > Mailing lists > Public > www-style@w3.org > June 2021

[CSSWG] Minutes Telecon 2021-06-30 [css-pseudo] [css-cascade-5] [css-values-4] [css-fonts] [css-color-5] [selectors-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 30 Jun 2021 19:02:15 -0400
Message-ID: <CADhPm3sWcAQOn8hxSB_DO7uMmrgNNPNiROTSMuerFioh1q8ctw@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 Pseudo
----------

  - RESOLVED: Add custom properties support to pseudo elements (Issue
              #6264: Highlight pseudos and custom props)

CSS Cascade
-----------

  - RESOLVED: Layer rules respect conditionals, and are ignored in
              non-global conditionals (Issue #6407: Do conditional
              rules impact layer order?)
  - RESOLVED: Name-defining at-rules follow layer order for collision
              resolution, similar to specificity resolution (Issue
              #6404: What happens to name-defining @-rules nested
              inside @layer?)

CSS Values
----------

  - Review is requested for the proposed text on issue #6113 (Add
      lvh+lvw values) before a resolution is requested next week.

CSS Fonts
---------

  - RESOLVED: The issue is resolved [now that we have size-adjust]
              (Issue #5533: Reduce layout shift via @font-face
              descriptor(s) overriding inline spacing)

CSS Color
---------

  - RESOLVED: Drop color-adjust(), stick with relative color syntax for
              color manipulation for now (Issue #6179: Is
              color-adjust() needed, now that we have relative color
              syntax?)

Selectors
---------

  - Please add feedback to issue #6399 (Remove the :scope dependency
      from the relative selectors definition) to help determine which
      of the proposed solutions to take.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0020.html

Present:
  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Oriol Brufau
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Jonathan Kew
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Alison Maher
  Miriam Suzanne
  Lea Verou

Regrets:
  Alan Stearns

Scribe: TabAtkins
Scribe's scribe: bkardell


  Rossen: Any extra agenda items?
  TabAtkins: I'd like to bump the first item unless fantasai's ready to
             talk about it
  Rossen: Happy to if that will help

  chris: I had an Agenda+ about dropping color-adjust that didn't make
         it to the list
  <chris> https://github.com/w3c/csswg-drafts/issues/6179

CSS Pseudo
==========
  scribe: bkardell

Highlight pseudos and custom props
----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6264

  TabAtkins: A chromium implementer was asking if custom properties
             should work on highlight pseudos and should have the same
             details -- leaverou was asking if there were any pseudos
             they shouldn't work on
  TabAtkins: We should probably make a blanket statement that they are
             valid on all pseudo elements
  Rossen: Opinions?

  leaverou: The only pseudos I could think of where they might not make
            sense are non-standard ones. If we ever were to standardize
            something like --webkit-scrollbar what would that mean?
  TabAtkins: There are already inheritable properties there

  sanketj: This sounds reasonable. The only question I had was is there
           a use case that prompted this or is it just for correctness.
           I would hate to update the spec and then it never gets used
  TabAtkins: The use cases for custom properties are myriad, it's
             reasonable to think they should work
  <leaverou> Strong +1 for enabling custom properties on every
             pseudo-element
  sanketj: I guess I am still wondering what the use cases are - in my
           mind the properties on pseudos are pretty specific. Mostly
           curiosity
  TabAtkins: Custom properties do nothing on their own, but they
             empower a million things - so they're always going to be
             hard to talk about like that
  sanketj: Fair enough
  <bkardell> +1
  Rossen: Any objections?

  RESOLVED: Add custom properties support to pseudo elements

CSS Cascade
===========
  scribe: TabAtkins

Do conditional rules impact layer order?
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6407

  miriam: What happens when layers are defined inside of conditionals?
  miriam: like @media ... { @layer ...; }
  miriam: Do those layers contribute to layer order, and if so, how?
  miriam: In the final thread comment I listed the options
  miriam: First is parse error - don't think that works.
  miriam: Like what happens when we apply a media to an entire
          stylesheet? Doesn't seem right to have layers disappear.
  miriam: Second is layers in conditionals don't contribute to the
          order. This has similar issues - what if a layer *only*
          appears inside a conditional? Still need some order for them.
  miriam: So remaining is (3) layers always contribute in order they
          appear, whether the conditional is matched or not
  miriam: I think this is my favorite solution, because it doesn't
          require special casing
  miriam: Last solution is to make layer ordering dynamic based on
          conditionals
  miriam: In some ways this is true already via (3) with media=""
          attribute, due to lazy-loading, so you'll get some dynamic
          behavior anyway
  miriam: This would just go all the way
  miriam: It'll need special casing for container queries; they don't
          have a global match state, they're matched per element.
          They'd have to fall back to the first or second option there.

  TabAtkins: I was originally for option 3, but lazy loading made me
             reconsider, so now I'm strong for option 4 (with ignoring
             layers in @container rules)
  TabAtkins: And emilio was also for 4 on Twitter, and it looks like
             Anders is for 4 from the issue thread
  miriam: The Twitter thread also voted for 4 by far. (Not always
          right, but it's useful info about what authors expect.)
  miriam: I think 3 is simpler to understand and teach, but I see the
          points for 4.
  miriam: Fine with either way.

  futhark: Not just lazy loading, also inserting stylesheets and rules.
           You can insert layer rules dynamically, right?
  miriam: Yeah
  futhark: So I think that leans toward fully dynamic as well, since
           other things cause similar dynamic results
  Rossen: So I'm hearing pretty strong support for 4 among authors and
          impls. Are you okay with that, Miriam?
  <bkardell> +1
  miriam: Sure
  Rossen: Any objections?

  RESOLVED: Layer rules respect conditionals, and are ignored in
            non-global conditionals.

Do conditional rules impact layer order?
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6407

  miriam: So inside of @container, layers can't contribute to order.
  miriam: Is that a parse error? (layer rules inside of @container is
          always invalid)
  miriam: Or is it only an error to *introduce* a layer inside of one,
          and it's fine to use one that's already defined?
  futhark: I'll need more time to think
  TabAtkins: Assuming layered styles are okay inside of container
             queries generally (I think so, but futhark can correct),
             then I suggest if a @layer is *introduced* in a
             @container, it's treated as always being introduced there,
             regardless of the @container matching or not.
  * bkardell doesn't understand tab's suggestion
  futhark: Need some more time to think on the consequences of this
  miriam: It's basically option 3, but applied only to container queries

  Rossen: So doesn't sounds like we have resolution yet, we'll take the
          rest of this topic to github

What happens to name-defining @-rules nested inside @layer?
-----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6404

  miriam: Would something like @keyframes, a name-defining at-rule,
          work in @layer and how?
  miriam: If there are two @keyframes with the same name, the later one
          wins.
  miriam: Not common to do intentionally, but I did find some people
          using this to test out new animations live in production.
  miriam: So question is if the two are defined in separate layers,
          does the layer order impact name collision resolution?
  miriam: I'd like to say yes, I think that's author expectation.

  TabAtkins: I agree with Mia - It would rule out a lot of use cases
             and would be very confusing if pure source order applied
             to these rules
  TabAtkins: the whole point of layering is against that - I think name
             defining rules should follow layer order just the same as
             anything else

  Rossen: Other opinions?
  Rossen: Not hearing objections, so let's resolve.

  RESOLVED: Name-defining at-rules follow layer order for collision
            resolution, similar to specificity resolution.

CSS Values
==========

Add lvh+lvw values
------------------
  github: https://github.com/w3c/csswg-drafts/issues/6113

  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-863677668
  <TabAtkins> https://drafts.csswg.org/css-values-4/#viewport-relative-lengths
  TabAtkins: Two weeks ago fantasai and I drafted new text for more
             viewport relative sizes. There was discussion about
             whether we should do some of these as env variables - we
             are currently using units
  TabAtkins: We introduced svw svh for small viewport, for example and
             a dvh for dynamic viewport ... as discussed in previous
             discussions dvh only needs to be accurate when it is stable
  TabAtkins: when the UI is stable, it is the correct size of the
             viewport
  TabAtkins: We would love comments or discussion - it's all very
             bikeshedable right now
  TabAtkins: If you have strong opinions on units vs env, let us know -
             we made an editors choice, but we can go either way
  TabAtkins: It would be great to be able to resolve on these next week
             (if we have the quorum)

CSS Fonts
=========

Reduce layout shift via @font-face descriptor(s) overriding inline
    spacing
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5533

  TabAtkins: Now that we have 'size-adjust', can we close this issue?
             Chris Harrelson and Chris Lilley both say yes, close it.
  <chris> Yes this one should be closed
  <jfkthame> +1 to closing
  <chrishtr> Xiaocheng is also happy to close it.

  RESOLVED: The issue is resolved

CSS Color
=========

Is color-adjust() needed, now that we have relative color syntax?
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6179

  chris: A few years ago we resolved to add two conflicting proposals
         for how to adjust colors
  chris: We've continued to publish with both, and refine them
  chris: At this point the relative color syntax seems like it's easier
         and strictly more powerful
  chris: it would be simpler if we could just decide to go with that one

  leaverou: I see color-adjust() as being slightly higher level than RCS
  leaverou: But for that, you don't actually get much more clarity
  leaverou: like color-adjust(..., lightness(20%)) - does that mean set
            it to 20%? Increase it to 20%?
  leaverou: But RCS is very clear, the math is laid out
  leaverou: So I support the RCS
  leaverou: That said, we've done research on how color is used in Sass
            since they have manipulation for years
  leaverou: The Sass equivalent of color-adjust is barely used at all
  leaverou: Instead they usually extract color components and do math
            on that, or use even higher-level functions like lighten()
            and darken()
  leaverou: So I think we should prioritize a method that does math on
            the components (RCS) and also pursue higher-level easy
            manipulations like lighten()
  leaverou: We might also want to in the future allow
            channel-extraction functions that would let you combine
            things from multiple colors; that's not possible at all
            right now.
  leaverou: I thought we might have wanted to just go with that, but
            since WK implemented RCS and people seem to like it, I'm
            fine with just going with that

  argyle: I'm very pro the RCS
  argyle: I recall some initial concerns about it confusing, but I'm
          happy to hear those are resolved.
  argyle: Agree there's no way to extract individual channels yet -
          good to work on in the future.
  <chris> I was also concerned that RCS was too complex, but I no
          longer feel that.
  argyle: So I support Lea's push here, to move forward with RCS and
          pursue channel manipulation later.
  argyle: And also doing higher-level simple manipulations like
          lighten()
  <chris> +1 to high-level color-lighten and color-darken
  argyle: So yeah, think removing color-adjust() will simplify and let
          us perhaps do a better version in the future
  <TabAtkins> +1 as well
  <bkardell> +1
  <miriam> +1

  Rossen: Any other opinions? See a bunch of +1s on the channel
  <leaverou> basically what I was trying to say is that between RCS and
             color-adjust() I'd support RCS, you get a lot more
             flexibility for only slightly more complexity. But we do
             need higher level functions and potentially something even
             more lower level that will allow combining components of
             multiple different colors (we even have internal CSS WG
             use cases for those)
  Rossen: Any objections?
  <chris> smfr on the record?
  <smfr> i want to see groove and ridge borders specified in terms of
         RCS
  <TabAtkins> smfr, I'm pretty sure it's doable without much
              difficulty, but would have to play with it.
  <leaverou> smfr: if it's not doable with RCS, it certainly isn't
             doable with color-adjust(). RCS's power is a strict
             superset.

  chris: So resolution would be to drop color-adjust(), keep relative
         color syntax.

  RESOLVED: Drop color-adjust(), stick with relative color syntax for
            color manipulation for now

  Rossen: Do you need to republish Color 5, Chris? This would be a
          pretty big change.
  chris: Yes, once we've done this we should repub
  Rossen: So let's resolve to repub once changes made

Selectors
=========

Remove the :scope dependency from the relative selectors definition
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6399

  bkardell: Selectors spec has :has(); we introduced a :scope pseudo
            alongside it. In querySelectorAll() it's very useful, but
            it's basically equivalent to :root in normal stylesheets.
  bkardell: Now :has() allows "relative selectors", starting with a
            combinator.
  bkardell: And :scope refers to that implicit starting element, and
            can be used later in the selector.
  bkardell: This causes a lot of issues; we'd prefer to drop the
            relative selector, and make the implicit starting element
            not be matched by :scope
  bkardell: I think current prior impl for it is only Prince. They do
            seem to support it.
  bkardell: But this is just a lot more difficult in the live profile
  bkardell: Issue goes into a lot more detail, looking for thoughts and
            feedback.
  oriol: In most cases, when there's a selector inside of :has() that
         has :scope, you can refactor it to move that reference outside
         of the :has() and not lose any functionality
  <leaverou> +1 to whatever restrictions we need to place on :scope to
             make :has() happen
Received on Wednesday, 30 June 2021 23:02:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 30 June 2021 23:02:57 UTC