New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: May 22
Cc:
Components:
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 na...@moon.email.ne.jp, May 20

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 https://jsfiddle.net/s2hfvqf4/ 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: 
[1] 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.
 
20180520-principal-writing-mode.html
954 bytes View Download
Labels: Needs-Triage-M68
Cc: susan.boorgula@chromium.org
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
Owner: mstensho@chromium.org
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.

https://chromium.googlesource.com/chromium/src/+log/93846275952fa28f83a4ea318e56c4f494bf7005..334b4846828ceb697785b466619a1f1b96592a3b

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/548379

As rune@opera.com and meade@chromium.org 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.

Thanks
Cc: mstensho@chromium.org
Labels: OS-iOS
Owner: futhark@chromium.org
rune@opera.com -> futhark@chromium.org
Cc: -mstensho@chromium.org futhark@chromium.org
Components: -Blink>CSS Blink>Layout
Owner: mstensho@chromium.org
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.

[1] https://drafts.csswg.org/css-writing-modes-3/#principal-flow
[2] https://www.w3.org/TR/css-writing-modes-3/#orthogonal-flows

Gecko's bug about "writing-mode: vertical-rl" applied to a body element is https://bugzilla.mozilla.org/show_bug.cgi?id=1102175

I was wrong about "the principal writing mode is not taken from a body element." In https://jsfiddle.net/agc3zjcz/ 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].

[1] https://chromium-review.googlesource.com/c/chromium/src/+/548379#message-a11ea5acd18a4e71a9c516df1a9bda999e7d9ce5
> There should be no difference whether author sets writing-mode to html or body

[2] https://chromium-review.googlesource.com/c/chromium/src/+/548379#message-65020cacbb47a82cf52947e33131203ff0a343af
> "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