Re: [css3-syntax] !important vs. ! /**/ important

On Sun, Jan 27, 2013 at 9:50 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Reminder: CSS 2.1 Appendix G allows whitespace and comments between '!' and
> 'important'. There was some discussion of not allowing this in css3-syntax.
>
> Previous discussion starts here:
> http://lists.w3.org/Archives/Public/www-style/2012Aug/0197.html
>
> Test cases: (All green in Gecko, only the last one in WebKit and Presto, all
> red in Trident.)
>
> data:text/html,<p style="color: green !/**/ important; color: red">test
> data:text/html,<p style="color: green !/**/important; color: red">test
> data:text/html,<p style="color: green ! important; color: red">test
>
> I don’t really care either way, as long as it’s specified. The question
> initially came up in the context of comments in
> CSSSupportsRule.conditionText serialization:
>
> http://lists.w3.org/Archives/Public/www-style/2012Aug/0142.html
>
>
> AFAIR the WG still has to decide what to do about this. But in the meantime,
> the ED is inconsistent. §3.6. "Changes from CSS 2.1 Core Grammar" has:
>
>> No whitespace or comments are allowed between the DELIM(!) and
>> IDENT(important) tokens when processing an !important directive at
>> the end of a style rule.
>
>
>
> But §3.5.10. "Declaration-important mode" has:
>
>> whitespace token
>> comment token
>>     Do nothing. Remain in this mode.
>
>
> Removing one of the quoted parts would make the draft consistent.
>
> If the part in §3.5.10 is removed (ie. no change from CSS 2.1 in parsing
> !important) then comments are ignored in every Tree Construction mode. They
> might as well not be emitted by the tokenizer.

Other way around, you mean - if the part in 3.6 is removed, we'll just
match 2.1.

And... I didn't think of the fact that we can just ignore comments
entirely if I match 2.1 there.  I was caught up on the serialization
problem, but we already decided that the serializer will handle
inserting comments in places where adjacent tokens won't round-trip.
Awesome.

So, I'll remove the mention in 3.6, never emit comment tokens, change
the list of tokens you'll see in the parser, and remove all mentions
of comments in the parser.  Then I'll put in a note that serialization
should handle the roundtripping problem.


> Back to serialization: I guess we need either to make the serializer smart
> about where to insert empty comments (is the serializer specified
> somewhere?), or make comments preserved tokens.

Serialization is not yet specified.  I think it's appropriate to put
in a serializer requirement in this spec, though.

~TJ

Received on Monday, 28 January 2013 06:02:05 UTC