1

What does the author think of solutions like Sencha io.src?

http://www.sencha.com/learn/how-to-use-src-sencha-io/

posted at 09:56 am on January 31, 2012 by bombfrog

2 img element

A nice solution to harness <video>-like functionality. But rather than some new element like , I’d rather see the <img> element accept multiple sources like video does.

posted at 10:09 am on January 31, 2012 by Ralph Mason

3 Great article

This really hits the nail on the head – the responsive web should live in markup! Developers shouldn’t have to rely on various forms of scripting to achieve what, in theory, is a pretty simple (and increasingly necessary) task.

In all honesty I would hope by the time something like this was implemented bandwidth limitation issues would be nil; though, all the mobile bandwith caps out there are telling me I’m an idiot.

posted at 10:10 am on January 31, 2012 by awesomerobot

4

Hi there,

there’s a mailing list here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-January/034494.html but without my latest proposal (http://novolo.de/blog/2012/01/19/what-happened-to-responsive-assets/).
So picture element wouldn’t work best as described in mailing list. And we don’t even need a new element in my mind but need only to do it my second way (described in my article). My first approach with attributes would work, too, but is not that pretty.

So, let’s hope that one of the good solution is coming up soon to the spec. And, by the way, also recognize my CSS3/4 approach which would do the same for layouted styles.

-Anselm

posted at 10:10 am on January 31, 2012 by anselmh

7 Why not user agent detection?

I’ve heard several people say they are against using user agent detection. Could anyone elaborate as to why?

Just as HTML/CSS needs to mature to better adapt to different devices, it seems like if the user agent strings matured and became more descriptive they would be extremely useful.

posted at 10:45 am on January 31, 2012 by matudnorthrup

8

I first ran into this issue about 10 years ago while developing content for mobiles, and about 6 years ago while developing a social network aimed at (pre-smartphone) mobile devices I started using user agent detection as this was the only viable solution I could come up with. I know there’s a lot of them but there are ways around this, with the most obvious one being WURFL and a bit of server-side scripting to keep the database updated.

The platform I use for building websites now automatically detects the device type (and any needed media size properties) and stores them for the life of the user session (either in a cookie or in a session query string matched to a database record for devices that don’t support cookies) which allows me to implement responsiveness in markup by only ever serving the right image size in the HTML img tags in the first place (as well as sorting out which type of video embed to use, if any).

Related to this is the subject of bandwidth. One of the key issues I’ve had in building mobile-suitable sites is not actually bandwidth (although this is always an issue), it’s how large a page (combined HTML, markup and images) a device can actually display, with the most visible one being the old Motorola Razr v3. Some versions of this handset had a whole 10k of RAM available for rendering pages. Device detection allowed me to cater for even this restriction by automatically breaking large pages into smaller chunks for delivery to such devices by detecting the device in advance from the user agent.

However with most modern devices now reporting screen sizes (or easily derivable screen sizes based om generic user agent strings) and it very rare that a non-smartphone is being used to access the sites I build I’m actually finding less need for specific device detection at all.

posted at 10:56 am on January 31, 2012 by cro

9 Spot on

These are some fantastic methods. As a backend guy, I can plan for and supply the frontend with whatever fields they like, but knowing the possibilities is more important. Thanks for a great article!

posted at 11:06 am on January 31, 2012 by timothymahoney

10 re: why not UA

@matudnorthrup: I think the article says this in so many words, but while UA detection is probably the best tool for this task at the moment, that doesn’t negate the need for implementation of a standards, simple, front-end approach to this problem. UA is a tool that should never be ignored, but it’s an increasingly complicated tool to use for negotiating situations like this one, especially when you’re trying to build against future browsers rather than working around known issues of past ones. As Mat mentioned, the video and audio elements have already set a nice example of how markup alone can address this very problem, and if we can follow that model, it’ll greatly simplify our job as developers down the road.

posted at 11:07 am on January 31, 2012 by Scott Jehl