Open Bug 1386541 Opened 7 years ago Updated 2 years ago

Baseline of inline-block in orthogonal vertical flow must be its bottom margin edge

Categories

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

defect

Tracking

()

Tracking Status
firefox57 --- wontfix

People

(Reporter: rego, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome, parity-edge, testcase)

Attachments

(2 files)

Attached file vertical-block-baseline-margin.html (deleted) —
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.13 Safari/537.36 Steps to reproduce: Use a vertical/orthogonal block with bottom margin to calculate the baseline. Open the attached example to reproduce the issue. Actual results: Baseline doesn't include the bottom margin. In the example 3) you can see the bottom margin is ignored. Expected results: It should have included the bottom margin like it does for images or empty blocks. The text from the spec (https://drafts.csswg.org/css-align-3/#baseline-export): > inline-level boxes synthesize from their margin edges Check the output in Chrome which seems right.
Component: Untriaged → Layout
Product: Firefox → Core
Version: 54 Branch → Trunk
Blocks: 1136521
Blocks: 1079125
No longer blocks: 1136521
" The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has (...) no in-flow line boxes (...) in which case the baseline is the bottom margin edge. " CSS2.x, section 10.8.1 Leading and half-leading https://www.w3.org/TR/CSS21/visudet.html#leading https://www.w3.org/TR/CSS22/visudet.html#leading Manuel Rego Casasnovas, In your test, your inline-blocks have no in-flow line boxes. So, I am inclined to think your analysis is correct. - - - - - - - I have examined the tests submitted and we have several tests involving inline-blocks and orthogonal flow (eg http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/orthogonal-parent-shrink-to-fit-001a.htm ) but none like yours. - - - - - - - Also, if I add 'margin-bottom: 1em' to the inline-blocks (which have descendant blocks; that is the main difference with your test in this bug report) in orthogonal flow in this test http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/baseline-alignment-inline-block-ortho-flow.html then such bottom margin is not rendered; Chrome 60+ renders such bottom margin though. But since line boxes in orthogonal flow can not have for practical reasons a baseline, then the "in which case ..." clause should apply. So, in my opinion, Chrome 60+ is correct and Firefox 54+ is wrong. And the same reasoning should apply to inline-table in orthogonal flow: "The baseline of an 'inline-table' is the baseline of the first row of the table.". Baseline-aligning an inline-table according to the baseline of its first row makes no sense if/when the inline-table is in orthogonal flow.
I've changed the summary line to: Baseline of inline-block in orthogonal vertical flow must be its bottom margin edge The corrolary of this would be: Baseline of inline-block in orthogonal horizontal flow must be its left margin edge for 'vertical-rl', 'vertical-lr' and 'sideways-rl' writing modes Baseline of inline-block in orthogonal horizontal flow must be its right margin edge for 'sideways-lr' writing mode Baseline of inline-table in orthogonal vertical flow must be its bottom margin edge Baseline of inline-table in orthogonal horizontal flow must be its left margin edge for 'vertical-rl', 'vertical-lr' and 'sideways-rl' writing modes Baseline of inline-table in orthogonal horizontal flow must be its right margin edge for 'sideways-lr' writing mode
Summary: Vertical/orthogonal block baseline doesn't include bottom margin → Baseline of inline-block in orthogonal vertical flow must be its bottom margin edge
I will create a set of tests which I intend to submit eventually to the Writing Modes test suite. This may take 1-2 months for several reasons. Marking as NEW
Status: UNCONFIRMED → NEW
Component: Layout → Layout: Block and Inline
Ever confirmed: true
Keywords: testcase
OS: Unspecified → All
Hardware: Unspecified → All
Manuel Rego Casasnovas, If I add the 'writing-mode: vertical-rl' declaration to the image in your 1) sub-test, then the vertical gap is "lost", the vertical gap disappears in Firefox 54 while it remains rendered in Chrome 60. Again, Firefox is wrong and Chrome is correct. So, that is another sub-set of tests that I will do. - - - - - - - - 6 code scenarios: baseline of vertical inline-block in orthogonal horizontal flow must be its left margin edge baseline of horizontal inline-block in orthogonal vertical flow must be its bottom margin edge baseline of inline-block with 'writing-mode' set to 'sideways-lr' in orthogonal horizontal flow must be its right margin edge baseline of inline-table in orthogonal horizontal flow must be its left margin edge baseline of inline-table in orthogonal vertical flow must be its bottom margin edge baseline of inline-table with 'writing-mode' set to 'sideways-lr' in orthogonal horizontal flow must be its right margin edge and 4 types of inline-block scenarios: a) inline-block has 2 descendant blocks b) inline-block has no descendant block but has text content c) inline-block has no descendant block and no content but just formating content declarations d) inline followed with image that is in orthogonal flow implies 24 tests for complete coverage.
Whiteboard: [parity-Chrome][parity-Edge]
Additional draft tests that Firefox 57.0a1 buildID=20170810100255 fails: Baseline of vertical (sideways-ed) inline-block with margin-bottom, in orthogonal flow - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-block-orthog-vertical-flow-009.xht http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-block-orthog-vertical-flow-010.xht http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-block-orthog-vertical-flow-011.xht Baseline of vertical (sideways-ed) inline replaced with margin-bottom, in orthogonal flow - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-replaced-orthog-vertical-flow-012.xht Baseline of vertical inline-table with margin-bottom, in orthogonal flow - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-table-orthog-vertical-flow-013.xht http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-table-orthog-vertical-flow-014.xht http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-table-orthog-vertical-flow-015.xht Baseline of vertical (sideways-ed) inline-table with margin-bottom, in orthogonal flow - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-table-orthog-vertical-flow-021.xht http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-table-orthog-vertical-flow-022.xht http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-table-orthog-vertical-flow-023.xht Reference file -------------- http://www.gtalbot.org/BugzillaSection/Bug1386541-inline-block-orthog-vertical-flow-001-ref.xht Do not bookmark any of those tests as I may filename-rename them later. And they will have different filenames when I submit them to the CSS Writing Modes test suite. Note: the sideways-ed tests will often fail in Chrome 62 and in Edge 16 because such browsers do not support 'writing-mode: sideways-lr'. See https://bugs.chromium.org/p/chromium/issues/detail?id=680331 and https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/17059573-implement-sideways-rl-and-sideways-lr-values-for-c
Priority: -- → P3
The wording of the description of several sentences is wrong or awkward. It is difficult to describe with words. But I can correct a few. - - - - - - - - > In your test, your inline-blocks have no in-flow line boxes. Only your 2) sub-test has no in-flow line boxes. - - - - - - - - > then such bottom margin [in Firefox] is not rendered; Chrome 60+ renders such > bottom margin though. I should have written instead: then such bottom margin in Firefox is not rendered correctly. Chrome 60+ renders such bottom margin at the inline formating context of the wrapper. - - - - - - - - > line boxes in orthogonal flow can not have for practical reasons a baseline, inline-block and inline-table in orthogonal flow have a baseline (according to section 10.8.1) but, when inline-formatted inside their orthogonal wrapper, they must be baseline-aligned according to the margin edge which "sits", which is on the line-over side of its orthogonal wrapper. - - - - - - - - > baseline of vertical inline-block in orthogonal horizontal flow must be its left margin edge > baseline of horizontal inline-block in orthogonal vertical flow must be its bottom margin edge (...) > baseline of inline-table in orthogonal horizontal flow must be its left margin edge > baseline of inline-table in orthogonal vertical flow must be its bottom margin edge These 4 descriptions are misworded, incorrect. It should have been the opposite baseline (for inline formating purposes) of vertical inline-block in orthogonal horizontal flow must be its physical bottom margin edge (logical right margin edge) baseline (for inline formating purposes) of horizontal inline-block in orthogonal vertical flow must be its physical left margin edge (logical left margin edge) (...) baseline (for inline formating purposes) of vertical inline-table in orthogonal horizontal flow must be its physical bottom margin edge (logical right margin edge) baseline (for inline formating purposes) of horizontal inline-table in orthogonal vertical flow must be its physical left margin edge (logical left margin edge)
[marking wontfix for 57 (current beta) since this isn't a regression and since we're only taking low-risk/extremely-severe patches for that release at this point]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-Chrome][parity-Edge]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: