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

Re: [whatwg] Media query for bandwidth ??

From: Yay295 <yay295@gmail.com>
Date: Fri, 9 Dec 2016 09:09:08 -0700
Message-ID: <CAH+HUiaiTCTvT8UwjLeNns6Z3XMhZ4xtrXg=h9LfAQ9zcNdg3w@mail.gmail.com>
To: Jonathan Zuckerman <j.zuckerman@gmail.com>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, "Michael A. Peters" <mpeters@domblogger.net>
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 16:09:42 UTC

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