Re: [csswg-drafts] Poor description of :lang() psuedo class selector [css-3] [selectors-3] (#3022)

(Reviewing open issues as part of L4 horizontal I18N review)

While the offending text in this issue has been resolved, other changes to the text may have brought in language tag conversion through the back door. Specifically:

> The element’s [content language](https://drafts.csswg.org/css-text-4/#content-language) matches a [language range](https://drafts.csswg.org/selectors-4/#language-range) if its content language, as represented in BCP 47 syntax, matches the given language range in an extended filtering operation per [[RFC4647]](https://drafts.csswg.org/selectors-4/#biblio-rfc4647) Matching of Language Tags (section 3.3.2). Both the content language and the language range must be canonicalized and converted to extlang form as per section 4.5 of [[RFC5646]](https://drafts.csswg.org/selectors-4/#biblio-rfc5646) prior to the extended filtering operation. The matching is performed [ASCII case-insensitively](https://infra.spec.whatwg.org/#ascii-case-insensitive).

This requires the "content language" to be canonicalized and converted to extlang form using BCP47's rules. While garden variety strings like `en_US` or `it-IT.utf-8` or `English` can be "canonicalized" and potentially put into extlang form (before not matching very well). Should there be an explicit note about this?

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


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

Received on Thursday, 2 April 2026 13:59:17 UTC