On 12/09/2016 06:14 PM, Florian Rivoal wrote:
On Dec 9, 2016, at 23:07, 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.
It's been considered before, and that approach will not work. Media queries are
the wrong tool for this. Neutrality / bias warning: I'm co-editor of the Media
Queries spec.
Media queries, by design, will switch instantly when the environment changes,
stop applying the old styles, and start applying the new ones. So if you finish
loading a page on your phone in your home wifi with the high-res and heavy
assets, start reading, then walk outside into 3G, you'll discard the high res
assets and start loading the low res ones. And if you're driving / riding a
train in and out of tunnels, you'll toggle between high and low (or low and
terrible) constantly, and never manage to finish loading anything, all while
using copious amounts of bandwidth. This isn't a bug, this is how Media Queries
work, and is the right thing to do for things where media queries are the right
tool. If that's not what you want, what you want isn't a media query.
The right approach is something like srcset[1], the source element[2], or
image-set()[3]: instead of switching between one variant or another based on a
hard criteria, you provide the UA with all the variants you have, and let it
switch intelligently.
Of course, these are UA based heurisitics, it is certainly possible that the UA
will make poor decisions sometimes, but that's a lot better than the guaranteed
bad behavior you'd get with Media queries.
For fonts, there isn't currently an equivalent mechanism, but we could think of
adding qualifiers either the @font-face that declares the font, or font-family
that tries to use it, to indicate that certain fonts are must-have, while
others are optional things that are fine to skip in case of bad bandwidth or
latency.
There's already one proposal in that direction, although it hasn't received
much attention lately: https://tabatkins.github.io/specs/css-font-display/
Finally, while you're free to talk about this anywhere you like, traditionally
the best forum for CSS related topics is the CSSWG, either through its
github[4] or its mailing list[5].
—Florian
[1] https://html.spec.whatwg.org/multipage/embedded-content.html#attr-img-srcset
[2]
https://html.spec.whatwg.org/multipage/embedded-content.html#the-source-element
[3] https://drafts.csswg.org/css-images-3/#image-set-notation
[4] https://github.com/w3c/csswg-drafts/issues
[5] https://lists.w3.org/Archives/Public/www-style/
I've thought about this for several hours now and I have to concede, a
media query is not the right place for this.
I don't think @font-face is either as it would cause backwards
compatibility problems, and there are other issues with @font-face.
For example, when I use @font-face to define a bold font face, then when
I declare that font for strong I have to explicitly tell the CSS to use
the normal weight or the browser applies a fake bold to the already bold
font.
Perhaps what is needed is an @font-family declaration that can be used
to specify the various variants of a font.
Then when the font-family is called and something like a strong tag is
encountered, the browser will use the defined bold variant if it exists
and apply fake bold to the roman font if it does not.
If variants within @font-family are declared optional, then the browser
does not have to include it.
That would solve another problem with my media query solution. If the
page was ever loaded when bandwidth isn't an issue, it may have the
optional woff2 files in cache.
It would then be able to use them even in low bandwidth, since it
already had them, and only apply fake variant instead if it doesn't have
it in cache and it is flagged as optional.
I'll think about this some more, then join the right list for it and put
the revised idea there.
But for now I have to concede media query is the wrong approach.
