CSSWG Anchor Positioning

13 September 2023


aaronlev, bramus, dbaron, eeeps, emeyer, emilio, fantasai, flackr, iank_, khush, Mark_Foltz, masonf, matatk, miriam, mrobinson, nicole, noamr, noamr_, ntim, oriol, romain, TabAtkins, una, vmpstr, ydaniv
Tab Atkins Jr.
emeyer, fantasai, vmpstr

Meeting minutes

<ntim> ntim: present+

<aaronlev> link to issue?

<ntim> tabatkins: Agenda: issue 66, go through all the anchor positioning issues, try to get tentative resolutions, that will be confirmed later this week

<TabAtkins> w3c/tpac2023-breakouts#66

<TabAtkins> github-bot, take up w3c/csswg-drafts#9117

[css-anchor-position] Anchor positioning proposal comparison

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9117.

<ntim> TabAtkins: Listed out all the use cases, and what proposals can do them well, not well, etc.

<astearns> updated list: w3c/csswg-drafts#9117 (comment)

<ntim> flackr: I don't see transitions between anchors, which none of the proposals cover, but is very common

<ntim> una: I see transitions between fallbacks

<ntim> dbaron: look at the second list that astearns linked to

<dbaron> Is there an item in that list for the sidenotes / doc comments use case?

<ntim> TabAtkins: you can animate between 2 distinct anchors, the problem is animating when what an anchor name refers to changes

<ntim> fantasai: transition between two anchor names is in the table

<nicole> https://docs.google.com/document/d/185yzaofuMP2p1KK00e2J0cmL8vAxOY3LF7NxhpjveRo/edit

<ntim> (what flackr was referring to)

<nicole> This is the document of examples

<ntim> TabAtkins: does anyone see something obviously missing in the table?

<dbaron> dbaron: "anchor reference changes" is a confusing term because it can mean either "a change to which anchor is referenced" or "the anchor that is referenced changes (e.g., moves)"... and we care about both

<ntim> fantasai: the ability to style based on fallbacks

<astearns> add w3c/csswg-drafts#9332 to the list

<TabAtkins> w3c/csswg-drafts#9332

<ntim> emeyer: multiple anchors is something I'm interested in, there is no issue

<ntim> fantasai: not in the issue, because Tab's proposal already covers it

<ntim> fantasai: Not sure if it's covered, but cascading behavior on the @try blocks is terrible

<TabAtkins> (it's on th elist of topics to discuss)

<TabAtkins> github-bot, take up w3c/csswg-drafts#9124

[css-align-3][css-position-3] Better interaction of auto insets and self-alignment properties?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9124.

<ntim> TabAtkins: before the spec existed there is no interaction between the 2, we would use the CSS 2.1 behavior

<ntim> TabAtkins: The remaining tension is what to do in the double auto case

<fantasai> My positions:

<fantasai> w3c/csswg-drafts#9124

<fantasai> w3c/csswg-drafts#9124 (comment)

<ntim> TabAtkins: my preference is to have double autos resolve the same way so they resolve to zeros when you have non-default alignments

<fantasai> w3c/csswg-drafts#9124 (comment)

<ntim> TabAtkins: main reason for this, there is one alignment keyword where this is necessary, the anchor-center keyword needs the space to be able to align.

<ntim> TabAtkins: the larger thing behind my reasoning, static pos as defined in CSS 2.1 is just a poor version of anchor positioning

<ntim> TabAtkins: it wasn't great, but it did do the job

<ntim> TabAtkins: but we don't need this anymore, since we have anchor positniing

<ntim> TabAtkins: we don't need to do this anymore, unless we are constrained by compat

<ntim> fantasai: It would be useful to focus on the case where anchor positioning is happening, because we probably have agreement on that one

<fantasai> PROPOSED: If only one inset in an axis is auto, and self-alignment in that axis is not normal, then auto computes to zero

<ntim> astearns: lets try to resolve on it

<fantasai> TENTATIVELY RESOLVED: If only one inset in an axis is auto, and self-alignment in that axis is not normal, then auto computes to zero

<ntim> fantasai: my proposal is in the double auto case if there is a default anchor, set the alignment rect to be the anchor's element's bounds

<ntim> iank: there are a few cases where this breaks down:

<ntim> iank: let's say my left is based on one anchor, and my right on another based on another

<ntim> TabAtkins: having the behavior being significantly different between the single and double auto cases is confusing

<fantasai> fantasai: We already have two different modes in abspos: static positoining or not

<fantasai> ... all this is doing is saying, instead of anchoring to your hypothetical box in the staticpos case, you anchor to the explicit anchor from anchor-default

<fantasai> ... I think it's more consistent with how CSS already works

<ntim> TabAtkins: i don't want it to be based on whether there's a default anchor or not, I want it to be based on the alignment value

<ntim> fantasai: we already have these 2 modes

<ntim> fantasai: alignment doesn't change what you layout relative to

<ntim> TabAtkins: I think it would be nice to have a consistent alignment model,

<ntim> we no longer need the static positioning, it would be nice to have alignment use a single consistent model

<fantasai> fantasai: Just becaue you dislike staticpos, because inferior to anchorpos, doesn't mean we should use the opportunity of any non-default property value to switch us out of it

<ntim> fantasai: you're proposing to change existing behavior on web pages

<ntim> TabAtkins: no I'm not

<ntim> TabAtkins: my argument is not that we should change based on some arbitrary prop, for the single auto case, we turn the auto into 0

<ntim> TabAtkins: we should be consistent in the double 0 case and resolve both to auto

<TabAtkins> and since the staticpos behavior is subsumed by anchor pos, we don't actually lose anything by dropping it in this case, so we can ahve a better, more ocnsistent behavior by having autos always become 0 when alignment is happening

<ntim> TabAtkins: re: changing existing behavior, no one implements alignment properties on abspos

<ntim> fantasai: they do impl alignment properties for the static pos of the abspos

<ntim> iank: not really

<ntim> iank: it's implemented in grid / flexbox

<ntim> iank: but flexbox only implements in one axis

<ntim> iank: we're willing to take that compat risk and take that back to the group

<ntim> iank: the proposed behavior is super useful

<ntim> iank: today if you need to center somnething in the containing block

<ntim> iank: there's about 2-3 ways people use, they are very clunky

<ntim> iank: you need to set multiple props

<ntim> iank: one way is setting insets to 0

<ntim> iank: the other way is using calc

<fantasai> iank: They're all super clunky

<ntim> iank: being able to set place-content: center and get centered alignment is very neat

fantasai: I'm not arguing that being able to use alignment props in abspos is bad. I specced it out, obviously I think we should have it

fantasai: The hacks iank mentions are indeed all terrible and should be replaced with alignment

fantasai: that doesn't mean that alignment should change the behavior in auto-auto case

fantasai: just means you set 'inset: 0' to switch to useing the abspos containing block

fantasai: I don't think this his hard or confusing

<Zakim> fantasai, you wanted to say that adding 'inset: 0' is not that much to add

miriam: inset 0 isn’t a lot to add, but I as an author have never found static positioning of abspos particularly useful
… I’m wondering what we gain by maintaining it
… What is the use case where I want to maintain it while adding alignment?

fantasai: Two things about adding alignment to static pos
… Static pos is like if you have an element in the document and then flip on abspos
… If you apply alignment properties in block mode (for example), then it will jump to somewhere else
… What I’m arguing for is, when you define an anchor, then static positioning becomes relative to the anchor bow
… That gets you the ability to be centered inside another box very easily
… I think for the non-anchor case, it’s about consistency with the way static positioning works

miriam: I understood you were proposing that when you switch to abspos, that would change your alignment, but in a different way

fantasai: If you want to be anchored to an element, I think it makes sense your automatic position moves to that element
… I think alignment changing your containing block to change is confusing
… Right now, alighment shifts you within the container to which you’re sizing
… anchor-default does move you; that’s its intention
… Why not have it do something as soon as it’s set?

TabAtkins: I think your argument is that current behavior is useful, and I want to argue with that
… We know that flexbox rules aren’t very useful; we watered them down on purpose
… In the one case that isn’t well implemented yet, the inline-block case, aligning goes into degenerate rectangles
… It would do something, but usually the opposite of what you expect it to do

…align: start would put you more end-ward and align: end would put you more start-word, in certain cases
… I think we were okay with that confusion when we defined the behvavior because we didn’t have anything better
… Now that we have better, we don’t have to offer authors this confusing behavior

fantasai: I think it’s great to offer a better way to do this; I’m not convinced this is the way to do it

iank_: I don’t think there’s been strong use cases presented for the double-auto case
… The behavior being proposed does solve developer pain quite well
… It does something very useful for center, stretch, a bunch of other things
… This is outside of anchor positioning

TabAtkins: I’m not sure how to resolve this, Elika
… My argument is that the default behavior wasn’t useful, perhaps when it was defined, but not now

xiaochengh: For center, resolving double-auto to zero seems more useful
… THe inset modified containing block isn’t just used for alignm,ent, but also for position fallback
… The only containing block to test is the original containing block
… For alignment, we could use a different containing block than for fallback, but I’d like to avoid that

miriam: Already we have a behavior where apply insets changes your reference, you’re no longer using the static position box
… To me, changing the alignment is exactly the same concept, so in my mind it aligns better with current behavior
… Alignment is an auto-inset sort of thing, so if one changes, why not the other?

vmpstr: Is there a web compatibility risk with this resolution?

TabAtkins: For some layout modes, we do implement the double-auto case
… We’re willing to take the compat risk

iank_: We’re also willing to take the risk
… We don’t think there will be much

astearns: Is there anyone who wants to show solidarity for Elika’s position?

emilio: Elika’s position is safest

iank_: If we show it’s web compatible, would that change your mind?

emilio: I don’t feel too strongly about preserving the current behavior

fantasai: Part of my point is you can get the behavior Tab and Ian want by setting inset to 0

astearns: Having a property that does nothing until you set another property isn’t good design

emilio: That’s already positioning, right?

iank_: I think our argument is that what we want is more useful and more what devs expect

astearns, that's a good argument for anchor-default having an effect without setting 'inset: anchor(..)'!

emilio: How is it more useful if the behavior Ian and Tab want can be achieved
… The current behavior cannot

<astearns> fantasai, I am OK with needing two properties when two things need to be connected

TabAtkins: Current behavior can be achieved via anchor position

astearns, they are connected already, why not have an effect

iank_: I think also, there hasn’t been strong use cases for the existing behavior

TabAtkins: Curernt staticpos behavior is in many cases unintuitive and inconsistent between layout modes
… Given it was mostly defined to give you certain powers that anchor positioning can give in better ways, we think authors are better served by having the old behavior be gone

emilio: I still th ink Elika’s position is safer but I wouldn’t object to removing it if you can get away with it

I'm not convinced you can do the same as staticpos for block and inline layout, at least not easily or without injecting additional things into the DOM

noamr_: If you want to achieve this non-useful behavior, you’d have to name everything

TabAtkins: You’d have to write a name, but it could be a locally s coped name (according to another proposal)

astearns: Does that meet your concern, Elika?

fantasai: Replicating for grid and flexbox is not too hard
… You have to assign a name to the contain and then tell the item to anchor itself to that
… For block and inline, you can’t just slap a name on a containing block
… You have to reference where the item would have been
… You’d have to add an empty element to the DOM to act as a placeholder

<TabAtkins> (not correct; you're always positioning relative to the prev/following element, and those can receive a name)

astearns: We’re out of time; not hearing consensus, but
… can we take a resolution?

fantasai: I think I’d object unless everyone else in the WG disagrees

TabAtkins: Thank you all for coming!


Tab, that doesn't work for "here's some text <span class=abspos></span> more text"

We've also changed staticpos behavior before (for flexbox e.g.) and people were kinda annoyed about it when we made it less capable

so at least some people do use it...

<TabAtkins> Right, the non-aligned staticpos. Not proposing to change that, the compat is definitely bad.

<TabAtkins> Oh and yes, for an abspos in raw text, indeed that would be the (sole?) case that would need *something* to get a wrapper to anchor to. (Either wrapping the text before/after, or an empty el where the abspos was.)

<khush> topic TPAC breakout: CSS View Transitions

do i need a github issue or do i just scribe as is? never done it

TPAC breakout: CSS View Transitions

github-bot, take up w3c/tpac2023-breakouts#20

<github-bot> vmpstr, I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts w3c/svgwg web-platform-tests/wpt WICG/animation-worklet WICG/construct-stylesheets WICG/scroll-animations WICG/custom-state-pseudo-class.

github-bot, take up w3c/csswg-drafts#8804

[css-view-transitions-2] Support ViewTransitions for same-origin cross-document navigations

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8804.

noamr: i'm going to present and chat about view transitions

noamr: we have a few VT issues scheduled for tomorrow. I feel like we deal with these issues like blind men and an elephant

noamr: we're not seeing the big picture and what we're trying to do with it

noamr: and some people might have not been here

noamr: i want to show where we are and where we want to go, and start a syntax discuss that we can continue tomorrow, so everyone has context


noamr: i'll show what we have today, and plans for the future

noamr: what is CSS view transitions (VT)

noamr: it's a transition between states; before we had a transition between elements

now we take a document capture it and morph it into a new state

noamr: we do this by capturing an element snapshot, change the dom, capture a different set and morph by name

noamr: this is a general idea of VT


noamr: here there's switching immediate. But if we put it inside start view transition, they get immediately a cross fade

noamr: now, this is a default and building on this we can define a whole bunch of customizations

noamr: i wanted to show something similar to what we saw

noamr: we have a button that switches states

(live demo!)

noamr: it does it immediately, if we add startViewTransition to it, and put it in the startViewTransition block, it cross fades

noamr: this is nice, but you want to customize

noamr: so for example, I'm giving h1s transition name of heading

noamr: and then I can customize the animation between heading elements

noamr: so now the animation is 1 second and has a blur

noamr: I do all of this with pseudo elements

noamr: the power here is that there is not just pseudo elements for the states together, but separate: one for the old state and one for the new state

noamr: i'm defining that there is a slide but one of them is a reverse

(this is still live demo)

noamr: this is extremely customizable, there's something at the start and at the end, and pseudo elements to transfer between states

noamr: this is css VT today in terms of features

(back to preso)

noamr: it creates a morph by creating a tree of pseudo elements with names like heading in this case

noamr: it creates a group for the transition, and a pair of elements old and new for the states

noamr: people are excited about this, there are a few companies using this and frameworks (Svelte.kit, Astro)

noamr: it's been a quite a popular request on surveys

noamr: i want to jump from that to what we saw people do

noamr: one thing that is very popular is a full page style, you set the page, you set the transition, you go to a different page

noamr: you have one animating element that is root. Before the css VT you had to put both pages in the dom and use a transition group

noamr: a11y wise it was where both states are in the DOM. Here there is no dom, it's pseudo elements and style

noamr: this is a very common use case

noamr: this is an even commoner use case. here is a list of songs, and you click one and expands to one song

noamr: this is a list to details view, like shopping list to details

noamr: this is extremely popular in demos that we have seen

noamr: the third one is different: it's animated layout, you can put stuff in a grid or a list, give everything view transition names, and change their placement in the grid

noamr: and this animates it

noamr: this is less of a navigation, but something internal to the page. we see this in things like timeline where list changes order

noamr: automatically sorting list is something we see a lot, and it's something i'm excited about

noamr: it was not easy to do before, you had to create some ghost elements with transforms. it was not fun, depending on what fun is for you

noamr: the constraints of css VT, where we are today, what you say looks demo-y

noamr: it can be incorporated into a page, but it's limited to the document

noamr: everything in the document you have, it will be selected for the document

noamr: also the whole document freezes, maybe you want just a widget to animate, and you don't want the whole page to lose pointer events etc

noamr: and you saw that a lot of cases are navigation cases, but if you leave the document, then you lose the transition. You don't have a CSS state today that is cross ocuent

noamr: from this we derived what we want in the vision; we want to remove constraints

noamr: to explain what we want to do, i want to show an ugly wireframe of a music list

(demo slide)

noamr: what you want on this page is three different transitions

noamr: first you want the slide page thing, you want the nav bar where things slide on the next page

noamr: then, if you click on a song, you want the song to expand

noamr: the third if you drag and drop the list, you want the list to animate

noamr: it doesn't look like an uncommon use case for a real web app

noamr: when using VT myself, i was struggling with doing this: incroproate a bunch of things into the same app

noamr: this is not in priority order, but this is what we envision for VT

noamr: we think that we want to allow to scope element transitions to elements

noamr: second, semantically group: you have the same app with different grouping of animations. you have the slide animation and expand animation and you group all elements that particpate in the animation semantically

noamr: number three, we want the transition to be triggered by a cross document navigation. we want transitions to work in the MPA. we definitely don't want view transitions to be a deciding factor for why people pick SPA

noamr: we want it to work with javascript and without javascript

noamr: element scoped transitions, and btw, all those three things is not because we're planning on doing them all in one go, but just when we design each one, we want to consider everything

noamr: we don't want to spec ourselves into a corner

noamr: element scoped transitions is about animating a widget without stopping the whole page, so animate with drag and drop while the page is responsive

noamr: can't do this today, but want to do it in the future

noamr: this is sort of how you do it in javascript

noamr: so currently the document.startViewTransition function exist. We want to have something like playerWidget.startViewTransition

noamr: and all those pseudo elements you saw, instead of being just on the html element, any element can be the originating element: #playerWidget::view-transition-group(play-pause)

noamr: and all animations are scoped to that

noamr: you might have simultanious (sp) transitions running at the same time

emilio: i wanted to ask about group. for top level VT in SPA

emilio: view transition are fixpos / top layer, what is the rendering model for the scoped transition. A thing with view transition name would need a containing block etc

khush: this is one of the things that we need to sketch out, like what constraints it needs. but what you saw on the previous slide, but what you saw before would happen in the iframe

emilio: the iframe is a whole contained thing

khush: the idea is to bring that type of containment into one element

noamr: a lot isn't solved

ntim: how does it work if you have a element that overlaps the scope, and you put it so it overlaps

ntim: if you have your scope, and an element outside the scope, how does the screenshotting work

noamr: the capture is of elements, not the screen and the overlap doesn't change

yoav: so if there's occlusion, that doesn't change anything

noamr: so you capture an element as an element capture, not the occluded screen capture

noamr: with rendering and implementation for scoped element transitions, we'll have some challenges, but whenever we design the syntax for thing, we consider that the VT will not always be global

noamr: semantic grouping, defining multiple transitions, but activating just one of them

noamr: when we click a nav bar, it does slide, but when you click an element it expands

noamr: these would be different animations, different pseudo elements, etc

noamr: a lot of people struggle with this, because they define too many names, and overdefine things, or things work slowly because they have a bunch of elements

noamr: we capture things that don't transition so you transition things that don't need to transition

noamr: i've seen this from demos and that's something that we can fix and want to fix

noamr: how do you fix it today? you can do it in javascript, say you want to click on details to expand

noamr: you can set a class on <html> then run the transition and then remove the class

noamr: during the transition you know which transition ran, so when you're in the expand song class, you know what names exist

noamr: instead we're suggesting when you startViewTransition you pass a list of ephemeral classes

noamr: this is the css of how you would read these classes

noamr: btw this is all bikeshed

noamr: we thought about this a lot, but this is all bikesheddable

emilio: one thing that jumps at me when i see that is that the way you do that means that you need to restyle the page

emilio: and you can change a lot more than the view transition names

trying again

"connecting to network"

conversation is about making a selector vs qualifying the names

noamr: doing something with a name is a possibility we felt it was a bit limiting

emilio: in particular for MPA, you're about to nav away from the page, I'd rather avoid doing actual work that will do render

noamr: you need to do render into a capture, and you have something with view transition name, but you don't want the text to appear

emilio: i'm still sad about things that require layout

noamr: sure we can reason about doing this at the last moment

noamr: but it's a drop in replacement for the html class name, but it's a good point, maybe we're allowing a lot of last minute things for MPA, but it's up the developers

emilio: sure

michael: is this ore about starting a subset of possible transition or customizing transitions or both

noamr: both

michael: once started the set will be on the whole document, the latter will allow multiple transitions

khush: if your transition targets a whole document, but have multiple transitions

noamr: this is 100% syntactic sugar, and continuation of previous CSSWG F2F, if something starts with style and ends with style, it shouldn't be required to change the dom

noamr: I think fantasai brought it up and it resonated with me

noamr: if we decide to not do this, i'm ok with that too

noamr: we have a type of the transition, and a slide one, and reason about them separately

noamr: the reason we put it in the pseudo class because of hte previous thing about scoped element transitions

noamr: the active view transition pseudo element can go into element that is a view transition route

noamr: the third one and most improtant one is navigation triggered transition -- automatically start a transition when a document navigation takes places

noamr: (missed)

noamr: let's say we have the same app, and we have slide transitions and the song expands

noamr: we want the song to be in a different document


noamr: we've been working with modern frameworks like nextjs, you don't build your app as MPA or SPA, you just build your app

noamr: and sometimes the choice is done did your document load, did you pass hydration to make it an spa

noamr: so when I think about an SPA or an MPA, i want to think about it as a detail

noamr: it's a progressive enhancement between different cases

noamr: they don't want to rewrite their css for different cases, so it should be more infrastructure

noamr: so we want the song to expand whether it's the same document or cross document and work consistently

noamr: plus we don't want to break the sort transition while we do that

noamr: so again, reminding of the bikeshed icon

noamr: so we define something like an event or behavior that is bidirection

noamr: we say if we're in the same origin navigation it's to trigger them rather than not trigger, can be called enable disable or what not

noamr: the concept is you put this in css document in both documents

noamr: and both sides opt in to trigger a transition

noamr: we'd read it twice: right before the last frame of the old document, and before the first frame of the new document

noamr: this also applies to back/forward cache and prerender

noamr: we'd read the current value of this and decide whether to trigger or skip the transition

noamr: we also need js events or something to customize the transition, probably on both sides

noamr: there is conversation with whatwg html spec to see if we can reach something

noamr: but the idea is to have an event. the big use case is to have a new document that wants to use web animations not css

noamr: then you get an event on the new document that can do that

yoav: how is commit navigation be different in terms of negative side effects of unload

noamr: we need to think about this, i'm hesitant to do this in unload event

yoav: ok

noamr: it has different htings that are different, and alternative proposals. one is it's only same origin navigation, so you'd be in the same javascript loop.. you're in the app

noamr: the other alternative is to send a same origin redirect

noamr: so you get a navigation event for navigation API, and get a redirect event if it redirects

yoav: is it make it to be passive, or do we need to fire in the context of the old document

noamr: it needs to request a frame of the old document and render into capture

khush: one thing when we say the last frame is captured we need to define what your last frame, so we defer it until you have a navigation response

khush: we are going to run a raf cycle and we tell the user this is the frame that will be captured, do your set up

yoav: i' m not concerned about VT, but people using it for everything else. I want to maybe close down the event to be VT specific, but in the same way that we're limiting (missed) dismissal events

yoav: it would be good to have preventive restrictions

noamr: we want to be careful of people creating VT just to get this event, so i'm hesitant with artifical restrictions

yoav: i'm not saying artificial, i'm saying you get the event, but you can't do fetch or beaconing, etc

noamr: that's ok

noamr: we want to be careful that is general, we don't want to say it's VT specific, because it can have an opposite effect

khush: what i'm confused: every raf is going to need to be restricted? since raf will fire

yoav: yeah, they'll queue raf and do weird things

noamr: and people can do this in pagehide, we're adding an event before pagehide

yoav: ok

noamr: we have challenges with MPA VT, one is progressive rendering: the incoming page might not be loaded/parsed

noamr: second is how do you deal with the lifecycle and events and footguns

noamr: third one is in css: is navigation and event or a state, or you can say it's two events, because the state goes between two documents

noamr: it's an event for the last frame and then for one more frame, so we're thinking more of it as an event than a state

noamr: this is up for discussion

noamr: this is also the first time where we define anything about navigations in css, so there was a fear of using a name like navigation for this

noamr: this is about future proofing, maybe in the future we want to define something else here in the future, like regular keyframes that start on navigations

noamr: maybe we want to qualify this with URLs or back/forward info

noamr: so how do things work together, the three features we talked about

noamr: first, you can start a view transition and give it a class

noamr: if cross document wants to be semantically grouped, we can add @navigation and specify view-transition-classnames behavior rule

noamr: now, our execution plan: we have two big issues we want to resolve soon

noamr: first, global cross origin opt-in.

noamr: second, the semantic grouping.

noamr: i feel like if we have two those things, plus the html events, javascript style, and we resolve these two things in the lifecycle and people can play with MPA VT

noamr: later on we plan to get to element view transition and expand navigation for url/back navigation/etc

noamr: this is what we want to do first: navigation trigger for MPA, and readytorender event that maybe gives you a view transition that you can work with

noamr: and semantic grouping where you set classes and respond to them

noamr: step c is to combine these two things together

noamr: questions? comments?

michael: for cross document navigations, i understand the desire to limit the need for js, and there is a navigation api now and so you're potentially firing these events at a similar time to intercept

noamr: yes, for outgoing

michael: so there is a problem for when to load, and end, and you have a placeholder like a spinner

noamr: yes, currently for the new document, this doesn't help us at all since there are no navigation events

noamr: for old document we thought about dealing with navigate event but also adding something for redirects

noamr: so you want this not just for things clicked in the page

noamr: we do want to make this work well together

fantasai: if you're just doing a declarative transition between pages, there is some ttype of syntax that enables that, some class navigation

noamr: right now, it's just @navigation same-origin

fantasai: and what is same-origin what else can you put there?

noamr: right now nothing, but as a reader you can see this applies to same origin navigation, and later we'll be putting things that map to url patterns / back reload

noamr: like you define what is a song page and play a page and a navigation between them has a class list expand

noamr: we didn't want to get into this, but we had some ideas about this, navigation is always qualified by some urls, so you might have to specify something at least as broad as same origin

noamr: we might also want to expand this to something that isn't same origin, we don't want existing pages to immediately upgrade to that without changes

fantasai: i think it would be a good idea to fully explore the space, since the decision we make here we'll be trapping ourselves here, although we don't want to implement things we want to explore we'd want to put in here

fantasai: in terms of mapping urls to classes of navigations, then can the page ... if you don't have the url or an obvious pattern, like it's a random identifier, which isn't great from url perspective but we shouldn't care, then you can't map a url pattern to types

fantasai: can we handle these cases

noamr: we explored things to the group and we can explore this internally and explore it tomorrow

noamr: this is about navigation urls and types which is (missed)

noamr: about url patterns, we can go this way forever and in the end you can do things in javascript. if you can't map things declaratively you can do script (or in the server)

noamr: we also don't want to work on the javascript api to work on this navigation

eeeps: is this feature limited to same origin navigations or is cross origin in scope

noamr: not in scope

eeeps: but are there cases for this

<ntim> we're out of time fwiw

noamr: maybe same site, or first party set

noamr: join us tomorrow for details


<fantasai> I think it would be good to make view transitions work without a dependency on URL patterns

<noamr> fantasai: I updated w3c/csswg-drafts#8048 (comment) in preparation for tomorrow, sharing also some of the research we've done on where we might go with @navigation

Minutes manually created (not a transcript), formatted by scribe.perl version 222 (Sat Jul 22 21:57:07 2023 UTC).