W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2016

Re: [whatwg] Media query for bandwidth ??

From: Michael A. Peters <mpeters@domblogger.net>
Date: Fri, 9 Dec 2016 12:42:12 -0800
To: whatwg@lists.whatwg.org
Message-ID: <3c5d482e-79f0-8e8c-4f82-e29720556df6@domblogger.net>
I have pondered that, and those cases will not be typical. The page may 
start to load the high bandwidth content (just like it does right now) 
and that may cause slow page loading as they walk outside (just like it 
does right now) but the next page at the site they load will use the 
low-bandwidth CSS and load a lot faster - unlike it does right now.

On 12/09/2016 11:58 AM, Jonathan Garbee wrote:
> Also, Ponder this case:
>
> User is on their cell phone and at home on wifi. So your "This user as
> 50MBs, send them 4k images!" query is hit on initial load. Well, 25%
> through page resources being called, they walk 20 feet outside of their
> home and now they are on their ~3G cell tower connection. If it is stuck on
> initial test metrics, that user is stuck downloading 75% of your 4k images
> and fonts over their cell connection. Now consider it as a pay-per-usage
> connection and you have easily blown a hole in their wallet.
>
> These things can't be locked into a single point in time. It just doesn't
> work from the perspective of the user. So whatever is done here, would need
> to be adaptable which in the case of CSS is even more complex since it is
> declarative and developers give up so much control. Bandwidth Media Queries
> simply aren't feasible.
>
> On Fri, Dec 9, 2016 at 2:51 PM Jonathan Garbee <jonathan@garbee.me> wrote:
>
>> FTR there was a working group to provide a Network Information API [1] to
>> let JS handle this more easily. In trying to do that, they had a difficult
>> time actually getting accurate information for the API to provide. So it
>> was canned in order to further assess the cases specifically and other
>> approaches. I highly doubt if there was trouble building a JS API for this
>> type of thing that CSS alone can handle it in some way.
>>
>> If something like this is to happen, it *needs* to happen in JS first.
>> That way developers have control, from a working and proven implementation
>> there we could find a syntax for CSS to work on top of. So for now, you're
>> probably best off polyfilling some JS API and using that to experiment with
>> to present as a solution. That way it can be more easily vetted and tested.
>>
>> [1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html
>>
>> On Fri, Dec 9, 2016 at 12:43 PM Michael A. Peters <mpeters@domblogger.net>
>> wrote:
>>
>> On 12/09/2016 09:03 AM, Boris Zbarsky wrote:
>>> On 12/9/16 5:57 AM, Michael A. Peters wrote:
>>>> max-height and max-width and orientation change, but device-width does
>>>> not change.
>>>
>>> Just as a point of fact, device-width can absolutely change.  The
>>> simplest case is a two-monitor setup with the window getting dragged
>>> from one monitor to another, but similar things can happen when things
>>> are docked/undocked, monitors are plugged in or removed, etc.
>>>
>>> -Boris
>>
>> Ah yes, point taken.
>>
>> With a bandwidth query I would recommend it only change on a page reload
>> but it wouldn't have to be done that way.
>>
>> This wouldn't only be beneficial to fonts, a lot of images etc. are
>> defined in CSS too.
>>
>>
Received on Friday, 9 December 2016 20:42:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:40 UTC