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

On Dec 12, 2007, at 18:09, Anne van Kesteren wrote:

> Now there is an open question on whether or not we want to use the  
> CSS parser for media queries used in other languages. This is  
> relevant for whether or not "all and (min-width:1p\x)" should work  
> in HTML, or "x,/**/all".
>
> 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?

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

> The disadvantage is that for non-CSS HTML implementations it would  
> be slightly more complicated to support <link rel=alternate  
> media=print href=print> for instance.
>
> Any feedback on this?


Some thoughts in no particular order:
  * 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.
  * 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.
  * 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.
  * Without escapes and comments, the media query syntax is just about  
simple enough to favor a manual implementation over using a parser  
generator.
  * 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?
  * 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.

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.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 17 December 2007 13:30:40 UTC