Re: [whatwg] Media query for bandwidth ??

max-height and max-width and orientation change, but device-width does 
not change.

It should behave like device-width because it should be applied when the 
resources are fetched and the page is rendered.

Yes low and high are relative, which is why it should be determined by 
the browser potentially with user preference settings to what means high 
and low to the user.

Someone using a service where they pay for all their bandwidth may want 
it always defined as low except when on wifi, someone who doesn't pay 
for bandwidth may want it only set to low when their phone only has two 
bars.

Leaving it up to the client allows it to remain relative. It doesn't 
need to be more fine-grained than high or low because web designers 
aren't likely to make use of more than two options anyway.

On 12/09/2016 07:32 AM, Jonathan Zuckerman 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 15:57:44 UTC