W3C home > Mailing lists > Public > www-style@w3.org > December 2014

Re: [selectors] Clarification on :lang() with asterisks

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 10 Dec 2014 08:44:57 -0800
Message-ID: <CAAWBYDCkXoj2HAYW4WTdBYzE7TaPTBPp+zCmequ9nOkyZb5gCQ@mail.gmail.com>
To: Benjamin Poulain <benjamin@webkit.org>
Cc: "www-style@w3.org" <www-style@w3.org>, Dhi Aurrahman <diorahman@rockybars.com>
On Tue, Dec 2, 2014 at 5:34 PM, Benjamin Poulain <benjamin@webkit.org> wrote:
> Hi all,
> Dhi Aurrahman is extending WebKit's :lang() selector to support the asterisk
> matching added in http://dev.w3.org/csswg/selectors4/#the-lang-pseudo.
> He has raised an issue that needs clarification:
> It is possible to use asterisks in the argument of :lang() simply by
> escaping them in the identifier. For example, :lang(de-\*-DE) defines a
> valid identifier.
> Such input is correct in RFC 4647 (http://www.ietf.org/rfc/rfc4647.txt), a
> single asterisk subtag is a wildcard in the range-matching algorithm (3.3.2
> -> 3.A.).
> So far so good, except for Example 31 in the CSS Draft, there is the
> sentence: "Note that asterisks are not allowed anywhere else in :lang()'s
> language range syntax: they only have meaning, and are therefore only
> allowed, at the beginning.".
> I don't see any restriction to the language range syntax of RFC 4647
> anywhere else in the spec. I am not sure what the sentence means in the
> example, maybe the raw input instead of the language range?
> Basically:
> -Can escaped asterisks be used for wildcard matching described by RFC 4647?
> (IMHO, they should)
> -Can we get that behavior clarified in the text?

No behavior clarification needed; the note is non-normative, and the
example you give matches the grammar defined in the spec.  Once we get
a value that matches the grammar, we just pass it through to RFC4647,
so asterisks that have been escaped in the middle will work just fine.

However, the note can definitely be cleaned up, as it's misleading.

Received on Wednesday, 10 December 2014 16:45:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:49 UTC