- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:09:41 -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 (Continued)
----------------------------
- RESOLVED: Add a single event to carry the cross-document VT
object. Work with HTML folks to define exact timing,
and whether it's a VT-specific event or generic (always
fired) (Issue #8805: Script event on new Document for
cross-document ViewTransitions)
- RESOLVED: Reloads don't trigger view transitions by default
(Issue #8784: Should ViewTransitions be triggered for
reloads?)
- Investigation will continue in issue #8784 to determine if there
are other cases that should not by default trigger view
transitions.
- RESOLVED: Leave these cases explicitly undefined in the spec
(Issue #8783: Should ViewTransitions be triggered for
browser initiated navigations)
- RESOLVED: Have some way to assign a name to a VT and style
differently based on it, details tbd (Issue #8960:
Components participating in the transition need to leak
info to embedding context)
- RESOLVED: Document security and privacy concerns into the spec,
encourage more reviews (Issue #8889: security/privacy
considerations with cross-origin css)
- RESOLVED: UAs may discard author transitions if they are
providing their own (Issue #8953: Cross-document View
Transition when there is a UA transition)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Scribe: fantasai
View Transitions (Continued)
============================
Script event on new Document for cross-document ViewTransitions
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8805
<noamr> https://github.com/w3c/csswg-drafts/issues/8805#issuecomment-1637790887
noamr: This comment summarizes the issue
noamr: Let's say both documents opted into a transition
noamr: We are at the state where the new document is ready to
present and activate the transition
noamr: Some transitions need to be in JS
noamr: e.g. animating using WebAnimations API
noamr: Another use case is JS wanting to have access to the
ViewTransition object
noamr: to know when it ends, or to be able to call skipTransition()
noamr: This is a problem we're trying to solve
noamr: Currently in the draft spec, we invented a new event "reveal"
noamr: right before the first frame
noamr: Right when the document is unblocked for render
noamr: That event will have an optional ViewTransition object
noamr: You can sign up to its promises, or skip it
noamr: The "reveal" event could be useful to HTML in any case
noamr: page visibility events only fire when the document is fully
loaded
noamr: so this is how it's currently presented in the draft spec
noamr: We like it for this purpose, and also because it lets us
keep the existing ViewTransition object
noamr: One of the design principles is that same-page and
cross-page transitions should be as similar as possible wrt
API
noamr: Another idea was to only send an event for actual view
transitions, not for every reveal
noamr: That event would require the ViewTransition object, wouldn't
be optional
noamr: Another idea was to fire events for when the VT starts, is
ready, and finished
noamr: This is a little more consistent with touch events etc.
noamr: where they have discrete events, rather than register to one
event
noamr: In all cases, updateCallbackDone promise would be resolved
from the beginning, as it's not relevant
astearns: My question about reveal event, say it might be useful
for other than VT. Did you have examples in mind?
noamr: It's a place where you can register for events, e.g. when
the first content paints etc.
noamr: and also place where you can do last-minute things that
affect presentation
noamr: e.g. if you think not enough of the document is parsed, so
you want to hide some elements
noamr: Other use cases have not been explored much, but it felt
like this is a new lifecycle point that we should expose
rather than only expose the one use case for VT
khush: Concrete use case from WebPerf, if you're adding new
resources that you want to block rendering, this event lets
you measure that
khush: Because it fires right before firstRender, it allows
customizing your transition
khush: E.g. if you're going from one page to another, but the image
hasn't been fetched yet, you might choose to do a different
transition
astearns: In addition to testing blocking things, you could use it
to test blocking in general. Since if blocking, would
affect when this event fires
astearns: Any more comments about the event?
fantasai: I don't remember from the spec (even though I recently
read it) - are there events for same-page transitions?
fantasai: or was it just promises?
noamr: Promises only
fantasai: In that case I don't think we should do the third option
(separate events for stages). If we want that we should
do it for both
fantasai: and if we want it for same-document we should also have
it for cross-document
noamr: Reason I brought up option 3, if you just want to respond
when transition is finished
noamr: you have to add an event listener onto the promise. Jump
through hoops
noamr: but it's a trade-off between that and same-document
khush: If you have just one event with the VT object, you have
access to everything you need
khush: In same-document, you already have the VT
khush: [something about customizing]
khush: This aspect of reveal event conceptually maps to one of the
promises in same-document case
khush: in that case you have your own callback, which sets up the
DOM, and then the first promise resolves
khush: since no callback setting up the DOM in cross-document case,
we need some event to do conceptually what's happening
khush: to let you know when that's done
SebastianZ: I think we should still do it for both same-document
and cross-document transitions
SebastianZ: for consistency
SebastianZ: I would have one event for them and then you could have
an attribute on those events to distinguish which kind
of transition it actually is
noamr: What's the proposal exactly?
SebastianZ: Maybe start/ready/finished and distinguish by an
attribute on the event whether it's cross-origin or
same-document
[some clarifications on naming]
SebastianZ: My point was to have one event that is covering all
those cases, and distinguish by the attributes of those
document
noamr: So also when you have a transition you started yourself?
SebastianZ: For consistency
astearns: If we have this reveal event, and it fires always before
first render
astearns: it will fire for every document
astearns: When you have a same-origin transition
astearns: and you have this event firing, does it contain the VT
object even though it's not a cross-origin VT
fantasai: I think we are getting confused here. There are cross doc
and same doc transitions
fantasai: [don't confuse with same-origin and cross-origin
transitions, which are both cross-document]
fantasai: for same docs we have an existing api and proposal
fantasai: In same doc case you create a VT by calling a method,
which returns the VT object
fantasai: You know you created that, because you said so
fantasai: When doing cross-doc, you need to get the VT object which
the UA creates automatically
fantasai: For that we need an event, or to add it to the doc somehow
<khush> thanks for the excellent summary fantasai!
fantasai: We are talking about 3 options
fantasai: Events for phases? if yes, we should have them for
same-doc as cross doc
fantasai: [missed]
khush: Thanks for the summary
khush: My vote is for one event that gives you access to the VT
object
khush: If we have multiple events, having it for the same document
transitions is awkward
khush: because we will soon have ability to trigger multiple
same-document transitions
khush: so if this event is limited to having a cross-document
transition
khush: [missed]
khush: seems much easier to wrap your head around
fantasai: So if the start/ready/finished events for same document
doesn't make sense
fantasai: then we should def go for one of the other two options
fantasai: either special event that only fires for a VT or the
reveal event
fantasai: Interested in hearing about the perf impls
fantasai: and wondering how html folks feel about reveal more
generally
astearns: Any thoughts on perf?
[silence]
astearns: Have you discussed with HTML folks about new event?
noamr: Was discussed in HTML ??
noamr: Don't think there's any particular perf implications
noamr: Wanted to understand use case better
emilio: Isn't the reveal effectively the first request Animation
Frame callback?
noamr: It's before that
noamr: rAF happens [missed]
noamr: Reveal happens right when last render-blocking element is
unblocked, so when you're about to have your first rAF
callback
noamr: but before actual rendering
noamr: If you write polyfill code today, you would check all your
render-blocking styles and scripts, and wait until all
loaded, and then fire an event
emilio: So point is you cannot insert new render-blocking stuff
then, because those are only parser-inserted?
noamr: You have to also listen for HEAD being finished. You can't
add more render-blocking at that point
emilio: Is there use case for exposing this timing, rather than
firing right before first rAF callback?
emilio: Presumably point of reveal event is you might want DOM set
up in a particular way
emilio: and that's what rAF does
emilio: so it would avoid exposing a new timepoint
emilio: but I don't feel strongly either way
vmpstr: Several reasons to make this appealing
vmpstr: First is providing the VT object -- rAF can't provide that
vmpstr: second is back/forward
vmpstr: ... [missed something]
khush: Can discuss at HTML meeting, if there's more thinking about
timing can bring with HTML group
khush: this is useful for perf measurement
emilio: Yes, it seems like something that HTML folks would have an
opinion on
emilio: but seems like using first request animation frame isn't
quite doable because of the ?? cache
emilio: If we need a new event, as long as it's well-defined when
it should fire, seems OK
emilio: just feels a bit weird to expose this extra last
render-blocking thing
emilio: especially because a bunch of stylesheets can be loaded
async
emilio: Authors would observe
emilio: So if you have a stylesheet in the memory cache, right now
that effectively doesn't block rendering
emilio: but from PoV of author, it probably should behave like that
emilio: and I think right now what we do is fire load event
emilio: So timing details is worth raising with HTML folks
emilio: but need it to happen before page is presented
emilio: So can't do rAF or synchronously when last stylesheet
loads etc.
fantasai: It sounds we could resolve we want a single event with
the VT object attached
fantasai: not sure we want it to be fired only for vt or something
more generic
fantasai: is that what we're landing
khush: Also emilio's question about when this is fired
fantasai: Which might depend on which of those two we land on
fantasai: In that case we should resolve on that and then discuss
further with the html folks?
astearns: So let's resolve to have a single event to carry the VT
object
astearns: and work with HTML folks to define exact timing and
whether it's a VT-specific event or generic
astearns: Any objections?
RESOLVED: Add a single event to carry the cross-document VT object.
Work with HTML folks to define exact timing, and whether
it's a VT-specific event or generic (always fired)
Should ViewTransitions be triggered for reloads?
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8784
noamr: This is about reloads, came up by people using the current
experiment we have with cross-document transitions
noamr: question is what should happen on reloads
noamr: By default, currently, the transition happens because
it's just a same-origin navigation where both pages opt in!
noamr: but developers find this confusing
noamr: In the future we might want opting in or customizing
specifically the reload transition
noamr: which is something we wanted to add to the opt in
noamr: but wanted to say that they're disabled for now
noamr: because more confusing that useful
<astearns> +1 to disabling on reload (by default)
noamr: Also thinking about reloads, reloading from cache, things
are not always fast when you reload
noamr: Also you probably went from some state to same state
noamr: Right now is disable by default, opt in if need arises
<khush> +1
fantasai: 100% agree about disabling
fantasai: Also this is something to think about when designing the
at-rule
emilio: Wanted to ask about reloads, or navigating to the same URI
emilio: e.g. if you click to the same URI
noamr: Related is history
noamr: I think that navigating to the same URI is also like posting
a form, for example
noamr: in which case transitions could be useful?
emilio: I'm fine with special-casing reloads
emilio: but seems like other cases to consider
emilio: e.g. click on GitHub logo from the GitHub homepage. Seems
weird to navigate around
<dbaron> my intuition is that special-casing reloads makes more
sense than special-casing same-uri navigation
khush: With regards to navigation, two types, replacing current
entry or adding a new entry
khush: so if you have a link to the same page, retrieve that as a
new navigation
khush: but if replacing the current entry, then that shouldn't do a
transition
emilio: So are you proposing to do reload, or all replacement
navigations?
emilio: I think we all agree that reloads shouldn't trigger VT
emilio: but are there other cases?
emilio: e.g. [lists examples: clicking on the same page (not a
replaced load), explicit replace load via script, ...]
emilio: Question is what specific concepts to use here, though we
all seem to agree on disabling reload by default
noamr: [too quiet]
noamr: Might be a good starting point
noamr: Redirect, like meta refresh
noamr: is that also a replace?
noamr: Client-side redirects
noamr: are also replace
noamr: [missed]
fantasai: It seems we all agree on reloads
fantasai: but we need more exploration for which other cases
shouldn't trigger a transition
fantasai: e.g. clicking on a fragment adds to history but probably
shouldn't transition
<khush> Unless it's cross-doc, we won't do a transition.
fantasai: So should we resolve on reloads not doing transitions and
investigating other issues in the issue?
astearns: Proposed resolution is reloads don't trigger VT by
default, any objections?
RESOLVED: Reloads don't trigger view transitions by default
ACTION: Investigate other cases that shouldn't trigger view
transitions.
<RRSAgent> records action 2
astearns: If we disable a bunch of stuff, re-enabling things might
be tricky, so need to be careful when categorizing the
set of things
astearns: but let's move on
Should ViewTransitions be triggered for browser initiated navigations
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8783
vmpstr: Same spirit, but about browser-initiated navigation
vmpstr: It is a navigation, but should that do a transition?
vmpstr: Reason it's a question is that the page might not expect
that route to be animatable
vmpstr: but at the same time, if it's supported, could do a
transition
noamr: Regardless of address bar, we do support for back/forward in
history
noamr: but that could also create unexpected routes
noamr: Address bar is a special case of something general, but many
things that we do want to support
noamr: e.g. jump in history
khush: My take on this is that it's hard to figure out all the
cases where we can say this navigation was intentional from
the author
khush: Easier to say that it's all same-origin
khush: and give some knobs for controlling which navigations trigger
khush: right now you would need some scrijpt
khush: but there are proposals for making that declarative
vmpstr: At least as a user, when I type into the URL bar, I'm
beginning a new experience
vmpstr: I don't expect there to be anything to persist my cognitive
state
vmpstr: so in that case a transition doesn't help me
vmpstr: So good point about back/forward, can also jump multiple
entries
vmpstr: I would argue again that you're breaking your experience
vmpstr: so non-transition animation is good
<bramus> seems reasonable
vmpstr: Happy to be convinced otherwise, but don't think we should
try to do transition in every possible place
vmpstr: but rather for cases where devs expect
khush: You mean user
vmpstr: No I mean developer
khush: If the user copies URL form a link and pastes...
vmpstr: I would still argue it's still a new thing
<dbaron> (I think I agree with vmpstr.)
<astearns> (I think I also agree with vmpstr - no transitions for
browser-initiated navigations)
nicole: When you go from one page to another, and the other origin
doesn't expect it either, isn't this also unexpected
nicole: for cross-origin, second page did not set up that
navigation transition
vmpstr: Agree, that's why we didn't pursue cross-origin originally
vmpstr: it's harder problem to work out
nicole: I think it would not be good experience if they have to say
exactly which pages they want, could have thousands
nicole: so should be easy to opt in or out of having transitions
khush: Phrasing is interesting wrt user vs dev expectations
khush: If I have transition from A to B, and I paste in the URL
khush: As a developer I would expect the transition
khush: I wouldn't know how the navigation is triggered
khush: As a user, type in the new URL, the transition keeps the
visual context
khush: As a user I think the animation would line up with what I
expect to see
khush: but yes, I'm curious about what web developers think
khush: We're not sure if how navigation was triggered changes things
fantasai: Need more information from authors and users, next steps
to collect more expectations?
astearns: Anyone else with an opinion?
astearns: It sounds like just in the room, between khush and vlad
we've got 2 different opinions
noamr: "browser-initiated navigation" isn't specified, and there
are lots of types
noamr: I'm not sure this needs to be interoperable because not
exactly web-visible
astearns: Seems like we should just keep this issue open and see if
we get a better sense of author and user expectations
nicole: I'm curious what percent of users modify the URL in the
navigation bar
nicole: Seems like a nerdy power-user thing to do
nicole: so maybe not something to resolve on
hober: I think the simple answer is that enough of them do that it
matters.
khush: Out of all the navigation, figure out how many same-origin
cross-document navigations happen, if the number is low
enough take the easier option
khush: jumping multiple steps in history is also power user
myles: They are not rare. Typing into the URL bar is not power user
option
khush: for a same-origin cross-document navigation... it seems like
cross-origin is more common for typing
fantasai: I suggest we leave these cases explicitly undefined in
the spec
fantasai: and revisit later if we end up with a definite opinion
astearns: so proposed resolution is to leave undefined
RESOLVED: Leave these cases explicitly undefined in the spec
Components in transition need to leak info to embedding context
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8960
khush: We've seen use cases where authors want to change view
transitions based on state of the DOM
khush: Some tutorials suggest setting up a class on the root element
khush: to get custom transitions
khush: Is this the most optimal way?
khush: Or should we allow startViewTransition() to pass in a keyword
khush: which then gets propagated to e.g. a media query
khush: I don't know that it's worth making a custom feature for
this, rather than just recommending using class names on the
root
ydaniv: The issue started as a perf problem, and then changed to a
?? API
ydaniv: We have state that's under the HTML object. In order to
lift that so that the DOM tree for the transition can be
styled based on that state
ydaniv: using the :has() selector
ydaniv: but that's a big perf no-no
ydaniv: Putting that aside, maybe even if browsers can optimize
that it's only styling the pseudo-tree for transitions
ydaniv: but aside from preferred way, after DOM callback, to set
attributes or ?
ydaniv: there was also a thought for maybe on the next level,
expose the state
scribe: TabAtkins
fantasai: I think it would be pretty straightforward to create this
kind of tag in the arguments of the startViewTransition()
function
fantasai: Easy way to expose it would be with ::view-transition(foo)
thing
fantasai: Modifying the dom to pass arguments is awkward even if
it's performant
fantasai: So if we can pass a name to startViewTransition() then
select based on that name, it seems nicer
fantasai: I think people would probably also want it for
cross-document stuff
fantasai: from urls A to urls B it's X class of transition
bramus: I was going to propose something similar
bramus: the flag or label in JS which you can read in CSS
bramus: In addition to that maybe a MQ
fantasai: You can't do an MQ because you might have multiple VTs
going
bramus: A CQ maybe?
fantasai: That's why I think having it be an argument in
::view-transition()
vmpstr: Problem with that is all the nested elements are accessed
via the root element directly, so it's unclear to me how to
limit a style to a group to only apply in this case
fantasai: Might be able to just pass that directly in as a second
argument?
<TabAtkins> (or define that ::view-transition-group() is *also*
accessible under ::view-transition ?)
vmpstr: I'm also ok with MQs but agree it could be confusing with
multiples VTs running
fantasai: With Tab's idea, nice thing is if Nesting allowed pseudos
you could open up brackets and put them all inside of
there
khush: We didn't want to have to express the entire pseudo tree,
how would you target something deep?
vmpstr: You just put them under the ::view-transition, it's like
having them come off of html
fantasai: Let's talk about this on the break
fantasai: Does anyone think we should *not* make this work, and
rely just on class names?
ydaniv: I think it's very good to pass to the startViewTransition
and recognize somehow in CSS, yeah
fantasai: Ok great let's try to come up with a proposal in this
issue
noamr: We have to think how this applies cross-document too
fantasai: I think this gives you more options cross-origin, yeah,
you don't have to try and modify the destination dom
khush: I want to make sure I understand the reason for not using MQ
khush: MQ is nice because you can configure what things get a vt
name based on type
khush: But using a ::view-transition() would only let you hit the
pseudos
fantasai: You said earlier that you plan to have the ability to have
multiple simultaneous VTs. How does that work?
khush: If you have different VTs, each will have different
originating elements
khush: So rather than html::view-* you'll have .foo::view-*
khush: so that's how it's different
fantasai: But the MQ can't match based on element...
<TabAtkins> Okay so they *would* all match in the MQ at once (and
you'd use the selector to actually target the right
element)
bramus: So if you have multiple transitions going on, the name you
attach to each would have to be different
khush: I just want to have the MQ syntax on the table to discuss
fantasai: Confusing bit is just if you start two transitions, they
both set the VT name, and they set it in the same subtree,
it can get confused with each other
vmpstr: Right MQ is global, these subtrees are very local. mixing
the two seems prone to weird conflicts
khush: Okay, seems fine
khush: You can always toggle some class names at the same time as
you call startVT() with a name, sure
astearns: So should we resolve that we want a solution, and continue
in the issue?
khush: Yeah
astearns: Objections?
RESOLVED: Have some way to assign a name to a VT and style
differently based on it, details tbd
security/privacy considerations with cross-origin css
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8889
scribe: fantasai
noamr: This goes back to ? and raised bigger question
noamr: Basically allows a third-party CSS to ? opt into transitions
noamr: If we add MQ that decides things based on incoming URLs,
which not proposed yet, but it's cooking
noamr: It could allow the third-party CSS to know things about the
incoming URL
noamr: and it was a general issue about how do we view third-party
CSS in terms of security
noamr: It does seem it's not safe, but safety is not a boolean
noamr: I opened this issue to get some guidance on it
astearns: Anyone with guidance to share?
khush: Fwiw we got a comment from security review which is that it's
OK, since author is opting in to loading the third-party CSS
khush: Already some amount of trust there
astearns: Author of the page that you're navigating to is opting
into loading third-party CSS by saying view transitions
are OK?
khush: If opt-in is in CSS, and you're embedding a third-party
stylesheet, could become an issue
khush: e.g. third-party transition could opt you into having
transitions
<TabAtkins> I agree with the security person's comment - if we
continue to respect existing Referer policy then what's
left is fine
fantasai: You probably have to trust a lot for a bunch of other
things if you are loading third-party CSS
fantasai: e.g. third-party CSS can make you load fonts that you
wouldn't otherwise load
noamr: Allows third-party CSS to know things that they didn't know
before
khush: e.g. could load resources based on what page you were
navigating from
khush: even if same-origin
khush: so I don't think you're going to learn new information
khush: Question was if you load third-party CSS, do you expose
things that the third party wouldn't have been able to know.
TabAtkins: I agree with the security comment, as long as we respect
existing referrer policy and don't expose to the new page
TabAtkins: then what's left is fine
TabAtkins: If you're allowing something that allows running @rules
from third-party, already allowing them to p0wn your page
astearns: We should document this in the Security section of VT spec
astearns: I think proposed resolution is to document security/
privacy concerns and continue getting reviews
RESOLVED: Document security and privacy concerns into the spec,
encourage more reviews
Cross-document View Transition when there is a UA transition
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8953
khush: This was about, some browsers have transition as part of
browser UX while navigating
khush: e.g. in Safari and Chrome today, if you swipe between pages
you get default transition from UA
khush: Proposal is that if the UA does its own transition, don't do
the author transition
khush: If there's a use case where authors want to customize, could
allow that somehow
khush: but don't run both
hober: I think that sounds good.
hober: I think the main case you identified on mobile is history
swiping
hober: It would be bad if having two animations, so if spec allows
browsers to skip transition in those cases seems fine
hober: There was a related issue wrt disabling browser animation,
and I have concerns about that
astearns: Should we be more permissive and say that the UA can
either skip the transition if providing their own, or
somehow accommodate
hober: That would work for me too
astearns: Other opinions?
astearns: Proposed resolution is that UAs may discard author view
transitions if they are providing their own
astearns: Objections?
RESOLVED: UAs may discard author transitions if they are providing
their own
<Lunch>
Received on Sunday, 10 September 2023 15:10:17 UTC