Re: [csswg-drafts] [selectors-4] Clarify :lang() behavior when the language range is not a well-formed BCP 47 code (#8720)

Yes, that's my understanding. In order to do any matching, we'd be requiring the tag to be _well-formed_ (so that it's clear how the matching algorithm behaves), but it need not necessarily be _valid_.

As noted in RFC5646:

> A tag is considered "well-formed" if it conforms to the ABNF
>   ([Section 2.1](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)).  Language tags may be well-formed in terms of syntax
>   but not valid in terms of content.  However, many operations
>   involving language tags work well without knowing anything about the
>   meaning or validity of the subtags.

The concern in this issue is about _ill-formed_ tags, which IMO cannot meaningfully be matched via RFC 4647. `lang=qq` is _well-formed_, so its matching behavior is well-defined despite not being a _valid_ language tag.

Regarding the proposed resolution:

> Selectors 4 should state that any `:lang()` argument that cannot be parsed with the BCP-47 syntax causes the selector to not match

This only mentions the argument of `:lang()`, and not the content of the `lang` attribute. ISTM that the `lang` attribute must also be well-formed in order for matching to happen. So should we add a second clause to the proposed resolution?

> ... and any `lang` attribute that is not well-formed according to BCP-47 syntax never matches any `:lang()` selector.

Thus, even `:lang("*")` should _not_ match junk such as `lang="something-random"`.

-- 
GitHub Notification of comment by jfkthame
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8720#issuecomment-4081363205 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 18 March 2026 10:25:34 UTC