Re: [css3-mediaqueries] Request for feedback on syntax

On Mon, 17 Dec 2007 14:30:19 +0100, Henri Sivonen <hsivonen@iki.fi> wrote:
>> The advantage of simply using the CSS parser is that HTML  
>> implementations that also support CSS can easily reuse code.
>
> Given that the W3C CSS parser does not reuse code that way and that,  
> given your test results, Opera apparently doesn't, either, is code reuse  
> on this point a strong actual implementation pattern?

Actually, Opera does. It's just that we have some minor issues with CSS  
escapes in certain places because nobody is using (or testing) them.


>> Another advantage is that authors can simply copy and paste their media  
>> query and that the way media queries are treated is predictable.
>
> Assuming, of course, that the author hasn't obfuscated the query with  
> unnatural escaping. Besides, you still can't copy and paste if you have  
> obfuscated using HTML layer escaping.

True.


>   * The strongest reason for allowing the full CSS syntax with escapes,  
> comments and all in the HTML media='' attribute or in XML PIs would be  
> CSS parser code reuse in browsers if excluding the escape and comment  
> handling part would be an actual problem.

The other reason would be that this is what everybody is doing already.


>   * From the authoring point of view, I see no pragmatic value in the  
> ability to use escapes or comments in media queries. Comments inside a  
> media query in a media='' attribute would be almost like comments in  
> email header values. The all-ASCII nature of the media query syntax  
> makes escapes pointless.

I agree.


>   * Even if reusing a full CSS parser were the way to go, you'd still  
> have to introduce a new media query-only entry point to a full CSS  
> parser. A new API entry point would be needed no matter what. If the  
> parser itself is based on code generation from a grammar definition,  
> entering in the middle of the larger grammar is likely to be a problem  
> with the parser generator.

 From the feedback I got finding such an entry point seems to be not much  
of an issue.


>   * If escapes and comments could occur anywhere, it would be possible  
> albeit ugly to remove them as a preprocessing step. But I suspect  
> escapes would only be allowed in identifiers and comments only in place  
> of whitespace, which would preclude easy preprocessing. Is this the case?

Yes.


>   * Dealing with escapes and comments in one parsing pass would make the  
> resulting syntax sufficiently complex to need a parser generator instead  
> of quick hand-rolled code. When the complexity grows to the point that  
> developers would need to take the step of adding a parser generator  
> dependency to their projects, you lose correct ad hoc implementations.  
> In general, in Web format processing outside browsers, correctness  
> happens if it's easy or if it's available as an off-the-shelf module.

I'm currently hoping for the latter.


> So in summary: I see no value in escapes, etc. from the author point of  
> view or from the point of view of non-browser apps, but I realize that  
> making things easy for apps that include a full CSS parser trumps making  
> easy for other apps if there is an actual reuse win or actual coding  
> hardship from selective support of the CSS base syntax.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Monday, 17 December 2007 13:45:37 UTC