[css-writing-modes] Does vertical writing mode of an HTML body element cause an orthogonal flow?

[nanto]

https://drafts.csswg.org/css-writing-modes-3/#principal-flow

As a special case for handling HTML documents, if the root element has a body child element [HTML], the principal writing mode is instead taken from the values of writing-mode and direction on the first such child element instead of taken from the root element. Note that this does not affect the values of writing-mode or direction on the root element itself.

When applying writing-mode: vertical-rl to body, html has writing-mode value horizontal-tb (initial value) according to the note and there happens an orthogonal flow between html and body?

Each browsers behave differently about this:

• Edge: An orthogonal flow doesn't happen. body { writing-mode: vertical-rl } behaves as same as html { writing-mode: vertical-rl }.
• Chrome: It seems an orthogonal flow happens since the margin of body child elements doesn't collapse with the margin of a body element.
  • I filed https://bugs.chromium.org/p/chromium/issues/detail?id=845008 and it marked as WontFix.
• Firefox: Propagation of writing-mode is not supported. https://bugzilla.mozilla.org/show_bug.cgi?id=1102175

According to the old spec text, an orthogonal flow can't happen.

The propagated values are treated as if they were specified on the root element.

[css-meeting-bot]

The CSS Working Group just discussed Does vertical writing mode of an HTML body element cause an orthogonal flow?, and agreed to the following:

• RESOLVED: proposed resolution: Propagate direction, and writing mode from the body to the root without affecting computed styles w/optional text-orientation

The full IRC log of that discussion

<Rossen_> Topic: Does vertical writing mode of an HTML body element cause an orthogonal flow?
<Rossen_> github: https://github.com//issues/3066
<una> fantasai: This deals w/the fact that we have writing mode propogation from writing mode to HTML tha tis not very consistently implemented
<una> ... it seems to me that we should propogate it to the HTML elem and consequently not have an orthogonal flow bc its on the the entire doc, not the root element
<una> Rossen_: so this is only the case when writing mode is specified ont he body only
<una> fantasai: whether you specify one on the body or not, we're basically ignoring it
<una> Rossen_: you end up w/double scrollbars sometimes on the wrong sides
<una> fantasai: Edge doesn't do that
<una> ... my proposal would be to do what Edge did
<una> ... theres a few things that need to be fixed, but the proposed resolution is to go w/that Edge did which is that the body writing mode is propogat4ed to both the root element and the writing block
<una> AmeliaBR: so it would be treated the same as if you set it on the HTML
<una> Rossen_: as an overwrite
<una> emilio: there is a viewport implementation, but the root element style is different
<una> Rossen_: wish we had a time machine to go back and have fixed this when it was originally done
<una> fantasai: there are margin-collapsing bugs
<una> ... we resolved to propogate things before but there are some side effects
<una> koji: in chrome, we used to track the propogate and we resolved not to propogate and removed the code
<una> fantasai: really? i remember it wasn't possible
<una> florian: IIRC direction does not propogate
<fantasai> s/possible/possible due to compat/
<una> emilio: we should use a computed value propogation ?
<una> dbaron: the way the spec describes this propogation, it is not affecting the computed styles
<una> koji: only the principle writing mode is affected but no style propogation
<una> dbaron: if i read what the spec says literally - it is saying tha ti fyou set writing mode on body to vertical LR
<una> ... you have an initail containing block fo rvertical LR containing a block for the body element which is seperate
<una> florian: either dont do any propogation at all or have all of those things use the same writing mode
<una> koji: propogation leads to conflicts
<una> dbaron: the hardest part of style is changing the computed styles, if you want to fix this propogation you want to make the propgat4ed val also apply to the block for the elem
<una> ... without messing with styles at all, making it apply to both the block and the styles for the html
<una> florian: we added propogation bc it felt necessary and i dont think we can remove it
<una> fantasai: my recollection was compat requirements for ebooks, which is why we have it
<una> emilio: batch propogates writing mode props
<una> ... direction, writing mode, etc.
<una> fantasai: i think we're propogating the full set, doing part of it will get weirdly inconsistent
<una> ... writing mode, direction, text orientation are the set of props that determine the direction mapping
<una> ... i think text-orientation won't have any effect on the intitial containing block anyway
<dbaron> s/you have an initail containing block fo rvertical LR containing a block for the body element which is seperate/you have an initial containing block that's vertical-lr containing a block for the html element that's horizontal containing a block for the body that's vertical-lr/
<Rossen_> q?
<una> Rossen_: so are we leaning towards that resolution that defined the propogation without affecting computed styles?
<una> ... so the style subsytem doesn't have to be complex, but the experience makes sense and it avoids orthogonal flow changes when they're not needed
<una> emilio: it'll be weird if you have a pseudo element but i guess thats not very common
<una> iank_: I'm a big concerned about the perf implications
<una> Rossen_: let's evaluate the perf once you have a patch that actually does it
<emilio> s/a pseudo-element/a pseudo-element in the root element
<una> ... in terms of behavior the proposed resolution is to add from body to the root element, the propogration & logic
<una> ? : is this for any root element?
<una> Rossen_: I remember we didn't do this for SVG
<astearns> s/?/heycam/
<una> AmeliaBR: is there a reason not to do it for SVG?
<una> Rossen_: we didn't have body element in SVG
<una> AmeliaBR: the propogation doesn't apply but the fact that the root element defines a principle writing mode for the document should apply to SVG
<una> Rossen_ & fantasai: sure
<una> iank_: what happens to props like border-block-end?
<una> fantasai: for propogating the user values, theyre resolved before writing implementation
<una> iank_: I'm concerned about low-end device perf
<una> Rossen_: let's talk abotu it when we have a little more info
<una> AmeliaBR: so is the resolution full propogation from the body to the root
<una> Rossen_: progotat4e direction, writing mode, and text orientation from the body to the root without affecting computed styles
<astearns> s/progotat4e/propogate/
<una> fantasai: the case of the document specifying vertical text orientation on the entire document and also being RTL is an unusual use case
<una> Rossen_: the proposed resolution is the same minus text-orientation
<una> fantasai: we could say propagated text orientation is optional
<una> proposed resolution: propagate direction, and writing mode from the body to the root without affecting computed styles w/optional text-orientation
<una> RESOLVED: proposed resolution: Propagate direction, and writing mode from the body to the root without affecting computed styles w/optional text-orientation
<una> fantasai: we'll need an implementation report and some bug fixes
<una> Rossen_: is it vastly different than what was done before?
<AmeliaBR> s/RESOLVED: proposed resolution:/RESOLVED:/
<una> fantasai: it needs an update
<una> florian: we're a week worth of work away from making it a rec - bug fixing and updating the implementation report
<Rossen_> github: topic
<Rossen_> github: end topic
<Rossen_> github: endtopic

[TalbotG]

@fantasai,

We have already 6 tests in the css-writing-modes-3_dev test suite challenging, verifying this quoted statement:

if the root element has a body child element [HTML], the principal writing mode is instead taken from the values of writing-mode and direction on the first such child element instead of taken from the root element.

Do we actually need to add more tests dedicated on that statement in the css-writing-modes-3_dev test suite? There are 20 other tests listed in bug report 1102175 comment 25

[emilio]

Note to self: The fact that this doesn't affect the computed style of course means that the proposed (but not yet implemented anywhere) vi and vb units would behave quite oddly in this case.

[frivoal]

@emilio If you want vi and vb to behave sanely, you need to set the writing mode on the root element, and then you're good, no?

[emilio]

Sure

[frivoal]

Some tests here: web-platform-tests/wpt#18114
More coming here: web-platform-tests/wpt#18112