W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2017

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

From: Xidorn Quan via GitHub <sysbot+gh@w3.org>
Date: Thu, 16 Mar 2017 06:44:36 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-214612402-1489646674-sysbot+gh@w3.org>
upsuper has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-font] Clarify what value is invalid for font-language-override and why it shouldn't generate parse error ==
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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1104 using your GitHub account
Received on Thursday, 16 March 2017 06:44:42 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:30 UTC