- From: Ashley Sheridan <ash@ashleysheridan.co.uk>
- Date: Sun, 13 May 2012 12:53:24 +0100
- To: David Goss <dvdgoss@gmail.com>
- 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 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
Received on Sunday, 13 May 2012 11:54:01 UTC