Open Bug 1385382 Opened 4 years ago Updated 19 days ago

bullet with text-align:center is positioned further to the right in Firefox, as compared to other browsers (breaking fake radio button at wetter.7pass.de)

Categories

(Core :: Layout: Text and Fonts, defect, P3)

defect

Tracking

()

Webcompat Priority revisit

People

(Reporter: dholbert, Unassigned)

References

Details

(Whiteboard: [webcompat])

Attachments

(2 files)

STR:
 1. Load attached testcase.

EXPECTED RESULTS:
Should look like a checked radio button -- the bullet should be centered inside of its circular border.  (That's what the original site is expecting, at least, in using this markup to generate their own radio-button.)

ACTUAL RESULTS:
Bullet is visibly not centered (or even partly outside the circle), for all but the smallest three examples.


The site where we ran across this (wetter.7pass.de [1])  uses "font-size: 44px", which is the second largest bullet in this example (the second one from the top).

Chrome 61 and Edge 15 give EXPECTED RESULTS (and match each other).
Firefox release 54 and Nightly 56 gives ACTUAL RESULTS.

So, we're not matching other rendering engines here -- hence, this is a webcompat issue.

[1] https://github.com/webcompat/web-bugs/issues/8350
Summary: bullet with text-align:center is positioned further to the right in Firefox → bullet with text-align:center is positioned further to the right in Firefox, as compared to other browsers (breaking fake radio button at wetter.7pass.de)
Attached file testcase 1
jfkthame, do you know what might be going on here? (And is this a dupe of some other bug?)
Flags: needinfo?(jfkthame)
Here's a testcase with extremely large font sizes.  With these:
 - Chrome and Edge do render the bullet off-center from the border-circle -- but the bullet still *overlaps* the border-circle.
 - In contrast, Firefox renders the bullet *entirely outside* the bordered area at these large font sizes.

So something seems qualitatively different between our positioning & chrome/Edge's positioning here.
Are all the browsers using the same font? If not, there's no valid comparison, because the vertical positioning of the bullet glyph within the font's em-square is far from guaranteed....

In particular, I notice that if I set the font of your testcase to Arial, the result looks much better in Firefox; but in Times, it's way off. YMMV with other fonts...

ISTM this is a very fragile way for a site to try and render a "radio button". I can produce lousy rendering of the site in Chrome, too, just by changing fonts.

Note that line-height metrics and the exact vertical alignment of text are known to be inconsistent across browsers and platforms, even for the same nominal font. And given the unpredictability of font availability and rendering settings across devices (what happens when a user, perhaps for accessibility reasons, has non-standard font faces and sizes?), this kind of thing just can't be expected to be reliable.
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #4)
> Are all the browsers using the same font? If not, there's no valid
> comparison, because the vertical positioning of the bullet glyph within the
> font's em-square is far from guaranteed....

They're all using their own selected default font (which happens to be fine in Chrome on Android and Linux (at least), and Edge on Windows.

The site in question happens to have "font-family: sans-serif", which picks DejaVu Sans for Firefox, and something else for Chrome.  If I force Chrome to use DejaVu Sans, then Chrome does indeed match our ACTUAL RESULTS.

So you're right -- the rendering difference seems to be entirely due to a different choice of font.

> In particular, I notice that if I set the font of your testcase to Arial,
> the result looks much better in Firefox; but in Times, it's way off.

On my Linux Nightly, it actually works great for me with both of those fonts. :)  (Tested by adding "font-family: Arial" or "Times" to the <body> element.)

> ISTM this is a very fragile way for a site to try and render a "radio
> button". I can produce lousy rendering of the site in Chrome, too, just by
> changing fonts.
> 
> Note that line-height metrics and the exact vertical alignment of text are
> known to be inconsistent across browsers and platforms, even for the same
> nominal font. And given the unpredictability of font availability and
> rendering settings across devices (what happens when a user, perhaps for
> accessibility reasons, has non-standard font faces and sizes?), this kind of
> thing just can't be expected to be reliable.

That was my initial judgement as well.  However, it's notable that this works fine with the *default* font (and in particular, the default "font-family:sans-serif" font, as chosen by the wetter.7pass.de website), in all browser/platform combinations that have been tested, besides Firefox. :-/
Priority: -- → P3

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Webcompat Priority: ? → revisit
You need to log in before you can comment on or make changes to this bug.