RE: Comments

--- Bill dehOra <Wdehora@cromwellmedia.co.uk> wrote:
> Matthew,
> 
>  
>    :  When you refer to <whitespace>, I presume you
> mean the
>    :  S token.
> 
> S  
> :  [ \t\r\n\f]+
> 
>    :  However, } isn't a token at all.
>    :  Here's the definition of
>    :  ruleset
>    :    : selector [ ',' S* selector ]*
>    :      '{' S* declaration [ ';' S* declaration ]*
> '}' S*
>    :    ;
> 
> I assume that production was from D. Section 4.1.1
> core grammar has:
> 
> ruleset:
> selector? '{' S* declaration? [ ';' S* declaration?
> ]* '}' S*;
> 
> which is rather different.

Yes, but Appendix D is surely what we use.

> 
> 
>    :  ruleset isn't a token - tokens are indicated
> by
>    :  uppercase.
>    :  E.g., the following is:
>    :  P {color: red }
>    :  
>    :  one IDENT token, a { character, an IDENT
> token, a :
>    :  character, a S token, an IDENT token, a S
> token and a
>    :  } character.
>    :  
> 
> Now, I would read that from 4.1.1 as:
> 
>  IDENT { IDENT : S IDENT S }
> 
> where {{: are productions.
> 
> You may want to seek expert clarification from the
> authors: section 4.1.1
> names <{> and  <}> (along with other parens) as
> tokens at the lexical level
> in the regular expression token/definition table.
> That they are escaped
> literals does not remove their status as tokens
> there. 

Hmm. It should surely say this in D, which is the
grammar that is actually used, if this were so.

> In particular, note
> the statement 'The list of tokens for CSS2 is as
> follows' in par. 2. However
> as you point out they are identified as literals in
> D.1, and, in the core
> grammar. Consequently, the Flex generator turns them
> into literals.
> 
> As a matter of personal preference I prefer to work
> from the regular
> expressions, precisely because the literals are
> eliminated leaving only
> grammatical expressions. But then again my interest
> in CSS was writing a
> parser.
> 
>    :  It does say that at:
>    :   
>    :  <q
>    : 
>
cite="http://www.w3.org/TR/REC-CSS2/syndata.html#comments">
>    :  Comments may not be nested. 
>    :  </q>
>  
> That's comforting; it would have been better to have
> that in the regular
> expression productions in 4.1.1.

That's the problem with cutting corners and just
saying comments may go anywhere between tokens. It
would be much better and less ambiguous if comments
were included in the grammar.


=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Received on Tuesday, 14 December 1999 08:17:20 UTC