<body> with writing-mode: vertical-rl doesn't align children to the right

ASSIGNED
Assigned to

Status

()

Core
Layout: Block and Inline
ASSIGNED
3 years ago
5 months ago

People

(Reporter: smontagu, Assigned: jfkthame)

Tracking

(Blocks: 2 bugs, {css3, intl, testcase})

unspecified
css3, intl, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [leave open])

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
Created attachment 8525944 [details]
Testcase

When the testcase has writing-mode vertical-rl, the children should be aligned to the right edge of the viewport, as they are in Chrome and IE.

This works as expected if writing-mode is set on a wrapper div with width and height 100%, but not when it's set on the <body> element.

The testcase also shows a second bug: the <hr> appears as a single dot in vertical modes, instead of a vertical rule.
(Assignee)

Comment 1

3 years ago
(In reply to Simon Montagu :smontagu from comment #0)
> The testcase also shows a second bug: the <hr> appears as a single dot in
> vertical modes, instead of a vertical rule.

This is a direct result of how it's defined in html.css; we need to figure out how to adapt this for vertical modes:
http://hg.mozilla.org/mozilla-central/annotate/d1adecc7adad/layout/style/html.css#l602

We should tackle that in a separate bug, though.
(Reporter)

Comment 2

3 years ago
I filed bug 1102177 for the <hr> issue
(Assignee)

Comment 3

3 years ago
The <body> issue here is related to the fact that Gecko and Webkit handle the sizing of the <body> element differently. Try

    data:text/html,<body style="border:1px solid red">body

in Gecko, and note that the size of the <body>, as shown by its border, is just sufficient for its contents. On the other hand, the same testcase in Safari shows that its <body> is the full size of the browser window.
(Assignee)

Comment 4

3 years ago
Hmm, further note: the <body> sizing discrepancy noted above is specific to quirks mode. Trying

  data:text/html,<!DOCTYPE html><html style="border:1px solid blue"><body style="border:1px solid green">body

we see the same result in both Firefox and Safari. Nevertheless, with (-webkit-)writing-mode:vertical-rl applied to the <body>, Safari still right-aligns it, even though its block-size is only just enough to contain its contents.
Does Safari do similar things at a change of writing direction when the change isn't from html to body (e.g., when it's just two nested divs, with the outer being horizontal and having extra space and the inner being vertical)?
(Assignee)

Comment 6

3 years ago
(In reply to David Baron [:dbaron] (UTC-8) (needinfo? for questions) from comment #5)
> Does Safari do similar things at a change of writing direction when the
> change isn't from html to body (e.g., when it's just two nested divs, with
> the outer being horizontal and having extra space and the inner being
> vertical)?

No, in this case the inner (vertical-rl) div remains flush left within its (horizontal, wider) container.

The html/body case appears to be special. One possibly-relevant thing I notice here is that the computedStyle of the <html> element has "-webkit-writing-mode: vertical-rl", apparently "upwards inheriting" this from its <body> child.
(Reporter)

Comment 7

3 years ago
(In reply to Jonathan Kew (:jfkthame) from comment #6)
> (In reply to David Baron [:dbaron] (UTC-8) (needinfo? for questions) from
> comment #5)
> > Does Safari do similar things at a change of writing direction when the
> > change isn't from html to body (e.g., when it's just two nested divs, with
> > the outer being horizontal and having extra space and the inner being
> > vertical)?
> 
> No, in this case the inner (vertical-rl) div remains flush left within its
> (horizontal, wider) container.

Other browsers seem to be consistent about this, but I have my doubts: in the parallel case of two nested divs where the outer has dir="ltr" and the inner dir="rtl", the inner div is flush *right* in its container, and I would have expected the same to be true with a nested vertical-rl div in a horizontal container.
(Assignee)

Comment 8

3 years ago
(In reply to Simon Montagu :smontagu from comment #7)
> in
> the parallel case of two nested divs where the outer has dir="ltr" and the
> inner dir="rtl", the inner div is flush *right* in its container

Are you sure? That's not what I see (or expect).

Note that the inner div's default (initial) value for "width" is "auto", in which case it will occupy the full width available within its container, and then its *contents* will indeed be flush right by default.

But if you explicitly give the inner div a smaller width, you'll see that it stays flush *left* in its containing div, while its contents remain flush *right* inside it:

data:text/html,
  <div dir="ltr" style="border:1px solid blue; width:200px">
    <div dir="rtl" style="border:1px solid red; width:100px">test
(Assignee)

Comment 9

3 years ago
Created attachment 8531012 [details] [diff] [review]
When the root element has writing-mode:vertical-rl, make its contents flush right instead of left

Poking around in the frame tree to see where we might handle this, I've come up with this patch, which seems to give the desired behavior if writing-mode:vertical-rl is set on the root <html> element, but not if it is only set on <body>. Is this a sensible starting-point, and do we then also want to copy the Safari behavior of propagating the writing-mode upwards from <body> to the root (or should we tell authors they should be setting it on the root themselves if that's what they want)? Comments and suggestions welcome...
Attachment #8531012 - Flags: feedback?(dbaron)

Updated

3 years ago
Duplicate of this bug: 1108398

Comment 11

3 years ago
Test
----
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002.xht

Expected result
---------------
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002-ref.xht

Notes
-----
- Chrome 39.0.2171.71 passes this test.

- Firefox 37.0a1 buildID 20141202213750 fails this test.

- There are other tests that fail because of this bug

Comment 12

3 years ago
I think Component for this bug should be "Layout: Block and Inline" instead of "Layout: Text". And Version should be "Trunk".
Just my opinion here.
Keywords: css3, intl, testcase
Comment on attachment 8531012 [details] [diff] [review]
When the root element has writing-mode:vertical-rl, make its contents flush right instead of left

This seems like a reasonable start, but I think we probably do want to propagate from body (and a helper function to do so, as I suggested in bug 1071098 comment 16).
Attachment #8531012 - Flags: feedback?(dbaron) → feedback+
Component: Layout: Text → Layout: Block and Inline

Comment 14

3 years ago
Created attachment 8533502 [details]
test case demonstrating the same problem (perhaps)

Comment 15

3 years ago
Same test but this time with root element having 'writing-mode: vertical-rl':
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002-root.xht

Reference file:
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002-ref.xht
(Assignee)

Comment 16

3 years ago
Created attachment 8535490 [details] [diff] [review]
When the root element has writing-mode:vertical-rl, make its contents flush right instead of left

This doesn't address the propagation of vertical-rl mode from <body> up to the root, but it does fix the rendering when the writing mode is set on the root itself; I think we want this, regardless of how we tackle the body-to-root issue.
Attachment #8535490 - Flags: review?(smontagu)
(Assignee)

Updated

3 years ago
Attachment #8531012 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
(Assignee)

Updated

3 years ago
Blocks: 1108067

Comment 17

3 years ago
The issue of "propagation of vertical-rl mode from <body> up to the root" is a distinct, separate issue. The spec is saying

"the writing-mode property of the HTML BODY element is not propagated to the viewport."

while on the other hand

"the direction property of the HTML BODY element is not propagated to the viewport."
is a statement being reconsidered
Re: [css-writing-modes][CSS21] propagation of 'direction' from <body> (was Re: [CSSWG] Minutes Telecon 2014-07-09)
http://lists.w3.org/Archives/Public/www-style/2014Dec/0003.html
Implementors are converging interoperably toward propagating 'direction' and 'writing-mode' from body to viewport (or ICB); so issue 239 should be reopened and resolved accordingly

By the way, I take no credit and no merit for mentioning this: Elika found out about or remembered this and told me about it.

> but it does fix the rendering when the writing mode is set on the
> root itself; I think we want this, regardless of how we tackle the
> body-to-root issue.

I think you had no choice (to want or not to want this) since

"The principal writing mode of the document is determined by the writing-mode and direction values specified on the root element."

Gérard
(Reporter)

Comment 18

3 years ago
Comment on attachment 8535490 [details] [diff] [review]
When the root element has writing-mode:vertical-rl, make its contents flush right instead of left

Review of attachment 8535490 [details] [diff] [review]:
-----------------------------------------------------------------

I'd rather address this as part of the logicalization of ReflowChild and ApplyRelativePositioning (bug 1079154)
Attachment #8535490 - Flags: review?(smontagu) → review-
(Reporter)

Comment 19

3 years ago
Created attachment 8538633 [details] [diff] [review]
Reftest

This includes 2 versions of attachment 8525944 [details]: one with writing mode set on <body>, marked as failing for now, and one with writing mode set on <html>.

I tried to make a reftest from http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002-root.xht as well, but although it seems to pass with the naked eye with the patches from bug 1079154, it's a long way from pixel perfect, so I need to look at that more deeply.
Attachment #8538633 - Flags: review?(jfkthame)
(Reporter)

Updated

3 years ago
Depends on: 1079154
(Assignee)

Updated

3 years ago
Attachment #8538633 - Flags: review?(jfkthame) → review+

Comment 20

3 years ago
Reduced and specific test with root element having 'writing-mode: vertical-rl':
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s31-block-flow-direction-025.xht

Reference file:
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s31-block-flow-direction-025-ref.xht

Notes
-----
- I am using Linux 3.16.0-28-generic x86_64, KDE 4.14.1, Kubuntu 14.10 utopic, Qt 4.8.6

- Chrome 39.0.2171.95 and IE11 pass this test

- Firefox 37.0a1 buildID 20141215131330 fails this test

- The blue square unexpectedly disappears (!) in Firefox 37.0a1 buildID = 20141215131330
  when window viewport (window.innerWidth) is resized, shrunk to 825px.
(Reporter)

Comment 21

3 years ago
Checked in attachment 8538633 [details] [diff] [review] since it passes after the checkins from bug 1079154, but leaving this open for the writing-mode on <body> case (or would it be better to close this and open a new bug for that?).

https://hg.mozilla.org/integration/mozilla-inbound/rev/c8270944ab91
Flags: in-testsuite+
Whiteboard: [leave open]
https://hg.mozilla.org/mozilla-central/rev/c8270944ab91

Comment 23

3 years ago
When ICB's 'writing-mode' is 'vertical-rl', then 'right' offset value should win, should have precedence over 'left' offset value in case of an overconstrained scenario. There is nothing specifically saying such in the Writing Modes spec but, intuitively speaking, this would make sense and developers over at Chromium project think so too.

So, this test 

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/abs-overconstrained-writing-mode.html

fails in Firefox 40.0a1 buildID=20150430100104 but passes in Chrome 40+ and in IE11. 

This test is definitely an edge case; I can file a separate bug report for such single test if requested.
(Assignee)

Comment 24

3 years ago
(In reply to Gérard Talbot from comment #23)
> http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/abs-
> overconstrained-writing-mode.html

This testcase is part of position:absolute support, and will be fixed by bug 1079151.
Blocks: 1260054

Comment 25

a year ago
24 tests testing systematically combinations of conflicting body writing-mode and document root writing-mode values:

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-002.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-003.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-004.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-005.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-006.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-007.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-008.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-009.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-010.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-011.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-012.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-013.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-014.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-015.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-016.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-017.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-018.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-019.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-020.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-021.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-022.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-023.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-024.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-025.xht



Reference files for those 24 tests:

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-003-ref.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s31-block-flow-direction-025-ref.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-005-ref.xht


- - - - - - - 

Only 5 tests have been submitted to the CSSWG test repository.

Updated

a year ago
Duplicate of this bug: 1112977

Updated

5 months ago
Duplicate of this bug: 1350692
You need to log in before you can comment on or make changes to this bug.