- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Jul 2023 16:45:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Declarative opt-in for cross-document navigations`, and agreed to the following: * `RESOLVED: Use an at-rule (of some kind) to control cross-document VT transitions, syntax tbd` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> noamr: VT2 adds cross-document transitions<br> <TabAtkins> noamr: This involves two added capabilities to same-doc transitions<br> <TabAtkins> noamr: One is the declarative opt-in, which is this issue<br> <TabAtkins> noamr: So instead of starting the transitio using JS, both transitions need to have an opt-in in CSS<br> <emilio> q+<br> <TabAtkins> noamr: If both documents approve, the transition happens, as if we'd called a startViewTransition()<br> <noamr> https://drafts.csswg.org/css-view-transitions-2/<br> <khush> q+<br> <noamr> https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1637806513<br> <TabAtkins> noamr: here's the spec, and heres the issue comment<br> <TabAtkins> noamr: So the current idea is to have a new at-rule, currnetly called @auto-view-transition<br> <TabAtkins> noamr: At first we'd have only one property in it, which is 'same-origin: enable | disable'<br> <TabAtkins> 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<br> <TabAtkins> noamr: Welcome bikeshedding<br> <TabAtkins> noamr: In the future we want to be able to nest this inside of MQ/conditionals<br> <TabAtkins> noamr: So you can, for example, guard it by (prefers-reduced-motion)<br> <TabAtkins> noamr: also might want an opt-in to disable same-document view transitions<br> <TabAtkins> noamr: At the moment I think we could probably only want to ahve this affect automatic VTs, let JS deal with the rest<br> <TabAtkins> emilio: This is the kind of thing we've generally fixed via meta tags, like color-scheme, viewport, etc<br> <TabAtkins> emilio: it seems liek the mai point of putting this in CSS is to use MQs, but <meta media> exists<br> <TabAtkins> emilio: Has that been considered and discarded? If so, why?<br> <TabAtkins> noamr: It has been.<br> <TabAtkins> noamr: the original proposal was meta tags<br> <TabAtkins> noamr: it's mainly around keeping the styling all in css<br> <TabAtkins> q+<br> <TabAtkins> q++<br> <TabAtkins> qq+<br> <TabAtkins> ack +<br> <fantasai> TabAtkins: Part of the reason why it's not quite as necessary in meta<br> <bramus> q+<br> <astearns> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to react to fantasai<br> <fantasai> TabAtkins: we do that for other things so you have it as early in loading as possible<br> <fantasai> TabAtkins: given you need enough styling to render the page, delaying the permission for cross-document transition doesn't hurt you at all<br> <fantasai> TabAtkins: you don't need to be early<br> <fantasai> TabAtkins: you might have to hold onto the first page a little longer<br> <fantasai> 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<br> <TabAtkins> SebastianZ: having such an at-rule would also mean having it high in the stylesheet<br> <emilio> q+<br> <fantasai> SebastianZ: it would need to be near the top near @import, right<br> <fantasai> TabAtkins: you have to read the whole stylesheet to render the VT anyway, so doesn't matter where you put it<br> <fantasai> astearns: [missed something]<br> <TabAtkins> khush: from impl perspective, right now we want to avoid having to parse stuff in the new page before capturing new<br> <TabAtkins> khush: right now, since both are fro mthe 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<br> <TabAtkins> khush: there's also some concept in HTML about render-blocking stylesheets, hopefully we can get authors to get the rule in those stylesheets<br> <astearns> s/[missed something]/if the first page opts in, then we are spending time reading CSS for the second page even if it is opt-out<br> <TabAtkins> 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<br> <astearns> q?<br> <TabAtkins> emilio: Do we want to make this work eventually for cross-origin?<br> <TabAtkins> emilio: If both pages opt in, it seems like it could work... (barring security constraints)<br> <TabAtkins> ack TabAtkins<br> <TabAtkins> khush: We have some use-cases right now for same-site, but not strong ones for cross-site<br> <TabAtkins> khush: and similarly in same-site it's likely both will opt in<br> <TabAtkins> 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.<br> <TabAtkins> vmpstr: Even if it was in meta tags we'd still have to eagerly capture the old page<br> <TabAtkins> emilio: so you have to wait for things to load and you have to delay rendering the new page until things are loaded<br> <TabAtkins> 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<br> <vmpstr> q?<br> <TabAtkins> khush: We're not trying to delay rendering just because there's a transition. there's already render-blocking in html<br> <TabAtkins> khush: We have to fetch enough of the dom and stylesheets before first render anyway<br> <TabAtkins> khush: So there will be some amoutn of CSS we have to block first frame on anyway<br> <TabAtkins> khush: They can put these rules into the same stylesheets and not delay rendering further than what it needs to<br> <TabAtkins> emilio: If you only have one dev that knows how to do this, sure, but that's not true generally<br> <TabAtkins> khush: the author has to think about it anyway<br> <TabAtkins> khush: So much CSS has to be parsed before you do first render anyway to make the animation work<br> <TabAtkins> emilio: VT doesn't wait, then? It does first render asap and relies on render blocking?<br> <TabAtkins> emilio: My understanding was we have to wait for the page to be fully loaded<br> <TabAtkins> khush: Right. In same-document you get a callback so you can block until ready.<br> <TabAtkins> khush: In cross-document we're relying on render blocking for the same<br> <TabAtkins> emilio: So if the stylesheets in the head are loaded we can start rendering before content is loaded<br> <TabAtkins> khush: there's an html issue where render blocking today is just stylesheets, but we are proposing extending it to content too<br> <TabAtkins> khush: So you can detail which elements need to exist before render starts. and a timeout does some fallback<br> <TabAtkins> emilio: So an important part of why specifying it in css is fine or not.[ not sure what this sentence meant]<br> <TabAtkins> emilio: with meta the order is clear<br> <TabAtkins> emilio: with an at-rule, then we need to define how they cascade<br> <TabAtkins> khush: I think that problem needs to be solved anyway.<br> <TabAtkins> khush: We have a feature request to have it apply only for some navigations - between certain urls, only on reloads, etc<br> <TabAtkins> khush: So author will need settings for these kinds of things<br> <TabAtkins> emilio: so if you ahve that, how they interact needs to be defined<br> <TabAtkins> noamr: we'll be using the same ordering that other at-rules use, stylesheet order<br> <TabAtkins> emilio: layers too<br> <TabAtkins> noamr: right, including all of that<br> <TabAtkins> (they'll cascade atomically, like most at-rules)<br> <astearns> q?<br> <astearns> ack khush<br> <TabAtkins> khush: just to give a concrete example<br> <SebastianZ> q+<br> <TabAtkins> khush: for same-site, going from foo.bar.com to baz.bar.com, you can say "im okay with most transitions, but veto this one url"<br> <TabAtkins> khush: so you'll specify two of these rules, one generally and one specialized to that path<br> <astearns> ack bramus<br> <TabAtkins> khush: so we'll need to make sure authors can specify a default behavior but override in special cases<br> <TabAtkins> bramus: i'm very in favor of doing this in CSS<br> <TabAtkins> bramus: was wondering about the name - auto-view-transition<br> <TabAtkins> bramus: Could it be more generic? @config? to cater to more descriptors in the future beyond VT<br> <TabAtkins> bramus: Also curious how this interacts with the cascade<br> <hober> qq+<br> <TabAtkins> bramus: Think I saw Tab saying no<br> <TabAtkins> (correct)<br> <TabAtkins> hober: I think it would be a mistake to rename to generic.<br> <TabAtkins> 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<br> <khush> +1 to keep it VT specific. We can make the pattern generic if needed.<br> <astearns> ack emilio<br> <astearns> ack hober<br> <Zakim> hober, you wanted to react to bramus<br> <TabAtkins> (agree strongly, plus it does have some VT-specific things it needs in filtering/etc)<br> <emilio> +1, at-rules like this are relatively inexpensive<br> <TabAtkins> fantasai: strongly agree to keep it in CSS, using meta is awful. styling should be in css if at all possible, external stylesheets are great<br> <emilio> s/+1/+1 to hober's comment/<br> <TabAtkins> 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.<br> <TabAtkins> fantasai: so we might want it to cascade individual descriptors, which some at-rules do<br> <bramus> +1 to that<br> <TabAtkins> (currently, only the ones that apply things to element-like stuff, i think?<br> <TabAtkins> )<br> <TabAtkins> 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<br> <TabAtkins> fantasai: think there was some discussion about different classes of transitions dpeneding on page you're going to/from<br> <TabAtkins> fantasai: Might not be the first thing we do, but should be explored to make sure the shape of the at-rule is good.<br> <TabAtkins> fantasai: So overall I agree with the direction of this, using an at-rule rather than meta unless ther'es a good mechanical reason.<br> <astearns> q+<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: but i think before we can udnerstand if the syntax is good we need to explore the spaces we're expecting to extend into first<br> <noamr> q+<br> <TabAtkins> SebastianZ: an idea from Bramus was to put the detection into a media feature<br> <astearns> ack SebastianZ<br> <bramus> Link: https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1551535268<br> <bramus> (second bullet)<br> <TabAtkins> SebastianZ: with that we could put everything that needs to be transitioned into that rule<br> <SebastianZ> https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1551535268<br> <fantasai> astearns: He's proposing to put into the @media rule<br> <TabAtkins> bramus: I immediatley discarded tha tidea in the next comment, it doesn't allow setting the choice<br> <TabAtkins> bramus: An MQ could complement the setting<br> <fantasai> emilio: wouldn't that create cycles<br> <khush> q+<br> <federicobucchi> presence+<br> <fantasai> TabAtkins: make it possible to change styling when VT is enabled<br> <fantasai> s/enabled/happening/<br> <fantasai> TabAtkins: you might want different styles for the page in that case<br> <TabAtkins> astearns: I'm not convinced yet that we won't need the meta tag<br> <TabAtkins> astearns: But I think we could start with the at-rule and if we find there is a perf reason to ahve the meta as the opt-in, we can add later<br> <khush> https://github.com/w3c/csswg-drafts/issues/8925 is related to media queries for setting state based on where you're navigating to.<br> <TabAtkins> astearns: the at-rule would still be necessary for other settings besides the bare opt-in<br> <astearns> q?<br> <TabAtkins> emilio: As long as there's a concrete point in time where the at-rule needs to be seen<br> <TabAtkins> emilio: then i don't object to an at-rule<br> <astearns> ack astearns<br> <TabAtkins> emilio: I just don't want to introduce unnecessary style updates to look up this config<br> <astearns> ack noamr<br> <TabAtkins> noamr: in reverse order<br> <TabAtkins> noamr: We're not adding new style updates, just parsing the stylesheet to capture the rules. no need for a full cascade<br> <emilio> q+<br> <TabAtkins> noamr: For MQs, that's a spearate feature, possibly an enhancement for later<br> <TabAtkins> noamr: wrt fantasai wanting more examples for th efuture, i think that's a fair request<br> <TabAtkins> noamr: something thats already come up is the ability to use this opt-in to disable same-document VTs.<br> <TabAtkins> noamr: So you can disable all VTs under prefers-reduced-motion<br> <TabAtkins> noamr: so that's one use-case we've already seen<br> <TabAtkins> noamr: Another was same-site or first-party-set<br> <TabAtkins> noamr: Another was having declarative same-document transitions, like allowing Navigation API to trigger VTs.<br> <astearns> ack khush<br> <TabAtkins> khush: one thing emilio brought up was having a defined point where this is queried<br> <TabAtkins> khush: we have to have a defined point where browser captures everything anyway<br> <TabAtkins> khush: so our thinking was to use the same point as when you set up styles and states for the navigation, shoudl b ethe same point we set the opt-in<br> <TabAtkins> khush: I also pasted 8925 which is related to this<br> <TabAtkins> khush: there's an idea of adding MQs to allow setting state based on old and new url<br> <TabAtkins> khush: this opt-in might play with that<br> <TabAtkins> khush: so you can use that MQ to set this at-rule to disable certain paths<br> <astearns> ack emilio<br> <TabAtkins> khush: so we can come back with more information on this<br> <TabAtkins> emilio: re noam's comment, you don't need to update dom styles but you still need to go thru all the stylesheets and make sure it's sorted correctly<br> <TabAtkins> emilio: adding a fast path for this doesn't seem appealing to me<br> <TabAtkins> emilio: in blink/wk terminology, this needs to "update the active stylesheets" and that still shows up considerably during page load<br> <TabAtkins> emilio: and i don't want to do that until all stylesheets are loaded<br> <TabAtkins> 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<br> <vmpstr> q+<br> <TabAtkins> emilio: so ideally the point where you determine the VT doesn't involve synchronously updating the active stylesheets<br> <astearns> ack vmpstr<br> <TabAtkins> vmpstr: I think the way were' structuring this is we're using othe rproperties, such as render blocking and proposed additions to that, to control when the document will render<br> <TabAtkins> vmpstr: and defining VT to say "at the point when the doc will render, you have know the opt-in/out'<br> <TabAtkins> vmpstr: So no extra work, but giving the dev a litlte more control over first render timing<br> <TabAtkins> 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<br> <TabAtkins> vmpstr: I'm not opposed to that, but think we still want the css at-rule for more detailed config<br> <TabAtkins> emilio: Using the initial frame for this makes sense and satisfies my constraint<br> <TabAtkins> khush: Okay then the spec currently says that's when we should be chekcing the opt-in<br> <TabAtkins> astearns: For this issue can we have a resolution to use the at-rule initially?<br> <TabAtkins> emilio: seems fine<br> <TabAtkins> noamr: also to start with an at-rule, but bring more examples of future usage to determine exact syntax<br> <TabAtkins> fantasai: yeah we can resolve *an* at-rule, not necessarily this exact shape<br> <TabAtkins> astearns: so proposed resolution is to use an at-rule for cross-document VT transitions<br> <TabAtkins> noamr: and gather examplkes before we decide on final syntax<br> <TabAtkins> RESOLVED: Use an at-rule (of some kind) to control cross-document VT transitions, syntax tbd<br> <TabAtkins> fantasai: Note it's not just examples of what's already there, it's looking at what might be possible<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1640574446 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 July 2023 16:45:25 UTC