Open
Bug 1385382
Opened 7 years ago
Updated 2 years 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)
Core
Layout: Text and Fonts
Tracking
()
NEW
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
|
Reporter | |
Updated•7 years ago
|
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)
|
|
Reporter | |
Comment 1•7 years ago
|
||
|
|
Reporter | |
Comment 2•7 years ago
|
||
jfkthame, do you know what might be going on here? (And is this a dupe of some other bug?)
Flags: needinfo?(jfkthame)
|
|
Reporter | |
Comment 3•7 years ago
|
||
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.
|
||
Comment 4•7 years ago
|
||
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)
|
|
Reporter | |
Comment 5•7 years ago
|
||
(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. :-/
|
||
Updated•7 years ago
|
Priority: -- → P3
|
||
Comment 6•6 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Webcompat Priority: --- → ?
|
|
||
Comment 7•6 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
|
||
Updated•5 years ago
|
Webcompat Priority: ? → revisit
|
||
Updated•2 years ago
|
Severity: normal → S3
|
||
Updated•2 years ago
|
Webcompat Priority: revisit → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•