Re: [css-syntax] <an+b> grammar

On Fri, May 17, 2013 at 5:04 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Monday 2013-05-13 10:54 -0700, Tab Atkins Jr. wrote:
>> On Mon, May 13, 2013 at 10:49 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> > On Sat, May 11, 2013 at 1:36 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
>> >> Hi TJ,
>> >>
>> >> I like your new approach for defining an+b, but I think that the grammar is missing a few clauses for when A is implicitly 1:
>> >>
>> >> n+3
>> >> +n+3
>> >> -n+3
>> >
>> > Should be fixed now.  I had to add 8 more clauses to the production,
>> > but they group naturally with the existing ones, so it should still be
>> > easy enough to understand.
>>
>> I'll note, though, that this is now technically *slightly* more
>> permissive than the original grammar: if you use any of the "+n"
>> forms, whitespace is now allowed between the "+" and the "n", while it
>> was illegal originally.  I couldn't wipe that out without abandoning
>> property grammar entirely, since property grammar is entirely agnostic
>> to whitespace between tokens.
>
> We did intentionally decide not to allow whitespace.  I'd prefer to
> leave it that way; it could be confusing for authors if some
> variations allow whitespace in certain places and some don't, and
> I'm unhappy with the idea of signed numbers allowing whitespace
> between the sign and the number.
>
> Also, I don't see what in the spec says that this is "a property
> grammar" or what says that "a property grammar" allows implicit
> whitespace between tokens.  When I initially read it, I was about to
> send a comment that it needs to allow whitespace.

It's not well-defined, but CSS defines things with two types of
grammars: what I call "token grammars", which lean on specific tokens,
and pay attention to whitespace (but allow comments anywhere), and
what I call "property grammars", which lean more on types and
higher-level productions, and allow whitespace and comments anywhere.

If you want to use <an+b> in a property grammar, it needs to be
defined consistently with other property-grammar productions and
ignore whitespace; otherwise it's an (admittedly minor) layering
violation.  It turns out this isn't overly hard to do, except for this
one case.

(Given that we originally defined an+b with a completely different
tokenizer than normal CSS, I was rather surprised to find that this
was the only troublesome case in the entire grammar.)

(I'd also like to eliminate the concept of a token grammar.  It
doesn't buy us any favors; all it does is make some things more
annoying. For example, defining calc() is harder than just saying that
it's a <length> or whatever as appropriate, since you have to go mess
with the token grammars that expect literal dimension tokens.  It's
also far more difficult to get whitespace rules right, and easy to
nanny your way into unnecessary whitespace-related restrictions that
should just be guidelines instead.)

> One reason is that it would be very unexpected if switching a + to a
> - changes whether something is valid.  I'd far rather have both be
> an error than allow one and disallow the other.  (Switching a plus
> to a minus is something I expect authors would expect to be able to
> do without extensive testing.)

The reason I'm not particularly concerned about this is that it's a
useless clause anyway.  There's never a reason to write "+n", since
you can just write "n" and it's easier.  If you *did* write "+n" for
some reason, I have no idea why you'd write it as "+ n", given that "-
n", "+2 n", "+ 2n" are all invalid.

We could fix it another way, by changing the grammar and just disallowing "+n".

We can't disallow "-n", because code like "-n + 5" exists in decent numbers.

~TJ

Received on Saturday, 18 May 2013 19:16:23 UTC