W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: [css3-conditional] Where () are ok inside @supports?

From: L. David Baron <dbaron@dbaron.org>
Date: Thu, 24 Nov 2011 16:34:39 -0800
To: www-style@w3.org
Message-ID: <20111125003439.GA20458@pickering.dbaron.org>
On Wednesday 2011-08-10 17:18 +1000, Alex Danilo wrote:
> Hi David,
> --Original Message--:
> >I asked Vitor Menezes, an intern this summer at Mozilla, to work on
> >implementing @supports (as @-moz-supports).  He pointed out the
> >following problem with the grammar: The grammar currently *attempts*
> >to avoid allowing nesting extra sets of parentheses, e.g., to allow
> >  @supports (display:block) and (display:inline)
> >but disallow:
> >  @supports (display:block) and ((display:inline))
> >but it fails to do that in one case, which is that it allows double
> >(but not more) parentheses around the argument to "not".
> >
> >On reflection, I think forbidding doubling of parentheses is a bad
> >idea because it makes it harder for people to test things by
> >commenting them out.  In other words, since an author may want to
> >experiment with:
> >  @supports not ((display:block) and (display:inline))
> >by changing it to:
> >  @supports not ((display:block) /*and (display:inline)*/)
> >it should be legal to write:
> >  @supports not ((display:block))
> The nesting of brackets is sensible to an arbitrary depth.
> >Now, the one other thing I'm reconsidering is my idea of forbidding
> >the declaration not being in parentheses.  In other words, my
> >current grammar attempts to allow these:
> >  @supports (display:block) {}
> >  @supports (display:block) and (display:inline) {}
> >  @supports not (display:block) {}
> >but it disallows:
> >  @supports display:block {}
> >I'm inclined to remove that restriction as well and allow the last
> >of the above as well.
> If the property value can contain shorthand, then this may be a path
> to parsing pain. Perhaps it's more sensible to keep the brackets
> and if there's a good later need/agreement it's easy to remove that
> restriction.

Since this largely seemed to reflect consensus, I've updated the
editor's draft accordingly:
(at least assuming I got the grammar right).

Arbitrary extra parenthesis nesting is now allowed (a change).  This
makes things like these legal:
  @supports ((display:flexbox)) { ... }
  @supports not ((display:flexbox)) { ... }
  @supports (not (display:flexbox)) { ... }
(Though the middle one was previously legal by mistake.)

It's still disallowed to have the property:value pair right at top
level, i.e.:
  @supports display:flexbox { ... }
is still illegal; authors have to write:
  @supports (display:flexbox) { ... }

It's still legal to use 'not', 'and', and 'or' at toplevel without
parentheses.  The following are thus all fine:
  @supports not (display:flexbox) { ... }
  @supports (display:flexbox) and (transition: 2s) { ... }
  @supports (display:flexbox) or (display: -vnd-flexbox) { ... }

(I also caught a mistake where I forgot to allow whitespace after an
opening parenthesis.)


𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Friday, 25 November 2011 00:35:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:10 UTC