- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Jul 2022 05:51:06 -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 Contain
-----------
- RESOLVED: Add the new event with the name
ContentVisibilityAutoStateChanged (Issue #7384: Proposal:
Add an event to fire when content-visibility: auto state
changes)
- RESOLVED: Add a note about potential issues for a11y (Issue #7384)
Selectors
---------
- RESOLVED: Start selectors 5 with the experimental work from this
issue (Issue #7346: Child & descendant pseudo element
combinators)
- 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
https://github.com/w3c/csswg-drafts/commit/d452a10a921391dc6b6a96e7be97218692c1de53
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jul/0000.html
Present:
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
Regrets:
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
changes
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
changes
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
with
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
tree.
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
ContentVisibilityAutoStateChanged
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
Selectors
=========
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
https://www.w3.org/TR/2014/WD-css-scoping-1-20140403/#fragment-scoping
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
general?
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
call
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
conversation
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
forward
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
edge.
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
happens?
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
physical?
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
properties
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,
right?
fantasai: If we're going to the full set that we'll be fully
consistent
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
both
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
properties
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
emilio
smfr: Not sure
<oriol> 6 is about aligning with implementations, so not sure we need
Emilio
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
https://github.com/w3c/csswg-drafts/issues/7189#issuecomment-1172771501
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
https://github.com/w3c/csswg-drafts/commit/d452a10a921391dc6b6a96e7be97218692c1de53
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