Dominik, could you take a look?

For the first page,
http://help.apple.com/osx/mac/10.12/macbook-pro-13
Safari's CSS parser seems to be more forgiving and accepts the 

font-family: "30px" "HelveticaNeue-Thin", "HelveticaNeue", "Helvetica Neue", "Helvetica", sans-serif;

line. Note the "30px" "HelveticaNeue-Thin" combination, which Blink interprets as invalid syntax. I consider this correct according to the spec:
https://drafts.csswg.org/css-fonts/#family-name-value

"Font family names other than generic families must either be given quoted as strings, or unquoted as a sequence of one or more identifiers. This means most punctuation characters and digits at the start of each token must be escaped in unquoted font family names."

I interpret this to forbid combinations of two quoted strings.

So, the Apple info page would be a WontFix.

What is the reported difference between the Twitter page except the font weight perhaps?
"Also it can be seen on Twitter as well (Only tweet links, not in the homepage or profile page)."

ugurcan.polat12, could you specify the problem you see with the Twitter rendering?

Firstly, I must say that I came back to El Capitan, so can't debug Chrome on Sierra.

Looks like, the Apple info page is not related to Sierra, It happens on El Capitan as well.

The tweet page problem is gone on El Capitan, so it should be related to Chrome on Sierra (see attached screenshot texts looks different on El Capitan than it how it looks like on Sierra). Let's clear out what I meant by saying "Also it can be seen on Twitter as well (Only tweet links, not in the homepage or profile page).".

The problem is not reproducible on your Twitter homepage (twitter.com) all text looks exactly the same as Safari. But, if you click on a tweet to open it up (as can be seen in screenshots), fonts become 'thinner'. 

Chrome on El Capitan draws that font 'bold', Safari on Sierra draws 'thinner', Chrome on Sierra draws the 'thinnest' font. 

Please note that, cursor hover on link in the attached screenshot on report (#c0) for Chrome on Sierra (tweet), this is my fault.

Deleted: Ekran Resmi 2016-09-12 11.37.22.png 2.0 MB

	Ekran Resmi 2016-09-12 11.37.22.png 2.0 MB View Download

Forgot to mention, Safari and Chrome draws tweet pages with much the same fonts on El Capitan, but not *exactly* the same.

I think, I and other have the same issue on Windows. Look at https://bugs.chromium.org/p/chromium/issues/detail?id=641861. 

Not sure if this helps, but I'm experiencing this in macOS Sierra when the font-family is "Helvetica Neue" and the font-weight is 300. In all other Apple OS's and other browsers on Sierra this combination renders as Helvetica Neue Light. In macOS Sierra on every version of Chrome I've tried (stable and canary) this renders as Helvetica Neue Thin. Again, no idea if this actually helps, but this is definitely my preferred font stack and would love it to render the same in Chrome as it does in other browsers. Thank you! - Mike

font-weight 300 ~ 100 are too similar
font-weight 300 and font-weight 400 are too different




https://jsfiddle.net/nye912mh/10/

Deleted: Artboard.png 109 KB

	Artboard.png 109 KB View Download

This sounds like there might be something going wrong with our toAppKitFontWeight conversion function?

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/mac/FontFamilyMatcherMac.mm?q=toAppKitFontWeight&sq=package:chromium&l=277&dr=C

It seems like AppKit FontManager returns wrong font weight value, which cause the `font-weight` not work correctly.

Let me do a brief reproduce of the "font-weight" bug for others who not know how the code working:

1. set `font-weight: 200` and `font-weight: 300` with `font-family: Helvetica Neue` as what Twitter did

2. blink convert the value `200` and `300` to `FontWeight200` and `FontWeight300` FontWeight enum value and pass it to `MatchNSFontFamily()` like:

````
MatchNSFontFamily(@"Helvetica Neue", 0, FontWeight200, 16.0);
MatchNSFontFamily(@"Helvetica Neue", 0, FontWeight300, 16.0);
````

hope to get the closest NSFont

3. `MatchNSFontFamily()` will convert blink FontWeight `FontWeight200` and `FontWeight300` to AppKit font weight `3` and `4` by `toAppKitFontWeight()`

```
static int appKitFontWeights[] = {
    2, // FontWeight100
    3, // FontWeight200
    4, // FontWeight300
    5, // FontWeight400
    6, // FontWeight500
    8, // FontWeight600
    9, // FontWeight700
    10, // FontWeight800
    12, // FontWeight900
};
```

4. then it will iterate the whole Helvetica Neue font family by `[fontManger availableMembersOfFontFamily]` which returns an Array of Array like:

(I removed Italic and Condensed font for only caring about font weight)

````
("HelveticaNeue", "Regular", 5, 0)
("HelveticaNeue-UltraLight", UltraLight, 2, 0)
("HelveticaNeue-Thin", Thin, 3, 0)
("HelveticaNeue-Light", Light, 3, 0)
("HelveticaNeue-Medium", Medium, 6, 0)
("HelveticaNeue-Bold", Bold, 9, 2)
````

lists all member of Helvetica Neue font family.

According to <https://developer.apple.com/reference/appkit/nsfontmanager/1462316-availablemembersoffontfamily?language=objc>, the third index of font member info is font weight.

BUT, HelveticaNeue-Thin AND HelveticaNeue-Light RETURN SAME APPKIT FONT WEIGHT
'3'.

After iterating making decision function `betterChoice()` which basically compare absolute distance from desire font weight and appkit font weight, `font-weight: 200` and `font-weight: 300` finally pointed to HelveticaNeue-Thin and HelveticaNeue-Thin

----

As a conclude:

1. The Ops issue is:

Twitter wants to show Helvetica Neue Light which bolder than Thin by setting `font-weight: 300`. 

Before macOS 10.12, both Safari and Chrome return Helvetica Neue Light.

After macOS 10.12, Safari still returns Helvetica Neue Light but Chrome returns Helvetica Neue Thin.

There is not way to get Light since Thin and Light both return AppKit Font Weight 3, and Thin appears earlier in iteration.

(In fact, Chrome treat fontWeight200 and fontWeight300 both returning Helvetica Neue Light before 10.12 and both returning Helvetica Neue Thin after 10.12, since Twitter doesn't use Thin before, this issue not happened, this may related to different order of `availableMembersOfFontFamily`)

2. The s0s0's Chinese Font issue is same as Ops:

He wants to use font family PingFang SC (which is new branding Chinese font of Apple), but availableMembersOfFontFamily returns:

````
("PingFangSC-Regular", Regular, 5, 0)
("PingFangSC-Ultralight", Ultralight, 2, 0)
("PingFangSC-Thin", Thin, 3, 0)
("PingFangSC-Light", Light, 3, 0)
("PingFangSC-Medium", Medium, 6, 0)
("PingFangSC-Semibold", Semibold, 8, 2)
````

You must notice that Thin and Light both return AppKit font weight 3, so font weight 200 and 300 both return PingFangSC-Thin

3. more:

As I have tested, Lato and Source Han Sans SC (open source Chinese font by adobe and google) have same problem: Thin and Light returns same font weight in availableMembersOfFontFamily.

----

More further about fix bug:

Safari must use other font decision function, which I assume based on second index of ("HelveticaNeue-Thin", Thin, 3, 0), like:

1. font-weight: 300 -> we should find font weight Light
2. ("HelveticaNeue-Light", Light, 3, 0) -> It is!

not

1. font-weight: 300 -> we should find font weight 4
2. ("HelveticaNeue-Thin", Thin, 3, 0) -> no 4 but found 3, It is!

Like trait strategy in betterChoice(), weight strategy should be more complicated and second index will get higher score in font matching since third index (font weight) is not trustable.

I'm not sure if I convey my thoughts clearly, but if I got any chance I want to patch this bug.

----

notice the 200 and 300 font weight in Safari and Chrome

Deleted: fontweight.png 847 KB

	fontweight.png 847 KB View Download

Midare, thanks for the thorough analysis - sounds plausible, patches welcome, I am happy to review a CL if you have one.

Wondered if there's been any progress on this? Helvetica Neue 300 is quite a popular choice these days, so I'm noticing this problem a fair bit.