Skip to content

systemLanguage is not clear about case-insensitive matches #517

Closed

Description

@GLRoylance

Document structure chapter
Switch and systemLanguage
https://svgwg.org/svg2-draft/struct.html#SwitchElement

The systemLanguage attribute is a comma-separated list of BCP 47 langtags.

The SVG 2.0 spec states the systemLanguage attribute:

Evaluates to "true" if one of the languages indicated by user preferences exactly equals one of the languages given in the value of this parameter, or if one of the languages indicated by user preferences exactly equals a prefix of one of the languages given in the value of this parameter such that the first tag character following the prefix is "-".

The phrase "exactly equals" has misled many implementers. It would be better to state explicitly that the comparison is a case-insensitive match. For example, the langtag "en-US" is equivalent to "en-us". To most readers, it is not "exactly equals" but is "equivalent". Saying it is a case-insensitive match would just make it clear.

Clarity is an issue. Chrome and Firefox browsers currently use case-sensitive matches for systemLanguage. Consequently, systemLanguage="EN" evaluates to false but systemLanguage="en" evaluates to true on those browsers.

BCP 47 (https://tools.ietf.org/html/bcp47) implies that the case of the langtag does not matter when doing some operations, but doesn't actually make a clear statement that case does not matter for any comparison. You can search through the RFCs and find mention that case does not matter in some situations, but I did not find the broad statement.

Search the BCP 47 document for "insensitive" to find statements such as

At all times, language tags and their subtags, including private use and extensions, are to be treated as case insensitive: there exist conventions for the capitalization of some of the subtags, but these MUST NOT be taken to carry meaning.

and

Language tags and thus language ranges are to be treated as case-insensitive: there exist conventions for the capitalization of some of the subtags, but these MUST NOT be taken to carry meaning. Matching of language tags to language ranges MUST be done in a case-insensitive manner.

A better statement for the SVG specification would be (also using "language tag" instead of "language"):

Evaluates to "true" if one of the language tags indicated by user preferences is a case-insensitive match to one of the language tags given in the value of this parameter, or if one of the language tags indicated by user preferences is a case-insensitive prefix of one of the languages given in the value of this parameter such that the first tag character following the prefix is "-".

Interestingly, BCP 47 (RFC 4647 section 3) states

Protocols and specifications requiring conformance to this specification MUST clearly indicate the particular mechanism used in selecting or matching language tags.

SVG is a specification, but it has not clearly indicated the mechanism used in matching langtags. SVG 1.1 uses 3.3.1 Basic Filtering; there's a match if the basic filtered set is not empty. The SMIL allowReorder semantics are more complicated (and even ambiguous).

Activity

  1. jarek-foksa commented on Aug 9, 2018

    @jarek-foksa

    It's also worth mentioning that in CSS language matching is case-insensitive: https://drafts.csswg.org/selectors-3/#lang-pseudo

  2. longsonr commented on Aug 15, 2018

    @longsonr
    Contributor

    Firefox has switched to case insensitive matches recently. Note that it does allowReorder matching per the SVG 2 specification requirements.

  3. fsoder commented on Aug 15, 2018

    @fsoder

    Blink will switch to case-insensitive matching in the near future.

  4. AmeliaBR commented on Aug 24, 2018

    @AmeliaBR
    Contributor

    I agree with @GLRoylance's main argument that, if we are defining the attribute values in terms of BCP 47, we should be defining equality of two values according to that spec, too. So I'd count this as a "correction" rather than a "change". We've got one implementation already matching the correction, and another (per #517 (comment)) with a fix in process.

    If any of those implementations come with tests suitable for uploading to WPT, that would be very helpful, too! (Currently, there is only one old, manual test for systemLanguage.)

  5. AmeliaBR commented on Aug 24, 2018

    @AmeliaBR
    Contributor

    Addition: per Eric's informal tests, reported here, MS Edge also already supports case-insensitive matching.

  6. added a commit that references this issue on Aug 27, 2018
    2736064
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions