- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 17 Dec 2007 15:30:19 +0200
- To: W3C Style List <www-style@w3.org>
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