Here is what I believe is the best proposition yet for managing our responsive designs. This includes managing our CSS, JavaScript, and inline <img>\u2019s.<\/p>\n
<head>\r\n <meta name='case' data='breakpoint1' media='min-width:350px' \/>\r\n <meta name='case' data='breakpoint2' media='min-width:1000px' \/>\r\n<\/head><\/pre>\nDeconstructing the case for breakpoint management in <head><\/h2>\n
To re-cap our current problems with breakpoint management; we write our Media Query\u2019s dozens of times in CSS files, we write the same tests in our JS files, and we will soon write them inside every <picture> element too. The same tests, in every case, but with a different \u201cdo something if true\u201d instruction. That\u2019s wasteful in terms of repetition, becomes very hard to manage, requires continuous re-processing of a test that never changes, and is future unfriendly.\u00a0Read more detail here<\/a>.<\/p>\n
So why does that code up there solve all these issues?<\/p>\n
At first glance, that code is going to cause many people a few frowns. We are not used to seeing this sort of thing – meta elements are supposed to describe a property of the URI aren\u2019t they? Well, no. We already set meta elements that do not describe a property of the loaded URI – all of us do. Every time we set <meta name=”robots” content=\u2019index,follow\u2019 \/> or any associated instruction. Or when we tell Google Translate to not run on the page. Or when we tell IE not to use its picture menus. These are all examples of using a meta tag to control the behaviour of some software that\u2019s consuming the URI\u2019s HTML, and not to describe properties of the page itself.<\/p>\n
What the code above does is set \u2018case\u2019 to equal a particular value, when a media query expression is matched. And if that\u2019s done in the HTML <head> we know that absolutely everything else can rely on it – the <head> is the very first thing parsed by a browser, even before anything inside <body>. Anyone familiar with working on the \u2018responsive images\u2019 problem should at this point be getting very excited. It means that the browser can be aware of the need to adapt\u00a0before<\/em>\u00a0any pre-fetch behaviours have been triggered by finding an <img \/> element in the mark-up.\u00a0That is a major advantage and is how this solution solves the problem of image pre-fetch.<\/p>\n
Some people will be uncomfortable with having the queries in the head, but I’d say putting the queries into the CSS is, most of the time, backward \u2013 it\u2019s just that we\u2019re used to doing it that way so it makes a certain kind of sense.\u00a0Remember that the order we actually build a site goes like this:<\/p>\n
1) Consider a device size
\n2) Create a design for that size on paper or in Photoshop
\n3) Write the code to implement it
\n4) Increase device size and goto 1<\/p>\nAll of our code is actually hanging off the same media query breakpoints, because they’re the design breakpoints. So why re-define the same tests in each technology rather than do it once in HTML and have the CSS and JS just reference them? We could still do specific tasks in the “old” way, if desired.<\/p>\n
How would we use these <meta> elements?<\/h2>\n
In HTML<\/h3>\n
Addressing first how we might use it to control <img\/> in our mark-up:<\/p>\n
<body>\r\n <img src='\/content\/images\/{case}\/photo.jpg' alt='' \/>\r\n<\/body><\/pre>\nWhat has this bought us?<\/p>\n
\n
- Well, we have a single image element with no custom properties or other code, which will adapt to any number of breakpoints you want to declair, without ever adding another character to the image code.<\/li>\n
- We have something that is backward compatible\u00a0right now<\/em>: either create a directory called \u201c[case]\u201d so that a file exists there, or if you want to be cleverer about it, set your server to alias [case]\u2019s path to an already existing path.<\/li>\n
- The image is cachable by proxies and CDNs because the source for each version of the image has a unique URI.<\/li>\n
- UPDATE: By using {} instead of [] this solution is actually complying with the URI Template<\/a>\u00a0too (See the RFC<\/a>) – thanks Brett<\/a>!<\/li>\n<\/ol>\n
Are there any drawbacks?<\/p>\n
None that I can see. Even with the current\u00a0proposal, we should never change the alt attribute because all resources are supposed to have the same semantic meaning.<\/p>\n
In CSS<\/h3>\n
Rather than writing endless clauses like this, where a test must be performed each time:<\/p>\n
@media only screen and (min-width: 700px) { ... }<\/pre>\nWe could write this instead:<\/p>\n
@media (case: breakpoint1) { ... }<\/pre>\nWhat has this bought us?<\/p>\n
\n
- We are abstracting the test itself away from the block of code that defines a response. This means if we decide to change the breakpoint condition, we do it\u00a0once<\/em>\u00a0in the <head> and everything else works automatically.<\/li>\n
- We reduce the number of tests required of the browser. It\u2019s not re-running a test, it\u2019s instead checking the value of case – which has already been computed.<\/li>\n
- We have smaller code. Yeah, i know, it\u2019s a tiny point but it\u2019s a benefit non the less.<\/li>\n<\/ol>\n
Are there any drawbacks?<\/p>\n
Not that I can see, because you can still carry on using existing syntax if you like, this is just an additional capability we may want to take advantage of. It can also be used in all the same ways you use any existing media-query.<\/p>\n
In the case of JavaScript<\/h3>\n
It\u2019s largely the same as for CSS. Instead of doing its own tests, it can just use whatever value is stored in the \u2018case\u2019 node. There is prior art for this: the behaviour here would be exactly the same as the wonderful shiv that a lot of people are now using Conditional CSS<\/a>, but it’d check against the meta element and not the body:before pseudo element.<\/p>\n
So why might this not work?<\/h2>\n
I\u2019ve only analysed this from the perspective of an author. I do not know how much effort it might be for a browser vendor to actually implement, and whether they would be willing to do so. For me, this is the only potential downside to the whole idea – it needs the vendors to implement it. In terms of functionality and benefits of the approach, i can see no downsides to the idea itself.<\/p>\n
I think vendors may object initially to the idea of browsers having to do this:<\/p>\n
1) detect the existence of a specific meta tag<\/p>\n
2) if it exists scan all src=”” properties for the variable string to replace with the variable value<\/p>\n
If no meta tag was there, it wouldn’t have to do anything with the src strings.<\/p>\n
How likely are variables?<\/strong><\/p>\n
There is a history of our core technologies not supporting Variables, but there is a trend of adding them recently:<\/p>\n
1) We now have variables in CSS (\u00a0http:\/\/dev.w3.org\/csswg\/css-variables\/<\/a>\u00a0)
\n2) We now have variables in URIs (\u00a0http:\/\/code.google.com\/p\/uri-templates\/<\/a>\u00a0)
\n3) We\u2019ve always had variables in JS<\/p>\nSo, HTML\u2019s the last one standing without support for variables.<\/p>\n