[css-counter-styles] counter-style square symbol (0x25FE) is bad

CSS Counter Styles Level 3 says:

The following stylesheet fragment provides the normative definition of these predefined counter styles:
...
@counter-style square {
 symbols: \25FE;
...

Unicode code point 25FE has Emoji_Presentation=Yes:
https://www.unicode.org/Public/UCD/latest/ucd/emoji/emoji-data.txt

This has the effect that a compliant UA will try to find a glyph for it from a color-emoji font rather than the current default text font, which leads to the following problems:

it isn't rendered using the current CSS foreground color
it's usually way too large in comparison to list-style-type: disc/circle
(see this testcase for some examples - 25FE is the third character from the left)

Currently, many UAs render list-style-type: square/disc/circle/... using custom non-standard methods (typically a special internal box type) so the above is a minor problem. However, we're changing Gecko to use generated text per the CSS Counter Styles spec instead, which makes this a major problem: the rendering for 25FE is so ugly that it's unshippable for this use. (Point 1 above can also lead to the glyph being invisible when the background is black.)

So I think this symbol needs to be changed to something else... I've tested the filled squares in Geometric Shapes code block with many different fonts and it appears 25AA would be the best choice. It's rendered in the foreground color and it's similar in size and alignment to disc/circle (2022/25E6). It also appears to be supported by most common fonts. (25AA is the second character from the left in the testcase mentioned above)

(Fwiw, even with the above change the default rendering is still too ugly in some fonts for us to ship that as the default rendering. So we'll use an internal font for these counter styles by default (that makes it very close to our current legacy rendering), but we'll let authors override that with a font of their choice if they want to.)

a compliant UA will try to find a glyph for it from a color-emoji font

This could also be prevented with \25FE\FE0E. From https://codepoints.net/U+FE0E

This codepoint may change the appearance of the preceding character. If that is a symbol, dingbat or emoji, U+FE0E forces it to be rendered in a textual fashion as compared to a colorful image.

Right, but I still think choosing a different code point would be better since it's rare that fonts have a glyph for 25FE so it would use a fallback font. And even when it is supported, e.g. STIXGeneral and DejaVu fonts, 25FE is much larger than disc/circle (2022/25E6) so in an<ul><li> list that is more than two levels deep the square marker will look ugly and out-of-place. 25AA is commonly supported by fonts and is a better visual match to 2022/25E6.

We've come at this from the other direction, trying to build list markers based on ::marker, but without a legacy implementation. We independently came to the conclusion U+25AA was the best option - and that the existing value of U+25FE was clearly nominal, as no-one has ever used it to render "square". So we'd support this proposal.

It's also clear that an internal font is the only way to do this, and that's also the route we took. So the exact choice of glyph is fairly arbitrary - it's only ever going to be an issue if the user sticks with square but changes the font-family for the list bullet, which I believe isn't currently possible anywhere. So the right time to change this is now, before implementations start shipping that do make this possible.

Chrome apparently favors U+25A0 ■︎ and has this annotation in /third_party/blink/renderer/core/css/predefined_counter_styles.css:

@counter-style square {
  system: cyclic;
  symbols: \25A0;
  /* Note: Spec requires \25FE, but we've always been using \25A0. */
  suffix: " ";
}

@Crissov

@Crissov However, note that Chromium doesn't paint normal native symbol markers as text. U+25A0 is just for things like content: counter(c, square), it was actually introduced in https://webkit.org/b/4980 for counter(). U+25AA seems indeed closer to the normal square.

@faceless2 If an internal font is the only way, then it should maybe be defined in the spec. Chromium doesn't treat symbols as text, which implies that things like text-shadow don't include the symbol, and I guess this can become more problematic once ::marker accepts more properties.

But not sure if I understand the font approach, is it like ::marker { font-family: -vendor-marker-font }? Isn't this bad when the marker is not a symbol?

I am more than happy to change that to whatever looks reasonable; I just grabbed a good-looking square at the time. I see that it does indeed render as an emoji now; either it didn't in the past, or the font stack used at https://www.fileformat.info/info/unicode/char/25FE/index.htm just causes the non-emoji rendering.

Looking over y'all's suggestions, 25AA does indeed seem to be a great square, with appropriate sizing and line positioning.

Agenda+ to confirm swapping out ◾ (U+25FE) for ▪ (U+25AA); I need a resolution since this spec is in CR. ^_^

Gosh dang it, GitHub swaps both characters out for emoji variants, so it's not clear how 25AA is better here.

@faceless2

Is it like ::marker { font-family: -vendor-marker-font }? Isn't this bad when the marker is not a symbol?

Yes I agree, for the general case. We do this with magic when we have list-style-type: disc|circle|square only. I agree it's not the neatest of fits; ideally we'd have a mechanism like

@font-face {
   font-family: -vendor-marker-font;
   unicode-range: U+2022, U+25A0;
}
::marker {
    font-family: -vendor-marker-font, inherit(font-family); /* note */
}

You can be sure I'll be checking Mats' UA stylesheet when it's out though to see if he's got any better ideas, but it feels like there will need to be some special casing for compat whatever we do.

@faceless2 If an internal font is the only way, then it should maybe be defined in the spec.

It sort of is already - the text says list-style-type: disc is "A filled circle, similar to • U+2022 BULLET". And even if you set <ul style="font-family: ahem">, that's still what you get - a circle, not a black square. The means by which that happens seems a bit of an implementation detail to me, and I think the spec is clear enough. But I'd be easily enough persuaded otherwise.

@tabatkins the two look different on macOS Safari, although TBF I need to squint a bit...

(*note - idea from #2864, not sure I've got it right but the intent should be clear.)

Yeah, the two GH emoji are different, but only barely, and importantly since they're both images they're both black squares when shown in dark mode, as I have my GH switched to, which avoiding that was one of the reasons to make this switch in the first place. :/

(But since U+2faa is not an emoji in actuality, it should be fine in practice.)

even if you set <ul style="font-family: ahem">, that's still what you get - a circle, not a black square

This seems needed for compat but I don't see it in css-lists nor css-counter-styles. So I have filed #6201 to discuss since probably it's off-topic here.

The CSS Working Group just discussed [css-counter-styles] counter-style square symbol (0x25FE) is bad, and agreed to the following:

RESOLVED: Switch to using 25aa

The full IRC log of that discussion

<dael> Topic: [css-counter-styles] counter-style square symbol (0x25FE) is bad
<dael> github: https://github.com//issues/6200
<dael> TabAtkins: One of the easy cases we need tor esolve on
<dael> TabAtkins: Count spec says build in square rendes something like 25FE codepoint. Problem is that has emoji presentation. Presents as an emoji rather than a character with text color
<dael> TabAtkins: Also apparently a little larger
<dael> TabAtkins: Suggestion of better character
<dael> TabAtkins: 25aa
<dael> TabAtkins: Switch in spec to 25aa which is not emoji so renders more correct and better size
<dael> TabAtkins: GH treats 25aa as an emoji which is not what borwsers do. Confusing but should be fine in practice.
<dael> Rossen_: Any other ideas of a character? If not, objections?
<dael> RESOLVED: Switch to using 25aa

Bug 1542807 part 1 - Create generated content and use normal box cons…

Convert beforeSelectorOnCodeElement.html to WPT tests

Bug 1725769 [wpt PR 30031] - Convert beforeSelectorOnCodeElement.html…

Navigation Menu

Repository navigation

[css-counter-styles] counter-style square symbol (0x25FE) is bad #6200

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-counter-styles] counter-style square symbol (0x25FE) is bad #6200

Description

Activity

Loirooriol commented on Apr 9, 2021

MatsPalmgren commented on Apr 9, 2021

faceless2 commented on Apr 9, 2021

Crissov commented on Apr 9, 2021

Loirooriol commented on Apr 9, 2021

tabatkins commented on Apr 9, 2021

tabatkins commented on Apr 9, 2021

tabatkins commented on Apr 9, 2021

faceless2 commented on Apr 9, 2021

tabatkins commented on Apr 9, 2021

Loirooriol commented on Apr 9, 2021

css-meeting-bot commented on Apr 28, 2021

3 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions