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

MatsPalmgren · 2021-04-09T13:37:56Z

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

The text was updated successfully, but these errors were encountered:

Loirooriol · 2021-04-09T14:02:51Z

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.

MatsPalmgren · 2021-04-09T18:12:00Z

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.

faceless2 · 2021-04-09T18:40:23Z

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.

Crissov · 2021-04-09T18:44:57Z

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: " ";
}

Loirooriol · 2021-04-09T19:17:04Z

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

tabatkins · 2021-04-09T19:46:50Z

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.

tabatkins · 2021-04-09T19:50:57Z

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

tabatkins · 2021-04-09T19:52:34Z

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

faceless2 · 2021-04-09T20:09:07Z

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

tabatkins · 2021-04-09T21:01:38Z

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

Loirooriol · 2021-04-09T21:11:23Z

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.

css-meeting-bot · 2021-04-28T16:55:58Z

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

…truction for list-style-type/list-style-image ::markers. r=emilio The change from 0x25FE to 0x25AA for list-style-type:square was approved here: w3c/csswg-drafts#6200 (comment) Differential Revision: https://phabricator.services.mozilla.com/D111691

This test was originally added for WebKit's bug 11197 [1] [2] as a crash test. It is not clear whether a pixel test was needed to check visual rendering but the description of the test suggests it is also testing the circle before and the square after. This test was later tweaked several times with some font-related rules to keep ensuring it matches the pixel expectation, leading for example to the introduction of the non-standard value '-webkit-monospace' that is intended to be removed [3] or of a workaround for bug [4] that is actually fixed now. This CL upstream the original test to WPT as a crash test. It also converts the visual part of the testing to a reftest. However, because Chromium does not render counter-style "square" as specified, the test remains internal for now [5]. Bug: 1065468 [1] https://bugs.webkit.org/show_bug.cgi?id=11197 [2] https://source.chromium.org/chromium/chromium/src/+/2203391429cd40f45325c1d275209c84b5c0dc57 [3] https://crbug.com/1065468 [4] https://crbug.com/939823 [5] w3c/csswg-drafts#6200 Change-Id: I70e489e6824c9afed1087b23ecee27c1bb861dc0

This test was originally added for WebKit's bug 11197 [1] [2] as a crash test. It is not clear whether a pixel test was needed to check visual rendering but the description of the test suggests it is also testing the circle before and the square after. This test was later tweaked several times with some font-related rules to keep ensuring it matches the pixel expectation, leading for example to the introduction of the non-standard value '-webkit-monospace' that is intended to be removed [3] or of a workaround for bug [4] that is actually fixed now. This CL upstream the original test to WPT as a crash test. It also converts the visual part of the testing to a reftest. However, because Chromium does not render counter-style "square" as specified, the test remains internal for now [5]. Bug: 1065468 [1] https://bugs.webkit.org/show_bug.cgi?id=11197 [2] https://source.chromium.org/chromium/chromium/src/+/2203391429cd40f45325c1d275209c84b5c0dc57 [3] https://crbug.com/1065468 [4] https://crbug.com/939823 [5] w3c/csswg-drafts#6200 Change-Id: I70e489e6824c9afed1087b23ecee27c1bb861dc0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3094428 Reviewed-by: Dominik Röttsches <drott@chromium.org> Commit-Queue: Frédéric Wang <fwang@igalia.com> Cr-Commit-Position: refs/heads/master@{#912123}

… to WPT tests, a=testonly Automatic update from web-platform-tests Convert beforeSelectorOnCodeElement.html to WPT tests This test was originally added for WebKit's bug 11197 [1] [2] as a crash test. It is not clear whether a pixel test was needed to check visual rendering but the description of the test suggests it is also testing the circle before and the square after. This test was later tweaked several times with some font-related rules to keep ensuring it matches the pixel expectation, leading for example to the introduction of the non-standard value '-webkit-monospace' that is intended to be removed [3] or of a workaround for bug [4] that is actually fixed now. This CL upstream the original test to WPT as a crash test. It also converts the visual part of the testing to a reftest. However, because Chromium does not render counter-style "square" as specified, the test remains internal for now [5]. Bug: 1065468 [1] https://bugs.webkit.org/show_bug.cgi?id=11197 [2] https://source.chromium.org/chromium/chromium/src/+/2203391429cd40f45325c1d275209c84b5c0dc57 [3] https://crbug.com/1065468 [4] https://crbug.com/939823 [5] w3c/csswg-drafts#6200 Change-Id: I70e489e6824c9afed1087b23ecee27c1bb861dc0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3094428 Reviewed-by: Dominik Röttsches <drott@chromium.org> Commit-Queue: Frédéric Wang <fwang@igalia.com> Cr-Commit-Position: refs/heads/master@{#912123} -- wpt-commits: d3aec8ca81b88ab6bacf672a125dea23edc1e001 wpt-pr: 30031

This test was originally added for WebKit's bug 11197 [1] [2] as a crash test. It is not clear whether a pixel test was needed to check visual rendering but the description of the test suggests it is also testing the circle before and the square after. This test was later tweaked several times with some font-related rules to keep ensuring it matches the pixel expectation, leading for example to the introduction of the non-standard value '-webkit-monospace' that is intended to be removed [3] or of a workaround for bug [4] that is actually fixed now. This CL upstream the original test to WPT as a crash test. It also converts the visual part of the testing to a reftest. However, because Chromium does not render counter-style "square" as specified, the test remains internal for now [5]. Bug: 1065468 [1] https://bugs.webkit.org/show_bug.cgi?id=11197 [2] https://source.chromium.org/chromium/chromium/src/+/2203391429cd40f45325c1d275209c84b5c0dc57 [3] https://crbug.com/1065468 [4] https://crbug.com/939823 [5] w3c/csswg-drafts#6200 Change-Id: I70e489e6824c9afed1087b23ecee27c1bb861dc0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3094428 Reviewed-by: Dominik Röttsches <drott@chromium.org> Commit-Queue: Frédéric Wang <fwang@igalia.com> Cr-Commit-Position: refs/heads/master@{#912123} NOKEYCHECK=True GitOrigin-RevId: 94e222dde3f73e1e48332eabcb03a91ae14bb6d4

tabatkins added css-counter-styles-3 Current Work Agenda+ labels Apr 9, 2021

css-meeting-bot removed the Agenda+ label Apr 28, 2021

fantasai added Agenda+ Closed Accepted by CSSWG Resolution Needs Edits labels Apr 28, 2021

mozilla-apprentice mentioned this issue Apr 28, 2021

[css-counter-styles] counter-style square symbol (0x25FE) is bad mozilla/wg-decisions#533

Closed

tabatkins closed this as completed in bf117c5 Apr 28, 2021

fantasai removed Agenda+ Needs Edits labels Apr 29, 2021

Loirooriol mentioned this issue May 13, 2021

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

Closed

chromium-wpt-export-bot mentioned this issue Aug 14, 2021

Convert beforeSelectorOnCodeElement.html to WPT tests web-platform-tests/wpt#30031

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

MatsPalmgren commented Apr 9, 2021

Loirooriol commented Apr 9, 2021

MatsPalmgren commented Apr 9, 2021

faceless2 commented Apr 9, 2021 •

edited

Loading

Crissov commented Apr 9, 2021 •

edited

Loading

Loirooriol commented Apr 9, 2021

tabatkins commented Apr 9, 2021

tabatkins commented Apr 9, 2021

tabatkins commented Apr 9, 2021

faceless2 commented Apr 9, 2021

tabatkins commented Apr 9, 2021

Loirooriol commented Apr 9, 2021

css-meeting-bot commented Apr 28, 2021

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

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

Comments

MatsPalmgren commented Apr 9, 2021

Loirooriol commented Apr 9, 2021

MatsPalmgren commented Apr 9, 2021

faceless2 commented Apr 9, 2021 • edited Loading

Crissov commented Apr 9, 2021 • edited Loading

Loirooriol commented Apr 9, 2021

tabatkins commented Apr 9, 2021

tabatkins commented Apr 9, 2021

tabatkins commented Apr 9, 2021

faceless2 commented Apr 9, 2021

tabatkins commented Apr 9, 2021

Loirooriol commented Apr 9, 2021

css-meeting-bot commented Apr 28, 2021

faceless2 commented Apr 9, 2021 •

edited

Loading

Crissov commented Apr 9, 2021 •

edited

Loading