=========================================
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 View Transitions
--------------------
- RESOLVED: Start specifying element-scoped view transitions in view
transitions L2 (Issue #9890: Element-scoped view
transitions)
- RESOLVED: Add ::view-transition-group-children() (open to better
names), and copy border-sizing properties to it (Issue
#11926: Nested ::view-transition-group should have a
container pseudo)
CSS Conditional
---------------
- RESOLVED: Scroll state queries against the root match the scroll
state of the layout viewport (Issue #11542: Match
scroll-state(scrollable) for root element on viewport)
- RESOLVED: Scroll state containment on root element blocks overflow/
scroll-related propagation from the BODY element (Issue
#11542)
CSS Borders
-----------
- RESOLVED: Add corner-shape to the border-radius clause in outline
definition (Issue #12194: Specify how `corner-shape`
affects `outline`)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025May/0022.html
Present:
Rachel Andrew
David Awogbemila
Kevin Babbitt
David Baron
Justin Breiland
Keith Cirkel
Emilio Cobos Ãlvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Simran Gill
Paul Grenier
Daniel Holbert
Jonathan Kew
Roman Komarov
David Leininger
Vladimir Levin
Rune Lillesveen
Alison Maher
Romain Menke
Florian Rivoal
Noam Rosenthal
Alan Stearns
Josh Tumath
Sam Weinig
Regrets:
Tab Atkins-Bittner
Oriol Brufau
Chris Lilley
Miriam Suzanne
Bramus Van Damme
Lea Verou
Scribe: emilio
Scribe's scribe: fantasai
CSS View Transitions
====================
Element-scoped view transitions
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9890
noamr: view transitions are shipping in multiple browsers
noamr: a big feature request has been having them element-scoped, so
that they don't have to lock the whole document, and you can
have multiple of them altogether
noamr: started prototyping it, lots of open issues
noamr: wanted to introduce the basics
noamr: and see if we can resolve adding it as a draft with everything
else as open issues
noamr: what we want to add is not just the document can start a VT,
but also on Element
noamr: the pseudo-elements are attached to the element rather than
document
noamr: lots of open issues, need to figure out what to do if the
element changes size, how the name resolution works, ...
noamr: we feel confident enough that we can go forward and wanted to
see if the WG is fine with adding a draft with the skeleton of
this
emilio: Is the main requested use case having multiple transitions at
the same time, or keeping the document responsive etc.?
emilio: Having multiple of them doesn't seem untenable either
emilio: multiple document-level ones I mean
emilio: though it would require some coordination
emilio: but, wondered about extending the document one rather than
adding nesting ones
emilio: can sidestep some of these issues
emilio: wanted to hear your thoughts; not opposed to this
noamr: Those difficulties are the feature in a way
noamr: we want to make this work in shadow dom and not worry about
document-level things interacting
emilio: Wondering, if you want to do some sort of independent
transition, don't want to coordinate with everything that
might start a transition
emilio: but that seems solve-able in a way, with the current setup
emilio: you add a scope parameter to the document.startViewTransition
emilio: for that transition, you only scan for transitions in that
subtree
emilio: only snapshot in that subtree
emilio: very similar to element.startVT but uses document
infrastructure
emilio: thing you don't want is to depend on things changing around
emilio: I'm assuming the eventual setup will be similar
emilio: so maybe it's fine ...
emilio: but wondering how much you had considered that
noamr: We had, but let's add to open issues
noamr: easier to discuss individually
emilio: sure
noamr: Once we have a draft we can address things more piecemeal
astearns: How are these element-scoped transitions going to interact
with document-level, does one win over the other?
noamr: open issue, but names can't conflict at least, and there'd be
some sort of contained view transition name to separate
internal names
noamr: in general you should be able to run both as long as names are
not conflicting, external one would use the output of the
scoped one
noamr: think about a `<video>` or another replaced element
astearns: vague concern about having a subset of the pages being
transitioned having rendering and hit-testing suppressed
astearns: something about spoofing clicks and what not
astearns: but I don't have a specific attack in mind
noamr: separate open issue about hit test suppression
noamr: the scoped element itself would receive hit testing, just the
internal elements wouldn't
astearns: view-transitions L3?
noamr: really rather not add another one
noamr: I'd suggest keeping at L2 and if other impl requests it we can
reduce its scope
fantasai: wrt levels seems one of the interesting things is working
out how these things correspond to each other
<fantasai> https://drafts.csswg.org/css-view-transitions-2/#changes
fantasai: would be helpful to list additions from L1 to L2
fantasai: other than view-transition-class is there anything not
related to nesting/scoping?
noamr: all the cross-doc stuff
noamr: actually a lot of kitchen-sink things
fantasai: gotcha
fantasai: if we end up splitting L2 might make sense to keep
kitchen-sink in L2 and move nesting and scoping stuff
with L3
noamr: wanted to merge L1 and L2
emilio: +1 to merging L1 and L2
astearns: other concerns?
RESOLVED: Start specifying element-scoped view transitions in view
transitions L2
Nested ::view-transition-group should have a container pseudo
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11926
vmpstr: we discussed this in the context of nested view-transition
groups
vmpstr: to add a container to the nested groups
vmpstr: with the purposes of clipping the nested groups
vmpstr: bunch of discussions on how to accomplish that
vmpstr: for the purposes of unblocking I'd like to split some
resolutions
vmpstr: so (1) we need a new element, (2) naming and (3) sizing
vmpstr: proposal is to size it so that if we apply a clip you make
the clip apply as in the original element
vmpstr: so size it to border-box and set border-color: transparent
and copy border* properties (border-width/border-box/
overflow-clip-margin)
vmpstr: that way if the author decides to apply a clip it'd clip the
same way as the original element
vmpstr: noamr had a different proposal, to take the original
element's clipping-region, and turn it into a mask, and apply
that mask on top
vmpstr: that may work in some cases better than this copying, but is
more complicated
vmpstr: so I'd prefer to resolve on copying the border props
vmpstr: and then open an issue to the mask
vmpstr: I'd like some resolutions to get some early version of this
into developers
vmpstr: none of the solutions are ideal
fantasai: so what we have right now is group() and image-pair()
fantasai: and we need another?
fantasai: why do we need a separate group() and image-pair()?
vmpstr: we want to nest things from other elements within this group
vmpstr: naively those would be siblings of the original group
vmpstr: which you wouldn't clip the children
vmpstr: so that it wouldn't affect the clipping of the image-pair
fantasai: remind me why we added the image-pair()
vmpstr: for isolation, we blend old+new with plus-lighter
fantasai: so generally we don't recommend authors to style the
image-pair()
fantasai: just pretend it doesn't exist?
vmpstr: that is the case in my experience
fantasai: wanna make clear in the spec that authors should style
group()
fantasai: so if the author creates a transition between old/new
versions of the grouping element, where the border is
transitioning as step() rather than smooth, would this
copied version of the border track that?
fantasai: or would it end up unsynchronized?
vmpstr: so you mean the transition step() is the new/old() ones?
vmpstr: I don't think it'd be synchronize
vmpstr: in the simple case old/new they cross-fade to the other, so
it doesn't animate borders, it blends the pixels
vmpstr: you can't cross-fade clips
vmpstr: with the mask approach you could cross-fade the masks I guess
vmpstr: but even in the default case it might not be great
flackr: I'm supportive of the idea
flackr: if we don't need to customize this we might want this to be
internal in order to change the mechanics?
vmpstr: I think that's very magical
vmpstr: something's clipping this but there's nothing there
vmpstr: it's maybe an option
vmpstr: maybe too magic for my taste
emilio: Seems to me splitting resolution, allow new pseudo
<flackr> emilio: Good idea to split resolutions. I thought default
was not clipping.
emilio: naming, I don't care very much
emilio: specifics of sizing and stuff is the tricky thing
emilio: I'd rather keep it simple and let authors use clip-path etc.
emilio: especially if default case won't be great
emilio: If you need to clip with rounded rect with border, you could
use clip-path or something else
emilio: should also work in the negative direction
emilio: seems like at least the first resolution would be
uncontroversial, and would help make progress
vmpstr: unfortunately bramus not on the call
vmpstr: happy to resolve on adding pseudo+name for now then see if we
can resolve further
flackr: Please resolve on adding the pseudo, but we need the border
on it because the position of the descendants depends on
having a border
flackr: if developers added that border it'd shift all the
descendants so we need the border size as part of the copied
props
<vmpstr> +1
emilio: would it though?
emilio: The groups are absposes, right?
emilio: and I guess the idea is that the group would always be the
containing block of these? but aren't we using transform to
position and size these?
flackr: yes but it's relative to the content
emilio: Isn't that how all other view transition pseudos work?
emilio: Doesn't it mess things up if you add a border to
::view-transition-group today?
flackr: Yes, but you would add this border to replicate the original
clip, but by adding border you would screw up the positions
of the elements
vmpstr: You wouldn't add the borders on the group element itself,
because captured the pixels that overflow the border box
vmpstr: not a typical use case
emilio: right, but you might not need a border
emilio: but ok, I guess, do other things affect padding vs border box?
emilio: does border-image do something weird?
noamr: no, only border-width really
vmpstr: I'd like to leave this a little open, as in anything that
does affect it
vmpstr: if other things affect, we can add them
emilio: I guess it's ok? It feels weird to account for existing
borders in this pseudo.
emilio: idea would be to change how positioning of inner things work,
to account for the border, right?
emilio: but maybe we can fix it more generally, so that if you add a
border to any of these pseudo-elements...?
emilio: I guess it's hard to know beforehand
emilio: The inconsistency with all the other grouping pseudoes
bothers me
emilio: also copying the border-width is not too terrible
emilio: I guess you also need to set border-style...
vmpstr: we can possibly copy border-{width,style}, set border-color
to transparent
vmpstr: Yes, we can possibly copy border-width and border-style, and
set border-color to transparent if it was set to something on
the original element
vmpstr: border-width might not have an effect depending on the rest
of the styles
vmpstr: details tbd but the idea would be to keep the border area
without drawing the border
astearns: think I'm hearing consensus of adding the pseudo and maybe
giving a name
vmpstr: would like to resolve on copying something details tbd
vmpstr: content-area-affecting properties like border-width, maybe
border-shape-affecting props like border-radius
astearns: proposed name?
vmpstr: `view-transition-nested-groups()`?
`view-transition-nested-content()`?
vmpstr: no particularly strong naming
<flackr> +1 to content
<fantasai> view-transition-group-children?
emilio: content sounds better for some reasons, but you also want the
padding area. nested-content seems fine. fantasai's
suggestion also seems fine
fantasai: I think none are particularly great
fantasai: I don't like nested content because a lot of the content is
going to be captured outside
<noamr> view-transition-content-area?
vmpstr: view-transition-group-children or content-area?
fantasai: children seems slightly better because it distinguishes the
image-pair
fantasai: content-area is weird because you want the padding
vmpstr: let's not reference specific boxes, and do
view-transition-group-children?
PROPOSED: add ::view-transition-group-children() (open to better
names), and copy border-sizing properties to it
fantasai: Want to propose clarifying the spec with the suggestion to
style ::group() and not ::image-pair
<fantasai> ACTION: Clarify L1 to encourage styling ::group() and not
::image-pair()
<RRSAgent> records action 1
RESOLVED: Add ::view-transition-group-children() (open to better
names), and copy border-sizing properties to it
Match scroll-state(scrollable) for root element on viewport
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11542
futhark: for scrollable feature, which queries whether something is
scrollable in that direction
futhark: so wanted to clarify that if the root element is a
scroll-state container we should evaluate the scroll state
against the viewport
futhark: similar to scroll-snap-type
futhark: I thought this was straight-forward but tab/miriam had some
comments, where they want to fall back to the viewport
futhark: basically if you set the scroll-state in the root it stops ??
futhark: also if you contain scroll state queries with style queries
we don't have a definition for them on the viewport
futhark: TabAtkins and miriam are not around, maybe fantasai does
have opinions?
flackr: just to clarify, we want the layout viewport right?
flackr: as it shouldn't change when you pinch-zoom
<fantasai> +1
<emilio> +1
flackr: I think from the issue we have a lot of precedent for the
root element representing the layout viewport
flackr: overscroll-behavior and so on
flackr: I think resolving that we handle this if you make the root a
scroll container makes sense
futhark: makes sense, we also have the same proposal of falling back
to the viewport for size queries
fantasai: making the root work this way makes sense. Having viewport
just work seems it'd be a separate thing and more work
probably
fantasai: in the meantime we can make this work
emilio: Makes sense. one of the tricky things wrt making viewport
just work is that root element is inside the viewport, but
can technically affect it, so wouldn't that be cyclic?
emilio: brings me to my next point, which is, if you make root a
scroll container
emilio: scroll-state container
emilio: we should not propagate overflow from the body, because that
would be cyclic
emilio: by default we do that
futhark: this has been resolved, for size queries we don't propagate
across containers
futhark: we don't propagate from body to viewport if root is a size
container
futhark: you were mentioning cyclic problems
futhark: even if the scroll state query matches the viewport you
wouldn't be able to match it, you could only style the
viewport
futhark: the spec says something about size queries, we might need
something to be added for scroll queries
fantasai: right, you'd be querying the scrollport of the viewport but
the root would be conceptually the container
<flackr> +1
fantasai: I think there's several things to resolve...
fantasai: scroll state queries against the root match the viewport
fantasai: the layout viewport
fantasai: this type of containment blocks scroll propagation from the
body
emilio: That matches my understanding as well
<fantasai> PROPOSED: Scroll state queries against the root match the
scroll state of the layout viewport
<emilio> +1
<flackr> +1
RESOLVED: Scroll state queries against the root match the scroll
state of the layout viewport
<fantasai> PROPOSED: Scroll state containment on root element blocks
overflow/scroll-related propagation from the BODY element
<flackr> +1
<emilio> +1
RESOLVED: Scroll state containment on root element blocks overflow/
scroll-related propagation from the BODY element
CSS Borders
===========
Specify how `corner-shape` affects `outline`
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12194
noamr: there was a question about how does corner-shape matches
outline. Current spec is not interoperable, rather handwavy
noamr: spec says it generally should follow the border
noamr: should I continue that path for border-shape?
noamr: following the border
noamr: should we try to make that interoperable?
florian: I think short term is to extend the current spec
florian: going beyond it is a big project, there are a lot of other
issues with outline
florian: defining would be a good project but a big project
[missed]
emilio: we have the magic thing, which is outline-style: auto
emilio: for easy cases we can more easily define
emilio: handwaving fragmentation cases can be fine
emilio: agree we shouldn't need to fix everything
emilio: but let's get interop on some cases
florian: two resolutions
florian: 1. Follow corner-shape
florian: 2. WG will attempt to outline in more detail
florian: we don't have a definition, but we can try
emilio: the non-auto cases seem pretty definable
florian: definable, but is not currently defined
florian: I used to have an art gallery of interesting outline
rendering, so there is a lot to define!
astearns: Out of time, but I think it sounded like we have consensus
to at least add corner-shape to the bit that defines how we
deal with border-radius
astearns: add it to that vagueness, and perhaps a note to better
specify this later
noamr: sgtm
florian: I agree with the direction, probably issue rather than note
though
noamr: open a separate issue
PROPOSED: Add corner-shape to the border-radius clause in outline
RESOLVED: Add corner-shape to the border-radius clause in outline
definition
Received on Wednesday, 28 May 2025 23:46:53 UTC
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4