[css-lists-3][css-pseudo-4] Does text-transform inherit to ::marker?

[fantasai]

Gecko blocks inheritance of text-transform, whereas Chrome allows it. Testcase What should the spec say?

Originally raised in https://www.w3.org/mid/515ED601.3090909@exyr.org by @SimonSapin

[Loirooriol]

Actually it's more complex than "Gecko blocks inheritance of text-transform, whereas Chrome allows it."

Consider this testcase:

<ol class="type-roman"><li>content</li></ol>
<ol class="type-string"><li>content</li></ol>
<ol class="marker-roman"><li>content</li></ol>
<ol class="marker-string"><li>content</li></ol>

li { text-transform: uppercase }
.type-roman { list-style-type: lower-roman }
.type-string { list-style-type: 'i. ' }
.marker-roman ::marker { content: counter(list-item, lower-roman) '. ' }
.marker-string ::marker { content: 'i. ' }

Firefox renders it as

i. CONTENT
i. CONTENT
 I.CONTENT
 I.CONTENT

So it seems ::marker's content obeys text-transform just like a ::before would do, but list-style-type does not. But I guess https://bugzil.la/1542807 may make list-style-type obey text-transform.

Chromium with LayoutNG looks like

I. CONTENT
I. CONTENT
I. CONTENT
I. CONTENT

so it obeys text-transform in both cases. But in legacy, list-style-type behaves like in Firefox:

i. CONTENT
i. CONTENT
I. CONTENT
I. CONTENT

Given that Firefox plans to remove legacy layout code path for ::marker, and Chromium will also remove legacy layout at some point, maybe we can resolve that ::marker should inherit text-transform? And probably other text properties like letter-spacing and word-spacing?

[emilio]

cc @MatsPalmgren

[fantasai]

The question of whether these properties apply is a separate one from whether we should reset them on ::marker in the UA style sheet, though.

Thinking about it more, especially in light of the list-style-type values being case-sensitive, I think we should block inheritance here for at least text-transform.

(And maybe also letter-spacing and word-spacing also, but I'm less sure about that particularly in consideration of inside list markers.)

Poking @dauwhe / @jensimmons / @faceless2 / @bradkemper for authoring perspective.

[Loirooriol]

I don't follow the argument. If you have a ::before pseudo-element, then content: "a" or content: "A" is case-sensitive, but it still obeys text-transform. Why shouldn't ::marker do the same?

[fantasai]

@Loirooriol Because conceptually (from an authoring, rather than implementation perspective) ::before/::after are more part of the content of the paragraph, whereas markers are more separate from it. And in particular because markers are commonly used in a way where casing creates a semantic distinction. Making the author go through the extra step of requesting the loss of casing information explicitly is therefore a good idea, imho.

[Loirooriol]

If they don't want to lose a semantic distinction, maybe they shouldn't be using text-transform in the first place. Blocking inheritance by default would also make authors who want to lose it go through the extra step of setting ::marker {all: unset} or something.

Given that, regardless of what we decide, it will always be an annoyance for some authors, I would just keep the UA styles for ::marker as simple as possible, and not block inheritance.

[dauwhe]

I was actually quite surprised that

ol { list-style-type: lower-roman; }
li { text-transform: uppercase; }

is not interoperable, and that something I do to a list item can potentially mess with the list marker. I explicitly said I wanted lowercase numbering. Why does Chromium (and Prince) get to change that?

I think of this as a separation of content (li) and style (the list marker). So I don't want text-transform to inherit to ::marker.

[faceless2]

I think I agree with @fantasai and @dauwhe, mainly because a ::marker can be generated and populated with content without the author ever having heard of the ::marker pseudo-element.

That means we really have to try and do the right thing in the UA stylesheet - resetting text-transform, and probably letter-spacing, word-spacing and text-indent (if it applies). We already reset unicode-bidi and set font-variant-numeric, so markers are already a little bit different to before/after.

I think the case for resetting letter-spacing and word-spacing is much less clear for inside markers, but I know we went over that in #4568 and didn't get to a solution. If we don't want to do anything clever here (as discussed in #4568) then optimizing for the most common case means we should reset them.

Because we have inside list markers, all text properties must all still apply. But I don't think anyone's arguing against that.

(aside: I know there's a list somewhere of what proportion of websites use certain features, but can't find it. What does it say about list-style-position: inside?)

[Loirooriol]

IMO the only of these properties for which blocking inheritance seems a clear benefit is text-indent, for the reason described in https://drafts.csswg.org/css-text/#text-indent-property

Since the text-indent property inherits, when specified on a block element, it will affect descendant inline-block elements. For this reason, it is often wise to specify text-indent: 0 on elements that are specified display: inline-block.

Outside markers are inline-block-like (and actual inline-blocks in Chromium LayoutNG), and this is not obvious to authors since they didn't set display: inline-block themselves, so text-indent: 0 in UA origin seems wise.

[tabatkins]

I also agree that it would be surprising to me to have text-transform affect the marker by default; it means that to "safely" do text-transform on the content of a list item, I have to wrap the contents in a span and style that instead.

I think I'm with @faceless2, in that while general styling should inherit (color, weight, etc), anything that can affect the semantics or otherwise make it harder to understand the marker should be blocked.