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 <yay...@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.zucker...@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 <mpet...@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?
