1136581 - <list-style-type> glyphs have a different rendering through/with 'counter()' and 'display: list-item'

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Xavier Zalawa]

Attachment: Screenshot of the result in some browsers

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150222232811

Steps to reproduce:

1. Construct an unordered list (one item is enough) with the appearance `list-style-type: disc`.
2. Display a static counter with the help of a pseudo-element and the declaration `content: counter(♥, disc)` on the list items.


Actual results:

The glyphs disc, circle and square which are drawn by the `counter()` or `counters()` function of the `content` property are smaller.

There are no problem with the others types of list item's markers: numbering systems, and alphabetic systems.


Expected results:

The glyphs disc, circle, and square (list item's markers) which are drawn by the `counter()` or `counters()` function of the `content` property and by the CSS declaration `display: list-item` should be the same (especially the size).

Comment 1

[Xavier Zalawa]

Attachment: Testcase

Comment 2

[[:Aleksej]]

Reproduced with 2015-03-04-03-02-31-mozilla-central-firefox-39.0a1.ru.linux-x86_64.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The "content: counter(whatever, disc)" version has to produce actual text to be inserted.  In particular, it produces U+2022 BULLET.

On the other hand, nothing I see in the spec requires the marker of a list-item to use actual text (and in fact list-style-image makes it clear that the marker need not be text at all).  What we do for the "disc" list style is fill an actual circle whose size depends on the size of the list marker box.

Similar for the "circle" list style, with U+25E6 WHITE BULLET vs stroking an actual circle, and for the "square" list style with U+25FE BLACK MEDIUM SMALL SQUARE vs drawing an actual square sized to the size of the list marker box.

Now some notes:

1)  It turns out that in practice the commonly used fonts don't actually have those Unicode characters, so if you try to use them for list bullets you end up with font substitution and bullets that look wrong/misaligned compared to the actual list item text.

2)  Per the spec, what we're doing here is totally fine, as far as I can tell.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Sort of duplicate of bug 152588.

When I implemented counters I thought about changing list-style-image bullets to use the same glyphs as counters, but it seemed riskier than the value we'd get out of it; it's not clear to me if fonts reliably have good glyphs for these codepoints.

If we eventually do bug 288704, we'd probably have to switch to the glyphs, though.

Comment 5

[Xavier Zalawa]

Thank you for your explanations. Now it's clearer in my mind ;)
Indeed, I didn't know `list-style-type`s were images and it is obvious that `counter` must produce text and not images especially because you can use them like this: `content: "chapter" counter(whatever, disc) attr(data-*) ♥`.
Moreover, if we take into account the new `@counter-style`at-rule, it seems that it always renders text even if we use it like this: `@counter-style bullets { system: extends disc }`. Am I wrong?

It could be great if Firefox used glyphs in all cases. If it can help you to choose, it seems that IE renders `list-style-type`s with glyphs.

I'm going to close this issue and to follow the bug 152588. However it was very interesting to have this discussion with you :)

Comment 6

[Boris Zbarsky [:bzbarsky]]

> It could be great if Firefox used glyphs in all cases.

The problem with that is note 1 from comment 3...

Comment 7

[Mats Palmgren (inactive)]

As Boris noted above, the CSS specs have always allowed UAs to render disc etc as they wish (not as text), CSS2 said:

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

https://www.w3.org/TR/CSS21/generate.html#propdef-list-style-type

The latest spec says:

Note: If the <counter-style> is one of the predefined symbolic styles, like disc, it might look different than when used in list-style-type. See CSS Counter Styles 3 §6.3 Symbolic: disc, circle, square, disclosure-open, disclosure-closed.

https://drafts.csswg.org/css-lists-3/#counter-functions

And, as he also noted, many fonts are either missing these glyphs or they look awful.

That is the reason we now render list-style-type:disc etc as text using a built-in font, with proper text anti-aliasing and scaling, so the bullets (disc, circle, square, disclosure-open, disclosure-closed) should now look great at any zoom level. We also honor an explicitly specified font-family in a ::marker rule, so an author can override that font with any font they wish. This change (bug 1542807) just landed so it's only in Nightly (91) so far and will take a few weeks to be reach the stable branch.

However, there's still an intentional rendering difference between list-style-type:disc and ::marker { content: counter(list-item, disc) } - only the former use the built-in font by default. You can override the font for either, by specifying a font with a ::marker { font-family: ... } rule, but please note that users may override your choice of font in the browser Preferences so using the built-in font is probably better.

Resolving as WONTFIX since we have no intention of changing this exactly as requested, but the default bullets should now look great anyway with bug 1542807 fixed, and there now is a way for authors to get the exact same rendering for list-style-type and content by adding a bit of ::marker styling.