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

[Ashley Sheridan]

> >
> > 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
speeds).

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.

Thanks,
Ash

http://www.ashleysheridan.co.uk