[css-lists] Should list marker affects line height?

[kojiishi]

This is for info-sharing as we worked on re-implementing lists in Blink.

Test@codepen

At least from this test, Edge/WebKit/Blink includes the list marker to the line height, while Gecko does not.

/cc @FremyCompany @upsuper @cathiechen

[FremyCompany]

I'd say yes. The css 2.1 spec says it should.

The only case that doesn't make sense is when Edge is creating a line just to host the bullet if there is no existing line where the place the bullet and we encounter a list-item content that is a bfc and inside which we cannot insert the bullet. The empty line is very weird and not expected by authors.

[kojiishi]

I'd say yes. The css 2.1 spec says it should.

I found in the outside value of list-style-position:

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.

but this is "may". Is there other definitions?

The only case that doesn't make sense is...

Is this the case about the last example of tests@codepen in #2417, or is this different?

[FremyCompany]

Is there other definitions?

Except the small design doc I presented to the group, no unfortunately.

Is this the case about the last example of tests@codepen in #2417, or is this different?

The last case indeed. I propose it renders the more or less as it does in Edge now for the bullet position (1. exactly where it is now in Edge) but there would be no white space for the unnecessary line above the blue div.

[cathiechen]

Changed Koji's test case a bit https://jsbin.com/cenibuvawe/3/edit?html,css,output. The behavior is wierd except Gecko.

If we let marker affect the line height of the content block. I'm afraid this might make the behavior of the content block unpredictable. And this might confuse web developers.

Back to the in-flow or out-of-flow issue:
If we treat list marker as in-flow: Accord to the behavior of in-flow, marker should be affected by float object, and it could affect the height of list item but not the content block of list item.
If out-of-flow: marker shouldn't be affected by float object, and it shouldn't change the height of list item or the content block.

Looks like:
Gecko is like out-of-flow more, but let float objects affect the position of marker.
Edge/WebKit/Blink is like in-flow more, but let marker affect the content block.

[cathiechen]

I personally think the ideal result is that:

1. Marker is in-flow.
2. It could be affected by float objects.
3. It doesn't affect the content block. But it could affect the height of list item.
4. It always could be displayed.

[FremyCompany]

Changed Koji's test case a bit https://jsbin.com/cenibuvawe/3/edit?html,css,output. The behavior is wierd except Gecko.

Maybe, but the layout constraints here are not very realistic. This is seriously over-constrained, and uses font sizes differing by an order of magnitude.

I would rather have a solution that looks like what we have now and makes sense in the reasonable cases than try to solve an infinite amount of cases and create a difficult-to-maintain code.

We already have something that is solid in most cases, with little developer complaints and very few broken sites. So, from Edge point of view, we just want to move the needle a bit towards an even more interoperable solution, and write down those interoperable guidelines in the spec.

[kojiishi]

So, @FremyCompany, do you want to start writing down the guidelines? I think we've got enough experiments to review them and see what's possible and what's not for us, and hopefully adopt our new impls to it as much as possible.

[fantasai]

I think inside list markers should behave as regular inline boxes would, and outside list markers should not affect the line height, as it throws off the rhythm. However, they could force the creation of a strut in certain cases. In CSS2.1 these two things would be equivalent, but with ::marker styling they are not.

[FremyCompany]

@kojiishi I can start building a bunch of test cases, and see what we can agree on

[kojiishi]

@FremyCompany sounds great. I believe wpt has some methods to add "tentative" tests, that tests proposed behavior but not really agreed yet. Probably this one:
https://github.com/w3c/web-platform-tests/blob/master/docs/_writing-tests/file-names.md
Maybe we can use this feature?

@fantasai I'm not sure about the line height yet. Not affecting is probably easier to implement, but I personally prefer "avoid overlap by default" and rhythm being opt-in. As far as I understand, that's the policy CSS2 has today since its beginning, and while I'm a big fan of rhythm, I'm even bigger fan of "avoid overlap by default." Rhythm is a professional feature where authors can opt-in, while avoiding overlap is a basic feature for non-professionals. From that perspective, it should affect the line height.