54979 - marker box should be part of first line box (or should create one if block is text-less) (list-item ::marker) [LIST] [MARGIN-C] [INLINE-V]

Status: NEW

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

Description

[Hixie (not reading bugmail)]

Per CSS2, the bullet cause by a list-item should be the :before pseudo-element,
with a display value of 'marker'. This means the bullet should take part in the
inline box model, and in particular should be part of the first line box of the
associated block. If there is no such line box, it should create one.

See http://www.w3.org/TR/REC-CSS2/generate.html#q11

Here is a relevant excerpt:
#
# For the :before pseudo-element, the baseline of text in the marker box will 
# be vertically aligned with the baseline of text in the first line of content 
# in the principal box. If the principal box contains no text, the top outer 
# edge of the marker box will be aligned with the top outer edge of the 
# principal box. For the :after pseudo-element, the baseline of text in the 
# marker box will be vertically aligned with the baseline of text in the last 
# line of content in the principal box. If the principal box contains no text, 
# the bottom outer edge of the marker box will be aligned with the bottom outer 
# edge of the principal box. 
# 
# The height of a marker box is given by the 'line-height' property. 
# The :before (:after) marker box participates in the height calculation of the 
# principal box's first (last) line box. Thus, markers are aligned with the 
# first and last line of an element's content, even though the marker boxes 
# live in distinct line boxes. If no first or last line box exists in a 
# principal box, the marker box establishes its line box alone. 

We need to map list-item properties into :before as per the spec, by supporting
display:marker and making everything Just Work. This will then fix bug 50480
the Right Way.

When fixing this, the interpretation of 'marker-offset' I propose in bug 54644,
or a better interpretation chosen by the WG, should be used instead of the
specification's definition. See bug 54644 for details.

See also:
 related bug 39013: list-item marker disappears when using "position: relative;"
 invalid bug 38832: Nested List symbol renders on same line as parent symbol 
blocking bug 14983: 'display:marker' not supported
     dep bug 21562: List markers are not properly aligned
 related bug 50480: list-item marker of link list overlaps 
 related bug 54644: -moz-float-edge sucks, should be taken out and shot

Comment 1

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 2

[Hixie (not reading bugmail)]

*** Bug 162170 has been marked as a duplicate of this bug. ***

Comment 3

[Boris Zbarsky [:bzbarsky]]

.

Comment 4

[Lina Kemmel]

Sorry if the following comment is irrelevant, but it looks like according to the
CSS2 spec
- http://www.w3.org/TR/REC-CSS2/generate.html#propdef-marker-offset -
vs. other elements, markers create a separate line box:

"While 'block' and 'inline' :before and :after content is part of the principal
box generated by the element, 'marker' content is formatted in an independent
marker box, outside the principal box. Marker boxes are formatted as a single
line (i.e., one line box), so they are not as flexible as floats."

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

FWIW, see http://www.w3.org/TR/css3-lists/#markers for the current WG thinking
on markers.

Comment 6

[Mats Palmgren (inactive)]

*** Bug 276971 has been marked as a duplicate of this bug. ***

Comment 7

[Philip flip Kromer]

Linking to the current active bugs on this subject: display: marker won't be
implemented (https://bugzilla.mozilla.org/show_bug.cgi?id=14983) -- instead
mozilla will eventually "Support CSS3's ::marker pseudo element"
(https://bugzilla.mozilla.org/show_bug.cgi?id=205202).

When 205202 is fixed you'll have proper positioning, etc of the LI marker.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So, if there's a child block, it should really be associated with the first line of that in some cases.  I think the spec now even says which ones.

Note that this line box is needed so that functions like nsLayoutUtils::GetFirstLineBaseline and nsLayoutUtils::GetLastLineBaseline can align to the line created by the bullet (e.g., for an empty display:list-item element in a baseline-aligned table row or in an inline-block).