1322986 - Orthogonal inline-blocks should use the margin-box edges as synthesized baseline

Status: RESOLVED INVALID

(Core :: Layout: Block and Inline, defect)

Description

[Javier Fernandez]

Attachment: inline-blocks-orthogonal.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20161115214506

Steps to reproduce:

1- load the attached test case


Actual results:

Only vertical RL uses correctly the synthesized baseline; the vertical RL container uses margin logical top, instead.



Expected results:

Both, vertical LR and RL containers should use their children margin-box logical bottom as synthesized baseline.

Comment 1

[Javier Fernandez]

I already filed the same bug in Chromium, see http://crbug.com/673295.

Comment 2

[Gérard Talbot]

Javier,

1- Can you confirm what your description of actual results is? Over here, it seems contradictory.

2- Can you create a reduced test from your current test and also create a reference file for such reduced test?

3- Please explain the 'text-orientation: sideways' declaration inside the test. Does the test pass, according to you, if 'text-orientation: mixed' is used instead?

4- Can you confirm that test current test (or eventual reduced test) fails in the latest Firefox nightly (Firefox 53.0a1 buildID=20161214030231)?

Gérard

Comment 3

[Javier Fernandez]

Attachment: inline-block-orthogonal-result.png

Comment 4

[Javier Fernandez]

Attachment: inline-block-orthogonal-expected.png

Comment 5

[Javier Fernandez]

Attachment: inline-blocks-orthogonal-reduced.html

Comment 6

[Javier Fernandez]

Attachment: inline-blocks-orthogonal-reduced-expected.html

Comment 7

[Javier Fernandez]

(In reply to Gérard Talbot from comment #2)
> Javier,
> 
> 1- Can you confirm what your description of actual results is? Over here, it
> seems contradictory.
> 

I've just updated and built last trunk and loaded the attached test case. The pictures
xxx-result.png and xxx-expected.png (generated using my own patched Chrome) describe
the issue.

Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0

changeset:   325877:18b5a7a5d833
tag:         tip
fxtree:      central
parent:      325835:126c324672ea
parent:      325876:dd390860c6c9
user:        Carsten "Tomcat" Book <[e-mail]>
date:        Wed Dec 14 16:41:28 2016 +0100
summary:     merge mozilla-inbound to mozilla-central a=merge


> 2- Can you create a reduced test from your current test and also create a
> reference file for such reduced test?
> 

Attached xxx-reduced-html and xxx-reduced-expected.html. It's not that easy
to define a good reference file, since the baseline depends a lot on the
font and platform. I managed to do something by adding custom margins to the
expected file. I hope it's useful to illustrate better the issue.


> 3- Please explain the 'text-orientation: sideways' declaration inside the
> test. Does the test pass, according to you, if 'text-orientation: mixed' is
> used instead?
> 

The behavior seems correct when using 'text-orientation: mixed'. I can only
suppose that the reason is that mixed implies using central baseline, as it's
stated in the spec:

https://drafts.csswg.org/css-writing-modes-3/#text-baselines
In vertical typographic mode, the central baseline is used as the dominant baseline when text-orientation is mixed or upright. Otherwise the alphabetic baseline is used. 

The central baseline, even when it's synthesized, is less sensible to the writing-mode.
When forcing the alphabetic baseline, by using 'text-orientation: sideways', the effect
of the writing mode is more noticeable.

> 4- Can you confirm that test current test (or eventual reduced test) fails
> in the latest Firefox nightly (Firefox 53.0a1 buildID=20161214030231)?
> 

Same result than in trunk. Attached, nightly-53.0a1.png picture.

Comment 8

[Javier Fernandez]

Attachment: nightly-53.0a1.png

Comment 9

[Gérard Talbot]

> > Javier,
> > 
> > 1- Can you confirm what your description of actual results is? Over here, it
> > seems contradictory.
> > 
> 
> I've just updated and built last trunk and loaded the attached test case.
> The pictures
> xxx-result.png and xxx-expected.png (generated using my own patched Chrome)
> describe
> the issue.

I believe you originally meant to say

Only vertical RL uses correctly the synthesized baseline; the vertical *_LR_* container uses margin logical top, instead. 

and not RL.


> > 2- Can you create a reduced test from your current test and also create a
> > reference file for such reduced test?
> > 
> 
> Attached xxx-reduced-html and xxx-reduced-expected.html. It's not that easy
> to define a good reference file, since the baseline depends a lot on the
> font and platform. 

Once we get a reduced test, then we use Ahem font, downloadable from
https://www.w3.org/Style/CSS/Test/Fonts/Ahem/
to create tests for the writing-modes test suite. With the Ahem font, we control accurately (and predictably) baseline alignment issues. I believe all tests involving baseline-alignment in writing-modes test suite use Ahem font.


> I managed to do something by adding custom margins to the
> expected file. I hope it's useful to illustrate better the issue.
 

It is useful. Thanks for creating the reduced tests and reference files.

 
> > 3- Please explain the 'text-orientation: sideways' declaration inside the
> > test. Does the test pass, according to you, if 'text-orientation: mixed' is
> > used instead?
> > 
> 
> The behavior seems correct when using 'text-orientation: mixed'. 

I agree, the behavior is correct when using 'text-orientation: mixed'.

One thing that is crucial with your bug report and tests is that, in 'vertical-lr' writing-mode, the baseline for 'text-orientation: sideways' is on the physical left side or, if you wish, the line-under 
https://drafts.csswg.org/css-writing-modes-3/#line-under
side is on the left side.

https://drafts.csswg.org/css-writing-modes-3/diagrams/text-flow-vectors-lr-reverse.png

Line box direction is rightwarded or from left to right. But the descent side is on the left while the ascent side is on the right. That is why I am enclined to believe that the baseline should be the (physical) margin left edge of those div class="item" inline-blocks, in which case your tests, including the vertical-lr ones, are rendered as expected and do not display a bug. My opinion will have to be confirmed by Elika 'fantasai' Etemad or Koji Ishii, the spec editors.
This may be easier to see out if/when you toggle OFF the 'width: 200px' in your reduced test ( attachment 8818668 [details] ). 

By the way, I believe such 'width: 200px' does not "help" your tests, is not needed in your tests. When you set 'width: 200px', you are *_not_* setting the line box height.

There is also another problem with all your tests: you normally add 1 glyph before and after (like "a" and "z" in the example of following document) the inline-blocks so that you can see how they align with the tested inline-blocks. It's difficult to explain quickly and accurately why this is needed for baseline-alignment testing but this document

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/inline-block-minimal-code-2.html

has an inline-block with block descendants without content example. Also this test

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/vertical-align-baseline-004a.htm

does it with glyphs after.

+CC: Koji Ishii and Elika Etemad

Comment 10

[Javier Fernandez]

Hi, 

(In reply to Gérard Talbot from comment #9)
> 
> One thing that is crucial with your bug report and tests is that, in
> 'vertical-lr' writing-mode, the baseline for 'text-orientation: sideways' is
> on the physical left side or, if you wish, the line-under 
> https://drafts.csswg.org/css-writing-modes-3/#line-under
> side is on the left side.
> 

Oh, this is indeed a good point. Thanks for pointing it out, I totally missed it. 
I've been always thinking on top/above terms, while under/over seems to imply a 
different concept.  I've been assuming that baseline is synthesized with the *bottom*
edge of the margin box (border-box in case of grid and flex). As far as I know, this 
is the right edge in vertical-lr. 

> https://drafts.csswg.org/css-writing-modes-3/diagrams/text-flow-vectors-lr-
> reverse.png
> 
> Line box direction is rightwarded or from left to right. But the descent
> side is on the left while the ascent side is on the right. That is why I am
> enclined to believe that the baseline should be the (physical) margin left
> edge of those div class="item" inline-blocks, in which case your tests,
> including the vertical-lr ones, are rendered as expected and do not display
> a bug. My opinion will have to be confirmed by Elika 'fantasai' Etemad or
> Koji Ishii, the spec editors.
> This may be easier to see out if/when you toggle OFF the 'width: 200px' in
> your reduced test ( attachment 8818668 [details] ). 
> 

I think part of my confusion came from this thread, which was
related to synthesizing baselines for grid:

https://github.com/w3c/csswg-drafts/issues/373#issuecomment-242863486

Now that we ask for confirmation to 'fantasai' it'd be great to clarify if
this grid and flexbox will have the same behavior. 

> By the way, I believe such 'width: 200px' does not "help" your tests, is not
> needed in your tests. When you set 'width: 200px', you are *_not_* setting
> the line box height.
> 
> There is also another problem with all your tests: you normally add 1 glyph
> before and after (like "a" and "z" in the example of following document) the
> inline-blocks so that you can see how they align with the tested
> inline-blocks. It's difficult to explain quickly and accurately why this is
> needed for baseline-alignment testing but this document
> 
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/inline-block-
> minimal-code-2.html
> 
> has an inline-block with block descendants without content example. Also
> this test
> 
> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/vertical-align-
> baseline-004a.htm
> 
> does it with glyphs after.
> 
> +CC: Koji Ishii and Elika Etemad

Oh. I see, Thanks for the info. I'll check out those tests.

Comment 11

[Gérard Talbot]

> I've been always thinking on top/above terms, while under/over seems to
> imply a 
> different concept.  I've been assuming that baseline is synthesized with the
> *bottom*
> edge of the margin box (border-box in case of grid and flex). As far as I
> know, this 
> is the right edge in vertical-lr. 

The logical bottom edge of the margin box in vertical-lr writing-mode is the left side. The descender side in vertical-lr writing-mode is the left side.
The logical bottom edge of the margin box in vertical-rl writing-mode is also the left side.
The descender side in vertical-lr writing-mode is also the left side.

In §6.3. Line-relative Directions
https://drafts.csswg.org/css-writing-modes-3/#line-directions
there is an SVG image describing "Line orientation in vertical-rl, vertical-lr, and sideways-rl". §6.4 also has a table with such information.

Comment 12

[Javier Fernandez]

(In reply to Gérard Talbot from comment #11)
> > I've been always thinking on top/above terms, while under/over seems to
> > imply a 
> > different concept.  I've been assuming that baseline is synthesized with the
> > *bottom*
> > edge of the margin box (border-box in case of grid and flex). As far as I
> > know, this 
> > is the right edge in vertical-lr. 
> 
> The logical bottom edge of the margin box in vertical-lr writing-mode is the
> left side. The descender side in vertical-lr writing-mode is the left side.
> The logical bottom edge of the margin box in vertical-rl writing-mode is
> also the left side.
> The descender side in vertical-lr writing-mode is also the left side.
> 
> In §6.3. Line-relative Directions
> https://drafts.csswg.org/css-writing-modes-3/#line-directions
> there is an SVG image describing "Line orientation in vertical-rl,
> vertical-lr, and sideways-rl". §6.4 also has a table with such information.

Oh, yes, I see it now. 
Then I think the bug is invalid, indeed. Sorry for the noise. 
These cases when dealing with orthogonal boxes cause me a lot of confusion. Actually, 
one of the reasons to use a fixed width is to detect how the horizontal blocks are
aligned in the vertical-lr or vertical-rl container. When I saw blocks left aligned
in vertical-lr container I assumed top (left) bottom (right). 

Anyway, the spec is pretty clear about the under/over logical directions, so I guess
the current implemented behavior is correct.

Comment 13

[Gérard Talbot]

(In reply to Javier Fernandez from comment #12)
> (In reply to Gérard Talbot from comment #11)
> > > I've been always thinking on top/above terms, while under/over seems to
> > > imply a 
> > > different concept.  I've been assuming that baseline is synthesized with the
> > > *bottom*
> > > edge of the margin box (border-box in case of grid and flex). As far as I
> > > know, this 
> > > is the right edge in vertical-lr. 
> > 
> > The logical bottom edge of the margin box in vertical-lr writing-mode is the
> > left side. The descender side in vertical-lr writing-mode is the left side.
> > The logical bottom edge of the margin box in vertical-rl writing-mode is
> > also the left side.
> > The descender side in vertical-lr writing-mode is also the left side.
> > 
> > In §6.3. Line-relative Directions
> > https://drafts.csswg.org/css-writing-modes-3/#line-directions
> > there is an SVG image describing "Line orientation in vertical-rl,
> > vertical-lr, and sideways-rl". §6.4 also has a table with such information.
> 
> Oh, yes, I see it now. 
> Then I think the bug is invalid, indeed. Sorry for the noise. 
> These cases when dealing with orthogonal boxes cause me a lot of confusion.
> Actually, 
> one of the reasons to use a fixed width is to detect how the horizontal
> blocks are
> aligned in the vertical-lr or vertical-rl container. When I saw blocks left
> aligned
> in vertical-lr container I assumed top (left) bottom (right). 
> 
> Anyway, the spec is pretty clear about the under/over logical directions, so
> I guess
> the current implemented behavior is correct.

Okay. -CC: Koji Ishii and Elika Etemad 

Resolving accordingly then