Re: [Syntax Level 3]

On Tuesday 2012-08-28 14:42 -0700, Tab Atkins Jr. wrote:
> On Tue, Aug 28, 2012 at 2:36 PM, L. David Baron <dbaron@dbaron.org> wrote:
> > On Tuesday 2012-08-28 13:38 -0700, Tab Atkins Jr. wrote:
> >> On Tue, Aug 28, 2012 at 1:21 PM, L. David Baron <dbaron@dbaron.org> wrote:
> >> > On Tuesday 2012-08-28 12:37 -0700, Tab Atkins Jr. wrote:
> >> >> The point is that, as currently implemented, whenever I see a ! in a
> >> >> rule, I need to push it into a substack, along with all subsequent
> >> >> whitespace and comment tokens, until I see a token that's neither
> >> >> whitespace nor a comment.  If it's an IDENT(important), I throw away
> >> >> the stack and make the declaration important.  If it's anything else,
> >> >> I insert the entire stack into the declaration's value.
> >> >>
> >> >> This isn't hard.  It is, however, inelegant and *useless*.  There is
> >> >> absolutely no reason to allow this, and it would simplify parsers the
> >> >> spec and parsers to disallow it.  There shouldn't be any compat impact
> >> >> to the change.
> >> >
> >> > Why should we allow ! within values?  It seems already somewhat
> >> > established as a delimiter.  Can't it just always end the value at
> >> > the !, and then make the thing after it make the declaration invalid
> >> > if it's something other than IDENT(important)?
> >>
> >> I'm amused that your alternative to my syntax change is a larger
> >> syntax change. ^_^
> >
> > It's not really a change, though.  It's merely a removal of a
> > reservation of syntax.
> >
> > In other words, one way to look at the forward compatible grammar
> > is that it reserves large amounts of syntax for potential future
> > use.  What I'm proposing unreserves a tiny piece of it.  It doesn't
> > change the error handling behavior at all.
> >
> > Also, I'm not proposing that we change the forward-compatible syntax
> > to treat things with multiple !s in a declaration or with things
> > other than important after the ! any differently from any other
> > invalid declaration.
> >
> > I'm just proposing we don't allow ! inside the value of a variable
> > (which I think I'd proposed before), or inside the values of future
> > properties.
> 
> I'm not particular against this change.  It keeps the spec simple too,
> and I doubt it'll have much effect, so it's fine.
> 
> Question, though.  ! is still allowed inside of functions, just not at
> the top level of a declaration.  Are variables affected here?  That
> is, does a variable still do the basic parsing of "oh look, a function
> of some type", or does it preserve the value as a pure token stream?
> If the latter, do we need an exception here somehow?  (If the latter,
> I don't think it's acceptable to say "too bad, no ! in variables",
> because we may very well have functions that allow !s as parts of
> their grammar (perhaps as part of a selector), and we should be able
> to store these functions in a variable.)

I'd be proposing no ! at top-level of variables (just like there's
no ; at top-level of variables); it would be allowed inside of (),
{}, or [].

(We may also want to consider eliminating the restriction on <!--
and --> at top-level, as I mentioned in
http://lists.w3.org/Archives/Public/www-style/2012May/1104.html .)

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Tuesday, 28 August 2012 22:37:34 UTC