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/
<TabAtkins> github-bot, take up w3c/
[css-anchor-position] Anchor positioning proposal comparison
<github-bot> OK, I'll post this discussion to https://
<ntim> TabAtkins: Listed out all the use cases, and what proposals can do them well, not well, etc.
<astearns> updated list: w3c/
<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://
<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/
<TabAtkins> w3c/
<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/
[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://
<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/
<fantasai> w3c/
<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/
<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!
topic-
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/
<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/
[css-view-transitions-2] Support ViewTransitions for same-origin cross-document navigations
<github-bot> OK, I'll post this discussion to https://
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
(presentation)
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
(demo)
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
(reconnecting)
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
end
<fantasai> I think it would be good to make view transitions work without a dependency on URL patterns
<noamr> fantasai: I updated w3c/