- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:09:24 -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: Close no change (Issue #9057: Size animation should use
logical properties)
- RESOLVED: Close no change (Issue #8886: top/left vs block-start/
inline-start)
- RESOLVED: Copy text-orientation from the dom node, along with the
existing writing-mode/direction (Issue #8230: How do the
writing-mode and direction properties affect the
view-transition pseudo-elements?)
- RESOLVED: Add mix-blend-mode to list of properties copied from the
element to the group pseudo (Issue #8962: Handling
mix-blend-mode on elements captured for a transition)
- A note will be added to the spec explaining the motivation for the
copied properties, being because they cannot be captured in the
snapshot.
- RESOLVED: Use an at-rule (of some kind) to control cross-document
VT transitions, syntax tbd (Issue #8048: Declarative
opt-in for cross-document navigations)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Present:
Rachel Andrew, Google
Tab Atkins, Google
David Baron, Google
Oriol Brufau, Igalia
Federico Bucchi, Apple
Stephen Chenney, Igalia
Mu-An Chiou, Ministry of Digital Affairs, Taiwan
Emilio Cobos, Mozilla
Yehonatan Daniv, Wix
Matthieu Dubet, Apple
Elika Etemad, Apple
Rob Flack, Google
Megan Gardner, Apple
Sammy Gill, Apple
Daniel Holbert, Mozilla
Brian Kardell, Igalia
Jonathan Kew, Mozilla
Ian Kilpatrick, Google
Una Kravets, Google
Vladimir Levin, Google
Peter Linss, Invited Expert
Theresa O'Connor, Apple
ChangSeok Oh, ByteDance
François Remy, Invited Expert
Florian Rivoal, Invited Expert
Cassondra Roberts, Adobe
Vitor Roriz, Apple
Noam Rosenthal, Google
Khushal Sagar, Google
Jen Simmons, Apple
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Bramus Van Damme, Google
Sebastian Zartner, Invited Expert
Scribe: TabAtkins
Scribe's scribe: fantasai
View Transitions
================
Size animation should use logical properties
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9057
vmpstr: This is about animating width and height
vmpstr: We currently animate those two props of the
::view-transition-group pseudo
vmpstr: question was if we should be animating in inline/block-size
instead
vmpstr: I don't think it matters, since we're always animating both
vmpstr: And they should map to each other
vmpstr: So proposal is close no change, but happy to hear other
opinions
emilio: It does matter if authors can override
vmpstr: The override you specify will override that property, but
the default animation doesn't matter since they're both
animated.
vmpstr: I don't see how the dimension you're overriding changes if
we're overriding logical vs physical
emilio: If they're also animating writing-mode...
emilio: But I agree that since you're doing both it probably doesn't
really matter.
emilio: let's say you animate to width:50px and height:100px
emilio: If you said vertical writing-mode, the width and height
won't change meaning, but what you have on your rule, which
may be logical, does
vmpstr: True, what you override is observable, but...
emilio: Right. I think animating physical props are fine though.
khush: We are copying the writing mode over from the element
actually doing the animation, fwiw. If you flip the writing
mode it'll flip the pseudo's writing mode too.
TabAtkins: Animating writing-mode is weird to do in the first place
<fremy> +1
emilio: I think a lot of these animations use transforms, which are
physical anyway, so I think it's okay to match.
fantasai: I also think overall using width/height makes more sense,
you're less likely to run into writing-mode issues
astearns: Any other opinions?
* fantasai notes that writing-mode is not animatable
RESOLVED: Close no change
[dbaron says something about the microphones)
top/left vs block-start/inline-start
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8886
vmpstr: This is similar to the last
vmpstr: We're using top/left to position the view-transition pseudo.
Question is if we should use block/inline-start
vmpstr: This is, I feel a little more strongly we should use top/
left. We're using a transform here and it uses physical
coordinates, we don't want to recompute based on writing
mode.
vmpstr: So I again propose closing no change.
astearns: fantasai was the one arguing against you but she's getting
the door for someone
noamr: I'd say the pseudos are not "really" laid out.
noamr: In general using margins/etc isn't really common, they don't
interact in that way.
noamr: They're just in the scene graph and positioned with
transform, so I think logical props make less sense.
vmpstr: It's also unclear to me what it means to lay out using one
anchor point and then transform using another.
vmpstr: So like suppose you anchor to one of the corners. If you use
block/inline insets the corner changes based on writing
mode, but then the transform has to change to use that
corner as well. That's what we want to avoid.
fantasai: I'm just trying to think through the implications if,
like, the element is larger...
TabAtkins: Since this is positioning, it'll overflow badly anyway
vmpstr: This is for the group element specifically, too. The
replaced elements that actually have an image use logical
coordinates, they'll overflow correctly for the writing
mode. But the group is just transformed into place, so I'm
not sure what it would be overflowing
khush: I guess the real awkwardness is that transforms are only
physical; if we had logical transforms we could use logical
position too.
khush: But for now having one half be logical and the other physical
is awkward.
fantasai: I guess it's probably fine since the box we're positioning
into is visible, it's not overflowing. So if we're laying
out with regards to that it works
khush: The reference box is the snapshot containing block, basically
the viewport.
fantasai: I think it's fine for now, we can fix it in the future if
we need.
astearns: So proposed resolution is to close no change
RESOLVED: Close no change
writing-mode and direction on view-transition pseudo-elements?
------------------------------===-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/8230
khush: This also came up in i18n review
khush: This is one case where directionality matters
khush: When you're animating an element, morphing from one shape to
another...
khush: The animation tries to make it so if the aspect-ratio of the
box changes, in the inline direction the snapshot stretches
to match the final size
khush: And the block matches the aspect ratio
khush: so whether it gets cover or contain behavior depends on
snapshot aspect-ratio
khush: To make it work this way, we have the group animate width and
height
khush: And the element inside use inset-block-start: 0,
inline-size:100%, and block-size:auto
khush: for this setup to work, there has to be a writing mode, we
copy those from the dom element to the group
khush: Are these two properties enough? do we need text-orientation
as well?
khush: It seems like the effect of text-orientation is baked into
the snapshot, so we don't need it for this animation to work
khush: fantasai had a point about how it interacts with cascade
fantasai: Yeah text-orientation can change which logical and
physical map to each other
fantasai: It won't affect the properties we are setting in the spec,
but it can have an impact on what the author sets
fantasai: So to get that correct we should copy over all three props
khush: I'm fine with copying over all three. Our defaults aren't
affected, so if it helps authors it sounds okay
astearns: So proposed resolution is to add text-orientation to the
writing-mode/direction properties that we copy from the
dom element
RESOLVED: Copy text-orientation from the dom node, along with the
existing writing-mode/direction.
Handling mix-blend-mode on elements captured for a transition
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8962
khush: When we're doing any kind of animation, we try to bake as
many things as possible into the snapshot itself
khush: but some just can't be done, like mix-blend-mode
khush: Right now it just gets dropped on the floor
khush: so if you want the pseudo-dom to reflect the real dom's
rendering, the best way to handle mix-blend-mode is to copy
it over to group pseudo
khush: And more generally, for other properties that can't be baked
into the snapshot, we propose to copy them over to the group
pseudo
noamr: If it's copied to the group, what happens if the two states
have different mix-blend-mode
khush: It doesn't interpolate so it'll flip immediately to the new
value
emilio: Do we have a list of which properties are meant to be baked
into the image than the group?
noamr: It's in the spec
khush: opacity/filter/etc are baked into the snapshot, and the list
of copied properties are very explicit
khush: There's a "capture these properties" step in the algo
khush: So if there are more properties to be copied we'll bring
those in another issue
emilio: It feels a little weird to special-case some props vs
others, but yeah
<emilio> noamr: Where is the list of copied properties in the spec?
astearns: Do we run the risk of having this list continue to be
expanded?
SebastianZ: Maybe we have to put these special properties in some
defined group
SebastianZ: I saw some more properties that are on the snapshot,
like clip-path. Are mask in that group?
khush: All of those are baked into the snapshot itself
khush: The set of properties that are copied as properties is in the
spec here...
<khush> https://drafts.csswg.org/css-view-transitions-1/#captured-elements
vmpstr: Basically what we copy are things that interact with other
content, not just the subtree
vmpstr: So opacity/clip-path only affect the element, but
mix-blend-mode interacts with something else and we can't
capture that statically
vmpstr: I was thinking backdrop-filter might be one of those props,
but I'm not sure how it works
TabAtkins: backdrop-filter lives in a similar space to mix-blend-mode
vmpstr: I just don't know if the topology is important for the tree
vmpstr: The element being affected is in a pseudo-element that is a
pseudo-child of the root...
khush: It does matter
khush: There's a feature extension of view transition that will let
you not lift the view transition pseudo up to the root
khush: So that'll be necessary to get backdrop-filter to work
correctly
astearns: I think some prose explaining why this list exists would
be good in the spec, that these are not effects that can
be captured in the snapshot
khush: Good idea, I'll add a note with motivation
ACTION: khush to add a note about the motivation for the copied
properties
<RRSAgent> records action 1
emilio: Are the snapshots we take semi-transparent? or do we
composite with the background?
khush: The base can be semi-transparent
khush: it's composited just as part of being rendered in the pseudo
vmpstr: The view-transition-name causes a stacking context
TabAtkins: I think the conclusion is that while backdrop-filter is
in the right spot for this, it's not usable with VT atm
emilio: So that means mix-blend-mode works okay so that's fine
emilio: Still seems weird to special-case some properties, but
better than dropping it on the floor
astearns: So proposed res is to add mix-blend-mode to the list of
properties
SebastianZ: and opacity/clip-path/mask?
<fantasai> [various other properties mentioned are baked into the
snapshot]
astearns: They're already captured in the snapshot
RESOLVED: Add mix-blend-mode to list of properties copied from the
element to the group pseudo
astearns: The list is a little weird but we do need to have this
behavior captured
astearns: and as people use VT and notice things being dropped from
the snapshot, people should have an idea of where to fix
it, so the note will be good
Declarative opt-in for cross-document navigations
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8048
noamr: VT2 is currently an ED
noamr: VT2 adds cross-document transitions
noamr: This involves two added capabilities to same-doc transitions
noamr: One is the declarative opt-in, which is this issue
noamr: So instead of starting the transition using JS, both
transitions need to have an opt-in in CSS
noamr: If both documents approve, the transition happens, as if we'd
called a startViewTransition()
noamr: Here's the spec, and here's the issue comment
<noamr> https://drafts.csswg.org/css-view-transitions-2/
<noamr> https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1637806513
noamr: So the current idea is to have a new at-rule, currently
called @auto-view-transition
noamr: At first we'd have only one property in it, which is
'same-origin: enable | disable'
noamr: while we have only one value to do right now, we expect to
need to extend this in the future so we're going with a
declaration design
noamr: Welcome bikeshedding
noamr: In the future we want to be able to nest this inside of MQ/
conditionals
noamr: So you can, for example, guard it by (prefers-reduced-motion)
noamr: also might want an opt-in to disable same-document view
transitions
noamr: At the moment I think we could probably only want to have
this affect automatic VTs, let JS deal with the rest
emilio: This is the kind of thing we've generally fixed via meta
tags, like color-scheme, viewport, etc
emilio: It seems like the main point of putting this in CSS is to
use MQs, but <meta media> exists
emilio: Has that been considered and discarded? If so, why?
noamr: It has been.
noamr: The original proposal was meta tags
noamr: It's mainly around keeping the styling all in css
TabAtkins: Part of the reason why it's not quite as necessary in meta
TabAtkins: We do that for other things so you have it as early in
loading as possible
TabAtkins: Given you need enough styling to render the page,
delaying the permission for cross-document transition
doesn't hurt you at all
TabAtkins: You don't need to be early
TabAtkins: You might have to hold onto the first page a little longer
TabAtkins: but waiting until all style comes in to turn on is fine,
because you need all that style to render to create a VT
anyway
SebastianZ: Having such an at-rule would also mean having it high in
the stylesheet
SebastianZ: it would need to be near the top near @import, right
TabAtkins: You have to read the whole stylesheet to render the VT
anyway, so doesn't matter where you put it
astearns: If the first page opts in, then we are spending time
reading CSS for the second page even if it is opt-out
khush: From impl perspective, right now we want to avoid having to
parse stuff in the new page before capturing new
khush: Right now, since both are from the same site, if the start
page opts in it's likely the end page will also opt in so we
eagerly capture the start page's elements
khush: There's also some concept in HTML about render-blocking
stylesheets. Hopefully we can get authors to get the rule in
those stylesheets
khush: We might be holding onto the start page a little longer, but
the chance of discarding is pretty low. We think it's worth
going for what's most ergonomic for webdevs
emilio: Do we want to make this work eventually for cross-origin?
emilio: If both pages opt in, it seems like it could work...
(barring security constraints)
khush: We have some use-cases right now for same-site, but not
strong ones for cross-site
khush: and similarly in same-site it's likely both will opt in
vmpstr: And still, doing a little bit of extra work that's
potentially wasted, it doesn't really affect how much of the
end page you have to parse before you know.
vmpstr: Even if it was in meta tags we'd still have to eagerly
capture the old page
emilio: so you have to wait for things to load and you have to delay
rendering the new page until things are loaded
emilio: So if you define it's a meta tag that's read, you can start
rendering the new page earlier, as we do now
khush: We're not trying to delay rendering just because there's a
transition. There's already render-blocking in html
khush: We have to fetch enough of the dom and stylesheets before
first render anyway
khush: So there will be some amount of CSS we have to block first
frame on anyway
khush: They can put these rules into the same stylesheets and not
delay rendering further than what it needs to
emilio: If you only have one dev that knows how to do this, sure,
but that's not true generally
khush: The author has to think about it anyway
khush: So much CSS has to be parsed before you do first render
anyway to make the animation work
emilio: VT doesn't wait, then? It does first render asap and relies
on render blocking?
emilio: My understanding was we have to wait for the page to be
fully loaded
khush: Right. In same-document you get a callback so you can block
until ready.
khush: In cross-document we're relying on render blocking for
the same
emilio: So if the stylesheets in the head are loaded we can start
rendering before content is loaded
khush: There's an html issue where render blocking today is just
stylesheets, but we are proposing extending it to content too
khush: So you can detail which elements need to exist before render
starts. and a timeout does some fallback
emilio: So an important part of why specifying it in css is fine or
not. [not sure what this sentence meant]
emilio: with meta the order is clear
emilio: with an at-rule, then we need to define how they cascade
khush: I think that problem needs to be solved anyway.
khush: We have a feature request to have it apply only for some
navigation - between certain urls, only on reloads, etc
khush: So author will need settings for these kinds of things
emilio: So if you have that, how they interact needs to be defined
noamr: We'll be using the same ordering that other at-rules use,
stylesheet order
emilio: Layers too
noamr: Right, including all of that
<TabAtkins> (they'll cascade atomically, like most at-rules)
khush: Just to give a concrete example
khush: for same-site, going from foo.bar.com to baz.bar.com, you can
say "I'm okay with most transitions, but veto this one url"
khush: so you'll specify two of these rules, one generally and one
specialized to that path
khush: so we'll need to make sure authors can specify a default
behavior but override in special cases
bramus: I'm very in favor of doing this in CSS
bramus: Was wondering about the name - auto-view-transition
bramus: Could it be more generic? @config? to cater to more
descriptors in the future beyond VT
bramus: Also curious how this interacts with the cascade
bramus: Think I saw Tab saying no
<TabAtkins> (correct)
hober: I think it would be a mistake to rename to generic.
hober: We don't have use-cases for non-VT cases right now. Having a
generic name would be an attractive nuisance, I'd prefer it
be purpose-built
<khush> +1 to keep it VT specific. We can make the pattern generic
if needed.
<TabAtkins> (agree strongly, plus it does have some VT-specific
things it needs in filtering/etc)
<emilio> +1 to hober's comment, at-rules like this are relatively
inexpensive
fantasai: Strongly agree to keep it in CSS, using meta is awful.
styling should be in css if at all possible, external
stylesheets that can be re-used across pages are great
fantasai: With multiple of these rules, you probably want them to
cascade together? If the last rule says you want to
disable cross-origin transitions, you don't want it to
break the rest of the settings.
fantasai: So we might want it to cascade individual descriptors,
which some at-rules do
<bramus> +1 to that
<TabAtkins> (currently, only the ones that apply things to
element-like stuff, I think?)
fantasai: Can you say same-origin:disable;cross-origin:enable?
that's weird. Would be good to explore the full space of
likely descriptors first to make sure they're coherent
together
fantasai: Think there was some discussion about different classes of
transitions depending on page you're going to/from
fantasai: Might not be the first thing we do, but should be explored
to make sure the shape of the at-rule is good.
fantasai: So overall I agree with the direction of this, using an
at-rule rather than meta unless there's a good mechanical
reason.
fantasai: but I think before we can understand if the syntax is good
we need to explore the spaces we're expecting to extend
into first
SebastianZ: An idea from Bramus was to put the detection into a
media feature
<bramus> Link:
https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1551535268
<bramus> (second bullet)
SebastianZ: With that we could put everything that needs to be
transitioned into that rule
astearns: He's proposing to put into the @media rule
bramus: I immediately discarded that idea in the next comment, it
doesn't allow setting the choice
bramus: An MQ could complement the setting
emilio: Wouldn't that create cycles
TabAtkins: Make it possible to change styling when VT is happening
TabAtkins: you might want different styles for the page in that case
<khush> https://github.com/w3c/csswg-drafts/issues/8925 is related
to media queries for setting state based on where you're
navigating to.
astearns: I'm not convinced yet that we won't need the meta tag
astearns: But I think we could start with the at-rule and if we find
there is a perf reason to have the meta as the opt-in, we
can add later
astearns: the at-rule would still be necessary for other settings
besides the bare opt-in
emilio: As long as there's a concrete point in time where the
at-rule needs to be seen
emilio: then I don't object to an at-rule
emilio: I just don't want to introduce unnecessary style updates to
look up this config
noamr: In reverse order
noamr: We're not adding new style updates, just parsing the
stylesheet to capture the rules. No need for a full cascade
noamr: For MQs, that's a separate feature, possibly an enhancement
for later
noamr: wrt fantasai wanting more examples for the future, I think
that's a fair request
noamr: Something that's already come up is the ability to use this
opt-in to disable same-document VTs.
noamr: So you can disable all VTs under prefers-reduced-motion
noamr: So that's one use-case we've already seen
noamr: Another was same-site or first-party-set
noamr: Another was having declarative same-document transitions,
like allowing Navigation API to trigger VTs.
khush: One thing emilio brought up was having a defined point where
this is queried
khush: We have to have a defined point where browser captures
everything anyway
khush: so our thinking was to use the same point as when you set up
styles and states for the navigation, should be the same
point we set the opt-in
khush: I also pasted 8925 which is related to this
khush: There's an idea of adding MQs to allow setting state based on
old and new url
khush: This opt-in might play with that
khush: so you can use that MQ to set this at-rule to disable certain
paths
khush: So we can come back with more information on this
emilio: Re noam's comment, you don't need to update dom styles but
you still need to go through all the stylesheets and make sure
it's sorted correctly
emilio: Adding a fast path for this doesn't seem appealing to me
emilio: In blink/wk terminology, this needs to "update the active
stylesheets" and that still shows up considerably during
page load
emilio: and I don't want to do that until all stylesheets are loaded
emilio: I'd rather make sure that on the page you're navigating to
you don't need to do unnecessary work to hook this up
emilio: so ideally the point where you determine the VT doesn't
involve synchronously updating the active stylesheets
vmpstr: I think the way we're structuring this is we're using other
properties, such as render blocking and proposed additions
to that, to control when the document will render
vmpstr: and defining VT to say "at the point when the doc will
render, you have know the opt-in/out'
vmpstr: So no extra work, but giving the dev a little more control
over first render timing
vmpstr: And on the meta tag, we've discussed a double opt-in - a
simple meta that can indicate whether the VT is even
possible, and then use the at-rule for all the actual options
vmpstr: I'm not opposed to that, but think we still want the css
at-rule for more detailed config
emilio: Using the initial frame for this makes sense and satisfies
my constraint
khush: Okay then the spec currently says that's when we should be
checking the opt-in
astearns: For this issue can we have a resolution to use the at-rule
initially?
emilio: Seems fine
noamr: Also to start with an at-rule, but bring more examples of
future usage to determine exact syntax
fantasai: Yeah we can resolve *an* at-rule, not necessarily this
exact shape
astearns: So proposed resolution is to use an at-rule for
cross-document VT transitions
noamr: And gather examples before we decide on final syntax
RESOLVED: Use an at-rule (of some kind) to control cross-document VT
transitions, syntax tbd
fantasai: Note it's not just examples of what's already there, it's
looking at what should be possible, and defining syntax
for it
<br dur=30min>
Received on Sunday, 10 September 2023 15:10:00 UTC