W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)

From: Ashley Sheridan <ash@ashleysheridan.co.uk>
Date: Sun, 13 May 2012 12:53:24 +0100
To: David Goss <dvdgoss@gmail.com>
Message-ID: <1336910019.2237.7.camel@localhost>
Cc: whatwg@lists.whatwg.org, James Graham <jgraham@opera.com>

> >
> > Also note that there is a great difference in implementation complexity
> > between various properties above. For example, viewport width/height is
> > rather easy to work with because one can assume it won't change between
> > prefetching and layout, so one can prefetch the right asset. On the other
> > hand switching based on containing element width/height requires layout to
> > happen before the right asset can be selected, so it has to be loaded late.
> > This will significantly decrease the perceived responsiveness of the site.
> >
> > Other properties like connection speed are very difficult to work with
> > because they can have high temporal variability e.g. due to sharing of one
> > connection by many consumers, due to temporary environmental conditions
> > (train goes into a tunnel) or due to switching transports (wifi to 3G, for
> > example). My suspicion is that trying to write a solution for switching
> > based on connection speed would lead to people getting the "wrong" assets
> > much of the time.
> So, if someone's connection speed changes dramatically when the image
> request has already started, they'll either get:
> 1 - a high res image, but slowly
> 2 - a low res image (relative to what their device can display)
> I'm not an expert on internet connections. I'd like to know,
> statistically, how likely it is that a user's connection speed will
> stay consistent (say +/- 20%) for a ten second period. Does anyone
> know of any research like this? If wireless internet connections were
> constantly all over the place it would be a concern, but as someone
> that uses them all the time it doesn't feel that way to me.
> I do appreciate that standardised connection speed testing is going to
> be hard. But if and when it comes, it should surely come in the form
> of a media query (as well as a JS API) in which case <picture> would
> support it automatically.
> > Note that these concerns argue, to a certian extent, *against* reusing a
> > very general syntax that can express constraints that aren't relevant to the
> > actual use cases, or that provide an attractive nuisance that encourages
> > developers to do things that can't be implemented in a performant way.
> Dumping <picture> as it is won't prevent this, as it's already in the
> door in the form of <video>.

This may not be as much of a problem as it seems though. A browser could
quite easily keep track of the connection speed over time and determine
a logical average. It could take into account things like the type of
network connection (e.g. a laptop may switch between wireless, tethered
phone or wired, and may move about between various networks of differing

This may even be available at the OS level (I believe a Mac allows for
various network configurations based on the network it's attached to)
which would allow for a better experience for anyone using multiple
browsers often.


Received on Sunday, 13 May 2012 11:54:01 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:42 UTC