[whatwg] Bandwidth media queries
kornel at geekhood.net
Fri May 18 03:17:37 PDT 2012
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.
On 18 maj 2012, at 10:52, Matthew Wilcox <mail at 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:
> Tricky problem.
>> I'm not sure if that was intended to be an answer to my message:
>> 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:
>> regards, Kornel Lesi¨½ski
More information about the whatwg