[css-lists] position:marker as layout model for list-style-position:outside list item markers
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 4.9k
- Forks
- 816
- PR merge metrics
- PR metrics pending
Description
https://drafts.csswg.org/css-lists-3/#position-marker
An element with position:marker counts as absolutely positioned.
Given the above quote, I have some doubt regarding using position:marker as a description of how layout works for list-style-position:outside list item markers. Making it positioned changes the stacking level in which it is painted. Given how prevalent <li> is on the web, I strongly doubt this would be web-compatible. Non-positioned content that happens to overlap a ::marker must paint on top of it.
FYI, Gecko has implemented ::marker and we made the following tweaks for it to make it compatible with the legacy rendering:
- when the list item has
list-style-position:outside, thedisplayvalue of the::markerpseudo-element is blockified - the
::markerbox inline-size shrink-wraps by default - the
::markerbox inline-axis margins are not calculated per the CSS2 block-level algorithm (because that would typically make the inline-end margin very large and thus misposition the::marker)
I think those tweaks are non-controversial since I think they would fall out from making it absolutely positioned anyway, as the spec suggests, so I think it's within the intent of the spec regarding the layout result. But, we do not treat it as absolutely positioned in our box tree.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the CSS Lists Level 3 position-marker section, the linked CSS2 stacking-level material, and the CSS Display blockification definition. Compare the proposed model with the listed Gecko ::marker behavior and determine what specification wording is needed to resolve layout and painting compatibility; done means the issue has an agreed, implementable specification outcome.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css
- Domain
- documentation, frontend
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100