[css-list-3] List-item outside markers

[FremyCompany]

https://drafts.csswg.org/css-lists-3/

This spec is not yet ready for implementation. It exists in this repository to record the ideas and promote discussion.

https://drafts.csswg.org/css-lists-3/#positioning

This section is not ready for implementation. It is an unreviewed rough draft that hasn’t even been properly checked for Web-compatibility.

http://www.w3.org/TR/CSS22/generate.html#propdef-list-style-position

The marker box is outside the principal block box. The position of the list-item marker adjacent to floats is undefined in CSS 2.2. CSS 2.2 does not specify the precise location of the marker box or its position in the painting order, but does require that for list items whose 'direction' property is 'ltr' the marker box be on the left side of the content and for elements whose 'direction' property is 'rtl' the marker box be on the right side of the content. The marker box is fixed with respect to the principal block box's border and does not scroll with the principal block box's content. In CSS 2.2, a UA may hide the marker if the element's 'overflow' is other than 'visible'. (This is expected to change in the future.) The size or contents of the marker box may affect the height of the principal block box and/or the height of its first line box, and in some cases may cause the creation of a new line box.

That's a lot of things left undefined. I think it's more than time to clean up this mess, and I'm glad to report it should be easier than fixing tables :)

I intend to describe at TPAC how Edge implements markers, which I think is similar to how Chrome implements it (bugs and tweaks apart) and would like to start a rewrite of the marker spec to align with this "ideal" implementation so we can all fix bugs and finally achieve interop here.

[Loirooriol]

Please also consider interaction of markers with ::first-line (#1442).

[FremyCompany]

Thanks for the heads up.

I haven't given any thought to the "inside" bullets yet since they seem mostly interoperable, but I will certainly clarify the reason behind this:

ul { color: red; list-style: outside }
li::first-line { color: green; background: yellow }

Interestingly, in Edge, the marker has green color when it has list-style-position: outside, despite theoretically being an out-of-flow content and the yellow background starting after the bullet.

[css-meeting-bot]

The Working Group just discussed Interop on List-item outside marker, and agreed to the following resolutions:

• RESOLVED: Add Francois to the Lists spec

The full IRC log of that discussion

<gregwhitworth> TOPIC: Interop on List-item outside marker
<astearns> github: https://github.com//issues/1934
<astearns> fremy projects
<gregwhitworth> fremy: more precisely the positioning of the marker
<gregwhitworth> fremy: you can center things, but it's 2017 and we still don't know where to put the bullets
<gregwhitworth> fremy: got a bug to put the bullet in the right place
<gregwhitworth> fremy: shows bug in Edge
<gregwhitworth> fantasai: wait it is spec conformant?
<gregwhitworth> dbaron: yes it is
<gregwhitworth> fremy: shows Chrome
<gregwhitworth> fremy: let's fix it
<gregwhitworth> fremy: so I started to look at the spec and it's missing
<gregwhitworth> fremy: spec isn't ready to implement
<gregwhitworth> fremy: put the 2.1 spec text and technically Edge is matching but the spec is very vague
<gregwhitworth> dbaron: I think I may have been responsible for that note
<gregwhitworth> fremy: I get the impression that nothing is defined
<gregwhitworth> dbaron: in Chrome it is inside the principal box so it violates the 2.1 text
<gregwhitworth> fremy: we want to fix this issue, but we want to spec it
<gregwhitworth> fantasai: yes
<gregwhitworth> tantek: all of those sentences come from long discussions and not agreeing
<gregwhitworth> fremy: so I'll describe how Edge is implementing this
<gregwhitworth> *fremy shows slides and he will post them a bit later*
<leaverou> since we're talking about weird bullet positioning, I'll quietly drop this Chrome & Edge issue here, in case it's relevant… http://dabblet.com/gist/3731c920fa0ee56efe3ec24a33a88964
<gregwhitworth> fremy: there are two different steps, find out which line box do you need to affect with the bullet
<gregwhitworth> fremy: then horizontally position the bullet
<gregwhitworth> fantasai: how we end up describing this, we'll need to really think about the markers - what they need to do and what they're trying to achieve typographically
<gregwhitworth> fantasai: we shouldn't need to switch the model
<iank_> q+
<astearns> ack fremy
<tantek> q?
<gregwhitworth> TabAtkins: attaching it to the first LI, and the first item may be overflow: hidden and the marker can disappear
<gregwhitworth> dbaron: that doesn't happen in Gecko because we position it to the align but it's not actually contained in that
<astearns> ack iank_
<gregwhitworth> dbaron: back when Gecko did what was in fremy feedback and when we fixed it we don't get bugs
<gregwhitworth> iank_: we're looking at re-implementing markers, our current list marker behavior is not nice
<gregwhitworth> iank_: we're doing something very similar to what you described
<TabAtkins> <li><div style="overflow:hidden">...</div> <= list marker is clipped in Chrome!
<gregwhitworth> iank_: I'll need to check with Koji, we're doing something very similar to what you described, so if you could specify it that sounds great
<gregwhitworth> fremy: that's what we want
<gregwhitworth> eae: now is the right time for us to spec this
<gregwhitworth> fremy: to reply to Tab, to have overflow: hidden we can't put it inside of a non-bfc and this is would not happen
<gregwhitworth> astearns: so what is the action?
<gregwhitworth> fremy: I wanted to know if there was interest, it seems like there is
<gregwhitworth> fremy: Sure I'll be a co-editor but I care more about interop
<gregwhitworth> RESOLVED: Add Francois to the Lists spec
<dbaron> some links to previous discussion:https://bugzilla.mozilla.org/show_bug.cgi?id=172073 https://lists.w3.org/Archives/Public/www-style/2008Feb/0116.html https://lists.w3.org/Archives/Public/www-style/2008Feb/0118.html
<dbaron> (and there's more that I haven't found yet)

[FremyCompany]

Fixed the link in previous post:
https://1drv.ms/b/s!Av6HldQ1OB8gppU68lZS-mwqvguVcg

[bfgeek]

Previous discussions from dbaron: https://bugzilla.mozilla.org/show_bug.cgi?id=172073 https://lists.w3.org/Archives/Public/www-style/2008Feb/0116.html https://lists.w3.org/Archives/Public/www-style/2008Feb/0118.html

[kojiishi]

Catching up the IRC log:

TabAtkins> <li><div style="overflow:hidden">...</div> <= list marker is clipped in Chrome!
leaverou> TabAtkins: A bit late but bullet is not clipped in Chrome in your example, it just inserts a line, see here: http://dabblet.com/gist/07b894c9f6c1bbc3237c422172d0e5b9

@tabatkins @LeaVerou is right that we fixed it, and also the "inserts a line" was fixed a few days ago, available in Canary. The fix isn't ideal, we're looking forward to better fix in LayoutNG.

[FremyCompany]

@kojiishi Thanks for sharing! I think the fix you just shared was not included in my current draft.

However, this latest change hasn't yet made it to my Canary version (v64) or I misunderstood what it was trying to fix exactly. I'll take another look when v65 reach us, because I have some questions based on what I read in the spec.

[LeaVerou]

My testcase is not fixed in Canary, if anything it got worse: in Chrome stable the bullet is there, but an extra line is inserted, in Canary the bullet is gone! http://dabblet.com/gist/3731c920fa0ee56efe3ec24a33a88964

[kojiishi]

Yeah, right, I was too terse, sorry. Here's better status:

• cathiechen@tencent.com is working on fixing the current layout engine
• crbug.com/626293 fixed the "hidden" issue Tab mentioned.
• That caused a few regressions, fixed in Aug and in Nov, based on a design proposal.
• The fixes above apply only to boxes that derive from LayoutBlockFlow in our native class hierarchy, but not other block-level boxes. Cathie started working on fixing for Flexbox, but Lea's textarea might be yet another case, and we know grid and some others are also in this category. We're discussing how to fix this better.
• In LayoutNG, I'm re-implementing list item marker, and we're trying to share the code/logic as much as possible.

[kojiishi]

@FremyCompany thank you for sharing the presentation, this looks great.

Could you share a bit more about why we need the stack to determine the insertion point? The LayoutNG implementation is still in early stage, didn't run full tests yet, but I'm inserting at the beginning of the li as an inline block, and I'm hoping applying absolute or relative positioning can solve issues I'm aware of. Your presentation suggests that's not the case, and I'm interested in learning more on that.

[cathiechentx]

Thanks! @kojiishi
The basic idea in this design proposal to fix overflow issue in chrome is that:

1. Generate a 0px height box as the parent of marker.( To eliminate line-break.)
2. Add this box as the first child of list item.
3. After all children of list item layout, align the vertical position of marker according to firstLineBox.

Theoretically， this design could eliminate the line-break generated by marker. Besides overflow\flex\grid\table\textarea, it could also be applied to the normal cases.

If any interest, very glad to discuss it.

BTW: I tried to apply this design to all cases in chrome before. See: https://chromium-review.googlesource.com/c/chromium/src/+/728119
It passed most test cases in chrome. There're 35 cases didn't pass. In general, there're two kinds of failure:

1. Layout tree difference: Moving maker out of list child brings layout tree change.
2. The second kind of failure is similar to the first case in design proposal. After moving marker out, marker doesn't affect the height of the child.

<ul>
  <li style="line-height: 50px; border:1px black solid;">
    <div style="line-height: 20px; border:1px red solid;">xxx</div>
  </li>
</ul>

I think the first kind change has no harm and the second one make sense too.

[cathiechentx]

Add line-break test cases.
list + flex: https://jsbin.com/nuhacaz/edit?html,css,output

list + table: https://jsbin.com/cusedir/edit?html,css,output

list + grid: https://jsbin.com/bekehoz/edit?html,css,output

list + block textarea: https://jsbin.com/sowuqat/edit?html,css,output

list + writing-mode: https://jsbin.com/folitog/edit?html,css,output