06:34:40 RRSAgent has joined #css 06:34:44 logging to https://www.w3.org/2023/09/13-css-irc 06:34:44 RRSAgent, do not leave 06:34:49 RRSAgent, make logs public 06:34:50 Meeting: CSSWG Anchor Positioning 06:34:50 Chair: Tab Atkins Jr. 06:34:52 Agenda: https://github.com/w3c/tpac2023-breakouts/issues/66 06:34:54 clear agenda 06:35:09 agenda+ Pick a scribe 06:35:09 agenda+ Reminders: code of conduct, health policies, recorded session policy 06:35:10 agenda+ Goal of this session 06:35:12 agenda+ Discussion 06:35:14 agenda+ Next steps / where discussion continues 07:18:20 projector has joined #css 07:18:50 leaverou has joined #css 07:19:21 Rossen has joined #css 07:19:51 shans has joined #css 07:20:14 tidoust has joined #css 07:20:21 sylvaing has joined #css 07:34:34 nigel has joined #css 07:45:13 jamesn has joined #css 07:48:02 myles has joined #css 08:12:49 myles has joined #css 08:18:45 tantek has joined #css 08:40:08 myles has joined #css 08:46:39 fserb has joined #css 09:01:00 tidoust has joined #css 09:06:09 oriol has joined #css 09:09:49 khush has joined #css 09:17:30 noamr has joined #css 09:36:53 tantek has joined #css 11:55:27 flackr has joined #css 11:58:25 myles has joined #css 12:05:13 tidoust has joined #css 12:33:38 RRSAgent has joined #css 12:33:38 logging to https://www.w3.org/2023/09/13-css-irc 12:33:43 ntim: present+ 12:33:50 present+ 12:33:54 Present+ 12:33:58 present+ 12:34:02 present+ 12:34:11 present+ 12:34:14 present+ 12:34:14 present+ 12:34:15 present+ 12:34:15 present+ 12:34:16 present+ 12:34:17 present+ 12:34:17 present+ 12:34:18 present+ 12:34:22 present+ 12:34:27 matatk has joined #css 12:34:29 present+ 12:34:33 present+ 12:34:35 nicole has joined #css 12:34:38 aaronlev has joined #css 12:34:43 present+ 12:34:48 present+ 12:34:56 present+ 12:35:17 present+ 12:35:24 ydaniv has joined #css 12:35:30 present+ 12:35:49 noamr has joined #css 12:36:25 link to issue? 12:36:31 tabatkins: Agenda: issue 66, go through all the anchor positioning issues, try to get tentative resolutions, that will be confirmed later this week 12:36:33 noamr_ has joined #css 12:36:37 present+ 12:36:40 https://github.com/w3c/tpac2023-breakouts/issues/66 12:37:56 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9117 12:37:56 Topic: [css-anchor-position] Anchor positioning proposal comparison 12:37:56 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9117. 12:37:56 TabAtkins: Listed out all the use cases, and what proposals can do them well, not well, etc. 12:38:28 updated list: https://github.com/w3c/csswg-drafts/issues/9117#issuecomment-1698431865 12:38:28 q+ 12:39:03 ack flackr 12:39:05 nigel has joined #css 12:39:23 flackr: I don't see transitions between anchors, which none of the proposals cover, but is very common 12:39:32 una: I see transitions between fallbacks 12:39:51 dbaron: look at the second list that astearns linked to 12:39:55 lea has joined #css 12:40:24 nigel has joined #css 12:40:43 Is there an item in that list for the sidenotes / doc comments use case? 12:40:54 TabAtkins: you can animate between 2 distinct anchors, the problem is animating when what an anchor name refers to changes 12:41:47 fantasai: transition between two anchor names is in the table 12:41:53 https://docs.google.com/document/d/185yzaofuMP2p1KK00e2J0cmL8vAxOY3LF7NxhpjveRo/edit 12:41:58 (what flackr was referring to) 12:42:02 This is the document of examples 12:42:08 lea_ has joined #css 12:42:42 TabAtkins: does anyone see something obviously missing in the table? 12:43:06 ntim: "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 12:43:07 eeeps has joined #css 12:43:10 fantasai: the ability to style based on fallbacks 12:43:13 q+ 12:43:27 s/ntim:/dbaron:/ 12:44:18 q+ 12:44:18 add https://github.com/w3c/csswg-drafts/issues/9332 to the list 12:44:18 https://github.com/w3c/csswg-drafts/issues/9332 12:44:20 q- 12:44:25 ack emeyer 12:44:42 emeyer: multiple anchors is something I'm interested in, there is no issue 12:45:06 fantasai: not in the issue, because Tab's proposal already covers it 12:45:46 fantasai: Not sure if it's covered, but cascading behavior on the @try blocks is terrible 12:46:00 (it's on th elist of topics to discuss) 12:46:04 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9124 12:46:04 Topic: [css-align-3][css-position-3] Better interaction of auto insets and self-alignment properties? 12:46:04 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9124. 12:46:46 TabAtkins: before the spec existed there is no interaction between the 2, we would use the CSS 2.1 behavior 12:47:26 TabAtkins: The remaining tension is what to do in the double auto case 12:48:00 My positions: 12:48:02 https://github.com/w3c/csswg-drafts/issues/9124 12:48:06 https://github.com/w3c/csswg-drafts/issues/9124#issuecomment-1679487628 12:48:12 TabAtkins: my preference is to have double autos resolve the same way so they resolve to zeros when you have non-default alignments 12:48:16 https://github.com/w3c/csswg-drafts/issues/9124#issuecomment-1678174879 12:49:01 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. 12:49:36 TabAtkins: the larger thing behind my reasoning, static pos as defined in CSS 2.1 is just a poor version of anchor positioning 12:49:48 TabAtkins: it wasn't great, but it did do the job 12:50:08 TabAtkins: but we don't need this anymore, since we have anchor positniing 12:50:28 TabAtkins: we don't need to do this anymore, unless we are constrained by compat 12:50:42 q+ masonf 12:50:49 ack fantasai 12:51:06 q+ 12:51:07 fantasai: It would be useful to focus on the case where anchor positioning is happening, because we probably have agreement on that one 12:51:39 PROPOSED: If only one inset in an axis is auto, and self-alignment in that axis is not normal, then auto computes to zero 12:52:14 astearns: lets try to resolve on it 12:53:09 ack masonf 12:53:12 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 12:54:56 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 12:55:22 iank: there are a few cases where this breaks down: 12:56:12 iank: let's say my left is based on one anchor, and my right on another based on another 12:57:12 TabAtkins: having the behavior being significantly different between the single and double auto cases is confusing 12:58:31 fantasai: We already have two different modes in abspos: static positoining or not 12:58:53 ... 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 12:59:03 ... I think it's more consistent with how CSS already works 12:59:55 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 13:00:10 fantasai: we already have these 2 modes 13:00:43 jensimmons has joined #css 13:00:44 fantasai: alignment doesn't change what you layout relative to 13:01:18 TabAtkins: I think it would be nice to have a consistent alignment model, 13:01:46 we no longer need the static positioning, it would be nice to have alignment use a single consistent model 13:02:36 fantasai: you're proposing to change existing behavior on web pages 13:02:47 TabAtkins: no I'm not 13:03:14 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 13:03:28 i/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/ 13:03:32 TabAtkins: we should be consistent in the double auto case and resolve both to auto 13:03:41 s/auto/0 13:04:37 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 13:05:11 TabAtkins: re: changing existing behavior, no one implements alignment properties on abspos 13:05:27 fantasai: they do impl alignment properties for the static pos of the abspos 13:05:33 iank: not really 13:05:47 iank: it's implemented in grid / flexbox 13:05:58 iank: but flexbox only implements in one axis 13:06:11 q? 13:06:13 iank: we're willing to take that compat risk and take that back to the group 13:06:15 ack iank_ 13:06:21 iank: the proposed behavior is super useful 13:06:34 iank: today if you need to center somnething in the containing block 13:07:06 iank: there's about 2-3 ways people use, they are very clunky 13:07:13 iank: you need to set multiple props 13:07:24 iank: one way is setting insets to 0 13:07:32 iank: the other way is using calc 13:07:52 iank: They're all super clunky 13:08:11 iank: being able to set place-content: center and get centered alignment is very neat 13:09:07 scribe+ 13:09:33 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 13:09:45 fantasai: The hacks iank mentions are indeed all terrible and should be replaced with alignment 13:09:58 fantasai: that doesn't mean that alignment should change the behavior in auto-auto case 13:10:07 fantasai: just means you set 'inset: 0' to switch to useing the abspos containing block 13:10:12 q+ 13:10:17 fantasai: I don't think this his hard or confusing 13:10:28 scribe+ 13:10:36 q+ 13:10:40 q+ 13:10:43 ack fantasai 13:10:43 fantasai, you wanted to say that adding 'inset: 0' is not that much to add 13:11:12 miriam: inset 0 isn’t a lot to add, but I as an author have never found abspos particularly useful 13:11:19 …I’m wondering what we gain by maintaining it 13:11:24 s/abspos/static positioning of abspos/ 13:11:34 …What is the use case where I want to maintain it while adding alignment? 13:11:56 fantasai: Two things about adding alignment to static pos 13:12:12 …Static pos is like if you have an element in the document and then flip on abspos 13:12:36 …If you apply alignment properties in block mode (for example), then it will jump to somewhere else 13:12:54 …What I’m arguing for is, when you define an anchor, then static positioning becomes relative to the anchor bow 13:13:10 …That gets you the ability to be centered inside another box very easily 13:13:28 …I think for the non-anchor case, it’s about consistency with the way static positioning works 13:13:52 miriam: I understood you were proposing that when you switch to abspos, that would change your alignment, but in a different way 13:14:12 fantasai: If you want to be anchored to an element, I think it makes sense your automatic position moves to that element 13:14:24 …I think alignment changing your containing block to change is confusing 13:14:37 …Right now, alighment shifts you within the container to which you’re sizing 13:14:49 …anchor-default does move you; that’s its intention 13:15:14 …Why not have it do something as soon as it’s set? 13:15:30 TabAtkins: I think your argument is that current behavior is useful, and I want to argue with that 13:15:46 …We know that flexbox rules aren’t very useful; we watered them down on purpose 13:16:12 …In the one case that isn’t well implemented yet, the inline-block case, aligning goes into degenerate rectangles 13:16:24 …It would do something, but usually the opposite of what you expect it to do 13:16:46 …align: start would put you more end-ward and align: end would put you more start-word, in certain cases 13:17:02 …I think we were okay with that confusion when we defined the behvavior because we didn’t have anything better 13:17:56 …Now that we have better, we don’t have to offer authors this confusing behavior 13:17:56 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 13:18:08 iank_: I don’t think there’s been strong use cases presented for the double-auto case 13:18:23 …The behavior being proposed does solve developer pain quite well 13:18:32 …It does something very useful for center, stretch, a bunch of other things 13:18:42 …This is outside of anchor positioning 13:18:52 q? 13:18:55 TabAtkins: I’m not sure how to resolve this, Elika 13:19:32 ack iank_ 13:19:32 q+ 13:19:32 …My argument is that the default behavior wasn’t useful, perhaps when it was defined, but not now 13:20:04 xiaochengh: For center, resolving double-auto to zero seems more useful 13:20:19 …THe inset modified containing block isn’t just used for alignm,ent, but also for position fallback 13:20:28 q+ 13:20:39 …The only containing block to test is the original containing block 13:20:57 …For alignment, we could use a different containing block than for fallback, but I’d like to avoid that 13:21:01 ack xiaochengh 13:21:07 ack miriam 13:21:27 miriam: Already we have a behavior where apply insets changes your reference, you’re no longer using the static position box 13:21:49 …To me, changing the alignment is exactly the same concept, so in my mind it aligns better with current behavior 13:22:03 …Alignment is an auto-inset sort of thing, so if one changes, why not the other? 13:22:08 ack ntim 13:22:25 q+ 13:22:38 ack vmpstr 13:22:49 vmpstr: Is there a web compatibility risk with this resolution? 13:23:06 TabAtkins: For some layout modes, we do implement the double-auto case 13:23:14 …We’re willing to take the compat risk 13:23:27 iank_: We’re also willing to take the risk 13:23:34 …We don’t think there will be much 13:23:52 astearns: Is there anyone who wants to show solidarity for Elika’s position? 13:24:11 emilio: Elika’s position is safest 13:24:24 iank_: If we show it’s web compatible, would that change your mind? 13:24:43 emilio: I don’t feel too strongly about preserving the current behavior 13:25:04 fantasai: Part of my point is you can get the behavior Tab and Ian want by setting inset to 0 13:25:21 astearns: Having a property that does nothing until you set another property isn’t good design 13:25:29 emilio: That’s already positioning, right? 13:25:44 iank_: I think our argument is that what we want is more useful and more what devs expect 13:25:49 astearns, that's a good argument for anchor-default having an effect without setting 'inset: anchor(..)'! 13:26:13 emilio: How is it more useful if the behavior Ian and Tab want can be achieved 13:26:23 …The current behavior cannot 13:26:30 fantasai: I am OK with needing two properties when two things need to be connected 13:26:44 s/fantasai:/fantasai,/ 13:26:59 TabAtkins: Current behavior can be achieved via anchor position 13:27:01 astearns, they are connected already, why not have an effect 13:27:19 iank_: I think also, there hasn’t been strong use cases for the existing behavior 13:27:27 q+ 13:27:40 nigel has joined #css 13:27:54 TabAtkins: Curernt staticpos behavior is in many cases unintuitive and inconsistent between layout modes 13:28:22 …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 13:28:42 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 13:28:42 ack noamr_ 13:28:45 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 13:29:05 noamr_: If you want to achieve this non-useful behavior, you’d have to name everything 13:29:31 TabAtkins: You’d have to write a name, but it could be a locally s coped name (according to another proposal) 13:29:41 astearns: Does that meet your concern, Elika? 13:29:52 nigel has joined #css 13:29:52 fantasai: Replicating for grid and flexbox is not too hard 13:30:06 …You have to assign a name to the contain and then tell the item to anchor itself to that 13:30:19 …For block and inline, you can’t just slap a name on a containing block 13:30:25 …You have to reference where the item would have been 13:30:42 …You’d have to add an empty element to the DOM to act as a placeholder 13:31:45 (not correct; you're always positioning relative to the prev/following element, and those can receive a name) 13:31:45 astearns: We’re out of time; not hearing consensus, but 13:31:53 …can we take a resolution? 13:32:00 fantasai: I think I’d object unless everyone else in the WG disagrees 13:32:00 TabAtkins: Thank you all for coming! 13:32:00 topic- 13:32:00 Tab, that doesn't work for "here's some text more text" 13:32:21 nigel has joined #css 13:32:44 emeyer has left #css 13:34:03 nigel_ has joined #css 13:38:09 myles has joined #css 13:40:20 We've also changed staticpos behavior before (for flexbox e.g.) and people were kinda annoyed about it when we made it less capable 13:40:35 so at least some people do use it... 13:42:47 Right, the non-aligned staticpos. Not proposing to change that, the compat is definitely bad. 13:43:57 nigel has joined #css 13:45:23 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.) 13:48:51 khush has joined #css 13:49:26 topic TPAC breakout: CSS View Transitions 13:49:55 khush has changed the topic to: TPAC breakout: CSS View Transitions 13:49:56 matatk has joined #css 13:54:48 do i need a github issue or do i just scribe as is? never done it 13:55:58 q? 13:56:15 topic: TPAC breakout: CSS View Transitions 13:57:47 tidoust has joined #css 13:57:56 github-bot, take up https://github.com/w3c/tpac2023-breakouts/issues/20 13:57:56 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. 13:59:22 duga has joined #css 13:59:22 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8804 13:59:22 Topic: [css-view-transitions-2] Support ViewTransitions for same-origin cross-document navigations 13:59:22 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8804. 13:59:22 scribenick: vmpstr 13:59:29 MasakazuKitahara has joined #css 14:00:32 romain has joined #css 14:00:37 emeyer has joined #css 14:01:17 present+ 14:01:17 present+ 14:01:17 present+ 14:01:36 mfoltzgoogle has joined #css 14:01:46 present+ Mark_Foltz 14:01:51 present+ 14:02:44 present+ 14:02:57 noamr has joined #css 14:03:01 present+ 14:03:31 Mu-An has joined #css 14:04:15 noamr: i'm going to present and chat about view transitions 14:04:17 ntim has joined #css 14:04:38 noamr: we have a few VT issues scheduled for tomorrow. I feel like we deal with these issues like blind men and an elephant 14:04:51 noamr: we're not seeing the big picture and what we're trying to do with it 14:04:55 present+ 14:04:58 noamr: and some people might have not been here 14:05:19 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 14:05:24 (presentation) 14:05:39 noamr: i'll show what we have today, and plans for the future 14:05:48 noamr: what is CSS view transitions (VT) 14:06:00 noamr: it's a transition between states; before we had a transition between elements 14:06:09 now we take a document capture it and morph it into a new state 14:06:31 noamr: we do this by capturing an element snapshot, change the dom, capture a different set and morph by name 14:06:40 noamr: this is a general idea of VT 14:06:48 (demo) 14:06:50 matatk has joined #css 14:07:14 noamr: here there's switching immediate. But if we put it inside start view transition, they get immediately a cross fade 14:07:30 noamr: now, this is a default and building on this we can define a whole bunch of customizations 14:08:13 noamr: i wanted to show something similar to what we saw 14:08:17 noamr: we have a button that switches states 14:08:17 (live demo!) 14:08:48 noamr: it does it immediately, if we add startViewTransition to it, and put it in the startViewTransition block, it cross fades 14:08:53 noamr: this is nice, but you want to customize 14:09:00 myles has joined #css 14:09:16 tantek has joined #css 14:09:29 noamr: so for example, I'm giving h1s transition name of heading 14:09:43 noamr: and then I can customize the animation between heading elements 14:09:55 noamr: so now the animation is 1 second and has a blur 14:10:08 noamr: I do all of this with pseudo elements 14:10:29 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 14:10:41 noamr: i'm defining that there is a slide but one of them is a reverse 14:11:14 (this is still live demo) 14:11:14 noamr: this is extremely customizable, there's something at the start and at the end, and pseudo elements to transfer between states 14:11:14 noamr: this is css VT today in terms of features 14:11:46 (back to preso) 14:11:46 noamr: it creates a morph by creating a tree of pseudo elements with names like heading in this case 14:11:49 noamr: it creates a group for the transition, and a pair of elements old and new for the states 14:12:09 noamr: people are excited about this, there are a few companies using this and frameworks (missed the names) 14:12:29 ydaniv has joined #css 14:12:29 noamr: it's been a quite a popular request on surveys 14:12:37 noamr: i want to jump from that to what we saw people do 14:12:50 s/missed the names/Svelte.kit, Astro/ 14:12:55 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 14:13:15 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 14:13:34 noamr: a11y wise it was where both states are in the DOM. Here there is no dom, it's pseudo elements and style 14:13:42 noamr: this is a very common use case 14:14:04 noamr: this is an even commoner use case. here is a list of songs, and you click one and expands to one song 14:14:14 noamr: this is a list to details view, like shopping list to details 14:14:23 noamr: this is extremely popular in demos that we have seen 14:14:47 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 14:14:51 noamr: and this animates it 14:15:07 noamr: this is less of a navigation, but something internal to the page. we see this in things like timeline where list changes order 14:15:27 noamr: automatically sorting list is something we see a lot, and it's something i'm excited about 14:15:43 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 14:15:59 noamr: the constraints of css VT, where we are today, what you say looks demo-y 14:16:13 noamr: it can be incorporated into a page, but it's limited to the document 14:16:24 noamr: everything in the document you have, it will be selected for the document 14:16:42 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 14:17:06 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 14:17:20 noamr: from this we derived what we want in the vision; we want to remove constraints 14:17:34 noamr: to explain what we want to do, i want to show an ugly wireframe of a music list 14:17:40 (demo slide) 14:17:55 noamr: what you want on this page is three different transitions 14:18:06 noamr: first you want the slide page thing, you want the nav bar where things slide on the next page 14:18:13 matatk has left #css 14:18:16 noamr: then, if you click on a song, you want the song to expand 14:18:27 noamr: the third if you drag and drop the list, you want the list to animate 14:18:36 noamr: it doesn't look like an uncommon use case for a real web app 14:18:54 noamr: when using VT myself, i was struggling with doing this: incroproate a bunch of things into the same app 14:19:11 noamr: this is not in priority order, but this is what we envision for VT 14:19:27 noamr: we think that we want to allow to scope element transitions to elements 14:19:57 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 14:20:26 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 14:20:35 noamr: we want it to work with javascript and without javascript 14:21:03 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 14:21:09 noamr: we don't want to spec ourselves into a corner 14:21:30 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 14:21:37 noamr: can't do this today, but want to do it in the future 14:21:43 noamr: this is sort of how you do it in javascript 14:22:04 noamr: so currently the document.startViewTransition function exist. We want to have something like playerWidget.startViewTransition 14:22:38 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) 14:22:49 noamr: and all animations are scoped to that 14:23:36 noamr: you might have simultanious (sp) transitions running at the same time 14:23:36 emilio: i wanted to ask about group. for top level VT in SPA 14:24:02 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 14:24:32 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 14:25:09 emilio: the iframe is a whole contained thing 14:25:09 khush: the idea is to bring that type of containment into one element 14:25:09 noamr: a lot isn't solved 14:25:13 ntim: how does it work if you have a element that overlaps the scope, and you put it so it overlaps 14:25:29 ntim: if you have your scope, and an element outside the scope, how does the screenshotting work 14:25:41 noamr: the capture is of elements, not the screen and the overlap doesn't change 14:25:54 yoav: so if there's occlusion, that doesn't change anything 14:26:13 noamr: so you capture an element as an element capture, not the occluded screen capture 14:26:49 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 14:27:21 noamr: semantic grouping, defining multiple transitions, but activating just one of them 14:27:21 noamr: when we click a nav bar, it does slide, but when you click an element it expands 14:27:23 noamr: these would be different animations, different pseudo elements, etc 14:27:48 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 14:28:07 noamr: we capture things that don't transition so you transition things that don't need to transition 14:28:24 noamr: i've seen this from demos and that's something that we can fix and want to fix 14:28:39 noamr: how do you fix it today? you can do it in javascript, say you want to click on details to expand 14:28:56 noamr: you can set a class on then run the transition and then remove the class 14:29:10 noamr: during the transition you know which transition ran, so when you're in the expand song class, you know what names exist 14:29:28 noamr: instead we're suggesting when you startViewTransition you pass a list of ephemeral classes 14:29:45 noamr: this is the css of how you would read these classes 14:30:02 noamr: btw this is all bikeshed 14:30:15 noamr: we thought about this a lot, but this is all bikesheddable 14:30:41 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 14:30:51 emilio: and you can change a lot more than the view transition names 14:31:07 trying again 14:31:13 "connecting to network" 14:31:44 conversation is about making a selector vs qualifying the names 14:31:59 noamr: doing something with a name is a possibility we felt it was a bit limiting 14:32:16 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 14:32:32 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 14:32:41 emilio: i'm still sad about things that require layout 14:32:51 noamr: sure we can reason about doing this at the last moment 14:33:13 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 14:33:17 emilio: sure 14:33:34 michael: is this ore about starting a subset of possible transition or customizing transitions or both 14:33:38 noamr: both 14:34:00 michael: once started the set will be on the whole document, the latter will allow multiple transitions 14:34:32 khush: if your transition targets a whole document, but have multiple transitions 14:35:00 noamr: this is 100% syntactic sugar, and continuation of previous CSSWG F2F, if something starts with style and ends with style, it shouldn't change the dom 14:35:09 noamr: I think fantasai brought it up and it resonated with me 14:35:13 s/shouldn't/shouldn't be required to/ 14:35:29 noamr: if we decide to not do this, i'm ok with that too 14:35:41 noamr: we have a type of the transition, and a slide one, and reason about them separately 14:35:58 noamr: the reason we put it in the pseudo class because of hte previous thing about scoped element transitions 14:36:11 noamr: the active view transition pseudo element can go into element that is a view transition route 14:36:31 noamr: the third one and most improtant one is navigation triggered transition -- automatically start a transition when a document navigation takes places 14:36:43 noamr: (missed) 14:36:56 noamr: let's say we have the same app, and we have slide transitions and the song expands 14:37:04 noamr: we want the song to be in a different document 14:37:45 (reconnecting) 14:38:01 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 14:38:13 noamr: and sometimes the choice is done did your document load, did you pass hydration to make it an spa 14:38:27 noamr: so when I think about an SPA or an MPA, i want to think about it as a detail 14:38:36 noamr: it's a progressive enhancement between different cases 14:38:52 noamr: they don't want to rewrite their css for different cases, so it should be more infrastructure 14:39:08 noamr: so we want the song to expand whether it's the same document or cross document and work consistently 14:39:19 noamr: plus we don't want to break the sort transition while we do that 14:39:28 noamr: so again, reminding of the bikeshed icon 14:39:39 noamr: so we define something like an event or behavior that is bidirection 14:39:57 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 14:40:12 noamr: the concept is you put this in css document in both documents 14:40:24 noamr: and both sides opt in to trigger a transition 14:40:39 noamr: we'd read it twice: right before the last frame of the old document, and before the first frame of the new document 14:40:50 noamr: this also applies to back/forward cache and prerender 14:41:07 noamr: we'd read the current value of this and decide whether to trigger or skip the transition 14:41:19 noamr: we also need js events or something to customize the transition, probably on both sides 14:41:30 noamr: there is conversation with whatwg html spec to see if we can reach something 14:41:49 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 14:41:56 noamr: then you get an event on the new document that can do that 14:42:09 yoav: how is commit navigation be different in terms of negative side effects of unload 14:42:20 noamr: we need to think about this, i'm hesitant to do this in unload event 14:42:22 yoav: ok 14:42:46 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 14:42:56 noamr: the other alternative is to send a same origin redirect 14:43:13 noamr: so you get a navigation event for navigation API, and get a redirect event if it redirects 14:43:29 yoav: is it make it to be passive, or do we need to fire in the context of the old document 14:43:37 noamr: it needs to request a frame of the old document and render into capture 14:44:02 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 14:44:24 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 14:44:56 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 14:45:06 yoav: it would be good to have preventive restrictions 14:45:26 noamr: we want to be careful of people creating VT just to get this event, so i'm hesitant with artifical restrictions 14:45:40 yoav: i'm not saying artificial, i'm saying you get the event, but you can't do fetch or beaconing, etc 14:45:46 noamr: that's ok 14:46:07 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 14:46:25 khush: what i'm confused: every raf is going to need to be restricted? since raf will fire 14:46:38 yoav: yeah, they'll queue raf and do weird things 14:46:52 noamr: and people can do this in pagehide, we're adding an event before pagehide 14:46:57 yoav: ok 14:47:26 noamr: we have challenges with MPA VT, one is progressive rendering: the incoming page might not be loaded/parsed 14:47:35 noamr: second is how do you deal with the lifecycle and events and footguns 14:48:00 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 14:48:17 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 14:48:22 noamr: this is up for discussion 14:48:45 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 14:49:06 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 14:49:17 noamr: maybe we want to qualify this with URLs or back/forward info 14:49:33 noamr: so how do things work together, the three features we talked about 14:50:16 noamr: first, you can start a view transition and give it a class 14:50:19 noamr: if cross document wants to be semantically grouped, we can add @navigation and specify view-transition-classnames behavior rule 14:50:33 noamr: now, our execution plan: we have two big issues we want to resolve soon 14:50:40 noamr: first, global cross origin opt-in. 14:50:49 noamr: second, the semantic grouping. 14:51:14 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 14:51:56 noamr: later on we plan to get to element view transition and expand navigation for url/back navigation/etc 14:52:03 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 14:52:20 noamr: and semantic grouping where you set classes and respond to them 14:52:32 noamr: step c is to combine these two things together 14:52:47 q? 14:52:47 noamr: questions? comments? 14:53:31 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 14:53:35 noamr: yes, for outgoing 14:53:54 michael: so there is a problem for when to load, and end, and you have a placeholder like a spinner 14:54:12 noamr: yes, currently for the new document, this doesn't help us at all since there are no navigation events 14:55:06 noamr: for old document we thought about dealing with navigate event but also adding something for redirects 14:55:06 noamr: so you want this not just for things clicked in the page 14:55:06 noamr: we do want to make this work well together 14:55:17 ack fantasai 14:55:30 fantasai: if you're just doing a declarative transition between pages, there is some ttype of syntax that enables that, some class navigation 14:55:39 noamr: right now, it's just @navigation same-origin 14:55:46 fantasai: and what is same-origin what else can you put there? 14:55:53 q+ 14:56:42 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 14:56:42 noamr: like you define what is a song page and play a page and a navigation between them has a class list expand 14:57:02 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 14:57:20 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 14:57:51 fantasai: i think it would be a good idea to fully explore the same, 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 14:58:35 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 14:58:42 fantasai: can we handle these cases 14:58:54 q+ 14:58:57 noamr: we explored things to the group and we can explore this internally and explore it tomorrow 14:59:03 s/explore the same/explore the space/ 14:59:14 noamr: this is about navigation urls and types which is (missed) 14:59:31 q- 14:59:49 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) 15:00:08 noamr: we also don't want to work on the javascript api to work on this navigation 15:00:37 eeeps: is this feature limited to same origin navigations or is cross origin in scope 15:00:41 noamr: not in scope 15:00:51 eeeps: but are there cases for this 15:00:53 ntim has joined #css 15:00:56 we're out of time fwiw 15:01:15 noamr: maybe same site, or first party set 15:01:21 noamr: join us tomorrow for details 15:01:23 topic: end 15:01:28 I think it would be good to make view transitions work without a dependency on URL patterns 15:02:19 ydaniv has left #css 15:06:57 tidoust has joined #css 15:14:02 fserb has joined #css 15:18:41 tantek has joined #css 15:20:24 myles has joined #css 15:26:42 khush has joined #css 15:40:17 emeyer has left #css 15:53:38 gtalbot has joined #css 15:55:49 noamr has joined #css 15:56:30 ntim has joined #css 15:56:48 gtalbot has left #css 15:56:55 gtalbot has joined #css 15:58:45 gtalbot has left #css 16:04:30 fantasai: I updated https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1716035713 in preparation for tomorrow, sharing also some of the research we've done on where we might go with @navigation 16:19:51 duga has joined #css 16:33:07 bradk has joined #css 16:48:53 bradk has joined #css 17:15:10 eeeps has joined #css 18:36:01 eeeps has joined #css 21:06:45 eeeps has joined #css 21:08:00 tidoust has joined #css 21:09:54 tidoust has left #css 21:35:10 github-bot has joined #css 21:42:04 eeeps has joined #css 21:45:21 eeeps has joined #css 22:04:24 karlcow has joined #css 22:04:39 eeeps has joined #css 22:35:51 eeeps has joined #css