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

(12/06/13 15:43), Simon Sapin wrote:
> First: I’ll call "UA" instead of "user" any software that uses tinycss
> as a library, to avoid confusion with the UA’s own end-user.

[keeping this terminology for later discussions]

>> 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
> 
> It really depends on how the change is implemented. For this particular
> change a new VariableDeclaration object could be added, or an
> is_variable flag could be added to Declaration objects. In either case,
> UAs that expect the older API will most likely "break": behave
> incorrectly on some inputs.
> 
> It might kind of work if I just use normal Declaration objects with a
> name that starts with $, but then '$foo: bar' would be the same as
> '\$foo: bar' so this would be a bad choice.

I think there are two questions here that can be made more precise.

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.

2. Is there a simple way that you can make tinycss support '$foo: bar'
without breaking any existing (or hypothetically existing) tinycss UAs
when they update their tinycss without updating itself?

I think the answer here is normally "Yes". It seems that either
VariableDclaration or the is_variable flag would work as long as the
name attribute is always set to "$foo" (to making sure that accessing
declaration.name doesn't throw) since current tinycss UA should just
ignore it (and wouldn't access is_variable anyway) because CSS doesn't
have a property like that.

On the other hand a tinycss UA that serializes CSS would be a "No" here
because '$foo: bar' would get serialized into '\$foo: bar'


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.

Given that tinycss has its design based on the CSS 2.1 Core Grammar, I
do think the job of css3-syntax is not only for browser convergence but
also for tool designer who wants to get an idea about how a CSS parser
is implemented. In particular, we should keep in mind that "3.6. Tree
Construction" isn't compatible with css-hierarchy and if I were to build
a parser like tinycss that guarantees forwards-compatibility, I could't
really just copy "3.6. Tree Construction".



Cheers,
Kenny

Received on Wednesday, 13 June 2012 10:30:20 UTC