[css-font] Clarify what value is invalid for font-language-override and why it shouldn't generate parse error

[upsuper]

The spec currently says the <string> value of font-language-override is

single three-letter case-sensitive OpenType language system tag, specifies the OpenType language system to be used instead of the language system implied by the language of the element

but it also states that

Use of invalid OpenType language system tags must not generate a parse error but must be ignored when doing glyph selection and placement.

It isn't clear to me what does it mean by "invalid OpenType language system tags", and why an invalid tag "must not generate a parse error".

In my understanding, a tag which is longer or shorter than three-letter, or includes any character outside ASCII letters range, is invalid. And if it is that case, I think generating a parse error for that is a more future-proof way, since if at some point, people want to introduce new syntax for language tag, authors would be able to use the new syntax in a backward-compatible way.

If that "invalid" refers to tags which conform to the format above but are not listed in the table linked, I agree that they should not generate a parse error, since OpenType may add new tags in the future. But I think these two cases should be handled separately anyway.

[dscorbett]

Some OpenType language system tags are four letters long (IPPH). Some include digits (HYE0). In principle, a tag can include any character between U+0020 and U+007E.

[upsuper]

I guess that means the spec needs some change anyway.

cc @nattokirai @litherum

[svgeesus]

Given font-language-override is at-risk due to only one implementation, maybe move this to level 4? Still needs discussion and resolution though.

[litherum]

Yes to level 4, and yes to clarifying. My intuition is that it’s saying that the grammar shouldn’t include the set of current languages and should instead just look at the string length and character set. If that’s true, we should certainly clarify it.

[dbaron]

It's also somewhat unusual for CSS to have parsing errors that are internal to the contents of a string. It might make sense for all strings to be accepted, but ones that don't make sense to be rejected later.

[css-meeting-bot]

The Working Group just discussed [css-font] Clarify what value is invalid for font-language-override and why it shouldn't generate parse error, and agreed to the following resolutions:

• RESOLVED: Move the issue in https://github.com/w3c/csswg-drafts/issues/1104 to Fonts L4

The full IRC log of that discussion

<dael> Topic: [css-font] Clarify what value is invalid for font-language-override and why it shouldn't generate parse error
<dael> github: https://github.com//issues/1104
<dael> Chris: It is odd to have a parsing error based on string contents.
<dael> Chris: b/c font lang override is at risk anyway we should move this to L4. I'm fine with that.
<dael> astearns: I'm fine with moving to L4. myles is as well it looks.
<dael> astearns: Obj to moving this issue to Fonts L4?
<dael> RESOLVED: Move the issue in https://github.com//issues/1104 to Fonts L4

[svgeesus]

From the OpenType spec:

All tags are 4-byte character strings composed of a limited set of ASCII characters in the range 0x20 to 0x7E. Spaces (0x20) may only occur as a trailing sequence within the tag. As a general convention, capital letters (0x41 to 0x5A) are used. If a language system tag consists of three or less visible letters, the letters are followed by the requisite number of spaces each consisting of a single byte, to complete a 4-byte tag.
https://www.microsoft.com/typography/otspec/languagetags.htm

That seems abundantly clear, and we already link to that definition.