- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Apr 2025 19:19:25 -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 Values
----------
- RESOLVED: Have sibling-index() and sibling-count() to default to
DOM tree (Issue #9562: Allow specifying flat vs light
tree in `sibling-index()` and `sibling-count()`)
CSS Position
------------
- RESOLVED: Adopt spec text as quoted, i.e. no change to spec. (Issue
#11195: Absolute positioning - Is the new inset &
auto-size behaviour web-compatible?)
View Transitions
----------------
- The proposal for issue #11926 (Nested ::view-transition-group
should have a container pseudo) was to add new new container.
Through discussion there were initially questions about expected
behavior and if the complexity was worthwhile. More examples will
be added to the issue including the broader context of what use
cases this would impact.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Apr/0009.html
Present:
Rachel Andrew
Kevin Babbitt
David Baron
Andreu Botella
Kurt Catti-Schmidt
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Daniel Holbert
Brad Kemper
Jonathan Kew
Roman Komarov
David Leininger
Vladimir Levin
Rune Lillesveen
Alison Maher
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Sam Weinig
Sebastian Zartner
Regrets:
Lea Verou
Scribe: ydaniv
CSS Values
==========
Allow specifying flat vs light tree in `sibling-index()` and
`sibling-count()`
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9562
emilio: This is about which tree do sibling-index and sibling-count
work on
emilio: Right now using the flat tree which is weird default
emilio: The right default would probably be the light tree
emilio: A lot of work if there is now use-case
emilio: Could expose, but feel strongly default should be DOM tree
astearns: This is only about using the DOM tree as default
bramus: We initially mentioned that this would be whatever n-child
is using
futhark: No strong opinion but nth-child already has issues
futhark: If we add support selectors inside -index() that would
enable it, otherwise there is a clear use-case for using DOM
tree
futhark: Do think it could be said the same for nth-child
futhark: There's also a proposal for children-count() and that would
have a big difference
futhark: because if you style the slot ... if allowing flat tree
emilio: I think that makes sense, I think sibling and child count for
flat tree are a bit more complicated because there are two
counts you care about, the one that includes slots and the
"flattened" one
emilio: I could come up with cases for both, we need a more holistic
conversation how we expose these in all functions
emilio: default should be DOM tree
<bramus> +1
futhark: I agree
futhark: implementation-wise not a big deal for us
astearns: What if we resolve to change specs to default for DOM tree
for sibling-index and -count
astearns: and keep this issue open for swapping for all of other
counting functions
PROPOSED: to have sibling-index() and sibling-count() to default to
DOM tree
RESOLVED: Have sibling-index() and sibling-count() to default to DOM
tree
CSS Position
============
Absolute positioning - Is the new inset & auto-size behaviour
web-compatible?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11195
emilio: Still one issue in spec - margin auto preventing stretching
emilio: need oriol to take this properly
astearns: Can we resolve on omitting this clause?
emilio: To change the text to refer to inset properties
fantasai: Issue with web compat, more general
fantasai: applying alignment where insets were auto
fantasai: I think it would be ideal if we apply <missed> to flexbox
and grid
fantasai: auto affecting stretch is not impacted by web compat
<fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%3B%20display%3A%20flex%3B%20height%3A%20100px%22%3E%0A%20%20%3Cdiv%20style%3D%22background%3A%20orange%3B%20align-self%3A%20stretch%3B%20margin-top%3A%20auto%22%3Ex%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
fantasai: In flexbox margin win over stretching
fantasai: AFAICT
astearns: Only in flexbox?
<fantasai> https://www.w3.org/TR/css-flexbox-1/#valdef-align-items-stretch
fantasai: I believe grid is the same
fantasai: So when alignment is normal we should do...
fantasai: but for stretch should be compatible with what we do
fantasai: The alignment property didn't have any effect until recently
fantasai: normal should be resolve margins to 0
fantasai: auto margins don't win over the stretchy behavior
fantasai: so for stretch alignment the auto margins should win
fantasai: just set to 0
astearns: You're suggesting we need a change for normal?
fantasai: No, the auto value already is correct
astearns: Maybe we need to take this back to issue?
fantasai: oriol is describing what browsers do currently
fantasai: The questions is what the specs should specify
<fantasai> Current spec says that if alignment is normal and margins
are auto, we stretch
<fantasai> If alignment is 'stretch' and margins are auto, we don't
stretch
fantasai: If author says stretch they want it more, but compat with
CSS 2 we can't change normal alignment, but can make
stretch alignment more like flexbox and grid
<bradk> +1 to usefulness of auto margin winning for stretch, like
flex and grid.
iank: So this might be orthogonal
iank: Changing anything for the double auto set case is not web compat
fantasai: Last comment was that this was fixed in spec
astearns: Anyone wants to argue that stretchy things would be
different?
iank: Could we add examples of who is doing what and what is intended
behavior?
fantasai: We have non-replace element, with insets set on both sides,
has auto margins, has either no alignment or normal
fantasai: what wins? stretch? or margins?
fantasai: On normal behavior stretch behavior wins
fantasai: that needs to be how we define normal
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=13699
<iank> this case?
fantasai: What I'm arguing is for stretch alignment where we have
room to make adjustments we
fantasai: be compat with flexbox and grid
iank: Seems fine
fantasai: Proposal is to adopt spec as quoted and not as suggested
astearns: Suggest to close and open only if spec text on stretch
turns wrong
<fantasai> PROPOSED: Adopt spec text as quoted, i.e. no change to
spec.
<emilio> sgtm
RESOLVED: Adopt spec text as quoted, i.e. no change to spec.
View Transitions
================
Nested ::view-transition-group should have a container pseudo
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11926
vmpstr: In VTs we have a pseudo struct with group, under image-pair,
under old and new
vmpstr: In group we added capability to nest groups
vmpstr: We found that you'll be able to clip in VTs that are not all
flat
vmpstr: We found it's hard to do if element has borders, you'd clip
the group instead of area that you intended
vmpstr: Proposal is to add a VT content or other pseudo element that
acts as the parent of all nested groups
vmpstr: so you have an image-pair and another child, say content
vmpstr: would allow you to clip just the group and not the content
vmpstr: Proposal is to size to padding box which clips the padding
box of the originating element that created the group
bramus: Wanted to say that I tried this in playground by faking it
real elements, and having this extra element makes it much
much easier for authors to achieve this clipping
bramus: You can see in the playground, if you compare the code of
element with hotpink <missed>
bramus: Much more convenient with this extra pseudo
emilio: Is that just a border that doesn't clip correctly?
vmpstr: It would be captured in either old or new that nested under
pair that's under group
astearns: Proposed resolution is to add a new VT container?
vmpstr: Happy to change the name, it's technically group container
bramus: with the * that it doesn't include the outer group
flackr: I think the name content is roughly consistent with the box
model
ntim: One question, are there any alternative solutions to address
this use-case?
ntim: Content is a better name than container cause here it's a child
of the group
vmpstr: Both a child of the group but contains other groups
vmpstr: As for q, bramus can answer better, not easily, can have
<missed>
fantasai: We got the VT group, and then for each group it contains a
pair and old/new, and in each thing we animate will have
its own nested
fantasai: within an existing groups
fantasai: Now we're saying to separate the image-pair, and now have
another grouping element around all nested transitions
vmpstr: Yes ....
fantasai: In many cases a lot of the content will be in the image-pair
fantasai: so container make more sense
fantasai: I think since a lot of content will be in the image-pair,
calling it content will be confusing
<ntim> -1 to the specific word combination of `-group-container`
astearns: Wondering if there are no nested VTs, is this new thing
going to be empty?
vmpstr: Good question, was thinking of not having one that would be
empty
emilio: This would be the only pseudo that would have special size,
or we don't need this special case?
vmpstr: I only know of the VT's sizing, and yes, that would be the
only case, the others are on border-box
bramus: Not having a pseudo if there are no nested groups is
consistent with not having a new or old pseudo in some cases.
emilio: Sounds unfortunate, maybe we should allow sizing the groups?
emilio: if you allow that then we could use them
<astearns> group-wrapper, group-parent…
vmpstr: Problem is if you size them then the border in the old,
adding a clip will clip that
emilio: Doesn't that mean that the snapshot will override the border?
emilio: I guess the old and new are things that actually need the
border
emilio: Would be nice to have a simpler use-case for this
emilio: Maybe fine...to me seems to want to have a border and not clip
emilio: My question, is this case worth adding the extra complexity?
emilio: when you capture the snapshot old/new elements, the size is
not necessarily size of border box, but ink overflow, so you
need a size for the pseudo element that represents this
emilio: I assume it's a reasonable default, it's doable but I think
it's unfortunate for special case
<ntim> +1 to emilio, magic is annoying
<ntim> `::view-transition-nested-*` is my probably my favorite pick
for a name
vmpstr: It contains the nested elements in it, so what would size
it to?
vmpstr: If to border-box then elements at the border ...
vmpstr: would you be ok with content box?
emilio: Groups do that
emilio: The things you're snapshotting and the box model of the
pseudo tree makes sense
emilio: We're not discussing that
vmpstr: Current box model of the pseudo tree makes sense
vmpstr: Make the case that shouldn't be sized to border box?
emilio: Yea
vmpstr: Possible
vmpstr: Overall, with nesting as it's specified right now you have
the ability to clip your groups it's only possible if you
clip yourself
vmpstr: if the objection is only to sizing, to border box
vmpstr: so probably to padding box, which is what I'd recommend, that
is my sense
astearns: I wonder would it make sense to have the box args as params
emilio: Doesn't quite work, because the function selects different
elements
emilio: I do think that something along those lines that you can
somehow specify how things are sized
emilio: like ink overflow, maybe
emilio: to me adding extra container is not big deal but feels like a
smell, for a particular case
emilio: maybe I'm misunderstanding
emilio: feels to special for something that we should address
differently
emilio: haven't thought about this deep enough
bramus: Wanted to address some remarks
bramus: I will record what I'm showing in the playground and add
comments
bramus: why this extra element would make things easier
bramus: it's a code smell but help a lot
emilio: Maybe we should allow the capture to be sized to padding
rather than border
emilio: feels like more general issue, maybe I'm wrong
vmpstr: The part I'm missing, suppose you take clipping as an
example, how else would you clip the group without clipping
the content?
emilio: If the container of the snapshot that sized to the border
box, ...
vmpstr: There's only one clip that clips both, they should have
different clippings
emilio: I guess I need to wrap my head around the tree
flackr: Another harder case is having shadows and decorations that go
outside of the border box
flackr: and shouldn't be clipped
vmpstr: Have a few diagrams in the issue you can respond to
emilio: Sounds good
astearns: We'll take this back to the issue
astearns: I suppose talk about the possibility of changing clipping
of everything else?
Received on Wednesday, 23 April 2025 23:19:58 UTC