Open Bug 1918740 Opened 5 days ago Updated 3 days ago

<li><span><div> produces misalignment/blank line next to bullet, because the first inline part of an IB-split (block-in-inline) generates an empty-but-nonzero-height line, when in list item (li)

Categories

(Core :: Layout: Generated Content, Lists, and Counters, defect)

defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Attached file testcase 1

STR:

  1. Load attached testcase.
  2. Look at the first chunk.

ACTUAL RESULTS:
The bullet has a blank line next to it, and the "Block-in-inline" text is pushed down to the next line.

EXPECTED RESULTS:
"Block-in-inline" text should be next to the bullet.

NOTES:
The top half of the testcase is testing an IB-split situation inside of a list-item, where this shows the problem.
The bottom half of the testcase is testing the same situations but not in a list-item; those are fine.

This is causing misalignment on a documentation page at Pinterest; see bug 1879879.

Comparing old browser versions to see the history of this compat difference:
A) Gecko: Our behavior here goes back ages; Firefox Nightly 4.0b9pre 2011-01-01 matches current Nightly.
B) EdgeHTML: Pre-chromium EdgeHTML (in Edge 18) also matches current Firefox Nightly.
C) Safari: Safari version 4.0 matches current WebKit/Blink.
D) Chrome: Chrome 16 matches current WebKit/Blink.
E) Opera: Pre-chromium Presto (Opera 12.15) matches current WebKit/Blink.

So: in the olden days where we had two more rendering engines (EdgeHTML and Presto), one agreed with Firefox, and the other agreed with WebKit.

Not sure offhand who's correct; it might be that there are arcane reasons why our cosmetically-unappearling result is correct, due to the details of how lists are represented in the css specs (which browser have lived up to to varying degrees over time, but IIRC we're the closest).

Comparing the frame-tree-in-css-pixels from the first chunk in the top half (li) vs. bottom half (no li) of my testcase, it looks like the relevant difference is that the first line (that wraps the empty Inline(span)) gets a height h=23 vs h=0 (near the right edge of the second line in the snippets below). In both cases, the inline(span) has h=23 and the scr-overflow is nonzero, but only with li do we end up with a nonzero h on the line's rect itself (the first x,y,w,h shown on the line of the frame dump).

With li:

Block(li)(0)@721b50dd3c88 parent=721b50dd3bd0 (x=40, y=0, w=966, h=46) ink-overflow=(x=-15.3667, y=0, w=981.367, h=46) scr-overflow=(x=-15.3667, y=0, w=981.367, h=46) [content=721b4db04670] [cs=721b50dcdf08] <
  line@721b50dd42f8 count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=0, y=0, w=0, h=23) ink-overflow=(x=-15.3667, y=4.5, w=15.3667, h=15) scr-overflow=(x=-15.3667, y=4.5, w=15.3667, h=15) <
    Inline(span)(0)@721b50dd3ee8 parent=721b50dd3c88 next=721b50dd4138 IBSplitSibling=721b50dd4138 (x=0, y=0, w=0, h=23) [content=721b4db04700] [cs=721b50dce108] <
    >
  >
  line@721b50dd4348 count=1 state=block,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=0, y=23, w=966, h=23) <
    Block(span)(0)@721b50dd4138 parent=721b50dd3c88 next=721b50dd4240 IBSplitSibling=721b50dd4240 IBSplitPrevSibling=721b50dd3ee8 (x=0, y=23, w=966, h=23) [content=721b4db04700] [cs=721b50dce808:-moz-block-inside-inline-wrapper] <
      line@721b50dd41f0 count=1 state=block,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=0, y=0, w=966, h=23) <
        Block(div)(0)@721b50dd3f90 parent=721b50dd4138 (x=0, y=0, w=966, h=23) [content=721b4db04790] [cs=721b50dce308] <
          line@721b50dd40e8 count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=0, y=0, w=111.667, h=23) <
            Text(0)"Block-in-inline"@721b50dd4048 parent=721b50dd3f90 (x=0, y=0, w=111.667, h=23) [content=721b4db06200] [cs=721b50dce708:-moz-text] [run=721b5392a580][0,15,T] 

Without li:

Block(div)(8)@721b50de8930 parent=721b50dd3a10 next=721b50de8ed8 (x=0, y=139, w=1008, h=25) [content=721b4db04dc0] [cs=721b50dcda08] <
  line@721b50de8de8 count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=1, y=1, w=0, h=0) ink-overflow=(x=1, y=-17, w=0, h=0) scr-overflow=(x=1, y=-17, w=0, h=23) <
    Inline(span)(1)@721b50de89e8 parent=721b50de8930 next=721b50de8c38 IBSplitSibling=721b50de8c38 (x=1, y=-17, w=0, h=23) [content=721b4db04e50] [cs=721b50dcdd08] <
    >
  >
  line@721b50de8e38 count=1 state=block,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=1, y=1, w=1006, h=23) <
    Block(span)(1)@721b50de8c38 parent=721b50de8930 next=721b50de8d40 IBSplitSibling=721b50de8d40 IBSplitPrevSibling=721b50de89e8 (x=1, y=1, w=1006, h=23) [content=721b4db04e50] [cs=721b50dced08:-moz-block-inside-inline-wrapper] <
      line@721b50de8cf0 count=1 state=block,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=0, y=0, w=1006, h=23) <
        Block(div)(0)@721b50de8a90 parent=721b50de8c38 (x=0, y=0, w=1006, h=23) [content=721b4db04ee0] [cs=721b50dce008] <
          line@721b50de8be8 count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=0, y=0, w=111.667, h=23) <
            Text(0)"Block-in-inline"@721b50de8b48 parent=721b50de8a90 (x=0, y=0, w=111.667, h=23) [content=721b4db06900] [cs=721b50dcec08:-moz-text] [run=721b53941640][0,15,T] 
Summary: <li><span><div> produces misalignment/blank line next to bullet, becasue the first inline part of an IB-split (block-in-inline) generates an empty-but-nonzero-height line, when in list item (li) → <li><span><div> produces misalignment/blank line next to bullet, because the first inline part of an IB-split (block-in-inline) generates an empty-but-nonzero-height line, when in list item (li)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: