Re: [whatwg] Bandwidth media queries
On Wed, May 16, 2012 at 9:48 PM, Matthew Wilcox m...@matthewwilcox.com wrote: If you're a browser you are the software interpreting the instructions of a given language: CSS in this case. In addition to the problem that it's actually hard for browsers to know what the current bandwidth is especially on mobile networks, some of this responsive design threads assume that the author knows best when to withdraw content or content quality due to low bandwidth. From the user perspective, I think it's not at all clear that users always prefer to get less content when they are on a slower connection. Personally, I expect to see full content on a slow connection if I wait for long enough, but it's also annoying to have to wait for the whole page to load before the page is usable. The problem is that sometimes waiting is worth it and sometimes it isn't and the author might not know when the user considers the wait to be worth it. Unfortunately, the way the load event works makes it hard to make pages so that they start working before images are fully loaded and then keep improving in image quality if the user chooses to wait. Also, some browsers intentionally limit their own ability to do incremental rendering both to get better throughput and to get better perceptual speed in cases where the overall page load is relatively fast. On a very slow networks (GPRS or airline Wi-Fi) I think Opera Mini with *full* image quality provides the best experience: the page renders with its final layout and becomes interactive with images replaced with large areas of color that represents the average color occupying that area in the images. The images then become sharper over time. Thus, the user has the option to start interacting with the page right away if the user deems the image is not worth the wait or can choose to wait if the user expects the images to contain something important. (This assumes, of course, that the user is not paying per byte even though the connection is slow, so that it's harmless from the user perspective to start loading data that the user might dismiss by navigating away from the page without waiting for the images to load in full.) Instead of giving web authors the tools to micro-manage what images get shown in what quality under various bandwidth conditions, I think it would be better to enable a load mode in traditional-architecture (that is, not the Opera Mini thin client architecture) browsers that would allow early layout and load event and progressive image quality enhancement after the load event is fired and the page has its final layout (in the sense of box dimensions). I.e. have a mode where the load event fires as soon as the everything except images have loaded and the dimensions of all image boxes are known to the CSS formatter (and PNG and JPEG progression is used 1990s style after the load even has fired). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Bandwidth media queries
On 05/20/2012 03:04 PM, Boris Zbarsky wrote: On 5/20/12 5:45 AM, Paul Irish wrote: Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. This is not true. There is an implementation for Firefox Android which is based on the connection type. -- Mounir
Re: [whatwg] Bandwidth media queries
On 5/21/12 10:09 AM, Mounir Lamouri wrote: On 05/20/2012 03:04 PM, Boris Zbarsky wrote: On 5/20/12 5:45 AM, Paul Irish wrote: Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. This is not true. There is an implementation for Firefox Android which is based on the connection type. Ah, indeed. I had missed that codepath. If I'm reading the right code now, that looks like it returns a constant value for each connection type (e.g. if you're connected via Ethernet or Wifi it returns 20; if you're connected via EDGE it returns 0.2, etc). -Boris
Re: [whatwg] Bandwidth media queries
On 05/21/2012 04:34 PM, Boris Zbarsky wrote: On 5/21/12 10:09 AM, Mounir Lamouri wrote: On 05/20/2012 03:04 PM, Boris Zbarsky wrote: On 5/20/12 5:45 AM, Paul Irish wrote: Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. This is not true. There is an implementation for Firefox Android which is based on the connection type. Ah, indeed. I had missed that codepath. If I'm reading the right code now, that looks like it returns a constant value for each connection type (e.g. if you're connected via Ethernet or Wifi it returns 20; if you're connected via EDGE it returns 0.2, etc). This suggests that the API is extremely silly; although one could presumably claim that an estimate allows one to return anything, I don't see how returning 20 if the server is feeding you 1 byte/second can be helpful to anyone. If no one plans to implement this as a loose proxy for type of connection the spec shouldn't pretend to do more than that. Can you point me to the discussion of usecases that led to this design?
Re: [whatwg] Bandwidth media queries
On 5/21/12 10:42 AM, James Graham wrote: Can you point me to the discussion of usecases that led to this design? Me personally, no. I wasn't involved in either the spec or the Gecko impl; I'm just reading the code -Boris
Re: [whatwg] Bandwidth media queries
On 05/21/2012 04:50 PM, Boris Zbarsky wrote: On 5/21/12 10:42 AM, James Graham wrote: Can you point me to the discussion of usecases that led to this design? Me personally, no. I wasn't involved in either the spec or the Gecko impl; I'm just reading the code Sorry; s/you/anyone/ (I also meant *except* as a loose proxy for 'type of connection')
Re: [whatwg] Bandwidth media queries
On 05/21/2012 04:42 PM, James Graham wrote: On 05/21/2012 04:34 PM, Boris Zbarsky wrote: If I'm reading the right code now, that looks like it returns a constant value for each connection type (e.g. if you're connected via Ethernet or Wifi it returns 20; if you're connected via EDGE it returns 0.2, etc). This suggests that the API is extremely silly; although one could presumably claim that an estimate allows one to return anything, I don't see how returning 20 if the server is feeding you 1 byte/second can be helpful to anyone. If no one plans to implement this as a loose proxy for type of connection the spec shouldn't pretend to do more than that. Can you point me to the discussion of usecases that led to this design? This has been discussed in the DAP WG [1]. Actually, I think we should move that discussion there. [1] http://www.w3.org/2009/dap/ Cheers, -- Mounir
Re: [whatwg] Bandwidth media queries
On 05/21/2012 04:34 PM, Boris Zbarsky wrote: On 5/21/12 10:09 AM, Mounir Lamouri wrote: On 05/20/2012 03:04 PM, Boris Zbarsky wrote: On 5/20/12 5:45 AM, Paul Irish wrote: Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. This is not true. There is an implementation for Firefox Android which is based on the connection type. Ah, indeed. I had missed that codepath. If I'm reading the right code now, that looks like it returns a constant value for each connection type (e.g. if you're connected via Ethernet or Wifi it returns 20; if you're connected via EDGE it returns 0.2, etc). The idea is that the specification allows the implementation to be trivial and improve without changing the specification. And that implementation is good enough for web pages to know if the user is in a slow or fast connection without giving the connection type and leaking information. That would require not returning exact constant by blurring them a bit. This is not done yet but could easily happen. -- Mounir
Re: [whatwg] Bandwidth media queries
On Mon, 21 May 2012, Mounir Lamouri wrote:
On 05/21/2012 04:34 PM, Boris Zbarsky wrote:
On 5/21/12 10:09 AM, Mounir Lamouri wrote:
On 05/20/2012 03:04 PM, Boris Zbarsky wrote:
On 5/20/12 5:45 AM, Paul Irish wrote:
Since no one mentioned it, I just wanted to make sure this thread is
aware
of the Network Information API [1], which provides
navigator.connection.bandwidth
It's been recently implemented (to some degree) in both Mozilla [2] and
Webkit [3].
As far as I can tell, the Mozilla implementation always returns Infinity
for .bandwidth.
This is not true. There is an implementation for Firefox Android which
is based on the connection type.
Ah, indeed. I had missed that codepath.
If I'm reading the right code now, that looks like it returns a constant
value for each connection type (e.g. if you're connected via Ethernet or
Wifi it returns 20; if you're connected via EDGE it returns 0.2, etc).
The idea is that the specification allows the implementation to be
trivial and improve without changing the specification.
That seems incredibly unlikely to work in practice. Early implementations
will return 20 or 0.2 and sites will do
if (bandwidth == 20) {
//get high quality site
} else {
//get simplified site
}
and users will be very surprised when upgrading their browser causes them
to get the simplified site or low quality assets when before they never
did.
And that
implementation is good enough for web pages to know if the user is in a
slow or fast connection without giving the connection type and leaking
information.
I think the fundamental problem with this API isn't that it might leak
information, it's that it's that it is quite likely to make the overall
user experience worse rather than better. It is also extremely difficult
to implement in a really good way as evidenced by the fact that all the
implementations so far are extremely half-hearted.
Re: [whatwg] Bandwidth media queries
Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. [1] http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/index.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=677166#c42 [3] http://trac.webkit.org/changeset/112815
Re: [whatwg] Bandwidth media queries
On 5/20/12 5:45 AM, Paul Irish wrote: Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. And this is perfectly compliant, since the spec says: The user agent must set the value of the bandwidth attribute to: 0 if the user is currently offline; Infinity if the bandwidth is unknown; an estimation of the current bandwidth in MB/s (Megabytes per seconds) available for communication with the browsing context active document's domain. -Boris
Re: [whatwg] Bandwidth media queries
On Sun, 20 May 2012, Boris Zbarsky wrote: On 5/20/12 5:45 AM, Paul Irish wrote: Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. And this is perfectly compliant, since the spec says: The user agent must set the value of the bandwidth attribute to: 0 if the user is currently offline; Infinity if the bandwidth is unknown; an estimation of the current bandwidth in MB/s (Megabytes per seconds) available for communication with the browsing context active document's domain. If no one is planning on implementing this feature in a meaningful way, why is it in the spec? (yes I know this is not exactly the right list).
Re: [whatwg] Bandwidth media queries
I think we may be talking past each other, as I don't see how your answers address the problems I'm trying to highlight. It's not enough to say it's a hard problem. It's not going to solve itself. If you say media queries can be useful for bandwidth/quality use-cases, you need to actually specify how can they work. I'm trying to show here that MQ model is very problematic, and won't work well *even if UA has perfectly accurate bandwidth information at all times*! MQs are stateless and expected to match the same way globally, and that clashes with stateful and non-uniform nature of caches that should be taken into account. So please specifically address cases I've listed in my previous email. -- regards, Kornel On 18 maj 2012, at 10:52, Matthew Wilcox m...@matthewwilcox.com wrote: Thanks for all the feedback everyone. I don't think it's going to stop people trying to do this though; there are already write-ups for doing bandwidth detection in JS to manipulate img assets: http://www.csskarma.com/blog/detecting-for-bandwidth/ Tricky problem. I'm not sure if that was intended to be an answer to my message: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036005.html I don't think that's at decision stage, because nobody has defined what options are there to decide. The options I see are not compelling: 1. let it match actual bandwidth and apply rules according to standard media query logic. This will suck, as the page design will flip and reload whenever wind blows, and cache will be wasted. 2. let it match some average or sticky value of bandwidth according to standard MQ logic. This will suck less, but still it won't make optimal use of cache OR bandwidth, and page may get stuck in suboptimal bandwidth (e.g. you catch WiFi only momentarily and get 3G browser stuck with peak value or vice versa). 3. Violate MQ logic and allow mixed queries on the page (e.g. if browser has cached image while it had high bandwidth, use the image, even if bandwidth has dropped since). That will allow UAs to use best quality images it can and eliminate redundant requests, but will create unpredictable, inconsistent nightmare for designers. That's why I think there needs to be alternative solution parallel to MQs. It's a shame that Respimg mailinglist is dead: http://lists.w3.org/Archives/Public/public-respimg/2012May/0003.html -- regards, Kornel Lesi��ski
Re: [whatwg] Bandwidth media queries
On 18 May 2012 11:17, Kornel Lesiński kor...@geekhood.net wrote: I think we may be talking past each other, as I don't see how your answers address the problems I'm trying to highlight. Indeed, I'm not debating your points - I accept that it isn't realistically achievable in HTML/CSS :) All the last comment was doing is pointing out that regardless of this, people will try to achieve the same effect using JS (and already are), and will wonder why it's not in HTML/CSS.
Re: [whatwg] Bandwidth media queries
Hi Matt, You really want to know what the throughput is rather than just the bandwidth and throughput is a bit of a PITA to work out in web conditions... Throughput is a mixture of available TCP connection time, bandwidth, latency and packet loss, etc. In theory you could measure it from the browser but there are a number of issues, here are some examples: A typical webpage is made up of many components, which are retrieved via short, bursty conversations between the browser and server. The initial TCP connections go though a 'slow-start' phase while the client and server determine what's the optimal number of packets that can be sent without being acknowledged. The number of packets inflight and the latency effective set a cap on the throughput. So measuring the resources that are downloaded first would probably under report the available throughput Multiple (sub-) domains confuse things further... Assume you can effectively measure throughput from the first resources to be downloaded (HTML, CSS etc), what happens if the images are on a different domain e.g. a CDN? The throughput that's just been measured isn't applicable to the CDN's domain. Caching further complicates things as you can't use anything that's in the cache to measure throughput (or can you?) Although slightly tangential it's worth having a read of Mike Belshe's More Bandwidth Doesn't Matter (Much) - http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/ I'm not sure I'd agree with Tab's comment that authors aren't the best people to make decisions on what content should appear under different throughput conditions though. If they aren't I'm not sure who is? If it's the browser then the author still has to signal their intent to the browser so they are effectively making the choice. Cheers Andy @andydavies
Re: [whatwg] Bandwidth media queries
On Wed, 16 May 2012 19:48:04 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: First off I know that a number of people say this is not possible. I am not wanting to argue this because I don't have the knowledge to argue it - but I do want to understand why, and currently I do not. Please also remember that I can only see this from an authors perspective as I'm ignorant of the mechanics of how these things work internally. The idea is to have something like: link media=min-bandwidth:0.5mps ... / link media=min-bandwidth:1mps ... / link media=min-bandwidth:8mps ... / This make an obvious kind of sense to an author. What would happen in this scenario: I'm in a cafe with free WiFi browsing on my phone, I have 8mbps bandwidth. I open the page and read it (it could be a webapp or a long article that stays open for a long time). I leave the cafe, my bandwidth drops to 1mbps, but I still have the same page open. Should the design change? Should the browser throw away all high-res images it has downloaded and re-download them in poor quality? What when I reload or browse to a next subpage? My browser still has high-res images in the cache. Should it now apply low-end design and re-download all images in poor quality? -- regards, Kornel
Re: [whatwg] Bandwidth media queries
Cheers for that feedback Andy - it is indeed a complicated issue with much more nuance than I think many people (myself included) would have expected. I still think there's a technical solution there, but as you say - it's making that solution reliable enough to be worth it. The problem really is what is reliable enough? How accurate does it need to be. I can understand that this is in practical terms too complex an issue to be worth the effort required to get something workable. And the logic isn't simple either. That said, it's only a matter of making a decision about what to do. The actual mechanics shouldn't be hard, it's the decision making that is.
[whatwg] Bandwidth media queries
First off I know that a number of people say this is not possible. I am not wanting to argue this because I don't have the knowledge to argue it - but I do want to understand why, and currently I do not. Please also remember that I can only see this from an authors perspective as I'm ignorant of the mechanics of how these things work internally. The idea is to have something like: link media=min-bandwidth:0.5mps ... / link media=min-bandwidth:1mps ... / link media=min-bandwidth:8mps ... / This make an obvious kind of sense to an author. One of the issues I see people raise when they attempt to explain why this won't work is that bandwidth is variable, and hard to measure (and something about CSS being stateless I think). Here's why this confuses me... If you're a browser you are the software interpreting the instructions of a given language: CSS in this case. You're an interpreter. So, if CSS essentially asks you as a browser what's the available bandwidth - why can the browser not just supply a value back to the CSS? The next thing that comes to mind is: How do we get the value? Again, I hope I'm not being too ignorant but the process *feels* like it should go like this: All browsers have a Web Inspector and all Inspectors have a Network tab. That network tab tracks and logs everything we'd need to know to figure out a reasonable approximation of the bandwidth available to *that open tab*. This isn't an argument so much as a statement of fact: all browsers can currently do this - it's just not exposed to CSS to interrogate. Why can we not be smart about this and follow a procedure like this: As soon as a request is made for a web page, start tracking the network activity. The browser knows when it sent a request, how long it took to receive a response (thus the latency), the size of the response and how long it took to deliver. It can start doing this with the favicon. It can then analyse that favicon's data and come up with a ballpark bandwidth. Subsequently it can do the same thing for every single http request made to that domain. And it could average out the results to get a more accurate bandwidth and latency measure of what is currently available for the browser to use, re-adjusting the value sent to the CSS as it goes. No doubt that would have some wobbliness due to the low sample rate on an initial connection, so what is to the stop the browser being smarter and keeping a log of connection speeds as a good starting point for future requests - for example, what was the average speed to this domain for all responses in the previous 10sec of requests? Or even more generally; what was the average speed available for *any* domain in the last five minutes? Thanks for your time, Matt
Re: [whatwg] Bandwidth media queries
It's not that bandwidth queries aren't possible, it's that they're not *useful* for the things you'd want to use them for, and they don't act like you'd want anyway. I explain much of the reasoning in http://www.xanthir.com/blog/b4Hv0 - while the blog post purports to be about resolution negotiation, it actually more generally covers why bandwidth queries are a bad idea. In short, bandwidth is often quite variable, particularly on the devices where you'd actually *want* to use this information. This means the instantaneous bandwidth (what MQ would be using) can easily be useless to you. It also means that you'll easily and commonly get into perverse situations where trying to be bandwidth-friendly ends up downloading *more* data than a naive page would. The author is just not in a good situation to be able to make sound decisions about how to react to bandwidth. You need a lot more information than a MQ can provide, and even if we provided it, the logic necessary to use that information *right* is fairly subtle and definitely not settled. This is why providing facilities for the author to just *tell* the browser about the relative filesizes of things, so it can make its own decisions about which resource to download. This keeps the language simpler, because we don't have to communicate as much information. It also centralizes the what to do logic into a small number of places (the browsers) where it has a better chance of being right, rather than hoping that thousands or milions of authors all stumble on the best solution together, and keep their pages updated as best-practices change. ~TJ
Re: [whatwg] Bandwidth media queries
Ok, so really it's an efficiency of authoring problem; before I just didn't get how it'd be any different to a viewport width from the perspective of an author. That said, when coupled with viewport responses... yeah, that could get complicated to author. Essentially each bandwidth bracket would be a multiplier for the number of cases you'd need to address. Cheers again. On 16 May 2012 20:00, Tab Atkins Jr. jackalm...@gmail.com wrote: It's not that bandwidth queries aren't possible, it's that they're not *useful* for the things you'd want to use them for, and they don't act like you'd want anyway. I explain much of the reasoning in http://www.xanthir.com/blog/b4Hv0 - while the blog post purports to be about resolution negotiation, it actually more generally covers why bandwidth queries are a bad idea. In short, bandwidth is often quite variable, particularly on the devices where you'd actually *want* to use this information. This means the instantaneous bandwidth (what MQ would be using) can easily be useless to you. It also means that you'll easily and commonly get into perverse situations where trying to be bandwidth-friendly ends up downloading *more* data than a naive page would. The author is just not in a good situation to be able to make sound decisions about how to react to bandwidth. You need a lot more information than a MQ can provide, and even if we provided it, the logic necessary to use that information *right* is fairly subtle and definitely not settled. This is why providing facilities for the author to just *tell* the browser about the relative filesizes of things, so it can make its own decisions about which resource to download. This keeps the language simpler, because we don't have to communicate as much information. It also centralizes the what to do logic into a small number of places (the browsers) where it has a better chance of being right, rather than hoping that thousands or milions of authors all stumble on the best solution together, and keep their pages updated as best-practices change. ~TJ
Re: [whatwg] Bandwidth media queries
On Wed, 16 May 2012, Matthew Wilcox wrote: First off I know that a number of people say this is not possible. I am not wanting to argue this because I don't have the knowledge to argue it - but I do want to understand why, and currently I do not. Please also remember that I can only see this from an authors perspective as I'm ignorant of the mechanics of how these things work internally. The idea is to have something like: link media=min-bandwidth:0.5mps ... / link media=min-bandwidth:1mps ... / link media=min-bandwidth:8mps ... / Without going deeper into the specific points, implementation experience suggests that even implementing a binary low-bandwidth/high bandwidth detection is extremely difficult; Opera has one coupled to the UI for the turbo feature and it has been somewhat non-trivial to get acceptable quality. In general the problem with trying to measure something like bandwidth is that it is highly time-variable; it depends on a huge number of environmental factors like the other users/applications on the same connection, possible browser features like down-prioritising connections in background tabs, external environmental features like the train just went into a tunnel or I just went out of range of WiFi and switched to 3G and any number of other things. Some of those are temporary conditions, some are rapid changes to a new long-term state. Trying to present a single number representing this complexity in realtime just isn't going to work.
Re: [whatwg] Bandwidth media queries
On 16 May 2012 20:10, James Graham jgra...@opera.com wrote: On Wed, 16 May 2012, Matthew Wilcox wrote: First off I know that a number of people say this is not possible. I am not wanting to argue this because I don't have the knowledge to argue it - but I do want to understand why, and currently I do not. Please also remember that I can only see this from an authors perspective as I'm ignorant of the mechanics of how these things work internally. The idea is to have something like: link media=min-bandwidth:0.5mps ... / link media=min-bandwidth:1mps ... / link media=min-bandwidth:8mps ... / Without going deeper into the specific points, implementation experience suggests that even implementing a binary low-bandwidth/high bandwidth detection is extremely difficult; Opera has one coupled to the UI for the turbo feature and it has been somewhat non-trivial to get acceptable quality. In general the problem with trying to measure something like bandwidth is that it is highly time-variable; it depends on a huge number of environmental factors like the other users/applications on the same connection, possible browser features like down-prioritising connections in background tabs, external environmental features like the train just went into a tunnel or I just went out of range of WiFi and switched to 3G and any number of other things. Some of those are temporary conditions, some are rapid changes to a new long-term state. Trying to present a single number representing this complexity in realtime just isn't going to work. Yeah, that's what I had figured the process I described would be able to work for - but I accept it must be more complicated than I have accounted for. Thanks for the feedback :)
Re: [whatwg] Bandwidth media queries
On Wed, 2012-05-16 at 20:09 +0100, Matthew Wilcox wrote: Ok, so really it's an efficiency of authoring problem; before I just didn't get how it'd be any different to a viewport width from the perspective of an author. That said, when coupled with viewport responses... yeah, that could get complicated to author. Essentially each bandwidth bracket would be a multiplier for the number of cases you'd need to address. Cheers again. On 16 May 2012 20:00, Tab Atkins Jr. jackalm...@gmail.com wrote: It's not that bandwidth queries aren't possible, it's that they're not *useful* for the things you'd want to use them for, and they don't act like you'd want anyway. I explain much of the reasoning in http://www.xanthir.com/blog/b4Hv0 - while the blog post purports to be about resolution negotiation, it actually more generally covers why bandwidth queries are a bad idea. In short, bandwidth is often quite variable, particularly on the devices where you'd actually *want* to use this information. This means the instantaneous bandwidth (what MQ would be using) can easily be useless to you. It also means that you'll easily and commonly get into perverse situations where trying to be bandwidth-friendly ends up downloading *more* data than a naive page would. The author is just not in a good situation to be able to make sound decisions about how to react to bandwidth. You need a lot more information than a MQ can provide, and even if we provided it, the logic necessary to use that information *right* is fairly subtle and definitely not settled. This is why providing facilities for the author to just *tell* the browser about the relative filesizes of things, so it can make its own decisions about which resource to download. This keeps the language simpler, because we don't have to communicate as much information. It also centralizes the what to do logic into a small number of places (the browsers) where it has a better chance of being right, rather than hoping that thousands or milions of authors all stumble on the best solution together, and keep their pages updated as best-practices change. ~TJ I've given the bandwidth issue some thought and it's definitely not a simple problem to solve. The way I see it, you need support at the OS level. Imagine these (fairly typical) scenarios: 1) A regular laptop computer on a typical home broadband connection (let's assume enough bandwidth to happily deliver a web page in a decent time) 2) The same laptop now connected to a work network. Contention ratios are higher so available bandwidth, although the same as the home one by spec, is slower because of it being shared so much more 3) Laptop now in a café somewhere tethered to a mobile phone for it's Internet connection Each scenario could have quite different average bandwidths, so it's fairly obvious that any bandwidth monitoring should be done with the network connection as a profile in mind. OS X and some Linux distros already offer statistics on the network you're connected to I believe, and Windows can with helper programs (although I think these only monitor on a single network interface generally). Some work would need to be done on algorithms to ensure the average gave a good representation of the bandwidth, e.g. smoothing out spikes, taking into account that some websites are generally just really slow to respond, etc. On it's own, a browser would find this impossible, because it won't be able to easily adapt to different situations as I've outlined above. -- Thanks, Ash http://www.ashleysheridan.co.uk
