- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 May 2024 19:52:27 -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.
=========================================
View Transitions
----------------
- RESOLVED: view-transition-name lookup is tree-scoped (Issue #10145:
Should view transition names be tree scoped?)
- While discussing issue #9839 (Handle startVT for offscreen
iframes), a new proposal came up to start an offscreen iframe
animation with a negative start delay so that it could begin to
animate when it appears without having to do a lot of work while
it's offscreen. There wasn't time on the call to think through
the potential upsides and downsides to this approach so
discussion will return to github.
- RESOLVED: ::view-transition pseudo is the last child of its
originating element, after everything else including
other pseudo-elements (Issue #9588: Clarify ordering of
`::view-transition` with other tree-abiding
pseudo-elements)
CSS Transitions
---------------
- RESOLVED: Animation to/from keyword sizes requires an opt-in, so by
default only get transition if at least one side gets
calc-size() (Issue #626: Transition to height (or width)
"auto")
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0005.html
Present:
Rachel Andrew
Tab Atkins-Bittner
David Baron
Kevin Babbitt
Stephen Chenney
Keith Cirkel
Daniel Clark
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Chris Harrelson
David Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Una Kravets
Vladimir Levin
Alison Maher
Florian Rivoal
Khushal Sagar
Jen Simmons
Alan Stearns
Brandon Stewart
Bramus Van Damme
Lea Verou
Jason Williams
Regrets:
Oriol Brufau
David Leininger
Noam Rosenthal
Miriam Suzanne
Chair: astearns
Scribe: fantasai
Scribe's scribe: emilio
View Transitions
================
Should view transition names be tree scoped?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10145
khush: Spec currently traverses all DOM elements, including those in
shadow DOM
khush: Suggestion is to limit to tree-scoped
khush: so this would exclude things in shadow DOM
<TabAtkins> +1 to this
astearns: I've written some tests for tree-scoping, btw, and interop
is terrible
khush: Are you talking about other features that are similar?
astearns: Yeah, I did @property rules and @xxx rules, which are
supposed to be tree-scoped, and they're not handled
correctly
astearns: so probably some other things are also broken
fantasai: Two things, khush does this mean that for view-transitions
that you'll never be doing transitions on anything in the
shadow dom?
khush: Yeah this means that you couldn't use something inside the
shadow dom as an independent thing
khush: scoped transitions would allow you to do that
khush: but only as a unit inside the DOM
fantasai: To Alan, there's two different kinds of scoping, at-rules
and name defining on elements
fantasai: those are quite different mechanism
fantasai: I'd expect less issues with things like timeline scopes and
so on
kizu: Wrt other scoping things, we also have timeline-scope and
anchor-name
kizu: Might want to have a way to expose these names, since might
have cases where you want to expose
kizu: maybe this is a more general issue that we need to handle in
CSS, and have it work consistently
<TabAtkins> +1, we need a general mechanic for weakening shadow
encapsulation
<TabAtkins> But we should be consistent for now
khush: kizu's point reminds me of ::part(), could use CSS to expose
names from within shadow DOM outside it
khush: maybe if you expose the element could allow it to match
khush: Could make it more complicated to implement
khush: We already have things in the platform that allow such
information, in those cases do you want naming in CSS to also
be exposed?
astearns: That would be a separate feature, though. This is for
default behavior for view transitions
khush: Does it make sense to make this resolution cover other cases
also? Have a general principle
astearns: I think a separate issue on general mechanism, because we
do want to consider them all
astearns: don't want to have a specific escape route just for VT
<TabAtkins> Agree, separate issues
RESOLVED: view-transition-name lookup is tree-scoped
Handle startVT for offscreen iframes
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9839
khush: Optimization that if an iframe is off-screen, we don't run
lifecycle updates or slow them down
khush: So as an optimization, offscreen doesn't get animated
khush: During view transitions, looking for that refresh
khush: but for iframe won't refresh until iframe comes on screen
khush: given it's already off-screen, user isn't going to see any
animation
khush: So suggestion that if it's offscreen, treat it as invisible
khush: or if iframe is detached from tree
khush: Current spec is to skip the transition
khush: just update the DOM directly, since user won't see the
animation anyway
khush: Question here is, what if iframe is not detached, but is far
enough off-screen that it's not being animated by the browser
khush: Currently what happens is transition once you bring it on
screen
khush: Other option is to skip the transition
khush: Third option is to force the update and do the transition
khush: once the browser has set up the animation, just like other
animations the UA won't need ot run the animation, just update
the timeline, as long as it's offscreen
emilio: I'm not a fan of forced-rendering, because it allows [missed]
emilio: You can call requestAnimationFrame and then
startViewTransition
emilio: I tend to think current behavior is more consistent with
regular animation frame would work
emilio: so I think current behavior is fine
emilio: Skipping transition allows you to detect this more directly,
I don't think it's great
emilio: we rely on the page not knowing whether it's throttled
khush: Because iframe is not getting rAF callbacks, can't they
already detect offscreen?
emilio: Well yeah, but you don't know if it's because of slow machine
or because offscreen
emilio: Can act somewhat differently, but iframe isn't allowed to
unthrottle itself, which is what forced rendering would do
vmpstr: We'll timeout by the time the animation is on screen, so if
call startViewTransition callback won't run until at least
one rAF callback, and by that time we are likely to skip the
transition
khush: Timeout starts after we cache the old state. Just happens
to ???
vmpstr: Doesn't seem great
emilio: Should we change that so that the timeout starts when you
actually call the API?
khush: Don't see any reason not to
astearns: Other questions/comments?
emilio: Given we unthrottle not exactly when you're in the viewport
bounds, but in some range, likely that by the time you scroll
to the iframe transition has finished anyway
stephenfromgoogle: Is throttling behavior thought to be interoperable
at this time? Vague in the spec.
stephenfromgoogle: Would we introduce an interop issue if we don't
force rendering?
<vmpstr> +1
flackr: That was one of my concerns about not forcing rendering. it
would expose more of those differences in behavior
emilio: That difference is already exposed by rAF timing
emilio: I think it's somewhat reasonably interoperable, at least I
assume all browsers to be throttling visibility:hidden and
very far off screen
emilio: This is an area that could get improvement, especially now
that lazyloading thresholds are a thing
stephenfromgoogle: I can tell you, our throttling code in Chromium
has no margin. If an iframe is even 1px outside
viewport, it will be throttled. That's different
form lazyloading, which does have a margin.
emilio: Worth discussing in an HTML spec issue
emilio: In any case, I still think forced rendering is not a great
option
emilio: If you call startVT, then you can force engine to unthrottle
you all the time, which is not great
khush: +1 everything Emilio said
khush: especially for one frame
khush: With other CSS animations, unless animating we don't need to
spend resources on it, but here do
khush: so would prefer current behavior
khush: Yes, different browsers use different margins, and different
features have different margins, being exposed doesn't seem
like a big constraint
flackr: Difference with animations is that you can always produce the
thing that would have been drawn
flackr: whereas with VT, once you draw the updated, you have
destroyed the old state
flackr: can't recover if it suddenly becomes visible
flackr: One use case was starting a view transition on a frame, and
then bring it into view
flackr: maybe there's an alternative to consider who's starting the
transition
flackr: if starting within hidden frame, ... but if starting from
root frame, could unskip frame by moving it into view?
vmpstr: Whether we keep these frames alive or not is also a function
of whether started when iframe on screen and then moved
offscreen or started offscreen
vmpstr: Also don't understand concern wrt frame throttling. You could
set timeouts and force rendering in a script
vmpstr: why would they use VT to unthrottle?
flackr: Browsers can force minimum timeouts on setTimeout
vmpstr: It would force it to run rAF?
vmpstr: iframe would do more work?
flackr: Yes, it would force it right away, but setTimeout would wait
a second
vmpstr: What's the attack vector here?
emilio: I'm not sure whether there's a good way... I've seen frames
consuming too much CPU unintentionally
emilio: I can't think of a recent case where they do it intentionally
dholbert: Maybe an ad wants to start playing immediately rather than
skipping a few frames, so continuously burns CPU in the
background so it's ready
khush: Use case I'm concerned is, it's hard for an iframe to do the
right thing without a lot of code
khush: whereas with other animations, just browser doesn't spend
resources. This is the first case where we would force
rendering
vmpstr: More wondering about second case
vmpstr: we could enforce setTimeout limits
vmpstr: Concerned that you call your startViewTransition for some
effect, and that will only start running when you're on screen
vmpstr: so I would force rendering or skip transition, but not doing
thing until on screen
emilio: alternatively set timeout mechanism to start when you call
API?
vmpstr: It's timing dependent -- whether you've scrolled the frame
into view within the timeout or not
vmpstr: much better than current behavior
flackr: One possibility, when we start the animation we could start
it with a negative start delay, so that it would be timed as
if it had started on time
flackr: This would basically defer the work until the animation
became visible
khush: You'd have to render to cache?
flackr: When it becomes visible. If it doesn't become visible until
end of duration, then you can skip it
khush: Complexity of all the animation after caching old DOM, you
still have to do at least one render to cache it
flackr: Or you defer the dom change
khush: Which pseudo-elements get rendered depends on the new DOM
khush: We don't know until we run the callback
flackr: You defer until it becomes visible
flackr: when it becomes visible, you do pre-snapshot, you do the
update, you determine animations, and you determine that the
animations are finished, so immediately jump to end state
khush: Sounds like skip
flackr: Except it fires all the events
flackr: and [missed]
flackr: it's only "skipped" ...
khush: What's the goal? We don't want the author to know we
skipped it?
flackr: There's no difference between whether your frame was on
screen or offscreen
flackr: if it comes on-screen during animation, you'll see the
animation
flackr: I haven't fully thought this out, but thinking that if you
know when the request to start the animation occurred, that's
the start of your timeline
khush: Like current behavior, except animations will finish faster
emilio: Might also be consistent with how time-based CSS animations
work
emilio: If you have an iframe, and then scroll down, by the time you
scroll up again the browser has done no rendering updates,
but animation jumps to the correct point
emilio: that's worth consideration
vmpstr: Capture right now can take some amount of time, and so that
time would then be immediately skipped into the animation,
which won't be a smooth experience
vmpstr: Essentially the animation start waits until the capture is
available; with this change it would be a frame or two of
delay
vmpstr: So those first 2 frames would be immediately skipped into the
third frame of the animation, which is not ideal
flackr: That's a fair concern, possible ways to mitigate that
flackr: you take the time until the frame started as your negative
start delay
vmpstr: Worth considering this model, but need to be careful about
the math
khush: My issue is this approach is complicated. What benefit do we
derive from it?
khush: ...
khush: What's the benefit of bringing iframe on screen with the old
DOM?
vmpstr: It supports cases of, suppose your animation is 30s and
starts offscreen, and then you scroll it into view partway
through
vmpstr: It looks like everything was working all along
khush: You eventually want user to see the new state
khush: point of doing animation is to go from old state to new state
nicely
astearns: Maybe we should look at the new option and bring it back
emilio: Perhaps more realistic use case for this model is, consider a
lazyloaded iframe
emilio: page being loaded has a view transition while loading
emilio: Right now, given stephen's comment about no margin
emilio: lazyloading kicks in first, page is invisible, then you call
startViewTransition. If you skip it, then you discard
everything the author wanted even though user is about to
scroll the iframe
<flackr> +1
emilio: That model doesn't seem too complicated, just need to handle
the first two frame jump
emilio: It behaves more consistently with our APIs also
emilio: rAF we just delay your callback, this seems similar
emilio: I think there are more use cases that justify this kind of
model
fantasai: Basically agree with astearns and emilio
fantasai: Let's explore flackr's model, and come back
vmpstr: Ok, let's look into the issue and comment with our findings
Clarify ordering of `::view-transition` with other tree-abiding
pseudo-elements
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9588
khush: Spec says ::view-transition element originates from the
document element
khush: but doesn't say what the ordering of the pseudo-element is wrt
other pseudo-elements
khush: Proposal is, since conceptually it's lifted into containing
block, it's meant to be last thing that paints over entire DOM
khush: so having it be after ::after makes sense to me
fantasai: Agree. Should be after everything, including ::after
emilio: Is this observable?
khush: I think maybe hit-testing. If the author removes ? from root
element, whether you hit ::after or view-transition?
emilio: That's a painting order problem
emilio: It's worth putting in the spec, but might not be observable
right now
khush: Which is a good time to do it :)
fantasai: If we all agree, let's just resolve and put it in the
spec :)
emilio: maybe `document.documentElement.getAnimations({ subtree:
true })`, if that returns pseudo-element animations?
RESOLVED: ::view-transition pseudo is the last child of its
originating element, after everything else including
other pseudo-elements
CSS Transitions
===============
Transition to height (or width) "auto"
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/626
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/626#issuecomment-2071016522
dbaron: We discussed calc-size() proposal. One question was whether
we could, instead of or in addition to calc-size(), write
what people want to write
dbaron: concern was compat, but did we check
dbaron: One thing I followed up with, since I had implemented, I
could implement the natural behavior where you could just
transition '0x' to 'auto'
dbaron: I could figure out what could break
dbaron: There's more details in the comment in the issue, but
basically what I did was a very conservative study
dbaron: ran through loading top 1000 sites with a special build
dbaron: Even with that limit, I found multiple pages that would break
with this change
dbaron: [gives some examples]
dbaron: Several pages animating widths and heights from zero that was
not expected
dbaron: At the same time, there was a page on ups.com with an
animation that got better
dbaron: but conclusion was, given this very small and conservative
sample shows multiple pages that are broken
dbaron: we know it's not web-compatible
dbaron: so we know we can't just support CSS transition from 0px to
auto and equivalents
dbaron: Given that, what I want to get out of this is to restate more
firmly that we want to move forward with calc-size()
dbaron: Given alternative, which would have better developer
ergonomics, is not compatible
flackr: Agree we can't just do it automatically
flackr: What about having a more generic opt-in for authors?
flackr: calc-size() require for each item to change the styling
flackr: whereas a switch could opt in your whole page
dbaron: We could consider something like that
dbaron: Maybe use transition-behavior, which is designed to do that
dbaron: it's reset by the transition shorthand
flackr: It's also about transitions only, not animation
dbaron: I think we can do both
dbaron: Current behavior with calc-size(), to get the animation you
have to wrap at least one endpoint in calc-size()
dbaron: I also do worry about global overrides
dbaron: because pages are built from smaller components
<TabAtkins> I'm completely fine with a value that can turn on the
transition behavior for general values, fwiw, so long as
the default behavior requires using calc-size() on at
least one side.
fantasai: Agree with flackr
fantasai: I think putting in transition-behavior is good, not global,
easy to incorporate into transitions and gets reset
whenever you do a different transition
fantasai: For animations, could consider something in the @keyframes
rule, so that it gets associated with the keyframes and
used wherever the keyframes get used
astearns: but agree that doesn't preclude using calc-size()
fantasai: Yes
TabAtkins: Proposed resolution, by default, only get transition if at
least one side gets calc-size()
RESOLVED: Animation to/from keyword sizes requires an opt-in, so by
default only get transition if at least one side gets
calc-size()
dbaron: At this point it's prototyped in Chromium, but it's getting
more stable and closer to matching spec at this point
Received on Wednesday, 8 May 2024 23:53:00 UTC