- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Mon, 22 Oct 2012 19:05:02 +0200
- To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
- Cc: "www-style list" <www-style@w3.org>
| I can probably live with this, though requiring the explicit "all" is a | bit counterintuitive; it took me a sec to figure out why that works. As was previously noted, this is very similar to what other programming languages do. To me, it's not writing it that feel strange ;-) I think it keeps the structure clean. If we go for a solution where you don't have to wrap the "else residue" in a media section, (1) you have be sure it's impossible to get ambigous notations (what if you want a media rule to apply in your "else residue") and (2) you have a an element which can actually contains two kinds of very different content, and which apply a different treatment to them. For example [[ @pickone { html { ... } xml { ... } } ]] isn't very intuitive at all. The reality is that it doesn't pick one at all, but apply both rules. This is confusing. Also you have to make sure media queries come before any other declaration because [[ @pickone { @media x { ... } html { ... } @media y { ... } } ]] would have the strange behavior or "evaluating" the 'y' media before applying the 'html' rule which would be considered as part of the 'else residue'. Regarding case (1): @pickone media { (min-width: 1200px) { ... } (min-width: 800px) { ... } (all) { /* some rules for touch devices only */ @media (touch) { ... } /* some rules that apply for every phone */ input { ... } } } | > @pickone import { | > "desktop.css" (min-width: 1000px); | > "phone.css" (min-width: 480px); | > "small-phone.css"; | > } | | Again, a bit more implementation and spec work than simply allowing | @import inside @media, but doable. The win is that it is seriously less redudant and easier to read than @pickone { @media (min-width: 1000px) { @import "desktop.css"; } @media (min-width: 480px) { @import "phone.css"; } @import "small-phone.css"; } But this was just a response to your question "how can we generalize this to more cases", there's no obligation to actually implement that :-)
Received on Monday, 22 October 2012 17:05:11 UTC