-
Notifications
You must be signed in to change notification settings - Fork 717
[css-font] Clarify what value is invalid for font-language-override and why it shouldn't generate parse error #1104
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
Comments
Some OpenType language system tags are four letters long ( |
I guess that means the spec needs some change anyway. |
Given font-language-override is at-risk due to only one implementation, maybe move this to level 4? Still needs discussion and resolution though. |
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. |
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. |
The Working Group just discussed
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 |
From the OpenType spec:
That seems abundantly clear, and we already link to that definition. |
@upsuper I moved the font-language-override section to Fonts 4, and then changed this
to
Can you confirm that this solves your issue? |
Does that mean the user agent should discard an unknown tag, so it doesn’t affect glyph selection or placement; or that it should pass the unknown tag through to the renderer, where it might have an effect but probably won’t? |
User-agents should pass it through. If the font supports some language that the browser has never heard of, there's no reason it shouldn't work correctly. |
@litherum agreed. Could that be made clearer in my new text? |
The current text still says “single three-letter case-sensitive OpenType language system tag”. Actually, it’s a string of four ASCII printable characters, where no space precedes a non-space. CSS should allow any such string for |
It now says:
|
The spec currently says the
<string>
value offont-language-override
isbut it also states that
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.
The text was updated successfully, but these errors were encountered: