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:24:31 -0800
To: whatwg@lists.whatwg.org
Message-ID: <6967f8a2-59b0-3fb6-8410-6b8deb70561c@domblogger.net>
My pages are not slow and tend to be much smaller than the typical web 
page out there.

The size of a woff2 file can vary greatly depending upon what characters 
it covers and the complexity of those characters.

jQuery is only needed once as it should then be cached for a very long 
time, and quite often is served from a CDN where the user does not need 
to load it for each and every site they visit.

With fonts, many sites use at least three different families and often 
several faces within those families, which is appropriate because many 
characters are far more readable when a genuine font face is used rather 
than fake italic or bold. The w character for example is often drawn 
different and more readable in the italic variant of the family.

There are free fonts that also exist on CDNs but there are many to 
choose from so it is less likely the user already has them cached even 
if they are on a common CDN (e.g. Google Fonts), and many webmasters 
license fonts that can't be on a common CDN due to the license.

There is a push for privacy reasons to limit a browsers ability to use 
fonts from the system, access to system fonts can be used for browser 
fingerprinting. If that push is successful (and I hope it is) then web 
font usage may increase due to the limited fonts that a particular 
browser may ship with.

Allowing for genuine font faces (and fatter font faces) where bandwidth 
isn't an issue but limiting the font faces (and using slimmer fonts) 
where bandwidth is an issue can provide for a better user experience 
when there are bandwidth constraints on the client.

A better experience for the end user under those fairly common 
conditions (especially common in developing countries) I believe is a 
worthwhile goal.

Web developers that don't want to or feel they don't need to accommodate 
those users won't have to, but those who do want to take bandwidth 
concerns into consideration will be able to.

I don't know how common it is, but it was a style sheet I saw in the 
wild where the web developer was trying to use device-width to 
accomplish that goal that made me think about a better way, because I do 
believe taking bandwidth into consideration is a noble thing for a web 
developer to do, and they shouldn't have to use device-width to try and 
accomplish that.

In my opinion.

On 12/09/2016 08:09 AM, Yay295 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:25:07 UTC

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