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

[csswg-drafts] [css-pseudo] Which properties to reset in ::marker (#4568)

From: Mike Bremford via GitHub <sysbot+gh@w3.org>
Date: Fri, 06 Dec 2019 10:05:56 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-533864439-1575626754-sysbot+gh@w3.org>
faceless2 has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-pseudo] Which properties to reset in ::marker ==
Migrated from #4477 

The specification currently states that only the following properties apply to ::marker:
* all font properties (see [CSS3-FONTS])
* the white-space property (see [CSS3TEXT])
* the color property (see [CSS3COLOR])
* the text-combine-upright, unicode-bidi, and direction properties (see [CSS-WRITING-MODES-3])
* the content property (see [CSS-LISTS-3])

...and that this list is likely to be revised. But markers don't exist in a vacuum; they're part of the tree, so even properties that don't apply will need to be reset if they're inheritable, to `initial` or some other sensible value.

As of today the specification has
unicode-bidi: isolate;
font-variant-numeric: tabular-nums;
with `white-space` to be reset to something closely resembling `pre` (#4448).

So, starting with inheritable properties in css-text and `text-shadow` from css-text-decor, and working on the presumption that markers will always be limited to a single line, we have these properties to consider:
<tr><th>property</th><th>applicability to markers</th></tr>
<tr><th>hanging-punctuation</th><td>probably n/a</td></tr>
<tr><th>tab-size</th><td>tabs in markers?</td></tr>
<tr><th>text-justify</th><td>will depend on text-align</td></tr>
<tr><th>white-space</th><td>already covered</td></tr>

I'm going to leave `tab-size`, it's technically applicable but the only place this would ever happen is a WPT test-case. I suppose a decision has to be made, but I doubt it matters what that is. 

I think `hanging-punctuation` doesn't apply - all values other than `force-end` will apply only if the text wraps, and `force-end` only applies to the end of the line. As white-space won't collapse in markers, and a space will almost always follow the punctuation I don't think that's the case, but will test for completeness (although as this depends on browser support for both `hanging-punctuation` and custom markers, it might not be a very useful test).

Test is here: https://output.jsbin.com/rusilefogo


Everyone's different, isn't that fun! To start the ball off on the discussion below, I'd suggest:

* letter-spacing - arguable either way.
* word-spacing - arguable either way but I lean towards no - as white-space will separate the marker from the content, word-spacing will always be applied and I don't think that's going to be compatible with what users expect.
* text-indent - surely no. Every browsers says no.
* text-align - I think this has to be a no, the FireFox results are clearly wrong
* text-transform - arguable either way; if it wasn't for the kana transformations I would say no, but I'm not sure how applicable they are to markers so can't comment
* text-shadow - arguable either way but I lean towards yes - I think the result in Chrome is more consistent visually.
* hanging-punctuation - if it applies at all, resetting to initial seems a good idea and matches current behaviour in Firefox. It's not testable in Chrome or Safari, as we need to remove the trailing space from the marker content, which I can't do without ::marker/content or @counter-style support.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4568 using your GitHub account
Received on Friday, 6 December 2019 10:05:58 UTC

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