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

Le 13/06/2012 14:35, Kang-Hao (Kenny) Lu a écrit :
> (12/06/13 19:24), Simon Sapin wrote:
>> Le 13/06/2012 12:29, Kang-Hao (Kenny) Lu a écrit :
>>> 1. If a tinycss UA doesn't update it's tinycss and things like '$foo:
>>> bar' becomes prevalent, would these input break the tinycss UA?
>>>
>>> Given that tinycss doesn't raise a exception to the UA, the answer here
>>> is normally "No", but if this tinycss UA serializes CSS (say, a
>>> minimizer) than the answer would be "Yes" (because '$foo: bar' is
>>> dropped). I am curious about other tools that might answer "Yes" here.
>>
>> No, nothing would break in this scenario. Older UAs with an older parser
>> will continue to see this input as invalid and drop declarations or rules.
>
> Why not? I think the comparison here is that serializing 'var-foo: bar'
> won't be broken while serializing '$foo: bar' will be, and the amount of
> '$foo: bar' out there were ignorable.

I don’t understand. Older UAs that do not support variables will 
continue to ignore variables declarations, and won’t break if they do 
not continue using compatible tinycss versions. By the way there is no 
serialization at all for declarations.


>> Officially tinycss only has a serializer for selectors and property
>> values. These are serialized exactly as parsed (the original strings are
>> preserved), so the serialization should not change even if the token
>> objects do.
>
> Which means that it handles 'var-foo' fine, right?

This is unrelated to serialization but yes, 'var-foo: bar' is a 
perfectly fine and normal declaration. It is up to the UA to treat 
specially properties whose name start with 'var-'.

tinycss is designed so that it does not have to be changed when a future 
CSS module adds the align-flex-background-text-origin property, as long 
as the property value can be parsed from existing tokens.


>>> I don't know what lessons can be learned here but my general opinion to
>>> css3-syntax "3.6. Tree Construction" and tinycss is that they should not
>>> drop anything when a "Parse Error" is encountered.
>>
>> Ignored stuff is not needed for an UA with cascade and all that. Keeping
>> it would help for minifiers. See the discussion at
>> https://github.com/SimonSapin/tinycss/issues/1#issuecomment-6298097
>>
>> This is a tinycss issue and has nothing to do with css3-syntax.
>
> I think the goal here is to make sure that css3-syntax doesn't trip
> ourselves 10 years later like CSS 2.1 Core Grammar is tripping us now.
> It's just a fact that folks on this list mention tools as reasons why we
> should not break the Core Grammar and adopt the '$foo: bar' proposal.
> While I don't like '$foo: bar' either, using the incomplete CSS 2.1 Core
> Grammar as a reason is just pretty lame.

I based tinycss on the Core Grammar on the hope that it would not 
change. It turns out that it under-specified in many corner cases 
(especially for error handling), so css3-syntax is needed.

In the future I will base tinycss on css3-syntax in the hope that it 
will never change. I really want to make sure we get it right this time!

It may be lame, but the fact remains that '$foo: bar' would require a 
change in tinycss while 'var-foo: bar' would not.

> [...]
>
> The reason I am saying this is that: The "3.6. Tree Construction" as it
> is is closer to tinycss than, for example, Gecko because Gecko doesn't,
> say, preserve unrecognized declarations. So, if tinycss has a way to
> guarantee a good amount of future-compatibility, say, to include
> css-heirarchy at least, it can be used as potential input to "3.6. Tree
> Construction".

I don’t understand how this is related to tinycss or Gecko’s parser, but 
I agree that css3-syntax needs to make sure that css-hierarchy or 
*something like it* is possible. Even if hierarchies in their current 
form end up rejected, we may want to add more stuff in style rules later.

(By the way, tinycss currently does *not* preserve invalid declarations.)

-- 
Simon Sapin

Received on Wednesday, 13 June 2012 14:20:03 UTC