Description
Migrated from #4474
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:
| property | applicability to markers |
|---|---|
| hanging-punctuation | probably n/a |
| hyphens | n/a |
| letter-spacing | ? |
| line-break | n/a |
| overflow-wrap | n/a |
| tab-size | tabs in markers? |
| text-align-* | ? |
| text-indent | ? |
| text-justify | will depend on text-align |
| text-transform | ? |
| white-space | already covered |
| word-break | n/a |
| word-spacing | ? |
| word-wrap | n/a |
| word-wrap | n/a |
| text-shadow | ? |
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
Findings:
| property | Firefox | Chrome | Safari |
|---|---|---|---|
| letter-spacing | N | Y | Y |
| word-spacing | N | Y | Y |
| text-indent | N | N | N |
| text-align | Y | N | N |
| text-transform | N | Y | N |
| text-shadow | N | Y | N |
| hanging-punctuation | N | - | - |
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.
(edit: pinging @MatsPalmgren @dauwhe and @fantasai for input as suggested by @fantasai in the original issue)