New issue
Advanced search Search tips

Issue 845008 link

Starred by 3 users

Issue metadata

Status: WontFix
Closed: May 2018
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , iOS , Mac
Pri: 1
Type: Bug-Regression

Sign in to add a comment

The principal writing mode is not taken from a body element

Reported by, May 20 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce the problem:
Visit or see the attached file (both are the same content)

What is the expected behavior?
There is no layout difference between two iframes — whether "writing-mode: vertical-rl" is applied to a body element or an html element.

What went wrong?
There are some differences between two iframes.

* If writing-mode is applied to a body element, the right margin of the body element and the right margin of the first p element are not collapsed.
* If writing-mode is applied to a body element, p elements are not resized when the document is resized.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 68.0.3436.0  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 29.0 r0

CSS writing mode module[1] says: 

> 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.
954 bytes View Download
Labels: Needs-Triage-M68
Labels: -Type-Bug -Pri-2 hasbisect-per-revision Target-67 RegressedIn-61 M-68 FoundIn-67 Target-66 FoundIn-66 Triaged-ET FoundIn-68 Target-68 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on Windows 10, Mac OS 10.13.3, Ubuntu 14.04 on the latest Canary 68.0.3436.0 and latest Stable 66.0.3359.181 as per the original comment.

Bisect Information:
Good Build: 61.0.3143.0
Bad Build : 61.0.3144.0

By running the per-revision bisect script, below is the Changelog URL.

From the above Changelog, suspecting the below change:

As and are not in use anymore, assigning the bug to the reviewer.
mstensho@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Labels: OS-iOS
Owner: ->
Components: -Blink>CSS Blink>Layout
The expected behavior in the description is wrong as the spec clearly says that the writing mode of the root (html) element is not affected by the body writing-mode[1], so the two iframes in the test case are clearly different.

However, we render this differently from Gecko. Gecko renders the vertical-rl body on the left side of the horizontal-tb html element, while Blink renders it to the right. I suspect Gecko is right about it since it looks like positioning the box with the orthogonal flow within its container is done according to the writing-mode of the container[1]. If this difference is a bug in Blink, it is a layout issue, I think.


Gecko's bug about "writing-mode: vertical-rl" applied to a body element is

I was wrong about "the principal writing mode is not taken from a body element." In the values of `left` and `bottom` are ignored since they are over-constrained. So, the writing-mode of the initial containing block will be `vertical-rl`, which is taken from the body element.

However, I still think current Blink's behavior is something unexpected.

css-writing-modes-3 chapter 8 says:

> Note that this does not affect the values of writing-mode or direction on the root element itself.

I think this sentence means that the result of `window.getComputedStyle(document.documentElement).writingMode` is not affected by the writing-mode of a body element, as Koji Ishii said in review[1][2].

> There should be no difference whether author sets writing-mode to html or body

> "No difference" I meant "no difference other than computed value of html element.

Status: WontFix (was: Assigned)
That's not what the spec says (getComputedStyle). The spec may be unexpected, but our implementation follows what the spec and Gecko does wrt propagation. You can try to bring this up as a spec issue again, but I'll close this as wontfix now.

Regarding comment #4, after discussing with mstensho, we concluded Gecko is wrong.

Sign in to add a comment