Baselines of inline-block and inline-table do not respect the last line box or the first row if 'writing-mode' is 'vertical-lr'.
Reported by
babata...@gmail.com,
Nov 11 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2915.0 Safari/537.36 Example URL: http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/inline-block-alignment-003/format/html5/ Steps to reproduce the problem: 1. Run any of following tests (inline-block) http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/inline-block-alignment-003/format/html5/ http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/inline-block-alignment-005/format/html5/ (inline-table) http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/inline-table-alignment-003/format/html5/ http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/inline-table-alignment-005/format/html5/ What is the expected behavior? The "Test Case" tab matches to the "Reference Page". What went wrong? It does not match. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? No Edge 38.14393.0.0, Firefox Nightly 52.0a1 Chrome version: 56.0.2915.0 Channel: canary OS Version: 10.0 Flash Version: When 'writing-mode' is 'vertical-lr' and 'text-orientation' is 'mixed' or 'upright', then the central baseline should be used as the dominant baseline. In the test case, the central baseline of 'div#inline-block' should be center of the blue square, as defined by [1]. Also, the central baseline of 'div#inline-table' should be center of the blue square [2]. However, the orange squares are not aligned to the blue square. https://drafts.csswg.org/css21/visudet.html#propdef-vertical-align [1] "The baseline of an 'inline-block' is the baseline of its last line box in the normal flow" [2] "The baseline of an 'inline-table' is the baseline of the first row of the table." Note that this issue does not occur if 'writing-mode' is 'vertical-rl'.
,
Nov 11 2016
This is the screenshot. The "Reference page" is the expected result, and the "Test case" is the actual test case. Results of both chrome and firefox are incorrect. (This test requires "Ahem" font. Please download and install it from https://www.w3.org/Style/CSS/Test/Fonts/Ahem/ )
,
Nov 14 2016
Labeling accordingly for someone from the respective team to have a look at this and confirm the correct behavior. On older chrome version:30.0.1549.0 as well, the 'TestCase' and 'Reference page' tab doesn't match. Issue is seen on the latest canary(56.0.2918.0) of Mac OS 10.11.6 and Linux Ubuntu 14.04 as well.
,
Nov 15 2016
,
Nov 16 2016
,
Nov 16 2016
,
Dec 14 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e2226caaef64115627bddea776cac031d065fd5a commit e2226caaef64115627bddea776cac031d065fd5a Author: jfernandez <jfernandez@igalia.com> Date: Wed Dec 14 13:39:03 2016 Use logicalBottom when computing baselines in vertical-lr inline-blocks When computing the baseline position of inline-block elements we use the InlineFlow logicalTop and the FontMetrics ascent. The issue comes from the fact that these units are incompatible. The logicalTop of a vertical-lr element is offset to the left edge, while the ascent is the distance from the right edge. We need to either use logical value for the FontMetrics ascent so we can compute the correctly the baselines of vertical-lr elements, or just using the logicalBottom for these cases. The approach based on a logicalAscent API for FontMetrics would require a lot of work because inline-block logic assumes everything is vertical-rl and at some point, flips the elements along the block-axis in case of vertical-lr mode. While it'd be desirable to get rid of this flipping logic, this patch tries first the simpler approach of using logicalBottom, which aligns with the currently implemented logic. BUG=664386 Review-Url: https://codereview.chromium.org/2523573003 Cr-Commit-Position: refs/heads/master@{#438502} [add] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/fast/inline-block/baseline-vertical.html [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/linux/fast/backgrounds/background-leakage-transforms-expected.txt [add] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/linux/fast/inline-block/baseline-vertical-expected.png [add] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/linux/fast/inline-block/baseline-vertical-expected.txt [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/linux/fast/writing-mode/border-styles-vertical-lr-expected.txt [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/mac/fast/backgrounds/background-leakage-transforms-expected.txt [add] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/mac/fast/inline-block/baseline-vertical-expected.png [add] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/mac/fast/inline-block/baseline-vertical-expected.txt [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/mac/fast/writing-mode/border-styles-vertical-lr-expected.txt [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/win/fast/backgrounds/background-leakage-transforms-expected.txt [add] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/win/fast/inline-block/baseline-vertical-expected.png [add] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/win/fast/inline-block/baseline-vertical-expected.txt [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/win/fast/writing-mode/border-styles-vertical-lr-expected.txt [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/win/fast/writing-mode/japanese-ruby-vertical-lr-expected.png [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/win/fast/writing-mode/japanese-ruby-vertical-lr-expected.txt [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/win7/fast/writing-mode/japanese-ruby-vertical-lr-expected.png [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/LayoutTests/platform/win7/fast/writing-mode/japanese-ruby-vertical-lr-expected.txt [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/Source/core/layout/LayoutBlock.cpp [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp [modify] https://crrev.com/e2226caaef64115627bddea776cac031d065fd5a/third_party/WebKit/Source/core/layout/line/InlineFlowBox.cpp
,
Dec 15 2016
I've been investigating this issue for a while. My patch landed in the CL https://crrev.com/2523573003 does not solve the cases initially reported in this issue. The difference with the ones I reported is the use of a display:block in one of the spans to be aligned. LayoutView 0x1d32f8804010 #document LayoutBlockFlow 0x1d32f881c010 HTML LayoutBlockFlow 0x1d32f881c138 BODY LayoutBlockFlow 0x1d32f881c388 P LayoutText 0x1d32f88283f8 #text "Test passes if 2 orange squares are centered with respect to a blue square." LayoutBlockFlow 0x1d32f881c4b0 DIV id="lr-mixed" LayoutText 0x1d32f88284c0 #text "A" * LayoutBlockFlow 0x1d32f881c260 DIV id="inline-block" LayoutInline 0x1d32f8828330 SPAN id="last-line-box" LayoutText 0x1d32f88281a0 #text "L" LayoutText 0x1d32f8828268 #text "\n " LayoutInline 0x1d32f88280d8 SPAN id="orange30" LayoutText 0x1d32f8828010 #text "O" versus LayoutView 0x1d32f8804010 #document LayoutBlockFlow 0x1d32f881c010 HTML LayoutBlockFlow 0x1d32f881c138 BODY LayoutBlockFlow 0x1d32f881c4b0 P LayoutText 0x1d32f88280d8 #text "Test passes if 2 orange squares are centered with respect to a blue square." LayoutBlockFlow 0x1d32f881c260 DIV id="lr-mixed" LayoutText 0x1d32f8828010 #text "A" LayoutBlockFlow 0x1d32f881c388 DIV id="inline-block" * LayoutBlockFlow 0x1d32f881c5d8 SPAN id="last-line-box" class="block-descendant" LayoutText 0x1d32f8828268 #text "L" LayoutInline 0x1d32f8828330 SPAN id="orange30" LayoutText 0x1d32f88281a0 #text "O" The issue is also related, as in the case of the cases I reported, with how we deal with vertical-lr elements in InlineFlowBox and RootInlineBox classes. The logic of assuming vertical-rl and then flipping the line elements in the block-direction is not working well with these cases, where there is a LayoutBlockFlow as container of the LayoutText, instead of a LayoutInline.
,
Feb 21 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 22 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by kkaluri@chromium.org
, Nov 11 2016Labels: Needs-Feedback
81.4 KB
81.4 KB View Download
69.7 KB
69.7 KB View Download