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 09:36:24 -0800
To: whatwg@lists.whatwg.org
Message-ID: <b5b2cd14-a83d-52bb-3a60-3047c5b72c62@domblogger.net>
How the browsers determine bandwidth would be up to the browser.

I assume they would have a reasonable default that the user can choose 
to override - like many other browser options.

On 12/09/2016 08:19 AM, Jonathan Garbee wrote:
> So, if this were to get in it is magically up to users to know to go change
> the settings (most don't) to get different modes. That is bad design. We
> need to handle things for users in this situation. Not do something and
> hope they pay attention.
>
> If you're suggesting a feature that requires browser settings explicit for
> it, rethink it.
>
> JavaScript handling let's you do exactly what you want. Let the most
> performance oriented solution be your default and enhance on top of that
> after load. There are other things coming for fonts, like the font loading
> API, to help make funny transitioning seamless.
>
> Browsers are handling things like data saver modes to let users opt in to
> certain things on their end. Overall, introducing media queries based on
> the network is a bad design.
>
> On Fri, Dec 9, 2016, 11:09 AM Yay295 <yay295@gmail.com> wrote:
>
>> On another note, are you sure it's *font files* that are slowing down your
>> page load? Maybe I've just been lucky, but of the 24 font files I happen to
>> have in a folder on my computer, 19 of them are only about 50KB. That's
>> one-fifth the size of jQuery. Perhaps you should be looking at shrinking
>> your font files first if they're such a problem?
>>
>> On Fri, Dec 9, 2016 at 8:32 AM, Jonathan Zuckerman <j.zuckerman@gmail.com>
>> wrote:
>>
>>> Michael - I think "high" and "low" are very relative terms, defining
>> those
>>> terms for all users for all time doesn't seem possible. Also,
>>> connectivity/bandwidth are subject to change at any moment during the
>>> lifetime of a page. Current media queries like `max-height` or
>>> `min-resolution` would respond to changes, have you thought about how
>> your
>>> proposed addition would behave?
>>>
>>> Currently you can use javascript to figure out if the network will
>> support
>>> your enhanced experience (and you're free to define what that means) and
>>> add a classname to the document to trigger the css rules for that
>>> experience, so you can build the feature you're asking for using existing
>>> parts. It's not baked into the platform, but because of the nature of the
>>> web and vagueness of the requirements, I'm not sure it's possible to do
>> any
>>> better.
>>>
>>> On Fri, Dec 9, 2016 at 9:07 AM Michael A. Peters <mpeters@domblogger.net
>>>
>>> wrote:
>>>
>>>> This was inspired by inspection of a style-sheet in the wild that uses
>>>> screen-width to try and reduce bandwidth needs of mobile devices.
>>>>
>>>> I like the concept, but very often I use my mobile devices where
>>>> bandwidth doesn't matter and my laptop via a mifi where bandwidth does
>>>> matter.
>>>>
>>>> I would like a CSS media query for bandwidth so that I can reduce how
>>>> many webfonts are used in low bandwidth scenarios. It seems browsers
>> are
>>>> already smart enough to only download a font defined by @font-face if
>>>> they need it, so it only needs to be done where the font is used, e.g.
>>>>
>>>> pre {
>>>>    font-family: 'monoFont-Roman', monospace;
>>>> }
>>>> pre em {
>>>>    font-family: 'monoFont-Italic', monospace;
>>>>    font-style: normal;
>>>> }
>>>> pre strong {
>>>>    font-family: 'monoFont-Bold', monospace;
>>>>    font-weight: normal;
>>>> }
>>>> pre em strong {
>>>>    font-family: 'monoFont-BoldItalic', monospace;
>>>>    font-style: normal;
>>>>    font-weight: normal;
>>>> }
>>>> pre strong em {
>>>>    font-family: 'monoFont-BoldItalic', monospace;
>>>>    font-style: normal;
>>>>    font-weight: normal;
>>>> }
>>>> @media screen and (device-bandwidth: low) {
>>>>    pre strong {
>>>>      font-family: 'monoFont-Roman', monospace;
>>>>      font-weight: 700;
>>>>    }
>>>>    pre em strong {
>>>>      font-family: 'monoFont-Italic', monospace;
>>>>      font-weight: 700;
>>>>    }
>>>>    pre strong em {
>>>>      font-family: 'monoFont-Italic', monospace;
>>>>      font-weight: 700;
>>>>    }
>>>> }
>>>>
>>>> That right there cuts the number of fonts the low-bandwidth device
>> needs
>>>> in half, and could have even gone further and used fake italic if the
>>>> fake italic for the font looks good enough.
>>>>
>>>> The small increase in CSS file size doesn't matter with high bandwidth
>>>> clients and is justified for low-bandwidth as it reduces the content
>>>> that needs to be fetched.
>>>>
>>>> It would be up to the client to define the device-bandwidth, web
>>>> developers should create the CSS for high bandwidth and only have the
>>>> alternate CSS kick in when a media query says it is low.
>>>>
>>>> Honestly I think low or high are the only definitions needed with low
>>>> being the only one that a site should have conditional styles set for.
>>>>
>>>> -=-
>>>>
>>>> The same concept could be applied to html5 media too. e.g. I could
>> serve
>>>> the 64 kbps opus to clients that don't define themselves as low, and
>> the
>>>> 32 kbps opus to clients that do define themselves as low.
>>>>
>>>> How to handle media in situations where a service worker pre-fetches
>>>> content I haven't thought about, because a client may pre-fetch content
>>>> before the bandwidth constraint changes, but I suspect there's a clever
>>>> solution to that (e.g. always fetch high bandwidth when async pre-fetch
>>>> and then use high bandwidth when cached even if in low bandwidth mode)
>>>>
>>>> But html5 media can be figured out later, CSS is what I really would
>>>> like to see a bandwidth media query for.
>>>>
>>>> Thoughts?
>>>>
>>>
>>
Received on Friday, 9 December 2016 17:36:58 UTC

This archive was generated by hypermail 2.3.1 : Friday, 9 December 2016 17:36:59 UTC