Improve parsing behavior and WPT tests for font-language-override
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox111 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
Details
Attachments
(1 file)
I notice that we are failing a couple of subtests in https://wpt.fyi/results/css/css-fonts/parsing/font-language-override-invalid.html, which is unfortunate given that we're the only engine that currently implements the property at all.
I believe the two subtests we're failing there are actually bogus: they specify a two-character string, and a string with non-alphabetics. Neither of these are likely to actually match an OpenType language system tag found in a font, but they are not "invalid" from a parsing point of view.
The spec is a little vague on this; it first says that the string is a "single four-character case-sensitive OpenType language system tag", which would imply than any non-4-character string is invalid; but then goes on to say that if it "is shorter than four characters, it is padded at the end with space (U+0020) characters such that the length is 4, before being matched". And indeed, the spec goes on to give an example with font-language-override: "SRB"
(3 chars).
(The "before being matched" phrasing here suggests, I think, that this padding happens when the value is used during rendering, not at parsing time. So it won't show up in the serialized or computed value.)
So I think the test is wrong to expect a 2-char string to be rejected; and there's also nothing in the spec requiring the string to be alphabetic, so rejecting the string with punctuation characters is also wrong.
The OpenType spec does impose some constraints: it requires tags to be 1 to 4 ASCII bytes. Accordingly, I think strings longer than 4 characters (or entirely empty), or containing non-ASCII codepoints, should indeed be rejected (and we should clarify this in the CSS Fonts spec), as they are not valid OpenType tags, but shorter strings -- even though they may not match the usual convention for language system tags of being 3 or 4 uppercase letters -- should not be invalid here.
Assignee | ||
Comment 1•2 years ago
|
||
Updated•2 years ago
|
Comment 4•2 years ago
|
||
bugherder |
Description
•