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

@SimonSapin

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

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

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?

@MatsPalmgren

cc @MatsPalmgren

@dauwhe

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.

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?

@Loirooriol

@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.

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.

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.

@fantasai

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?)

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.

@faceless2

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.

The CSS Working Group just discussed [css-lists-3][css-pseudo-4] Does text-transform inherit to ::marker?, and agreed to the following:

RESOLVED: add ::marker { text-transform: none; } to UA stylesheet, at least for now
RESOLVED: text-transform applies to ::marker

The full IRC log of that discussion

<dael> Topic: [css-lists-3][css-pseudo-4] Does text-transform inherit to ::marker?
<dael> github: https://github.com//issues/4206
<dael> fantasai: One browser blocks inheritance of list marker
<dael> fantasai: Blocking text-tranform makes sense. ::marker means UA should set text-transform:none and author can set to inherit. But default it should not inherit.
<florian> +1
<dael> fantasai: I want to go through text-transform before other properties
<TabAtkins> +1 to text-transform
<dael> oriol: Not sure I agree. test-transform applies to text like color. If you set color it's inherit, why should text-transform be different? For ::before and ::after it inherits. If you set something case sensitive you would close it. Why should marker be different
<Rossen_> q?
<dael> florian: In general we don't know if text is case sensitive but we do know markers are
<dael> TabAtkins: Agree with fantasai and florian where we have 2 pairs of markers that are explicitly case sensitive. Having text-transform for in is likely unitnentional. Having it automatically it may make it confusing to read. Should be allowed to set
<dauwhe> q+
<dael> fantasai: Can also be semantic where nested lists have some upper and some lower and then they're referenced in other parts of text. If you transform the case it breaks the link. THe default would be safer if we don't have this inherit by default
<dael> dbaron: I think some question if the thing is markers or counter references
<dael> dbaron: I think the thing we're talking about is references to counters which are lower-roman, upper-roman. If we were to have a feature for counter references then the thing we want to not be transformed is the counter reference.
<dael> dbaron: If rule in css is the counter references are not text transformed there's no way for author to say they really do want.
<dael> fantasai: INteresting point. Advocate a separate issue for that. In meantime set text-transform to none so we get markers as defined today
<florian> +1
<dauwhe> q-
<dael> dauwhe: Author PoV I found it surprising that i do something to list item and changes list numbering
<dael> oriol: Should we allow it to list of properties allowed in markers so authors can set to inherit?
<dael> fantasai: Yes, that's part of proposal
<dael> Rossen_: Nearing a resolution. Other questions or PoV?
<dael> Rossen_: If not I'll ask if there are objections.
<dael> oriol: Should we discuss other properties in issue? Text-indent seems more obvious
<dael> fantasai: Let's not all properties together. Let's do one and move to next
<dael> TabAtkins: Unless you think they're linked.
<dael> Rossen_: Do you believe they should be linked?
<dael> oriol: Independent
<dael> Rossen_: Objections?
<dael> fantasai: text-transform is #4558
<dael> florian: You mean text-indent?
<dael> Rossen_: Where should the resolution go?
<dael> fantasai: Here.
<fantasai> s/text-transform/text-indent/
<dael> text-indent is separate
<fantasai> https://github.com//issues/4206
<dael> dbaron: I think at some poitn there was sumamry of existing impl
<dael> dbaron: Trying to understand that state
<dael> fantasai: Top of issue
<dael> dbaron: Claim Gecko blocks inheritence of text-transform. Do we support text-transform:inherit?
<dael> oriol: In chromium markers if you use content:normal it uses ns bullet which doesn't support text-transform. Content to something different than normal it's a different box and it inherits like Chromium. If you set it to something else it will also do that
<dael> dbaron: I think implication is trying to resolve on something done by some impl. I don't think that's the case
<oriol> s/In chromium/In Gecko
<dael> fantasai: I think there's some spec in what's impl. Effect on existing pages...features where we don't have the behavior are new and not much used. Discussion in the issue but I concluded we shoudl block text-transform on markers
<dael> dbaron: Rather than say it doesn't apply to counter references
<oriol> s/ns bullet/nsBulletFrame
<dael> fantasai: Until that's defined I think it's important to not establish a precedence in the majority of cases with markers
<dael> dbaron: Okay
<dbaron> (I think I probably prefer tying this to counters than to markers, but I don't object.)
<dael> Rossen_: Going back, any new objections from this conversation?
<TabAtkins> I could see a list style that's like "First: ", "Second: ", etc., which is fine to text-transform and probably *expected* to respond to that. Maybe this does need to go into the @counter-style definition, like dbaron's earlier comments suggested...
<fantasai> RESOLVED: add ::marker { text-transform: none; } to UA stylesheet, at least for now
<fantasai> TabAtkins, dbaron: yeah, I could live with that... but I'm not sure how we're going to make that work yet, and until we do I think this is a good move
<dael> Rossen_: Next set of properties in the issue?
<fantasai> https://github.com//issues/4568
<dael> fantasai: Separate issue open which is #4568 which discusses all properties
<fantasai> https://github.com//issues/4568#issuecomment-562734422
<dael> fantasai: I suggest we continue there.
<dael> fantasai: My take is we need to define what is inherited through ::marker vs properties that are for paragraph or line box. Properties for block containers shouldn't be for ::marker. Once we define the interesting question is if word-spacing or letter-spacing is also reset.
<dael> fantasai: Not sure we should take it now.
<dael> florian: Given resolution we took I think we need to say text-transform applies to ::marker
<dael> fantasai: Sure
<dael> florian: We said we'd put the property in the UA stylesheet without saying to property applies
<dael> fantasai: Does it apply to marker or text. Need clarity
<dael> florian: That is applies somehow needs to be resolved
<dael> fantasai: Sure
<dael> Rossen_: What's the proposa?
<dael> florian: text-transform applies to ::marker
<dael> Rossen_: Thoughts or objections?
<dael> RESOLVED: text-transform applies to ::marker
<dael> Rossen_: fantasai you asked if we should open #4568 about which properties reset?
<dael> fantasai: I think today we should move on

[css-pseudo] Support text-transform in ::marker

I have changed Chromium and added some WPT checking that text-transform is supported and that it defaults to none.
So now what's missing is just updating the spec.

[css-pseudo] Support text-transform in ::marker

Bug 1654858 [wpt PR 24725] - [css-pseudo] Support text-transform in :…

Fixed in a1caf77

Bug 1654858 [wpt PR 24725] - [css-pseudo] Support text-transform in :…

Navigation Menu

Repository navigation

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

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

Loirooriol commented on Oct 24, 2019

emilio commented on Oct 25, 2019

fantasai commented on Jul 8, 2020

Loirooriol commented on Jul 8, 2020

fantasai commented on Jul 9, 2020

Loirooriol commented on Jul 9, 2020

dauwhe commented on Jul 9, 2020

faceless2 commented on Jul 9, 2020

Loirooriol commented on Jul 15, 2020

tabatkins commented on Jul 15, 2020

css-meeting-bot commented on Jul 15, 2020

3 remaining items

Loirooriol commented on Jul 27, 2020

fantasai commented on Sep 11, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions