W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2019

Re: [csswg-drafts] [css-lists] How should spaces be treated in markers? (#4448)

From: Mike Bremford via GitHub <sysbot+gh@w3.org>
Date: Thu, 24 Oct 2019 23:48:16 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-546144806-1571960896-sysbot+gh@w3.org>
Three observations on this:

1. If spaces are in ::marker, they're there because the stylesheet explicitly listed them, either in the `content` property or in `@counter-style`. Trailing spaces (one or more) are also used to separate the marker from the content. So whitespace should definitely _not_ be collapsed, at least not by default, which means inheriting white-space from the parent is not an option. At the very least you'd need a user-agent rule like `::marker { white-space: N }`

2. Markers are aligned against the first in-flow linebox descendent of the list-item - so if the list-item's first child is a block, for example, it's that child's linebox. I can't find my notes on this right now but I am pretty certain they also contribute to the height of that linebox - i.e. the initial list-item linebox is as at least as high as the marker. For this reason I think allowing newlines might prove problematic; you're then effectively trying to size a linebox to accomodate content which is already multiline. Until I can recall the tests that will back me up on this point, I'm prepared to be corrected on this one.

3. inside positioning just generates a regular inline, so poses no more problem for white-space than any other inline. Insice markers should probably be considered separately to outside markers.

So if removing newlines does prove critical, you can't allow the user to override white-space on the ::marker, in case they try to keep newlines.

-- 
GitHub Notification of comment by faceless2
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4448#issuecomment-546144806 using your GitHub account
Received on Thursday, 24 October 2019 23:48:18 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:55 UTC