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

nanto · 2018-08-30T04:09:34Z

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.

The text was updated successfully, but these errors were encountered:

css-meeting-bot · 2019-06-05T14:39:17Z

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 · 2019-06-05T23:07:19Z

@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 · 2019-06-29T23:45:01Z

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 · 2019-06-30T03:27:33Z

@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 · 2019-07-01T20:45:30Z

Sure

'writing-mode' and 'direction' are propagated up from the body element. This affects the root element in addition to the ICB and viewport, but only for used values, not for computed values. The same propagation is optionally allowed for 'text-orientation'. Closes w3c#3066

'writing-mode' and 'direction' are propagated up from the body element. This affects the root element in addition to the ICB and viewport, but only for used values, not for computed values. The same propagation is optionally allowed for 'text-orientation'. Closes #3066

frivoal · 2019-07-26T20:48:39Z

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

Added 24 tests and 7 references to cover issue w3c/csswg-drafts#3066

… issue 3066, a=testonly Automatic update from web-platform-tests Added 24 tests and 7 references to cover issue 3066 (#18122) Added 24 tests and 7 references to cover issue w3c/csswg-drafts#3066 -- wpt-commits: c5c81ed0afc96d09ff5ba061458a47af9b3dd925 wpt-pr: 18122

…ts#18122) Added 24 tests and 7 references to cover issue w3c/csswg-drafts#3066

… issue 3066, a=testonly Automatic update from web-platform-tests Added 24 tests and 7 references to cover issue 3066 (#18122) Added 24 tests and 7 references to cover issue w3c/csswg-drafts#3066 -- wpt-commits: c5c81ed0afc96d09ff5ba061458a47af9b3dd925 wpt-pr: 18122 UltraBlame original commit: 1992297544b9ea1bcc3b832b17a339bd2a01d239

myakura added the css-writing-modes-3 label Aug 30, 2018

xfq mentioned this issue Dec 24, 2018

[css-display-3][css2] initial direction & writing-mode from root or body? #3260

Closed

fantasai added the Agenda+ F2F label May 16, 2019

astearns removed the Agenda+ F2F label Jun 5, 2019

mozilla-apprentice mentioned this issue Jun 5, 2019

[css-writing-modes] Does vertical writing mode of an HTML body element cause an orthogonal flow? mozilla/wg-decisions#55

Closed

fantasai added Closed Accepted by CSSWG Resolution Needs Edits Needs Testcase (WPT) and removed Closed Accepted by CSSWG Resolution Needs Edits labels Jun 5, 2019

frivoal mentioned this issue Jul 19, 2019

[css-writing-modes] Clarify how propagation from body works #4130

Merged

fantasai closed this as completed in #4130 Jul 21, 2019

frivoal added Tracked in DoC and removed Needs Edits labels Jul 21, 2019

TalbotG mentioned this issue Jul 26, 2019

Added 24 tests and 2 reference to cover issue 3066 web-platform-tests/wpt#18112

Closed

frivoal removed the Needs Testcase (WPT) label Jul 26, 2019

frivoal added the Tested Memory aid - issue has WPT tests label Jul 26, 2019

TalbotG mentioned this issue Jul 27, 2019

Added 24 tests and 6 references to cover issue 3066 web-platform-tests/wpt#18122

Merged

frivoal pushed a commit to web-platform-tests/wpt that referenced this issue Jul 28, 2019

Added 24 tests and 7 references to cover issue 3066 (#18122)

c5c81ed

Added 24 tests and 7 references to cover issue w3c/csswg-drafts#3066

natechapin pushed a commit to natechapin/wpt that referenced this issue Aug 23, 2019

Added 24 tests and 7 references to cover issue 3066 (web-platform-tes…

fd8d482

…ts#18122) Added 24 tests and 7 references to cover issue w3c/csswg-drafts#3066

emilio mentioned this issue Sep 20, 2019

writing-mode propagation from body to document element is annoying #4357

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

nanto commented Aug 30, 2018

css-meeting-bot commented Jun 5, 2019

TalbotG commented Jun 5, 2019

emilio commented Jun 29, 2019

frivoal commented Jun 30, 2019

emilio commented Jul 1, 2019

frivoal commented Jul 26, 2019

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

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

Comments

nanto commented Aug 30, 2018

css-meeting-bot commented Jun 5, 2019

TalbotG commented Jun 5, 2019

emilio commented Jun 29, 2019

frivoal commented Jun 30, 2019

emilio commented Jul 1, 2019

frivoal commented Jul 26, 2019