[css-lists][css-counter-styles] Define which symbols are not affected by font-family, and how exactly

[Loirooriol]

If you have this code:

<!-- AdobeBlank defined in https://github.com/adobe-fonts/adobe-blank/blob/master/adobe-blank.css -->
<ol style="font-family: AdobeBlank">
  <li style="list-style-type: decimal">1.</li>
  <li style="list-style-type: circle">◦</li>
</ol>

Then the font displays both 1. of the ::marker and text node as blank.
But in the 2nd item, we still see the ◦ of the ::marker, only the text node is blank.

This was kinda explained in CSS2 https://www.w3.org/TR/CSS22/generate.html#list-style

Glyphs are specified with disc, circle, and square. Their exact rendering depends on the user agent

However, according to https://drafts.csswg.org/css-counter-styles-3/#simple-symbolic, circle is just supposed to produce a U+25E6 ◦, and CSS Lists doesn't say that ::marker should change the font-family or something.

So reading the specs I would guess that the ◦ should disappear too, but that's probably bad for compat.

So I think the specs should define what exactly happens. Implementations haven't been much consistent in the details:

• Is it just for list-style-type set to disc, circle, square, disclosure-open, disclosure-close? What if their definition is changed using @counter-style?
• What if I use my own @counter-style like

  @counter-style my-circle-1 { system: cyclic; symbols: "◦"; suffix: " "; }
  @counter-style my-circle-2 { system: extends circle; }

• What if I use list-style-type: "◦ " or ::marker { content: "◦ " }?
• What if I use ::after { content: counter(c, circle) }?

[Loirooriol]

OK, I missed this text in https://drafts.csswg.org/css-counter-styles-3/#simple-symbolic

Alternately, a browser may render these styles using a browser-generated image instead of the defined character.

So browsers can do that to avoid changing the symbol depending on the font. But I guess we still need to decide what should happen if browser use actual text from the @counter-style "normative definition".

[fantasai]

If there's a compat reason to restrict these keywords to browser images or browser-chosen fonts, we can do that. If there isn't, then maybe it's fine as-is?

[Loirooriol]

Yes, it seems there are compat reasons for using either browser images or browser-chosen fonts, at least in common cases.

@MatsPalmgren is working on replacing the browser images with actual text in Firefox, and seemingly this will require using a -moz-bullet-font font.

And in #6200 (comment), @faceless2 said:

It's also clear that an internal font is the only way to do this, and that's also the route we took.

[fantasai]

@MatsPalmgren @faceless2 Can you look over @Loirooriol's questions and clarify what you think we should spec here? It seems there are several options:

• Allow the font-family to influence ::marker as normal for text and numeric counters, but ensure that the system fallback hits a font with the correct glyphs for the shapes.
• Set up the shape keywords specifically to perform lookup against the UA-chosen font.
• Set up ::marker in general to perform lookup against the UA-chosen font for the characters we use for predefined shapes, falling back to the inherited font for other characters, maybe via some kind of special font-family keyword.
• Something else?

[Loirooriol]

OK, so per resolutions in #3584 (comment),

1. Symbolic counter styles can't be overridden
2. A counter style extending a symbolic one just extends the spec version, it doesn't inherit the special implementation-defined rendering

I guess we can infer from 2 that things like these don't magically obtain the special rendering of circle:

@counter-style my-circle { system: cyclic; symbols: "◦"; suffix: " "; }
list-style-type: my-circle;

list-style-type: "◦ ";

list-style-type: symbols(cyclic "◦");

::marker { content: "◦ " }

A remaining case is content: counter(c, circle). It uses the circle style itself, so it may be expected to use the special rendering of list-style-style: circle. But used in content means that you can mix it with other text, which seems unnecessarily tricky for implementations. So I wouldn't inherit the special rendering, just like for counter styles extending symbolic ones.

[tabatkins]

I guess we can infer from 2 that things like these don't magically obtain the special rendering of circle:

I don't understand what you mean by this example, there's nothing about it that invokes circle at all.

A remaining case is content: counter(c, circle). It uses the circle style itself, so it may be expected to use the special rendering of list-style-style: circle. But used in content means that you can mix it with other text, which seems unnecessarily tricky for implementations. So I wouldn't inherit the special rendering, just like for counter styles extending symbolic ones.

Sounds right, tho that case should already work today, right?

[Loirooriol]

I don't understand what you mean by this example, there's nothing about it that invokes circle at all.

circle just an example. Same for all other symbolic counter styles, replacing "◦" with the corresponding character.

Sounds right, tho that case should already work today, right?

Yes, Chromium and Firefox don't use the special rendering when using content on a ::before, ::after or ::marker. Same for WebKit on ::before and ::after (it doesn't support content on ::marker).

[tabatkins]

Are you trying to imply that any counter style resembling the predefined symbolic's definition would get the same magic exception allowing for special drawing?

I'm not sure where you'd infer that from.

[tabatkins]

Yes, Chromium and Firefox don't use the special rendering when using content on a ::before, ::after or ::marker. Same for WebKit on ::before and ::after (it doesn't support content on ::marker).

Right, that'll be an edit on Lists tho.

[tabatkins]

Okay, explicit exception put in for the predefined symbolics, extending the existing "you can use an image" to be "or a UA-chosen font, if you're actually rendering text".

The behavior of extending the predefined symbolics was handled in #3584; the behavior of any other counter style using the same characters doesn't need any tweaking or clarification because nothing implies they're special at all.

[fantasai]

Also restricted such special rendering to 'list-style-type'.

[Loirooriol]

Are you trying to imply that any counter style resembling the predefined symbolic's definition would get the same magic exception allowing for special drawing?

The opposite, I'm saying that we can discard that possibility.