Impending problems with authoring responsive designs
Responsive design, for the moment, consists mainly of CSS that uses @media queries to selectively load and apply given styles. On it’s own, this is fine.
Sometimes we need to adapt the JS to a given breakpoint too, for example we’d like to turn a long navigation UL into a select box on mobiles, so that we can keep the functionality of a long navigation but without the problem of taking up the whole screen. To do that, we repeat the environment tests that are already in the CSS once again in the JS, and apply given rules.
There will soon be a HTML native method to retrieve a device appropriate <img>. It too will repeat the very same environment tests that both our CSS and JS have performed in order to modify their behaviour to the client’s capabilities. And in the case of HTML it will repeat these environment tests for every single <picture> on the page.
This is incredibly inefficient, and has the potential to make hand-authoring web documents implausible. Not to mention the problem that’s really to blame:
Our technologies need to sense the environment in unison and adapt to a design, not to a device.
It is the design that is the parent to which everything else should adapt; you never need a content image larger than the design is wide. You never need a background image larger than the design requires. You will always adapt behaviour inside of the restrictions of a design. The heirarchy of importance and reliance is Device > Design > [HTML/CSS/JS]. The device capabilities inform the design considerations which inform the language constructs. Right now we are authoring it in the wrong order, with the design being something that occurs at the end of that list.
The most important aspect of all is the environment the page is running in, which doesn’t change from test to test or technology to technology - and yet we are re-testing the same things three different ways for a single page.
What happens when it comes time to re-design? All of those environment tests are buried in each technology stack - you have to change three different code bases because of one design edit. And in the case of HTML, you will have to go through each and every <picture> element in your entire site in order to do this.
Madness.
So, I’d really like to see a unified environment language which the other technologies can inspect - instead of only being able to directly inspect the environment itself. I’d imagine something like a JSON configuration that effectively acts as an environment sensing template for the HTML, CSS, and JS. Each technology would be able to over-ride the template, but would ordinarily inherit from it - saving countless repetitions of the same sensing tests and making life a hell of a lot easier.
Entry Information
- Posted:
- Sun, 26th Feb 2012 at 20:02 UTC
- Filed under:
- Tags:
Comments
skip to comment formI think you're on to something. If there were some standardized way to include a design manifest - for lack of a better word - in a simple text-based format like YAML it would make this concept possible. Something like this could be possible using current technologies, but it would certainly rely on JS to parse the manifest and apply the appropriate @media rules within the client.
Not exactly elegant and it's definitely not a reliable solution. However, I think you're on to something that we've all been dealing with in our day-to-day work. It's an itch that needs to be scratched.
Jeff Croft has a similar post about this issue, he solves it by not using media queries, and instead doing it all via JS…
http://jeffcroft.com/blog/2012/mar/02/implementing-responsive-design/