[css-view-transitions-1] top/left vs block-start/inline-start

[fantasai]

https://www.w3.org/TR/css-view-transitions-1/#::view-transition-group

I'm wondering if the top/left rules shouldn't be inset-block-start/inset-inline-start?

[khushalsagar]

#8599 was meant to clarify this! There's some more background context on that issue.

The relevant part is that the group element is meant to position itself at the same position as the underlying DOM element using transform. We're using transform instead of top/left (or any other layout position properties) because we want the animation to be accelerated which can be done using transform.

CSS transform is always relative to the top left corner of the containing block. If I do translateX(10px), the result is the same irrespective of what the writing-mode (or block/inline direction) is.

So UA CSS puts the layout position of the box to the top left corner with top: 0; left: 0 and adds a transform. We could technically compute the transform in logical coordinate space and use inset-block-start/inset-inline-start but that seems backward? For example if the author adds an additive transform animation (because they want to create a bounce effect), that transform will also be physical coordinates.

[fantasai]

OK, I've been thinking about this... I think the right answer is to lay it out using block-start/inline-start, but transform it using physical coordinates (at least for now, since we don't have logical transforms). So if the author turns off the UA-provided transforms, the element is anchored to the start/start corner even on an RTL page.

Let me know if that makes sense or not. :)

[khushalsagar]

The awkwardness with this is because the transform property is in physical coordinates. The UA will have to convert the transform applied to the group from physical to logical coordinates which doesn't sound right.

The whole idea with the group pseudo is to position it in the viewport using transform, because it can be accelerated and the setup is for an ephemeral effect rather than proper positioning. Even if the author wants to override for a custom animation, they should still do it using transform. If they have a legit use-case that needs logical positioning for this animation, they can override top/left in favour of logical coordinates. Its the origin anyway so trivial to override to logical origin.

I would've been ok if we had logical transforms. Say in the future we do add logical transforms, using block-start/inline-start now still won't make it possible to switch to those because of compat. Authors can read the transform value computed by the UA, so we won't be able to change it from logical to physical coorindates.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-1] top/left vs block-start/inline-start, and agreed to the following:

• RESOLVED: close no change

The full IRC log of that discussion

<TabAtkins> vmpstr: This is similar to the last
<TabAtkins> vmpstr: We're using top/left to position the v-t pseudo. Q is if we shoudl use block/inline-start
<TabAtkins> vmpstr: This is, I feel a little more strongly we should use top/left. We're using a transform here and it uses phsyical coordinates, we dont' want to recompute based on writing mode.
<TabAtkins> vmpstr: So I again propose closing no change.
<TabAtkins> astearns: fantasai was the one arguing against you but she's getting the door for someone
<TabAtkins> noamr: I'd say the pseudos are not "really" laid out.
<TabAtkins> noamr: In general using margins/etc isn't really common, they don't interact in that way.
<TabAtkins> noamr: They're just in the scene graph and positioned with transform, so I think logical props make less sense.
<TabAtkins> vmpstr: It's also unclear to me what it means to lay out using one anchor point and then transform using another.
<federicobucchi> Federico Bucchi, Apple
<TabAtkins> vmpstr: So like suppose you anchor to one of the corners. If you use block/inline insets the corner changes based on writing mode, but then the transform has to change to use that corner as well. That's what we want to avoid.
<TabAtkins> fantasai: I'm just trying to think thru the ipmlications if, like, the element is larger...
<fantasai> TabAtkins: Since this is positioning, it'll overflow badly anyway
<TabAtkins> vmpstr: This is for the group element specifically, too. The replaced elements that actually have an image use logical coordinates, they'll overflow correctly for the writing mode. But the group is just transformed into place, so I'm not sure what it would be overflowing
<TabAtkins> khush: I guess the real awkwardness is that transforms are only physical, if we had logical transforms we could use logical position too.
<TabAtkins> khush: But for now having one half be logical and the other physical is awkward.
<TabAtkins> fantasai: i guess it's probably fine since the box we're positioning is visible, it' snot overflowing. so if we're laying out wrt that it works
<TabAtkins> khush: The reference box is the snapshot containing block, basically the viewport.
<fantasai> s/positioning/positioning into/
<TabAtkins> fantasai: I think it's fine for now, we can fix it in the future if we need.
<TabAtkins> astearns: So proposed resolution is to close no change
<TabAtkins> RESOLVED: close no change