Cloud Four Blog

Technical notes, War stories and anecdotes

Preferred solutions for responsive images

Scott Jehl recently tweeted:

Time to shift the responsive imgs discussion to how we'd actually prefer to do things, and then make it happen. Attrs? CSS? JS? New headers?

I concur. A couple of months ago, I asked what you preferred as a solution for responsive images. At the time, I didn’t have a strong opinion. But over the last couple of weeks, I’ve become increasingly comfortable with a direction that Scott Jehl, Ethan Marcotte and I discussed on twitter recently.

Short run solution: preparse attribute

In September, Scott Jehl proposed a solution that might be fairly easy for browser makers to implement in the short run: adding a preparse attribute to the script tag.

@grigs silly: <script preparse> //document.src references raw HTML src document.src = document.src.replace( pattern, replacement ) </script>

Like the defer and async attributes, there is a general use case for document authors to be able to tell the browser that a piece of javascript will impact the loading of assets and thus should be executed before parsing begins. There are probably even use cases that have nothing to do with asset downloading where telling the browser to execute javascript before parsing would be beneficial.

One of the other suggestions for solving this was for browsers to standardize on how they load assets. I don’t like that idea because it prevents browsers from experimenting on ways to parse pages and load assets more quickly.

If authors explicitly tell the browser when javascript loading matters (preparse, defer or async), it allows browser makers to experiment freely in other situations.

Long run solution: improvements to img tag

In the long run, I don’t like the idea that solutions require javascript. Images are content or presentation which means it should be possible to handle it with HTML and CSS alone.

Therefore, I would like to see one of these two improvements to the img tag:

<img alt="butterfly"> <source src="butterfly-small.png" media="max-device-width:480px" /> <source src="butterfly-large.png" media="min-device-width:481px" /> </img>

Modified from Bryan and Stephanie Rieger’s Rethinking the Mobile Web talk.

This is my preferred option, but I’m unclear on how older browsers would handle an image tag that contains child elements.

Isaac Lewis put together a test page using this style of markup. It would be great to collect some feedback on old browser support to see if it works or causes problems.

If that won’t work because of legacy browsers, the following variation proposed by Anselm Hannemann should:

<img src="http://cdn.url.com/img/myimage_xs.jpg" media-xs="(min-device-width:320px and max-device-width:640px)" media-src-xs="http://cdn.url.com/img/myimage_xs.jpg" media-m="(min-device-width:640px and max-device-width:1024px)" media-src-m="http://cdn.url.com/img/myimage_m.jpg" media-xl="(min-device-width:1024px)" media-src-xl="http://cdn.url.com/img/myimage_xsl.jpg" />

Why not headers?

I would love the browser to send more data to the server about the device making the request, but I don’t think servers should be necessary for the image tag to work in a responsive design.

I also think there is a decent chance that screen size is just the first of many headers we’d like the browser to send along. I don’t want to open up pandora’s box, but it would be nice to get something that felt more like a comprehensive solution instead of a bandaid.

Why not a different, progressive image format?

I’d love this, but feel wholly unqualified to judge what it would take. I’m not sure how long something like that would take to implement and what sort of patent minefield might lie there.

So let’s start with the preparse attribute

Unless someone points a major flaw with the preparse idea, I’m going to submit it as a feature request to the appropriate people to get the ball rolling.

Which reminds me, does anyone know where I should start? :-)

A Big Day for Lucid Meetings

Last year, John Keith, one of the founders of Cloud Four, started a side venture called Lucid Meeting. John doesn’t like Lucid Meetings to impinge on Cloud Four which is why you haven’t heard much about it on our blog. It is also the reason why I’m writing this post without his knowledge (sorry John!).

John and his co-founders at Lucid Meetings set out to make meetings that don’t suck. We’ve complained for years about rudderless meetings with no agenda, no leader and no follow up.

They decided to do something about it.

So Lucid Meetings started out focused on providing a way for people to set agendas, focus meetings, and take action items out of the meeting. Over the last year, it has grown into much more than that including:

  • Meeting minutes
  • Screen sharing and pdf presentations
  • Time tracking to keep people on task
  • Voting on motions and recording of decisions
  • Integrated conference calling

It is the last one that they’ve made big improvements on today. They’ve just shipped:

  • Free toll calling for every room up to 50 participants
  • Volume discounts for businesses that want to switch over

Those may not seem like a big deal on the surface, but the changes are huge because the combined solution is better than current web sharing and collaboration software at a price that is significantly cheaper.

Basically, you get something better and save money. Pretty much a no brainer if you’re doing any web conferencing or running remote meetings. Check it out.

What’s even more exciting for me is that all of this has been built by a small team with hard work and passion. They’ve had no outside investment. And they’ve built something that I think will have a big impact.

I’m very excited by what they’ve done thus far and what they’ve got planned on their roadmap. Congratulations to John and the Lucid Meetings team!

Clarification on device detection for images

Jeremy Keith has taken issue with my post about using device detection as a future friendly solution for responsive images. I think he missed the point.

The entire post was about what technique to teach in the book we’re writing. A book that has a deadline at the end of the month.

Jeremy writes:

The solution seems clear: we need to standardise on browser download behaviour …which is exactly what the HTML standard is doing (along with standardising error handling).

That would be awesome. Doesn’t help with the book. He continues:

That’s why I was surprised by Jason’s conclusion that device detection is the future-friendly img option.

Two bits of clarification:

  1. The thing that makes it future friendly isn’t the device detection. It is the fact that the markup is unchanged. It buys people time until either browsers standardize download behavior, we have a replacement for the image tag or someone finds a yet undiscovered way to solve this problem. Every other technique requires changes to the markup that are specific to a particular solution and rely on browser behavior that hasn’t been standardized.
  2. Again, my post was in regards to the questions I asked about which technique to teach in the book. I outlined the constraints of the book series and talked about how I entertained the idea of teaching the noscript technique before being talked out of it. Basically, I provided a lot of context for how I was evaluating the techniques for the book.

In addition to standardizing download behavior, Jeremy describes ways that he would like to see device detection improve. All of these are advances we’d welome. They are things that we might even have time to work on once the book is complete. But they aren’t the constraints I outlined in my posts and thus the rebuttal misses the mark.

So yes, device detection, as Jeremy says, is present-friendly way of keeping you from butchering your markup in a way that kinda, sorta works with today’s browsers, but may not work for tomorrow’s browsers.

However, having clean, semantic markup that so you can quickly replace device detection with a better solution in the future is the part that is attractive and arguably more future friendly than picking one of other unproven solutions and littering your markup in the hopes these solutions prove to work in the long run.

With that, I’ll conclude the same way I did my last post:

At least that’s how I see it for the book. For your project and use case, it depends.