- From: Oriol Brufau via GitHub <sysbot+gh@w3.org>
- Date: Sat, 09 Nov 2019 16:42:14 +0000
- To: public-css-archive@w3.org
> There's no reason whatsoever that ::marker can't support the same properties as `::before/::after` does.
I'm not that sure about non-inherited properties. But I tend to agree for inherited properties (except `list-style-*` I guess). The restriction can be bypassed anyways by setting the desired marker value to the list-item, let the marker inherit it, wrap the list-item contents inside some container, and reset the value in that container. But this sucks for authors.
> it's also trivial for authors to use a non-collapsing space if that's what they want: `\A0`.
The point is that `@counter-style` is being used on the wild, with the expectation that spaces won't collapse. Changing the behavior to no longer collapse by default would break existing code.
Also, IMO using U+00A0 is semantically wrong, non-breaking spaces are supposed to be used to avoid breaks between specific pairs of words, not to avoid whitespace collapsing (I know it's a lost battle, but still). The proper way to control whitespace collapsing is the `white-space` property.
So I tend to think
- We should settle on some default value for `white-space` in markers (`pre`?) and assign it in UA origin.
- This default value may depend on whether the marker is inside or outside, e.g.
```css
::marker:inside-marker { white-space: inherit }
::marker:outside-marker { white-space: pre }
```
where `:inside-marker` and `:outside-marker` would be internal pseudo-classes that can only be used in UA origin (not exposed to the web).
But probably it's simpler to always have the same default value.
- Decide what to do with multiline markers.
- At some point, let authors customize marker's `white-space` (among other properties) with their desired value.
--
GitHub Notification of comment by Loirooriol
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4448#issuecomment-552116397 using your GitHub account
Received on Saturday, 9 November 2019 16:42:16 UTC