Re: [css3-syntax] Separation of concerns: "declaration/rule-filled", "can be made important"

Le 27/01/2013 06:01, Tab Atkins Jr. a écrit :
> On Sat, Jan 26, 2013 at 10:03 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
>> Is it guaranteed that an at-rule’s name (its at-keyword) is and will even be
>> enough to decide 1.? In other words, 1. does not depend on the at-rule’s
>> context/parent or its prelude.
>>
>> If this is the case, tree construction could take a list of at-rule names
>> that information[1] as part of its "input", in addition to a list of tokens
>> and a quirks mode flag. The introduction of §3.5. Tree Construction should
>> be updated in that direction.
>>
>> [1] A mapping of at-rule names to declaration-filled/rule-filled/neither
>
> This is already assumed by the spec - you have to know whether the
> rule is rule-filled or declaration-filled by the time you hit the
> corresponding { token, so at *most* it could depend on the at-rule's
> name and maybe its prelude.  In practice, the name is enough.
>
> I'll try and make this more explicit.

Good, thanks.

For all at-rules we currently have, the name is enough yes. I’d just 
like to ensure it remains that way. That would be bad design IMO, but 
there could be a crazy at-rule that does something completely different 
at the top level or in @page.


> […]
>
> Descriptors only exist in at-rules so far (and likely forever), but
> keyframe blocks are style rules whose contents can't be made
> important.

Ah, I had missed that not all property declarations can be made important.


> However, I don't think I gain anything from going further.  I mean,
> the check for important-capableness has to occur in the parser.  The
> latest I can push it to is when the rule is popped and syntax-checked.
>   That doesn't really change anything.

I see. If syntax checking of property values (and shorthand expansion) 
happens as each declaration is parsed, this makes sense.

I’m writing CSS parsing libraries that are usable independently of a UA. 
For example, tinycss is used both in WeasyPrint (HTML+CSS) and CairoSVG 
(SVG+CSS). It could also be used in minifiers, or other tools that need 
to parse CSS but are not UAs. These tools may not have any knowledge of 
whether a declaration is valid, or if will be next year. This is 
especially important in server-side pre-processors that eventually 
target any web browser in existence.

So for me, the parser’s output is a tree as described in §3.5: 
selectors, at-rule preludes and declaration values appear as unparsed 
lists of primitives. It’s up to the caller to parse these further or 
reject them as invalid.

I’ll just consider that all declarations can be made important, and the 
caller can reject declarations based on the important flag. (Like option 
b. in my previous email.)

That a library implements 95% of a spec (and the caller has to do the 
remaining 5% itself) is a bit weird, but it’s an implementation concern 
that does not need to affect the spec.

-- 
Simon Sapin

Received on Sunday, 27 January 2013 08:30:12 UTC