I'm not sure what Stylish is, but it sounds like this extension? https://chrome.google.com/webstore/detail/stylish-custom-themes-for/fjnbnpbmkenffdnngjfgmeleoegfcffe?hl=en

It sounds like this could be an issue with the extension, please report it to the developer of the extension (https://userstyles.org/help/stylish_chrome).

No it's an issue about how Chrome process @font-face CSS. Stylish just insert the style into webpage. Since Chrome stopped supporting custom user styles, you can use any custom user style extension and the result will be the same.

Thank you for providing more feedback. Adding requester "mikelawther@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

You can also create a webpage such as https://pastebin.com/2LdZXswC and test it.

Btw, "@font-face { font-family: "Tahoma"; src: local("Noto Sans Bold"); font-weight: bold }" also doesn't work.

I took your example and used different fonts to make it clearer (I don't have Noto Sans locally): https://jsfiddle.net/juesyo6m/8/

This displays identically on Chrome, Firefox and Edge - as you describe, both lines are changed to Courier New, but the second one is not bold.

If you replace the second font-family with "Tahoma Bold", then Chrome, Firefox and Edge all display the second one as bold.

Does that fix your problem?

If not, we'll need an example that behaves differently on Chrome than it does on the other browsers.

First, "@font-face { font-family: "Tahoma"; src: local("Noto Sans"); font-weight: bold }" used to work in the earlier versions of Chrome. It might not be the proper behavior, though.
Second, you can use https://pastebin.com/2LdZXswC (I edited it). In Firefox and IE11, "Courier New Bold" is used in the second line, which I think is the correct behavior. But in Chrome, "Tahoma Bold" is used in the second line. By the way, Edge also cannot display it correctly for it uses regular version of Courier New in the second line.

Thank you for providing more feedback. Adding requester "mikelawther@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on reported version63.0.3213.3 and on latest canary 63.0.3218.0 using Windows 10, Mac 10.12.1 and is reproducible with JSfiddle mentioned in comment#9. 

NOTE: Issue is not seen in Ubuntu 14.04

Manual Bisect Info:
===============
Good Build: 62.0.3166.0 
Bad Build: 62.0.3167.0 

You are probably looking for a change made after 490004 (known good), but no later than 490007 (first known bad).

CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/4e112e84ae592c82aef95065fa4d5def8ecea3bb..4fda6e374f41bd3740e15d4cf1c96094b5a5b32d

Suspecting  https://chromium.googlesource.com/chromium/src/+/818128039c5b02fd68d171f18014a34035f87023 from changelog.

@drott: Please confirm the issue and help in re-assigning if it is not related your change.

Adding RB-Stable as it is a recent regression. Please change if not the case.

Thanks!

drott@ Ping! Since this issue is marked as RB-Stable, could you please take a look in to this issue?

Thanks!

I am currently traveling, back in the main office on Monday. I'll try to take a look next week. I doubt this is RB-Stable really, though. font-weight: bold in a @font-face declaration should not trigger synthetic bolding. If we did that before the CL, then this was wrong.

The local() property value for the src: attribute of a font-face rule needs to specify the unique postscript name of a font. See https://drafts.csswg.org/css-fonts-4/#src-desc 

"For OpenType and TrueType fonts, this string is used to match only the Postscript name or the full font name in the name table of locally available fonts. Which type of name is used varies by platform and font, so authors should include both of these names to assure proper matching across platforms. Platform substitutions for a given font name must not be used."

Unfortunately, Chrome has a bug about matching local() correctly against the postscript name or full font name, see issue: 627143. We're working on a plan to resolve this.

Regarding the original reporters' use case of overriding Tahoma using Stylish or another user style sheet extension: The placement of font-weight: bold; in a @font-face rule is not meant to affect font matching. The fact that this has worked is because of not-spec compliant behavior in Chrome.

In order to replace bold occurrences of Tahoma with the bold version of Noto Sans, I would recommend to use the following CSS (tested on Mac). See also https://codepen.io/anon/pen/jGybVe for a demonstration:

@font-face { font-family: "Tahoma"; src: local("Noto Sans") }
@font-face { font-family: "Tahoma"; src: local("NotoSans-Bold"), local("Noto Sans Bold"); font-weight: bold }

Hope this helps.

Deleted: noto_sans_bold_name_table.txt 1.9 KB

noto_sans_bold_name_table.txt 1.9 KB View Download

The CSS mentioned above doesn't work on Windows. I've uploaded a screenshot of https://codepen.io/anon/pen/dVNeYZ.

Deleted: screencapture-codepen-io-anon-pen-dVNeYZ-1506403167761.png 270 KB

	screencapture-codepen-io-anon-pen-dVNeYZ-1506403167761.png 270 KB View Download

The CSS you're posting is not identical to the one I posted. However, I see that you have tried to match the names accordingly using the full font name and the postscript name. At the moment, I can only refer to issue 627143, which is about improving local() matching. Currently, we match local() against the family name, which even for "CourierNewPS-BoldMT" is only "Courier New", so in that case unfortunately it won't work as expected.