It appears that the issue is related to the ::marker
pseudo-element.
The conflict arises from multiple specifications intersecting, making it unclear what the expected behavior should be.
This situation is complicated because these are still proposals under development and not yet suitable for implementation. A warning in CSS Lists 3 - Positioning Markers highlights this concern:
This section is not ready for implementation. It is an unreviewed rough draft that hasn't even been properly checked for Web-compatibility. Feedback is welcome, but avoid using this part of the spec.
An analysis of how Chrome handles markers internally follows.
To simplify, applying list-style-position: inside
to a list item with containing blocks yields:
Illustration:
https://i.sstatic.net/cVE7u.png
Of note is the marker overlapping the div but adjusting its first line box like floats typically do.
A float should not overlap a formatting context root. For instance, display: inline-block
establishes a block formatting context.
Example:
https://i.sstatic.net/kt9AY.png
Subsequently, while displaying some float-like characteristics, it operates differently than a traditional float element.
Observations continue regarding various scenarios and how Chrome processes them, including cases involving inline-flex
and flex
display properties.
Contrasting behaviors of Chrome and Firefox also come into focus when handling markers in different situations.