You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-fonts] Rename <*-family-name> to <*-font-family-name>? #13263
Users might intuitively think that a value matching <voice-family-name> can match <family-name>. Should <family-name>, <generic-family-name>, <system-family-name>, be renamed to <font-family-name>, <generic-font-family-name>, <system-font-family-name>, for font properties?
I mainly renamed it to <voice-family-name> to avoid the naming conflict. Though I agree it makes sense to prefix the other data type names with font- to make the distinction even clearer.
No, because <font‑family‑name> implies that “Foo” is allowed to match all of “Foo Regular”, “Foo Bold”, “Foo Italic”, etc. depending on font‑weight and font‑style settings, whereas <font‑name> implies that “Foo” is only allowed to match a font named exactly “Foo”.
I am not comfortable making changes at the moment.
<family-name>, <generic-font-family>, <system-family-name>, are a little confusing to me.
My understanding is that they are all font family names and that <system-family-name> is separated because it cannot be used in font-family, since other font properties would not apply.
But I am not sure why <generic-font-family> is separated and why it does not have the -name suffix. "Generic family names" and "generic family keywords" are both used in prose.
And I do not see what other properties, besides its name, a font family can have, so "font family name" seems redundant to me.
Finally, I am not sure how to update the Changes section. I do not know if I should leave its entries related to the renamed productions and if I should only add "- Renamed <*-family-name> to ...".
So to continue/answer my previous comment, <generic-family> and <system-family-name> are both excluded from the set of all font families because they are valid only in specific contexts:
font for <system-family-name>
font-family for <generic-family>
<family-name> is the only production used in different contexts: @font-face/font-family, @font-face/font-src, @font-feature-values, @font-palette-values.
As defined in the spec, a generic font family keyword is an alias for one or more font family names, which appears to be the only reason for the family name redudancy. In my opinion, the use of generic font family name seems confusing. Referring to font family names and keywords as font families does not seem perfect, but it seems acceptable.
So my first thought was that, ideally, font-family should be defined with [<custom-ident> | <string> | <generic-font-family>]#, and that <'font-family'> should be used to define @font-face/font-family, @font-face/src, @font-feature-values, by excluding <generic-font-family> and <system-font-family> in prose when appropriate, which might not be ideal. So then I thought <user-font-family>, <generic-font-family>, <system-font-family>, could make sense.
But that was not the original purpose of this issue, which was to remove the ambiguity between voice and font families. I will therefore leave this suggestion to another issue, if it proves appropriate.
Most properties and productions that end in -name expect only author-defined idents (i.e. custom, dashed or string) or third-party names, see #13389 for an overview. For fonts, it is a mix of
<family-name>: font family names exposed by the operating system to the browser and further from there to the stylesheet based on (localized) names stored within the font files by their vendors,
<family-name>: custom font resource names specified by an author in @font-face rules,
<generic-family>: generic font family aliases, to be resolved by browser and OS to some appropriate font, as
<generic-complete> | <generic-incomplete>: predefined keywords or
<generic-script-specific>: predefined keywords within the generic() function and
<system-family-name>: font aliases as keywords for the font shorthand.
For legacy reasons, the font-family property and the font-family descriptor within @font-face are using the same production <family-name> (which is proposed to be renamed to <font-family-name> above). This was a mistake in hindsight, because the property needs to support 1. and 2., whereas the descriptor only needs to support 2.
I am not sure whether it would make sense to introduce an artificial distinction for font-family now while at it:
Make the the value of the descriptor a new production like <font-face-name> = <string> | <custom-ident>+ (i.e. no effective change due to web compatibility).
Make the value of the property [ <font-family-name> | <generic-font> ]# with <font-family-name> = <font-name> | <font-face-name> and <font-name> = <string> | <custom-ident>+, also without effective change.
Rename <system-family-name> to <system-font> (as it is a predefined keyword and not a custom identifier and also used within font only, not in font-family).
Rename <generic-family> to <generic-font>, or keep as is; perhaps adapt <generic-script-specific>, <generic-complete> and <generic-incomplete> accordingly.
PS: Note that the voice-family property has no at-rule partner (yet), its generic families work differently and its <voice-family-name> therefore only covers case 1, which I‘m proposing <font-name> for – so <voice-name> would be a systematic equivalent.
Activity
SebastianZ commentedon Dec 24, 2025
I mainly renamed it to
<voice-family-name>to avoid the naming conflict. Though I agree it makes sense to prefix the other data type names withfont-to make the distinction even clearer.@svgeesus What's your opinion on this?
Sebastian
Crissov commentedon Dec 26, 2025
Wouldn’t it be still unambiguous (but a bit more readable) if
…-family-namewas shortened to-namein all cases?ExE-Boss commentedon Dec 26, 2025
No, because
<font‑family‑name>implies that “Foo” is allowed to match all of “Foo Regular”, “Foo Bold”, “Foo Italic”, etc. depending onfont‑weightandfont‑stylesettings, whereas<font‑name>implies that “Foo” is only allowed to match a font named exactly “Foo”.svgeesus commentedon Dec 26, 2025
@cdoublev please feel free to make a PR for this
cdoublev commentedon Dec 27, 2025
I am not comfortable making changes at the moment.
<family-name>,<generic-font-family>,<system-family-name>, are a little confusing to me.My understanding is that they are all font family names and that
<system-family-name>is separated because it cannot be used infont-family, since other font properties would not apply.But I am not sure why
<generic-font-family>is separated and why it does not have the-namesuffix. "Generic family names" and "generic family keywords" are both used in prose.And I do not see what other properties, besides its name, a font family can have, so "font family name" seems redundant to me.
Finally, I am not sure how to update the Changes section. I do not know if I should leave its entries related to the renamed productions and if I should only add "- Renamed
<*-family-name>to ...".svgeesus commentedon Dec 27, 2025
It is fine, I can do that.
This is why I tend to use non-linked text in the changes section
That is what I would do.
cdoublev commentedon Dec 28, 2025
So to continue/answer my previous comment,
<generic-family>and<system-family-name>are both excluded from the set of all font families because they are valid only in specific contexts:fontfor<system-family-name>font-familyfor<generic-family><family-name>is the only production used in different contexts:@font-face/font-family,@font-face/font-src,@font-feature-values,@font-palette-values.As defined in the spec, a generic font family keyword is an alias for one or more font family names, which appears to be the only reason for the family name redudancy. In my opinion, the use of generic font family name seems confusing. Referring to font family names and keywords as font families does not seem perfect, but it seems acceptable.
So my first thought was that, ideally,
font-familyshould be defined with[<custom-ident> | <string> | <generic-font-family>]#, and that<'font-family'>should be used to define@font-face/font-family,@font-face/src,@font-feature-values, by excluding<generic-font-family>and<system-font-family>in prose when appropriate, which might not be ideal. So then I thought<user-font-family>,<generic-font-family>,<system-font-family>, could make sense.But that was not the original purpose of this issue, which was to remove the ambiguity between voice and font families. I will therefore leave this suggestion to another issue, if it proves appropriate.
Crissov commentedon Jan 25, 2026
Most properties and productions that end in
-nameexpect only author-defined idents (i.e. custom, dashed or string) or third-party names, see #13389 for an overview. For fonts, it is a mix of<family-name>: font family names exposed by the operating system to the browser and further from there to the stylesheet based on (localized) names stored within the font files by their vendors,<family-name>: custom font resource names specified by an author in@font-facerules,<generic-family>: generic font family aliases, to be resolved by browser and OS to some appropriate font, as<generic-complete> | <generic-incomplete>: predefined keywords or<generic-script-specific>: predefined keywords within thegeneric()function and<system-family-name>: font aliases as keywords for thefontshorthand.For legacy reasons, the
font-familyproperty and thefont-familydescriptor within@font-faceare using the same production<family-name>(which is proposed to be renamed to<font-family-name>above). This was a mistake in hindsight, because the property needs to support 1. and 2., whereas the descriptor only needs to support 2.I am not sure whether it would make sense to introduce an artificial distinction for
font-familynow while at it:<font-face-name> = <string> | <custom-ident>+(i.e. no effective change due to web compatibility).[ <font-family-name> | <generic-font> ]#with<font-family-name> = <font-name> | <font-face-name>and<font-name> = <string> | <custom-ident>+, also without effective change.<system-family-name>to<system-font>(as it is a predefined keyword and not a custom identifier and also used withinfontonly, not infont-family).<generic-family>to<generic-font>, or keep as is; perhaps adapt<generic-script-specific>,<generic-complete>and<generic-incomplete>accordingly.PS: Note that the
voice-familyproperty has no at-rule partner (yet), its generic families work differently and its<voice-family-name>therefore only covers case 1, which I‘m proposing<font-name>for – so<voice-name>would be a systematic equivalent.