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

[whatwg] Media query for bandwidth ??

From: Michael A. Peters <mpeters@domblogger.net>
Date: Fri, 9 Dec 2016 06:07:22 -0800
To: whatwg@lists.whatwg.org
Message-ID: <be02f937-41fe-b8fd-c232-98469b4a450b@domblogger.net>
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 14:08:02 UTC

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