IRC log of css on 2023-09-13

Timestamps are in UTC.

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