Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
MatsPalmgren opened this issue Apr 9, 2021 · 12 comments
Closed

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

MatsPalmgren opened this issue Apr 9, 2021 · 12 comments

Comments

@MatsPalmgren
Copy link

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:

  1. it isn't rendered using the current CSS foreground color
  2. 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.)

@Loirooriol
Copy link
Contributor

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
Copy link
Author

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
Copy link

faceless2 commented Apr 9, 2021

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
Copy link
Contributor

Crissov commented Apr 9, 2021

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
Copy link
Contributor

@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
Copy link
Member

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
Copy link
Member

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

@tabatkins
Copy link
Member

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

@faceless2
Copy link

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jun 12, 2021
…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
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jun 14, 2021
…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
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Jun 15, 2021
…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
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Jun 15, 2021
…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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 14, 2021
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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 14, 2021
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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 16, 2021
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}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 16, 2021
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}
blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this issue Aug 16, 2021
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}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Sep 3, 2021
… 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
spinda pushed a commit to PLSysSec/cachet-firefox that referenced this issue Sep 8, 2021
… 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
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants