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

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.

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.

This becomes a packaging issue: making sure that the UA does not use the 
latest version of tinycss, but one it is compatible with. The thing I do 
not know in advance if the next version is going to break compatibility 
or not. This could be addressed by a different version number scheme. 
But this is getting out of www-style’s scope. I invite to write on the 
WeasyPrint mailing-list if you want to discuss this particular point 
further.


> 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'

There are ways, but maybe not simple. At least by having new stuff 
enabled on-demand only, so that older UAs will get them disabled by default.

Actually there already is a mechanism in tinycss (through multiple 
inheritance of the parser class) to enable or disable features. 
Currently only Paged Media (parser support for margin boxes) works like 
this, but in the future media queries and @font-face would do that too. 
It is a bit superfluous in some cases (an UA could just ignore some 
at-rules) but it would be perfect for '$foo: bar'.

Syntax however is more fundamental. Supporting both Syntax 3 and the CSS 
2.1 core grammar (switching on demand) would require more code and 
maintenance than I’m willing to do at this point.

If someday tinycss is widely used and more stable itself I can make 
compatibility promises, deprecation cycles, etc. But in the current 
situation I prefer to make a single breaking release to switch to Syntax 
3 (when it is ready), and update WeasyPrint and CairoSVG.


> 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.


> 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".

If css3-syntax is not compatible with css-hierarchy, it is a spec issue 
that should be resolved in spec. It has nothing to do with tinycss or 
other implementations.

-- 
Simon Sapin

Received on Wednesday, 13 June 2012 11:25:24 UTC