Re: [CSSWG] Minutes and Resolutions 2009-08-05

On Thu, 6 Aug 2009, Zack Weinberg wrote:

> * Add the following new macros:
>
> {badcomment1}	\/\*[^*]*\*+([^/*][^*]*\*+)*
> {badcomment2}	\/\*[^*]*(\*+[^/*][^*]*)*
> {badcomment}	{badcomment1}|{badcomment2}
>
> {baduri1}	url\({w}([!#$%&*-~]|{nonascii}|{escape})*{w}
> {baduri2}	url\({w}{badstring}
> {baduri3}	url\({w}{string}{w}
> {baduri}	{baduri1}|{baduri2}|{baduri3}
>
> * Replace the INVALID production with
>
> BAD_STRING	{badstring}
> BAD_COMMENT	{badcomment}
> BAD_URI		{baduri}
>
> * Add prose to ЪЪ4.2 explaining that while each of these is an automatic
>  syntax error, the recovery behavior is different: BAD_STRING triggers
>  the "unexpected end of string" rule, BAD_COMMENT is just discarded,
>  and BAD_URI is treated as an unexpected FUNCTION token.

terrible.

S { P : url(-my-hack()); }

current token stream:
   FUNCTION('url(') + FUNCTION('-my-hack(') + ')' + ')';
syntactically correct && produce expected parsed tree.

new token stream:
   BAD_URI('url(-my-hack') + '(' + ')' + ')';
i miss something or what it supposed to be?

anyway, 'improve perfoprmance' of particular [imaginary] impl with
particular tool is not a rationale for changing core css syntax.