Open Bug 1713039 Opened 3 years ago Updated 11 months ago

-apple-system Font Weights Inconsistent with Safari

Categories

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

Firefox 88
defect

Tracking

()

UNCONFIRMED
Webcompat Priority P3

People

(Reporter: stephanierahart, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

  1. Create text with style:
    font-family: -apple-system;
    font-weight: 500;
    font-size: 15px;

Open Safari and create text with the same style.

  1. Create Japanese or Hebrew text with the same style and add lang="ja-JP", for example with text "こんにちは".

Actual results:

  1. -apple-system font-weight: 500; appears to be somewhere between the equivalent of font-weight: 500; and font-weight 600; on Safari.

More importantly,
2) -apple-system only has two font-weights for Japanese and Hebrew, so font-weight: 600; looks very different on Firefox and Safari.

Expected results:

-apple-system font weights should be consistent with Safari.

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core

I think the underlying issue here is that "the system font" on macOS is not in fact just one font; it's a collection of fonts supporting various languages/scripts.

We don't currently implement -apple-system via the proper Core Text API (we probably should be using CTFontCreateUIFontForLanguage with the kCTFontUIFontSystem type) to get the appropriate font for a given language; at startup time, we look up "the system font" (for the default locale, IIRC), which will generally be the (hidden) .SFNS font, and then the -apple-system keyword simply maps to that.

But this means that once you start using it with things like Japanese or Hebrew content, our interpretation of -apple-system doesn't support those character sets, so we'll end up falling back to some other default for the relevant Unicode characters. And so it's unsurprising that the result doesn't fully match Safari.

(See also bug 1605605, which is closely related although the initial report was looking at things from a different point of view.)

Severity: -- → S3
See Also: → 1605605

This is hitting WebKit.org blog posts now (Safari and Chrome show italics where Firefox does not). We are not showing italicized text where other browsers do (see https://github.com/webcompat/web-bugs/issues/109407). It seems to be exacerbated by the site also using font-synthesis:none in their default CSS reset: html { font-family: -apple-system, "SF Pro Text", Helvetica, sans-serif; font-synthesis: none; }

Webcompat Priority: --- → P3
Blocks: 1835378
You need to log in before you can comment on or make changes to this bug.