[css-view-transitions-1] How do the writing-mode and direction properties affect the view-transition pseudo-elements?

[bert-github]

After reviewing the spec for i18n issues, I wasn't clear what the function of the 'writing-mode' and 'direction' properties was. They occur, e.g., in 8.3. Setup view transition:

Set capture’s old styles to the following:
[...]

• writing-mode
  The writing-mode of element.
• direction
  The direction of element.

And similar in 8.9. Update pseudo-element styles.

These properties are set on elements that are images. But they don't have effect on images, do they? In other words, would anything change if these properties were omitted from the style for these view-transition pseudo-elements?

If they do have an effect, a note or an example could be useful.

And, please, write the answer to this issue, and any explanation in the spec, in simple language! We (the I18N WG) found the spec rather difficult to understand…

[vmpstr]

The position of the image elements (i.e. the -new and -old pseudo elements) are specified in terms of block and inline directions: https://drafts.csswg.org/css-view-transitions-1/#selectordef-view-transition-old-pt-name-selector

The css here is

position: absolute;
inset-block-start: 0;
inline-size: 100%;
block-size: auto;

The block and inline directions map to vertical or horizontal physical directions based on the writing mode.

In layperson terms, in horizontal writing mode, the CSS above says "image is located at the top of its container; the image width fills the container and the image height is automatically determined based on aspect ratio and width"

However, in vertical left-to-right writing mode (as an example), this is "image is located at the left of its container; the image height fills the container and the image width is automatically determined based on the aspect ratio and height"

It's for this reason that we capture the writing mode and direction.

In practice, this would only be noticeable with CSS that changes the group pseudo element size, which would cause the inline size and the block size of the container to differ from the aspect ratio of the new or old images

Let me know if I can elaborate on anything better

[khushalsagar]

@fantasai did you want to take a look at this? You mentioned that you can do an i18n review.

[svgeesus]

ping @bert-github could you confirm that our clarification resolves your concerns!

[bert-github]

I think I understand the explanation. And the I18N WG also agrees that there is no problem with the properties.

But the spec itself still doesn't explain very well what 'writing-mode' and 'direction' do to the transition. Maybe 'writing-mode' and 'direction' can be mentioned in the note just after the occurrence of 'inline-size', or, conversely, 'inline-size' and 'block-size' can be mentioned just after the first occurrence of 'writing-mode'?

Anyway, we can close the issue.

[khushalsagar]

Let me take another stab at clarifying this since it came up on #8958 this as well. Just to make sure we're preserving the right bits from computed style.

There's 2 aspects of layout that ViewTransitions sets up a default animation for :

• A change in the element's viewport based transform. This is covered in [css-view-transitions-1] top/left vs block-start/inline-start #8886.
• The size of the element. This is the animation that requires properties like writing-mode so I'll cover that below.

If an element's border box size is changing, which could also involve a change in its aspect ratio, the default animation animates between the layout sizes of the old and new element. Since the element snapshots may not match the size of the replaced element during this animation, we take the following strategy to decide how to scale the snapshots during the animation:

• In the inline direction, the snapshot scales to match the length of that edge.
• In the block direction, the snapshot scales to maintain the same aspect ratio (so there is no weird stretching).

This is because we found that in most use-cases, it's better for a single line of text to be completely visible. The content in the block direction can gradually reveal or hide itself. For example, you click on a button which expands into a details list. If the developer puts overflow: clip on the replaced elements, the visual effect is that you see more lines of text as the box size expands.

So we do this by copying over the writing-mode and direction from the DOM elements onto their group pseudo-element. And setting up the layout of the replaced elements using logical properties:

:root::view-transition-old(*),
:root::view-transition-new(*) {
	position: absolute;
	inset-block-start: 0;
	inline-size: 100%;
	block-size: auto;
}

I don't think we need text-orientation because the effect of that properties is baked into the captured image itself, i.e, text-orientation will determine how the glyph is rendered when capturing the snapshot. So it doesn't need to impact how the pseudo-elements are rendered.

[fantasai]

So it doesn't need to impact how the pseudo-elements are rendered.

Yes, but it can impact how the properties cascade together. E.g. whether 'margin-inline-start' maps to 'margin-top' or 'margin-bottom' in vertical writing depends on 'text-orientation'. So I think it would be good to copy them as a set.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-1] How do the writing-mode and direction properties affect the view-transition pseudo-elements?, and agreed to the following:

• RESOLVED: Copy text-orientation from the dom node, along with the existing writing-mode/direction.

The full IRC log of that discussion

<TabAtkins> khush: This also came up in i18n review
<TabAtkins> khush: this is one case where direcitonality matters
<TabAtkins> khush: when you're animating an element, morphing from one shape to another...
<TabAtkins> khush: The animation tries to make it so if the a-r of the box changes, in the inline direction the snapshot stretches to match the final size
<TabAtkins> khush: And the block matches the aspect ratio
<TabAtkins> khush: so whether it gets cover or contain behavior depends on snapshot a-r
<TabAtkins> khush: To make it work this way, we have the group animate width and height
<TabAtkins> khush: And the element inside use inset-block-start: 0, inline-size:100%, and block-size:auto
<TabAtkins> khush: for this setup to work, there has to be a writing mode, we copy those from the dom element ot the group
<TabAtkins> khush: Are these two properties enough? do we need text-orientation as well?
<TabAtkins> khush: It seems like the effect of text-orientation is baked into the snapshot, so we don't need it for this animation to work
<TabAtkins> khush: fantasai had a point about how it interacts with cascade
<astearns> ack fantasai
<TabAtkins> fantasai: yeah text-orientation can change which logical and physical map to each other
<TabAtkins> fantasai: It won't affect the properties we are setting in the spec, it can have an impact on what the author sets
<TabAtkins> fantasai: So to get that correct we shoudl copy over all three props
<TabAtkins> khush: I'm fine with copying over all three. Our defaults aren't affected, so if it helps authors it sounds okay
<TabAtkins> astearns: So proposed resolutio is to add text-orientation to the writing-mode/direction properties that we copy from the dom element
<TabAtkins> RESOLVED: Copy text-orientation from the dom node, along with the existing writing-mode/direction.

[khushalsagar]

Added an additional note to the spec for this: #9092.