From: Responsive Images Community Group
Managing responsive designs is hard, so let’s use our <head>
Here is what I believe is the best proposition yet for managing our responsive designs. This includes managing our CSS, JavaScript, and inline <img>’s.
<head> <meta name='case' data='breakpoint1' media='min-width:350px' /> <meta name='case' data='breakpoint2' media='min-width:1000px' /> </head>
Deconstructing the case for breakpoint management in <head>
To re-cap our current problems with breakpoint management; we write our Media Query’s 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 “do something if true” instruction. That’s wasteful in terms of repetition, becomes very hard to manage, requires continuous re-processing of a test that never changes, and is future unfriendly.Read more detail here.
So why does that code up there solve all these issues?
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’t 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=’index,follow’ /> 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’s consuming the URI’s HTML, and not to describe properties of the page itself.
What the code above does is set ‘case’ to equal a particular value, when a media query expression is matched. And if that’s 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 ‘responsive images’ problem should at this point be getting very excited. It means that the browser can be aware of the need to adapt before any pre-fetch behaviours have been triggered by finding an <img /> element in the mark-up.
How would we use it?
In HTML
Addressing first how we might use it to control <img/> in our mark-up:
<body> <img src='/content/images/[case]/photo.jpg' alt='' /> </body>
What has this bought us?
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.
We have something that is backward compatible right now: either create a directory called “[case]” so that a file exists there, or if you want to be cleverer about it, set your server to alias [case]’s path to an already existing path.
The image is cachable by proxies and CDNs because the source for each version of the image has a unique URI.
Are there any drawbacks?
None that I can see. Even with the current proposal, we should never change the alt attribute because all resources are supposed to have the same semantic meaning.
In CSS
Rather than writing endless clauses like this, where a test must be performed each time:
@media only screen and (min-width: 700px) { ... }
We could write this instead:
@media (case: breakpoint1) { ... }
What has this bought us?
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 once in the <head> and everything else works automatically.
We reduce the number of tests required of the browser. It’s not re-running a test, it’s instead checking the value of case – which has already been computed.
We have smaller code. Yeah, i know, it’s a tiny point but it’s a benefit non the less.
Are there any drawbacks?
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.
In the case of JavaScript
It’s largely the same as for CSS. Instead of doing its own tests, it can just use whatever value is stored in the ‘case’ node.
So why might this not work?
I’ve 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.
I think vendors may object initially to the idea of browsers having to do this:
1) detect the existence of a specific meta tag
2) if it exists scan all src=”” properties for the variable string to replace with the variable value
If no meta tag was there, it wouldn’t have to do anything with the src strings.
———–
N.b., This post is a re-post from a blog entry I wrote, it was suggested on Twitter that the Community Group should see it. Source: http://mattwilcox.net/archive/entry/id/1091/
The suggestions here are a mix from an older suggestion of mine which worked with <picture>, and the ideas of Denis LeBlanc