- 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