Firefox on windows - if a number is used right before an `<sup>` tag and has no character in between and the matching CSS selector, which sets the font-size, includes a *. Then the number is as small as the <sup> elements
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: frederikbring, Unassigned)
Details
Attachments
(1 file)
662.46 KB,
application/zip
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Steps to reproduce:
Quickly reproduce:
- Unpack the attached .zip file
- Start Firefox 65 on windows
- Open up index.html, which is included in the attached .zip file
Manual reproduce:
- Create brand new HTML-file
- Paste the following HTML inside the body "<p>G3<sup>1</sup>⁄<sub>4</sub></p>"
- Create a CSS selector which matches the text and includes a * - for example: "body *"
- Specify the font-size inside this selector
Note:
-
You have to use a number right before the first opening <sup> tag, without any character in between. The "G" is just used to better see the difference.
-
Use a CSS selector which includes a *
-
I have included some screenshots, which may help to understand the problem. They show the difference between MacOS and Windows as well as the difference between my workaround and the "actual" implementation.
Actual results:
The number right before the first opening <sup> tag has the wrong font-size. It has the same or almost the same size as the following <sup> tags and does not fit on the baseline of the "G".
Expected results:
I would have expected, that the font-size and baseline alignment stays the same and doesn't change when I use the * in the CSS selector. Also see workaround.html to see the "expected" behavior.
Updated•5 years ago
|
Comment 1•5 years ago
|
||
:emilio, could you investigate please ?
Comment 2•5 years ago
|
||
So just to clarify, the font-size and baseline alignment is expected to change when using *
, because you're overwriting the font-size of the <sup>
/ <sub>
elements. So the expected rendering (and what I get on Linux) is the same as your firefox-macos-index.png
.
Could you confirm that? I don't know why windows would render like that, I don't have a Windows machine handy. Jonathan, if you have a windows machine around can you repro? Otherwise, any ideas of what may be going on with the fonts in that test-case? Seems pretty wild.
Comment 3•5 years ago
|
||
This is happening because the font has an OpenType feature that recognizes <digit(s)> <U+2044> <digit(s)> and converts the digits to reduced-size numerator and denominator forms, to automatically "format" fractions.
The trouble is, such shaping isn't really appropriate across the boundaries of the <sup> and <sub> elements here, which are already trying to format the fraction via CSS properties.
Bug 1064172 fixed this by disabling shaping across such inline-element boundaries.
Reporter | ||
Comment 4•5 years ago
|
||
Hi guys,
thanks for investigating this issue so quickly!
I am sorry that I missed the already existing bug.
Updated•5 years ago
|
Description
•