Responsive design: fixing our sensors and technology.
This is a follow up from my previous post where I talked about the problems with our current approaches with HTML/CSS/JS in order to enable building responsive websites. Please read that post to understand why our current approach is not future-friendly, and will cause us problems in the long run. Here I propose a solution to those problems; it’s this:
<head> <respond> <breakpoint case="one" media="min-width:200px"/> <breakpoint case="two" media="min-width:400px"/> <breakpoint case="three" media="min-width:600px"/> </respond> </head> <body> <picture alt="An alt tag for the image"> <source src="mobile.jpg" match="one" /> <source src="medium-res.jpg" match="two" /> <source src="high-res.jpg" match="three" /> <source src="very-high-res.jpg" media="min-width:800px" /><!-- special case not templated --> <img src="mobile.jpg" /><!-- fallback for old browsers --> </picture> </body>
The idea behind this is to abstract the sensing from the asset negotiation. Because the sensing is so often the same, there’s no need to run the test on every single item we want to become responsive. The above pseudo code is a proposed method to template that solution. I should point out that another nice thing about taking this sort of approach (putting the sensing in the HTML head as a template) is that the CSS and the JS could all be made to inspect the breakpoint’s set in HEAD too, rather than having to re-declare the same tests in the CSS and JS files themselves. Meaning breakpoints are shared through the entire technology stack instead of being individually assigned, and the test is defined only once for the entire page.
The above approach would not stop us using existing methods to over-ride or expand on the templates either - if a particular use case does not fit with the defined template, do what we currently do and run a new test on that object itself.
Couple this approach with the likelihood of the media="” property being expanded to detect network speed and latency in the future, and this is a very flexible and DRY approach.
Note: I do not know whether this syntax is possible with HTML and whether or not it could be made possible if it isn’t now; it is merely an example to illustrait my thinking.