html filter for responsive
These days mobile-first responsive design is all the rage. And with good reason as at least the theory behind it should work for most websites. Things might be a little different for service-oriented sites who'd benefit from a more tailored solution, but responsive should be suitable enough for 75-80% of all the sites out there and would prove to be a great improvement over the current situation. There is one big hurdle left though, which lies with the served html between different resolutions.
This year's edition of 24ways.org provided two different solutions to incorporate "responsive images" in a webpage, both of them rather crappy hacks (said with the proper respect to those who uncovered these hacks - they're just not very pretty). More importantly, these proposed hacks don't even begin to fix the fact that we're sending way too much html to a device with a limited maximum resolution, only to hide it from view again after the html has arrived. Not what you call very efficient coding. I don't have a practical solution ready for you, but I believe it's still useful to try and define the goals and pitfalls of how responsive html could be achieved.
viewport vs resolution
One important thing to note is that the viewport size of the browser doesn't matter much when talking responsive html, it's the device resolution that matters. You should always send enough html to fully display the site on the current maximum resolution of the device, otherwise you could end up with too little html when someone is loading a site in a small browser window, only to remain like that when the window is enlarged. That's not very responsive now is it? So if we want to filter our html based on the clients' context, it should definitely be based on the device resolution instead of browser viewport size.
The first problem we face is trying to find out the client's resolution. This is easy when working client-side, but since we want to limit the html we are sending to the client based on the clients resolution, we should know about it beforehand. As far as I heard, it's not exactly impossible to do this (using redirects or other nasty solution), but there's no real clean way to get what we want before we start generating our html code. Setting a cookie after the first pageload is an option, but this is not ideal either. Maybe browsers could include this information in the request they are sending (no idea if any security risks are linked to sending this kind of info), but clearly that isn't happening yet.
A much dirtier way is to sniff for browser identification strings and make a base assumption about resolution on that, but that too is hardly an option worth pursuing I think. So for now, cookies are probably the best I can come up with.
direct filter or post-filter
The most efficient way to filter unneeded html is to filter it within the CMS (or whatever system you are using to generate your html). That way we can save server execution time as the back-end will only generate the necessary html the device resolution can handle. The downside is that you will need to support an endless list of CMSs, frameworks and languages and each implementation is custom development. Not a very global and/or centralized solution.
There is a much easier way to filter our html (though not as efficient). Rather than dive into the back-end html generation code, we could just wait until the html is ready for distribution, hijack it, filter it and send the filtered output to the client. This way we could write the application once and use it everywhere (as long as it is able to run on the server). Downside is that you're not only wasting time generating useless html, you're also wasting extra time filtering it afterwards.
Still, the second option sounds like the preferred solution to me. It's clean and straight-forward, it's centralized and maintainable.
filtering
The actual filtering shouldn't be too hard I think. If you look at how easy it is to manipulate the dom on client-side with javascript, a similar thing should definitely be possible on the back-end. If you write decent html your html code should be sufficient to define tasks based on dom queries (through css selectors or whatever). Imagine the following rule for small resolutions:
#page > #main > aside {display:none} Now imagine your filter just deleting the nodes that match the above selector from the html. Easy right? Not everything should be about deletion though, this would also be the perfect place and time to switch image resolutions for smaller resolutions, making the hacks described on 24ways.org obsolete.
conclusion
You might have noticed that this article is very much focused on theory instead of suggesting any practical solutions. The reason for that is actually quite simple: my knowledge of server-side implementation is staggeringly insufficient.
Still, I'm quite certain that a stand-alone html filter like this should make things very easy to brew responsive html versions of your site based on device resolution (and ideally also on available bandwidth, as this is an even more decisive factor). You would only need to focus on developing one application that could be used independently of the way a html page is generated and is easily configurable to mess about with the html.
I'm sure I missed some huge pitfalls in the process, if so tell me about them. If not, please build this thing as quickly as possible :)