W3C home > Mailing lists > Public > www-style@w3.org > October 2012

Re: [css3-conditional] Resolving issues

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 12 Oct 2012 11:25:19 -0700
Message-ID: <CAAWBYDBfjZsp-4bnByUhbyeT_e5t4e1GQ7b0z0tEuWPVEe6Y5g@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style@w3.org
On Fri, Oct 12, 2012 at 5:27 AM, Florian Rivoal <florian@rivoal.net> wrote:
> But even then, I am still somewhat skeptical. According to
> http://www.w3.org/TR/CSS21/syndata.html#tokenization,
>   FUNCTION S* [any|unused]* ')'
> cannot match
>   ruleset( p{foo:bar} )
> unless you use the 'unused' production, which is documented
> as something that will never be used for anything be error
> recovery.

That's fine.  I see no use-case for matching a "ruleset" like that.
On the other hand, having a "selector()" or "at-rule()" function seems
useful in the future.

(The Syntax module has no need of such "unused" restrictions, by the way.)

> If we don't add this "| FUNCTION S* [any|unused]* ')'" to the
> supports_declaration_condition production in this level,
> nothing prevents us from adding "| 'block' '(' S* block ')'" in
> a future level, but if we do add "| FUNCTION S* [any|unused]* ')'",
> introducing things that look like a functional notation but don't
> actually match this production later risks being pretty awkward.

Actually, we *are* prevented from doing that.  An ident followed by a
( is a FUNCTION token automatically.  You can't work around the
FUNCTION restrictions like that.

Received on Friday, 12 October 2012 18:26:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:04 UTC