- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 11 Nov 2014 16:14:01 -0800
- To: Benjamin Poulain <bpoulain@apple.com>
- Cc: www-style list <www-style@w3.org>
On Mon, Nov 10, 2014 at 9:17 PM, Benjamin Poulain <bpoulain@apple.com> wrote: > Hi, > > I am not sure what is the correct way to handle “invalid" language ranges > with :lang(). > > The draft says that :lang() accepts valid CSS identifiers > (http://dev.w3.org/csswg/selectors4/#the-lang-pseudo). > > RFC4647 is significantly more restrictive. > > Given the following values: > en- > en--us > It is no clear how to handle the step 3.3.2 of RFC4647. > > We could either ignore empty groups: > en- -> [“en”, “”] -> [“en”] > en--us -> [“en”, “”, “us”] -> [“en”, “us”] > > Or consider them part of the matching, in which case they always fail to > match since the normalized element’s language would never contains the empty > group. > > Is this defined anywhere by any chance? > I assume they should always fail for compatibility with Level 3. Tags like that are definitely valid at the CSS level; they don't trigger error-handling. Parsing and matching of language tags is defined by RFC4647; do whatever the RFC says to do for malformed language tags. If we assume that "en-" and "en--us" are valid (dunno if we should, I'm just doing a cursory skim of the RFC), then following 3.3.2's algo seems straightforward: you'll get empty groups, which won't match anything. ~TJ
Received on Wednesday, 12 November 2014 00:14:48 UTC