Repository navigation
[css-fonts] Rename <*-family-name> to <*-font-family-name>? #13263
Description
Activity
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
Reacted by ExE BossWouldn’t it be still unambiguous (but a bit more readable) if
…-family-namewas shortened to-namein all cases?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”.Reacted by Chris Lilley and Sebastian ZartnerI 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 ...".Finally, I am not sure how to update the Changes section.
It is fine, I can do that.
I do not know if I should leave its entries related to the renamed productions
This is why I tend to use non-linked text in the changes section
and if I should only add "- Renamed
<*-family-name>to ...".That is what I would do.
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.
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 forfont-familynow 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 withinfontonly, not infont-family). - Rename
<generic-family>to<generic-font>, or keep as is; perhaps adapt<generic-script-specific>,<generic-complete>and<generic-incomplete>accordingly.
- Rename
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.
3baba27 renamed
<family-name>to<voice-family-name>forvoice-*properties.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?