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

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

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

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

Post by 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.

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

[Boris Zbarsky]

Post by Michael A. Peters
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

[Michael A. Peters]

Post by Boris Zbarsky

Post by Michael A. Peters
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.

[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

Post by Michael A. Peters

Post by Boris Zbarsky

Post by Michael A. Peters
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.

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

Post by 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

Post by Boris Zbarsky

Post by Michael A. Peters
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.

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

Post by Jonathan Garbee
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.

Post by 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

Post by Boris Zbarsky

Post by Michael A. Peters
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.

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

Post by 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

Post by Michael A. Peters

Post by Boris Zbarsky

Post by Michael A. Peters
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.

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

Post by 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.

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

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

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

Post by Jonathan Zuckerman
Michael - I think "high" and "low" are very relative terms, defining

those

Post by Jonathan Zuckerman
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

Post by Jonathan Zuckerman
proposed addition would behave?
Currently you can use javascript to figure out if the network will

support

Post by Jonathan Zuckerman
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

Post by Jonathan Zuckerman
better.

Post by 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

Post by Jonathan Zuckerman

Post by Michael A. Peters
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

Post by Jonathan Zuckerman

Post by Michael A. Peters
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

Post by Jonathan Zuckerman

Post by Michael A. Peters
the 64 kbps opus to clients that don't define themselves as low, and

the

Post by Jonathan Zuckerman

Post by Michael A. Peters
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?

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

Post by 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.

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

Post by Jonathan Zuckerman
Michael - I think "high" and "low" are very relative terms, defining

those

Post by Jonathan Zuckerman
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

Post by Jonathan Zuckerman
proposed addition would behave?
Currently you can use javascript to figure out if the network will

support

Post by Jonathan Zuckerman
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

Post by Jonathan Zuckerman
better.

Post by 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

Post by Jonathan Zuckerman

Post by Michael A. Peters
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

Post by Jonathan Zuckerman

Post by Michael A. Peters
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

Post by Jonathan Zuckerman

Post by Michael A. Peters
the 64 kbps opus to clients that don't define themselves as low, and

the

Post by Jonathan Zuckerman

Post by Michael A. Peters
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?

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

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

Post by 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.

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

[Florian Rivoal]

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.

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/

[Michael A. Peters]

Post by Florian Rivoal

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.

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

[Nils Dagsson Moskopp]

Post by Michael A. Peters
[…]
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 <ad> 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,