Re: [whatwg] Media query for bandwidth ??

[Nils Dagsson Moskopp]

"Michael A. Peters"  writes:

> […]
>
> 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.

I suspect that developers that cared enough to use such a thing would be
able to create CSS that is not bloated enough to need the feature … take
advertising for example: Almost all pages become smaller without ads and
still there exists no  element; incentives for advertisers to markup
advertisments on web pages do not exist. Same for tracking scripts etc..
Note that browsers contain tools to limit loading speed to e.g. UMTS/3G.

Greetings,
-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

On 12/09/2016 06:14 PM, Florian Rivoal wrote:

On Dec 9, 2016, at 23:07, Michael A. Peters  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.

Re: [whatwg] Media query for bandwidth ??

[Florian Rivoal]

> On Dec 9, 2016, at 23:07, Michael A. Peters  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/

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

I have pondered that, and those cases will not be typical. The page may 
start to load the high bandwidth content (just like it does right now) 
and that may cause slow page loading as they walk outside (just like it 
does right now) but the next page at the site they load will use the 
low-bandwidth CSS and load a lot faster - unlike it does right now.


On 12/09/2016 11:58 AM, Jonathan Garbee wrote:

Also, Ponder this case:

User is on their cell phone and at home on wifi. So your "This user as
50MBs, send them 4k images!" query is hit on initial load. Well, 25%
through page resources being called, they walk 20 feet outside of their
home and now they are on their ~3G cell tower connection. If it is stuck on
initial test metrics, that user is stuck downloading 75% of your 4k images
and fonts over their cell connection. Now consider it as a pay-per-usage
connection and you have easily blown a hole in their wallet.

These things can't be locked into a single point in time. It just doesn't
work from the perspective of the user. So whatever is done here, would need
to be adaptable which in the case of CSS is even more complex since it is
declarative and developers give up so much control. Bandwidth Media Queries
simply aren't feasible.

On Fri, Dec 9, 2016 at 2:51 PM Jonathan Garbee  wrote:


FTR there was a working group to provide a Network Information API [1] to
let JS handle this more easily. In trying to do that, they had a difficult
time actually getting accurate information for the API to provide. So it
was canned in order to further assess the cases specifically and other
approaches. I highly doubt if there was trouble building a JS API for this
type of thing that CSS alone can handle it in some way.

If something like this is to happen, it *needs* to happen in JS first.
That way developers have control, from a working and proven implementation
there we could find a syntax for CSS to work on top of. So for now, you're
probably best off polyfilling some JS API and using that to experiment with
to present as a solution. That way it can be more easily vetted and tested.

[1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

On Fri, Dec 9, 2016 at 12:43 PM Michael A. Peters 
wrote:

On 12/09/2016 09:03 AM, Boris Zbarsky wrote:

On 12/9/16 5:57 AM, Michael A. Peters wrote:

max-height and max-width and orientation change, but device-width does
not change.


Just as a point of fact, device-width can absolutely change.  The
simplest case is a two-monitor setup with the window getting dragged
from one monitor to another, but similar things can happen when things
are docked/undocked, monitors are plugged in or removed, etc.

-Boris


Ah yes, point taken.

With a bandwidth query I would recommend it only change on a page reload
but it wouldn't have to be done that way.

This wouldn't only be beneficial to fonts, a lot of images etc. are
defined in CSS too.

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

I don't think it needs to happen in JS first. A CSS media query is 
completely opt-in. Developers don't need to use the media query if they 
do not want to, it is just a way that developers can make their websites 
more friendly to users with bandwidth constraints without sacrificing 
for users who do not have bandwidth constraints.


On 12/09/2016 11:51 AM, Jonathan Garbee wrote:

FTR there was a working group to provide a Network Information API [1] to
let JS handle this more easily. In trying to do that, they had a difficult
time actually getting accurate information for the API to provide. So it
was canned in order to further assess the cases specifically and other
approaches. I highly doubt if there was trouble building a JS API for this
type of thing that CSS alone can handle it in some way.

If something like this is to happen, it *needs* to happen in JS first. That
way developers have control, from a working and proven implementation there
we could find a syntax for CSS to work on top of. So for now, you're
probably best off polyfilling some JS API and using that to experiment with
to present as a solution. That way it can be more easily vetted and tested.

[1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

On Fri, Dec 9, 2016 at 12:43 PM Michael A. Peters 
wrote:


On 12/09/2016 09:03 AM, Boris Zbarsky wrote:

On 12/9/16 5:57 AM, Michael A. Peters wrote:

max-height and max-width and orientation change, but device-width does
not change.


Just as a point of fact, device-width can absolutely change.  The
simplest case is a two-monitor setup with the window getting dragged
from one monitor to another, but similar things can happen when things
are docked/undocked, monitors are plugged in or removed, etc.

-Boris


Ah yes, point taken.

With a bandwidth query I would recommend it only change on a page reload
but it wouldn't have to be done that way.

This wouldn't only be beneficial to fonts, a lot of images etc. are
defined in CSS too.

Re: [whatwg] Media query for bandwidth ??

[Jonathan Garbee]

Also, Ponder this case:

User is on their cell phone and at home on wifi. So your "This user as
50MBs, send them 4k images!" query is hit on initial load. Well, 25%
through page resources being called, they walk 20 feet outside of their
home and now they are on their ~3G cell tower connection. If it is stuck on
initial test metrics, that user is stuck downloading 75% of your 4k images
and fonts over their cell connection. Now consider it as a pay-per-usage
connection and you have easily blown a hole in their wallet.

These things can't be locked into a single point in time. It just doesn't
work from the perspective of the user. So whatever is done here, would need
to be adaptable which in the case of CSS is even more complex since it is
declarative and developers give up so much control. Bandwidth Media Queries
simply aren't feasible.

On Fri, Dec 9, 2016 at 2:51 PM Jonathan Garbee  wrote:

> FTR there was a working group to provide a Network Information API [1] to
> let JS handle this more easily. In trying to do that, they had a difficult
> time actually getting accurate information for the API to provide. So it
> was canned in order to further assess the cases specifically and other
> approaches. I highly doubt if there was trouble building a JS API for this
> type of thing that CSS alone can handle it in some way.
>
> If something like this is to happen, it *needs* to happen in JS first.
> That way developers have control, from a working and proven implementation
> there we could find a syntax for CSS to work on top of. So for now, you're
> probably best off polyfilling some JS API and using that to experiment with
> to present as a solution. That way it can be more easily vetted and tested.
>
> [1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html
>
> On Fri, Dec 9, 2016 at 12:43 PM Michael A. Peters 
> wrote:
>
> On 12/09/2016 09:03 AM, Boris Zbarsky wrote:
> > On 12/9/16 5:57 AM, Michael A. Peters wrote:
> >> max-height and max-width and orientation change, but device-width does
> >> not change.
> >
> > Just as a point of fact, device-width can absolutely change.  The
> > simplest case is a two-monitor setup with the window getting dragged
> > from one monitor to another, but similar things can happen when things
> > are docked/undocked, monitors are plugged in or removed, etc.
> >
> > -Boris
>
> Ah yes, point taken.
>
> With a bandwidth query I would recommend it only change on a page reload
> but it wouldn't have to be done that way.
>
> This wouldn't only be beneficial to fonts, a lot of images etc. are
> defined in CSS too.
>
>

Re: [whatwg] Media query for bandwidth ??

[Jonathan Garbee]

FTR there was a working group to provide a Network Information API [1] to
let JS handle this more easily. In trying to do that, they had a difficult
time actually getting accurate information for the API to provide. So it
was canned in order to further assess the cases specifically and other
approaches. I highly doubt if there was trouble building a JS API for this
type of thing that CSS alone can handle it in some way.

If something like this is to happen, it *needs* to happen in JS first. That
way developers have control, from a working and proven implementation there
we could find a syntax for CSS to work on top of. So for now, you're
probably best off polyfilling some JS API and using that to experiment with
to present as a solution. That way it can be more easily vetted and tested.

[1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

On Fri, Dec 9, 2016 at 12:43 PM Michael A. Peters 
wrote:

> On 12/09/2016 09:03 AM, Boris Zbarsky wrote:
> > On 12/9/16 5:57 AM, Michael A. Peters wrote:
> >> max-height and max-width and orientation change, but device-width does
> >> not change.
> >
> > Just as a point of fact, device-width can absolutely change.  The
> > simplest case is a two-monitor setup with the window getting dragged
> > from one monitor to another, but similar things can happen when things
> > are docked/undocked, monitors are plugged in or removed, etc.
> >
> > -Boris
>
> Ah yes, point taken.
>
> With a bandwidth query I would recommend it only change on a page reload
> but it wouldn't have to be done that way.
>
> This wouldn't only be beneficial to fonts, a lot of images etc. are
> defined in CSS too.
>

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

On 12/09/2016 09:03 AM, Boris Zbarsky wrote:

On 12/9/16 5:57 AM, Michael A. Peters wrote:

max-height and max-width and orientation change, but device-width does
not change.


Just as a point of fact, device-width can absolutely change.  The
simplest case is a two-monitor setup with the window getting dragged
from one monitor to another, but similar things can happen when things
are docked/undocked, monitors are plugged in or removed, etc.

-Boris


Ah yes, point taken.

With a bandwidth query I would recommend it only change on a page reload 
but it wouldn't have to be done that way.


This wouldn't only be beneficial to fonts, a lot of images etc. are 
defined in CSS too.

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

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  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 
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 
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 la

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

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 
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 
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-w

Re: [whatwg] Media query for bandwidth ??

[Boris Zbarsky]

On 12/9/16 5:57 AM, Michael A. Peters wrote:

max-height and max-width and orientation change, but device-width does
not change.


Just as a point of fact, device-width can absolutely change.  The 
simplest case is a two-monitor setup with the window getting dragged 
from one monitor to another, but similar things can happen when things 
are docked/undocked, monitors are plugged in or removed, etc.


-Boris

Re: [whatwg] Media query for bandwidth ??

[Jonathan Garbee]

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  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 
> 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  >
> > 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 ma

Re: [whatwg] Media query for bandwidth ??

[Yay295]

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 
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 
> 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?
> >
>

Re: [whatwg] Media query for bandwidth ??

[Michael A. Peters]

max-height and max-width and orientation change, but device-width does 
not change.


It should behave like device-width because it should be applied when the 
resources are fetched and the page is rendered.


Yes low and high are relative, which is why it should be determined by 
the browser potentially with user preference settings to what means high 
and low to the user.


Someone using a service where they pay for all their bandwidth may want 
it always defined as low except when on wifi, someone who doesn't pay 
for bandwidth may want it only set to low when their phone only has two 
bars.


Leaving it up to the client allows it to remain relative. It doesn't 
need to be more fine-grained than high or low because web designers 
aren't likely to make use of more than two options anyway.


On 12/09/2016 07:32 AM, Jonathan Zuckerman 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 
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?

Re: [whatwg] Media query for bandwidth ??

[Jonathan Zuckerman]

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 
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?
>

[whatwg] Media query for bandwidth ??

[Michael A. Peters]

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?