Re: [css3-syntax] First draft of parser section completed

(12/06/12 22:48), Simon Sapin wrote:
> Le 12/06/2012 08:52, Kang-Hao (Kenny) Lu a écrit :
>> Can you provide some examples about this? Some objections to Core
>> Grammar changes are based on the assumption that changing it is breaking
>> tools, so it would be helpful to understand more about it.
> 
> Ok, here is an example:
> 
> tinycss 0.2 does not implement exactly the CSS 2.1 core grammar but
> something based on it. In particular, it has different token types for
> INTEGER and (non-integer) NUMBER.
> 
> In WeasyPrint 0.9 I have a function for each property that takes a list
> of tokens and parses the value. For example, the 'orphans' property
> checks that there is a single INTEGER token.
> 
> https://github.com/Kozea/WeasyPrint/blob/v0.9/weasyprint/css/validation.py#L652
> 
> 
> Now if tinycss 0.3 changes to match css3-syntax, the INTEGER token type
> will disappear and NUMBER tokens will get an 'is_integer' flag. When
> WeasyPrint 0.9 gets such a token for 'orphans', it will incorrectly
> reject it as invalid. Therefore, tinycss 0.3 will be
> backward-incompatible with 0.2 and WeasyPrint will need to be adapted.
> 
> This is not too much of a problem because I maintain both, but breaking
> stuff like this is not very nice to other users of tinycss. (I don’t
> know of any, but maybe they just don’t tell me.)

Thanks for the example!

>> 2. Is it possible to build a parser on top of tinycss which never throws
>> and follows the error handling rules of CSS 2.1 like a browser?
> 
> That is what it should do. And what it does, as far as I know. I use
> exceptions internally for flow control, but these are not supposed to
> interrupt the parser or to be propagated to the user.

Ah, I noticed that "raise"s in the source of tinycss but that the
"except:"s. So am I right that changing what's previously called "Core
Grammar" in CSS 2.1 would not break any use of tinycss since all such
error would have been caught?

I think I just mis-cited "tinycss" as a tool that might break if the
$foo proposal is accepted[1].

[1] http://lists.w3.org/Archives/Public/www-style/2012Jun/0085

>> 3. Does tinycss, as it is, need a special conformance class so that it
>> can be considered conforming (e.g. The HTML spec defines a bunch of
>> non-browser conformance classes. It also says a UA can do the error
>> handling *or* fail at the first error encountered.),
> 
> I don’t think that a special conformance class is needed. Actually
> css3-syntax already has this:
> 
>  # Certain points in the parsing algorithm are said to be parse errors.
>  # The error handling for parse errors is well-defined: user agents
>  # must either act as described below when encountering such problems,
>  # or must abort processing at the first error that they encounter for
>  # which they do not wish to apply the rules described below.
> 
> But I’m not sure that allowing to stop at the first "error" is a good
> idea. At least this is not what I want to do in my implementation. Error
> recovery and fallback are pretty fundamental in CSS.

Agreed. I think we should get rid of it if no tools really needs it. I
don't think this behavior was allowed in CSS 2.1.

>> since there are a bunch of test cases in the test suite which will
>>just make tinycss throw?
> 
> Such test cases just mean that I haven’t spent enough time testing. Is
> this in the CSS 2.1 test suite?

I just made early (and wrong) judgments when I saw the "raise"s. Sorry
about the confusion.


Cheers,
Kenny

Received on Wednesday, 13 June 2012 02:36:06 UTC