Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@font-face/src incorrectly describes the values accepted by the local() specifier #12347

Closed
nk9 opened this issue Jan 22, 2022 · 5 comments · Fixed by #24133
Closed

@font-face/src incorrectly describes the values accepted by the local() specifier #12347

nk9 opened this issue Jan 22, 2022 · 5 comments · Fixed by #24133
Labels
Content:CSS Cascading Style Sheets docs effort: small This task is a small effort. help wanted If you know something about this topic, we would love your help!

Comments

@nk9
Copy link

nk9 commented Jan 22, 2022

What page(s) did you find the problem on?

Specific page section or heading?

@font-face/src, Formal Syntax

What is the problem?

The Formal Syntax claims that the value which should be passed to local() is the "family-name". In fact, the CSS spec makes clear that the value should describe the font face:

The locally-installed argument to local() is a format-specific string that uniquely identifies a single font face within a larger family.

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.

This piece of advice seems super relevant for web developers.

Did you test this? If so, how?

I discovered this issue while testing with Firefox, Chrome and Safari on macOS 11.6.2. Firefox and Chrome generally require e.g. local("Helvetica-Oblique") here to render an italic version of the font, whereas Safari happily accepts local("Helvetica") and works out which font face is meant. You can use the following code on different browsers to see the issue:

<html>
  <head>
  <style>
    body {
      font-family: "Helvetica";
    }

    @font-face {
      font-family: "Helvetica";
      font-style: italic;
      font-weight: 400;
      font-display: swap;

      /* Font family name will display roman text on most browsers */
      src: local("Helvetica");

      /* Font face PostScript name will display italic text on all browsers */
      /*src: local("Helvetica-Oblique");*/
    }
  </style>
  </head>

  <body>
    <em>This should be italic.</em>
  </body>
</html>
@nk9 nk9 added the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label Jan 22, 2022
@sideshowbarker sideshowbarker added Content:CSS Cascading Style Sheets docs help wanted If you know something about this topic, we would love your help! effort: small This task is a small effort. and removed needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. labels Jan 22, 2022
@tlylt
Copy link
Contributor

tlylt commented Jan 30, 2023

Hi @nk9,

I just checked the section referenced by you and it seems that perhaps the content has already been corrected.
Instead of

The Formal Syntax claims that the value which should be passed to local() is the "family-name"

It currently states: local(<font-face-name>), which <font-face-name> is explained above as:

Specifies the full name or postscript name of a locally-installed font face using the local() component value, which uniquely identifies a single font face within a larger family. The name can optionally be enclosed in quotes. The font face name is not case-sensitive.

Hope that's clear about what arguments are accepted by local() and perhaps @sideshowbarker can close this issue?

@sideshowbarker
Copy link
Collaborator

Closing per #12347 (comment)

@bsmth
Copy link
Member

bsmth commented Jan 30, 2023

Side note that these pages have been refreshed recently in:

@nk9
Copy link
Author

nk9 commented Jan 30, 2023

Thanks for this, glad to see the docs have been corrected. However, I notice that the new wording still doesn't explicitly include the W3C recommendation about using both names:

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.

The first Example block does contain a @font-face using both names of Gill Sans, with comments, but no explanation about why both names should be provided. And the previous example in that block (Futura Medium) doesn't follow the recommended practice of providing both names. Isn't this compatibility advice useful for web developers to have when they're looking up how to use this parameter in MDN?

@tlylt
Copy link
Contributor

tlylt commented Feb 3, 2023

Thanks @nk9 for following up on this. I have raised a PR to add the recommendation.

The first Example block does contain a @font-face using both names of Gill Sans, with comments, but no explanation about why both names should be provided. And the previous example in that block (Futura Medium) doesn't follow the recommended practice of providing both names. Isn't this compatibility advice useful for web developers to have when they're looking up how to use this parameter in MDN?

I do see that examples on the W3C page also omit providing both names at times, I suppose that's fine if some examples are not focused particularly on the local() part. Hence, I have not make changes to the examples in MDN.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content:CSS Cascading Style Sheets docs effort: small This task is a small effort. help wanted If you know something about this topic, we would love your help!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants