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

[CSSWG] Minutes Telecon 2022-07-06 [css-contain] [selectors] [css-overflow] [css-flexbox]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 7 Jul 2022 05:51:06 -0400
Message-ID: <CADhPm3s5cUJJFOo31hfhBovfaqc3Npi6RAj5dhbmxY05C3Ps2Q@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 Contain

  - RESOLVED: Add the new event with the name
              ContentVisibilityAutoStateChanged (Issue #7384: Proposal:
              Add an event to fire when content-visibility: auto state
  - RESOLVED: Add a note about potential issues for a11y (Issue #7384)


  - RESOLVED: Start selectors 5 with the experimental work from this
              issue (Issue #7346: Child & descendant pseudo element
  - A new issue (#7463) was opened to explore making pseudo elements
      inside :has invalid

CSS Overflow

  - RESOLVED: Add overflow-clip-margin-inline, -block, and the full set
              of properties (Issue #7245: overflow-clip-margin might
              want to set different boxes in the block and inline axes)
  - A new issue will be opened to explore how to disambiguate the
      properties on the overflow-clip-margin shorthand.

CSS Flexbox

  - Implementers are asked review the proposed changes to the Flexbox
      Intrinsic Main Size algorithm (Issue #7189: Intrinsic Main Size
      algorithm has errors) so the group can seek resolution on a
      future call. The commit to be reviewed is


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jul/0000.html

  Rossen Atanassov
  Tab Atkins Bittner
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Dael Jackson
  Vladimir Levin
  Cameron McCormack
  Jen Simmons
  Alan Stearns

  Mike Bremford
  Boris Chiou
  Daniel Holbert
  Jonathan Kew
  Florian Rivoal
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou
  Sebastian Zartner

Scribe: dael

  Rossen: It is a couple minutes past the hour. Let's get started
  Rossen: As always, I want to get a quick call out for agenda items or
  Rossen: Did see Sebastian's ask to defer 1533 & 4557 which I'm glad
          to do
  Rossen: Agenda 3 & 4
  Rossen: Anything else we want to change?

CSS Contain

Proposal: Add an event to fire when content-visibility: auto
    state changes
  github: https://github.com/w3c/csswg-drafts/issues/7384

  vmpstr: This is a prop for a new event for content-visibility: auto
  vmpstr: content-visibility: auto right now skips rendering when
          element is offscreen or not relevant to use
  vmpstr: Proposal is expose and event that fires when this state
  vmpstr: Motivation is some of the partner feedback. In particular
          they want to skip additional work when element is offscreen
          such as react update. Event is convenient way to do so

  Rossen: Catching up, did we establish event name?
  vmpstr: We can talk about name. I have proposals and TabAtkins
          commented more explicit and verbose is better which I'm fine

  Rossen: Backing up, can you remind me for the content-visibility:
          auto elements nested inside do they participate in a11y tree?
  vmpstr: content-visibility: auto elements do participate in a11y.
          They're exposed as visible.
  Rossen: From PoV of a11y these events and content-visibility: auto
          has no meaningful meaning?
  <chrishtr> whether the content is skipped affects layout
  vmpstr: The event itself doesn't. The only potential difference is if
          script does something in response to the event such as
          skipping react updates that eventually cause a different a11y
  Rossen: Thanks. That's what I wanted to decipher here. If, as an
          author, I'm pausing a bunch of work on the event and I'm
          aware what impact pausing would have on a11y that could
          degrade the experience of assistive tech
  vmpstr: It is a possibility. Currently the solution is to add own
          intersection observer and do the same thing but impossible to
          guess the margin content-visibility: auto has internally. But
          this could be done with intersection observer
  chrishtr: Clarifying your point, Rossen. I think you were saying
            exposing the event makes it easier for author to remove
            offscreen content from DOM?
  Rossen: That would be one more kind of aggressive change, yes
  chrishtr: Yeah. Then I would repeat that it is already possible and
            virtual scrollers do it. Main value is it allow them to
            play with performance benefits. But if a site unmounts DOM
            that's far offscreen it would be less info for a11y tech

  heycam: By the sounds of it this can be achieved using intersection
          observer already by watching for the same changes, maybe with
          some additional checks for focus. Wondering about firing of
          events and which elements fired to. One difference with
          intersection observer is you register on an element and
          sounds like this event should be dispatched to every element
  heycam: Could be like the focus state of an element changes, would
          that mean have to dispatch a separate event to each ancestor?
  vmpstr: I think I would like to dispatch this event to an element
          that has content-visibility: auto style on it when relevance
          of that element changes. Spec is element is relevant if in
          flat tree has an element that has focus. It's if the
          content-visibility: auto element with the element in the
          subtree has focus
  heycam: I see. Okay

  Rossen: Additional feedback?
  Rossen: I guess you're looking for resolution to add this event, with
          name and shape tbd?
  vmpstr: If no objections to ContentVisibilityAutoStateChanged I'd
          like to resolve on that. But also happy to resolve to add
          event with name tbd
  Rossen: If no other feedback or additional comments to vmpstr then
          are there any objections to exposing such event?
  Rossen: Objections to ContentVisibilityAutoStateChanged as the name?

  heycam: Is there a way to query the content-visibility auto state?
  vmpstr: No, so the event would have that information on it
  Rossen: Hearing no objection on event or name

  RESOLVED: Add the new event with the name

  Rossen: Still a bit concerned about if there is a way to add author
          guidance about potential degradation of a11y experience. I
          don't think that's the event itself, but the event might make
          it more comfortable
  vmpstr: Can add a note to the spec next to the event
  Rossen: Would love that
  Rossen: Thanks

  RESOLVED: Add a note about potential issues for a11y


Child & descendant pseudo element combinators
  github: https://github.com/w3c/csswg-drafts/issues/7346

  TabAtkins: We've had for a little while a minor problem where pseudo
             elements inside pseudo elements have been tricky to target
  TabAtkins: Repeatedly written incorrect rules that do not correctly
             target. *::marker doesn't hit inside ::before
  TabAtkins: This will get more problematic over time as we add things
             like shared element transitions with a family of nested
             pseudo elements. Targeting a grandchild of a transition
             element you have the name the transition tag regardless of
             where because can't meaningfully use target
  TabAtkins: You can't save effort with nesting either
  TabAtkins: Jake came up with the idea of having a combinator that can
             select into pseudo tree as a descendant combinator. You
             say a name and you find it regardless of how nested it is
  TabAtkins: Suggested syntax is :> for child pseudo combinator and :>>
             for the new descendant that goes as deep as needed
  TabAtkins: Specifics is when you use this combinator pseudo elements
             are elements with tag that is their element. :: is not
             part of the name
  TabAtkins: I think that's the specifics. Allows us to greatly
             simplify and write code targeting, for example, ::marker
  TabAtkins: Thoughts?

  heycam: Can you summarize why not possible to use regular child and
          descendants once past first ::? If we're considering things
          inside top level can we use regular tag name matching?
  <fantasai> heycam++
  TabAtkins: Issue with doing that, first is would not let you
             generically select into pseudo trees. That feels not great
             that you have to enter the pseudo tree with a specific
             name and then you can do arbitrary.
  TabAtkins: Slightly more important issue is it presupposes we don't
             event use child relationships in any other way which I'm
             not certain we want to guarantee. Some pseudo elements
             refer to real elements like ::slotted. Right now can't
             access further into tree but I don't know why we wouldn't
             do that in the future
  <fantasai> See also
  TabAtkins: Instead idea here is there's a separate relationship and
             this combinator only goes across pseudo/child relationship
  heycam: Makes sense
  fantasai: One specific area we thought about this is ::page or
            ::column type things and being able to pick elemental
            fragments in that fragmented region.
  fantasai: We had thought about doing something where you can style
            black and white columns differently which needs you to
            enter the tree

  Rossen: fantasai I saw your last comment lifting BradK's old
          response. Is this something we want to repeat here?
  fantasai: I think I was pulling up old comments. Haven't thought
            deeply to have a conclusion. Idea of going deeper into
            pseudo tree makes sense. I think bradk comment was we ID
            pseudo elements with a name that begins ::. The pseudo
            element is named :: which is how we know it's not real.
            This proposal breaks that naming association
  fantasai: I think it's a comment worth thinking about.
  fantasai: Idea of using combinator syntax I can see benefits to it.
            I'm trying to think what's a way of keeping these
            considerations and bring together. Maybe instead of :> we
            do ::> so maybe still association with pseudo element so at
            least you've got two :s
  TabAtkins: Using ::>?
  fantasai: Yeah
  TabAtkins: That would be fine. I suggested : to suggest pseudo, but
             more explicit ::> is fine
  TabAtkins: Obvious solution is :: as combinator and for reasons I
             explored years ago that's unfortunately impossible due to
             selector syntax. But it would be fine with ::> and ::>>

  vmpstr: I wanted to ask how would this interact with :has?
  vmpstr: Presumably to know if there is a pseudo element you need up
          to date style and I don't think we do this now. And with :has
          you can make it display:none
  TabAtkins: Good question. Because pseudo elements always exist or
             conditionally exist I suggest answer is :has can't see
             pseudo elements when you select that deep. We can address
             it in the future if there's a need, but I would say we
             should make it invalid to use the combinator
  fantasai: Should we also make pseudo elements invalid in has in
  TabAtkins: I don't know
  fantasai: Has the same problem
  TabAtkins: Not sure you can write selectors that are problematic. If
             you can we should
  fantasai: I suggest we make both invalid for now

  Rossen: Additional feedback for TabAtkins or Jake?
  fantasai: I'd like to have a few more people weigh in but this
            overall makes sense to do this
  TabAtkins: I can start laying down details in spec and we can get
             eyes once there's text. As long as no obvious objection
             now I'm happy
  Rossen: Not hearing any such objection from dozen or so people on the
  Rossen: Let's move forward with spec. Once you have that hopefully
          more people will provide feedback
  fantasai: Related question, do we want to take a cut of selectors 4
            to CR and redraft selectors 5?
  TabAtkins: Think so and happy to put this in selectors 5
  fantasai: Okay. Let's do that and you and I can work on taking a cut
            of selectors 4
  TabAtkins: sgtm
  Rossen: Let's resolve on starting selectors 5 with the experimental
          work from this issue
  Rossen: Objections?

  RESOLVED: Start selectors 5 with the experimental work from this issue

  Rossen: For selectors 4, any resolution for that at this point?
  fantasai: We were going to make it invalid to use a pseudo element
            inside :has
  Rossen: Is this part of the issue or part of moving selectors 4?
  fantasai: Related to this issue because this issue brought what
            happens if you put pseudo element in :has
  jensimmons: We should open a new issue for that and give it more time
  jensimmons: I don't think we should do it ahead of time because we
              think this is going to go through. We should look at
              present state
  <@astearns> +1 to a separate issue to discuss async and bring it back
              for a resolution
  fantasai: Yes, looking at current and think it's a problem for the
            same reason as in context of this discussion. I think it's
            something we didn't consider.
  <@fantasai> ol:has(li::marker) is confusing and shouldn't be possible
  jensimmons: Cool. How about open an issue for next week's agenda?
  Rossen: I don't mind that at all since the proposed resolution also
          didn't come through to me clearly from the previous
  Rossen: Do we want to fork that into a new issue and slot it for next
          week? It will fit nicely with some other items we're skipping
          this week
  fantasai: Okay
  Rossen: Next week we can take all the resolutions to move selectors 4
  Rossen: fantasai will you open?
  fantasai: Sure
  Rossen: Anything else on this issue?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/7463

CSS Overflow

overflow-clip-margin might want to set different boxes in the block
    and inline axes
  github: https://github.com/w3c/csswg-drafts/issues/7245

  Rossen: Can we discuss this w/o emilio?
  fantasai: Probably. Next issue should wait
  fantasai: On this, proposal we accepted to add overflow-clip-margin
            property. Takes a value to clip a little outside border
  fantasai: This allows some amount of overflow
  fantasai: Typical margin properties have longhands that allow you to
            do sizes of box with physical or logical coord.
  fantasai: Also semi-longhands that do both inline or both block sides
            at the same time
  fantasai: emilio filed this saying might be useful to be able to set
            overflow-clip-margin independently in block and inline
            axis. That brought up question of do we want full set of
            longhands or just per axis
  fantasai: If we're going halfway overflow-clip-margin would take 1
            value and set all 4. You could do
            overflow-clip-margin-block and -inline. Later we could add
            the full longhands if there's need
  Rossen: Comments?

  vmpstr: To clarify, if both are set is there a precedent of what
  fantasai: overflow-clip-margin is shorthand for
            overflow-clip-margin-block and -inline
  vmpstr: Got it
  Rossen: And if you only set....okay...

  Rossen: Proposal is start with the single value and extend to inline
          and block?
  Rossen: Or do we want to resolve on the full expansion?
  fantasai: That's my question. Just inline and block or explode all
            the way?
  Rossen: Would be quite inconsistent to have a shorthand with only 2
          values. For consistency prefer if similar to margin
  Rossen: But that's a point for consistency
  jensimmons: Agree to explode it out so we don't confuse people
  Rossen: And compat later is easier
  Rossen: When you have impl that only support 2 and other impl that
          support all
  Rossen: Sounds like we want to resolve to expand out the shorthand to
          support all the inline and block values, both logical and
  fantasai: Yeah, if we want all the sides we do the full set
  Rossen: Add overflow-clip-margin-inline, -block, and the full set of
  Rossen: Additional thoughts? Objections?

  khush: Clarifying one thing. Margin shorthand has syntax to spec
         value for all 4 sides. Resolution is not to make that work,
  fantasai: If we're going to the full set that we'll be fully
  khush: Oh. Depending on how many values spec it was saying
         overflow-clip-margin could have 2 values to specifying content
         box and margin. If we see 2 is it supposed to be for top or
  fantasai: So because we have 1 or 2 values for each longhand we would
            have to figure out how to disambiguate shorthand
  khush: Exactly
  fantasai: Other option is pull out the box choice into own longhand
            so margins are all linked. But then couldn't choose
            different boxes to offset from. That would solve
            disambiguation issue.
  fantasai: Other possibility is restrict the shorthand so it's only
            one but it's applied to all for the longhand. If you want
            to offset differently you have to use the longhand. We do
            have precedent
  khush: So shorthand wouldn't let you supply both values. If you want
         that you have to use longhand
  fantasai: Yeah, I think would be one easy way to do.
  fantasai: To allow everything in shorthand we would have to either
            require box for every keyword or require length for
            everything or use a separator.
  fantasai: A bunch of ways to handle. Probably should resolve to add
            all the longhands and then follow-up how to handle the
            shorthand parsing because should discuss more
  khush: We did ship overflow-clip-margin in chrome which lets you spec
         both things. But exploring options separate sounds good
  fantasai: I think if you do keyword + length all the options here
            still allow that

  Rossen: Proposal: Add all the longhands to
          overflow-clip-margin-inline and follow up with a separate
          issue for how to handle the shorthand parsing
  Rossen: Does that sound reasonable?
  khush: sgtm
  Rossen: Additional comments or objections to add
          overflow-clip-margin-inline, -block, and the full set of

  RESOLVED: Add overflow-clip-margin-inline, -block, and the full set
            of properties

  Rossen: khush or fantasai please open separate issue

  Rossen: fantasai you asked to make time for agenda item 4 but
          Sebastion asked to skip. Should we take now or wait until
          next week?
  fantasai: Next week
  Rossen: Why skip 6 without emilio?
  fantasai: It's impacting the cascade and want to make sure it works
            with their architecture
  Rossen: Okay. MQ issue (7213) seems to be in similar boat to need
  smfr: Not sure
  <oriol> 6 is about aligning with implementations, so not sure we need
  Rossen: happy to push that
  smfr: Sure, let's push

CSS Flexbox

Intrinsic Main Size algorithm has errors
  github: https://github.com/w3c/csswg-drafts/issues/7189

  <@fantasai> See
  TabAtkins: This is a call for review from others. We found when
             reviewing WPT that the handling of intrinsic sizes of
             flexbox when sum < 1 wasn't correct. Have gone back and
             forth with dgrogan a few times. Pretty sure it's right now.
  TabAtkins: Found to avoid explosions to infinity need slightly
             different algorithm to get correct intrinsic size. David
             thinks they're fine. Anyone else, we would appreciate
             review. It's is subtle changes and if there are mistakes
             or violates other requirements would appreciate review
  fantasai: We should get resolution, but can have more time for review
  Rossen: I was reading through commit linked in issue and it's quite
          involved. Would prefer to give time to reason through it
  Rossen: I think even though some of it is notes they're complex and
          good to give time
  TabAtkins: Yeah. This was complicated enough I had to do 2 nested
             details. Definitely a little complex
  Rossen: So in that case action to implementers of flexbox to please
          review the commit
  <Rossen> commit to be reviewed

  jensimmons: Do the WPT tests need updating or are they now accurate?
  TabAtkins: Not 100% sure but I believe tests will need updating. I
             think David will take care of that
  jensimmons: If he's not, recommend opening an issue on interop repo
  jensimmons: Just so they're aware
  jensimmons: I can file
  fantasai: I think intrinsic algorithm is a focus on there since it's
            been changing based on impl feedback
  Rossen: Would be great to add the issue, thanks jensimmons

  Rossen: We're at time.
  Rossen: Reminder we have a F2F in less than a month. Please register
          if you haven't done so
  <@fantasai> Please register! https://wiki.csswg.org/planning/nyc-2022
  Rossen: Please signal attendance and other details for the organizers.
  Rossen: Thank you everyone!
Received on Thursday, 7 July 2022 09:51:46 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:20 UTC