W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2016

Re: [csswg-drafts] [selectors][css-syntax] "parse a selector" missing trailing parenthesis

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Thu, 15 Sep 2016 20:47:38 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-247450865-1473972456-sysbot+gh@w3.org>
> Regardless, following the grammar, we end up not matching, so we 
should return failure.

Incorrect. It is *literally impossible* for you to fail to match a 
function/block due to a missing ending token like this, because that 
information is *completely erased* by the parsing process.  Token 
streams don't escape the Syntax spec; everything (explicitly or 
implicitly) uses one of the parsing entry points, and those collect 
functions/blocks automatically.  (In this case, this is unfortunately 
implicit; I didn't link the word "parse" to 
<https://drafts.csswg.org/css-syntax/#parse-grammar> like I should 
have. That's an easy fix.)

You can't pay attention to just Selectors.  The grammar that Selectors
 is *using* to define the selectors grammar is not derived from 
universal first principles; it's defined in the Syntax and V&U specs.
  This is somewhat implicit; we don't explicitly ref Syntax and V&U 
every time we use some of the value definition grammar, but everything
 in CSS uses it.  I'm happy to add some refs, but it's not exactly a 
killer issue; this is definitely in the "everyone knows what we mean" 

Syntax, then, defines how blocks and functions work, via the paragraph
 you quoted - you have to include the closing token in grammars, but 
they're not actually required when matching things against the 
grammar, because it's literally impossible to require such; the data 
model returned by the Syntax parsing algos doesn't include such 
information, just "functions" and "blocks" with contents.  Whether or 
not the ending token was present is *completely erased* by the time 
you get to the point of comparing a value against a CSS grammar.

>  and what is considered to define a function.

I guess I could put some redundant text being super-explicit about 
this? This runs real close to the "uh, obviously it means X" thing; we
 rely on a lot of implicit context in our definitions. I understand 
that you're coming at it from an "assume nothing, test everything" 
perspective, but still. ^_^

GitHub Notification of comment by tabatkins
Please view or discuss this issue at 
using your GitHub account
Received on Thursday, 15 September 2016 20:47:46 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:03 UTC