Media query for bandwidth ??

# Michael A. Peters (7 months ago)

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?

Contact us to advertise here
# Jonathan Zuckerman (7 months ago)

Michael - I think "high" and "low" are very relative terms, defining those terms for all users for all time doesn't seem possible. Also, connectivity/bandwidth are subject to change at any moment during the lifetime of a page. Current media queries like max-height or min-resolution would respond to changes, have you thought about how your proposed addition would behave?

Currently you can use javascript to figure out if the network will support your enhanced experience (and you're free to define what that means) and add a classname to the document to trigger the css rules for that experience, so you can build the feature you're asking for using existing parts. It's not baked into the platform, but because of the nature of the web and vagueness of the requirements, I'm not sure it's possible to do any better.

On Fri, Dec 9, 2016 at 9:07 AM Michael A. Peters <mpeters at domblogger.net>

wrote:

# Jonathan Zuckerman (7 months ago)

Michael - I think "high" and "low" are very relative terms, defining those terms for all users for all time doesn't seem possible. Also, connectivity/bandwidth are subject to change at any moment during the lifetime of a page. Current media queries like max-height or min-resolution would respond to changes, have you thought about how your proposed addition would behave?

Currently you can use javascript to figure out if the network will support your enhanced experience (and you're free to define what that means) and add a classname to the document to trigger the css rules for that experience, so you can build the feature you're asking for using existing parts. It's not baked into the platform, but because of the nature of the web and vagueness of the requirements, I'm not sure it's possible to do any better.

On Fri, Dec 9, 2016 at 9:07 AM Michael A. Peters <mpeters at domblogger.net>

wrote:

# Michael A. Peters (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Yay295 (7 months ago)

On another note, are you sure it's font files that are slowing down your page load? Maybe I've just been lucky, but of the 24 font files I happen to have in a folder on my computer, 19 of them are only about 50KB. That's one-fifth the size of jQuery. Perhaps you should be looking at shrinking your font files first if they're such a problem?

On Fri, Dec 9, 2016 at 8:32 AM, Jonathan Zuckerman <j.zuckerman at gmail.com>

wrote:

# Yay295 (7 months ago)

On another note, are you sure it's font files that are slowing down your page load? Maybe I've just been lucky, but of the 24 font files I happen to have in a folder on my computer, 19 of them are only about 50KB. That's one-fifth the size of jQuery. Perhaps you should be looking at shrinking your font files first if they're such a problem?

On Fri, Dec 9, 2016 at 8:32 AM, Jonathan Zuckerman <j.zuckerman at gmail.com>

wrote:

# Jonathan Garbee (7 months ago)

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.

# Jonathan Garbee (7 months ago)

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.

# Boris Zbarsky (7 months ago)

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 Zbarsky (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Jonathan Garbee (7 months ago)

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] dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

On Fri, Dec 9, 2016 at 12:43 PM Michael A. Peters <mpeters at domblogger.net>

wrote:

# Jonathan Garbee (7 months ago)

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] dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

On Fri, Dec 9, 2016 at 12:43 PM Michael A. Peters <mpeters at domblogger.net>

wrote:

# Jonathan Garbee (7 months ago)

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.

# Jonathan Garbee (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Michael A. Peters (7 months ago)

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.

# Florian Rivoal (7 months ago)

On Dec 9, 2016, at 23:07, Michael A. Peters <mpeters at domblogger.net> wrote:

This was inspired by inspection of a style-sheet in the wild that uses screen-width to try and reduce bandwidth needs of mobile devices.

I like the concept, but very often I use my mobile devices where bandwidth doesn't matter and my laptop via a mifi where bandwidth does matter.

I would like a CSS media query for bandwidth so that I can reduce how many webfonts are used in low bandwidth scenarios. It seems browsers are already smart enough to only download a font defined by @font-face if they need it, so it only needs to be done where the font is used, e.g.

It's been considered before, and that approach will not work. Media queries are the wrong tool for this. Neutrality / bias warning: I'm co-editor of the Media Queries spec.

Media queries, by design, will switch instantly when the environment changes, stop applying the old styles, and start applying the new ones. So if you finish loading a page on your phone in your home wifi with the high-res and heavy assets, start reading, then walk outside into 3G, you'll discard the high res assets and start loading the low res ones. And if you're driving / riding a train in and out of tunnels, you'll toggle between high and low (or low and terrible) constantly, and never manage to finish loading anything, all while using copious amounts of bandwidth. This isn't a bug, this is how Media Queries work, and is the right thing to do for things where media queries are the right tool. If that's not what you want, what you want isn't a media query.

The right approach is something like srcset[1], the source element[2], or image-set()[3]: instead of switching between one variant or another based on a hard criteria, you provide the UA with all the variants you have, and let it switch intelligently.

Of course, these are UA based heurisitics, it is certainly possible that the UA will make poor decisions sometimes, but that's a lot better than the guaranteed bad behavior you'd get with Media queries.

For fonts, there isn't currently an equivalent mechanism, but we could think of adding qualifiers either the @font-face that declares the font, or font-family that tries to use it, to indicate that certain fonts are must-have, while others are optional things that are fine to skip in case of bad bandwidth or latency.

There's already one proposal in that direction, although it hasn't received much attention lately: 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] html.spec.whatwg.org/multipage/embedded-content.html#attr-img-srcset [2] html.spec.whatwg.org/multipage/embedded-content.html#the-source-element [3] drafts.csswg.org/css-images-3/#image-set-notation [4] w3c/csswg-drafts/issues [5] lists.w3.org/Archives/Public/www-style

# Florian Rivoal (7 months ago)

On Dec 9, 2016, at 23:07, Michael A. Peters <mpeters at domblogger.net> wrote:

This was inspired by inspection of a style-sheet in the wild that uses screen-width to try and reduce bandwidth needs of mobile devices.

I like the concept, but very often I use my mobile devices where bandwidth doesn't matter and my laptop via a mifi where bandwidth does matter.

I would like a CSS media query for bandwidth so that I can reduce how many webfonts are used in low bandwidth scenarios. It seems browsers are already smart enough to only download a font defined by @font-face if they need it, so it only needs to be done where the font is used, e.g.

It's been considered before, and that approach will not work. Media queries are the wrong tool for this. Neutrality / bias warning: I'm co-editor of the Media Queries spec.

Media queries, by design, will switch instantly when the environment changes, stop applying the old styles, and start applying the new ones. So if you finish loading a page on your phone in your home wifi with the high-res and heavy assets, start reading, then walk outside into 3G, you'll discard the high res assets and start loading the low res ones. And if you're driving / riding a train in and out of tunnels, you'll toggle between high and low (or low and terrible) constantly, and never manage to finish loading anything, all while using copious amounts of bandwidth. This isn't a bug, this is how Media Queries work, and is the right thing to do for things where media queries are the right tool. If that's not what you want, what you want isn't a media query.

The right approach is something like srcset[1], the source element[2], or image-set()[3]: instead of switching between one variant or another based on a hard criteria, you provide the UA with all the variants you have, and let it switch intelligently.

Of course, these are UA based heurisitics, it is certainly possible that the UA will make poor decisions sometimes, but that's a lot better than the guaranteed bad behavior you'd get with Media queries.

For fonts, there isn't currently an equivalent mechanism, but we could think of adding qualifiers either the @font-face that declares the font, or font-family that tries to use it, to indicate that certain fonts are must-have, while others are optional things that are fine to skip in case of bad bandwidth or latency.

There's already one proposal in that direction, although it hasn't received much attention lately: 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] html.spec.whatwg.org/multipage/embedded-content.html#attr-img-srcset [2] html.spec.whatwg.org/multipage/embedded-content.html#the-source-element [3] drafts.csswg.org/css-images-3/#image-set-notation [4] w3c/csswg-drafts/issues [5] lists.w3.org/Archives/Public/www-style

# Michael A. Peters (7 months ago)

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

On Dec 9, 2016, at 23:07, Michael A. Peters <mpeters at domblogger.net> wrote:

This was inspired by inspection of a style-sheet in the wild that uses screen-width to try and reduce bandwidth needs of mobile devices.

I like the concept, but very often I use my mobile devices where bandwidth doesn't matter and my laptop via a mifi where bandwidth does matter.

I would like a CSS media query for bandwidth so that I can reduce how many webfonts are used in low bandwidth scenarios. It seems browsers are already smart enough to only download a font defined by @font-face if they need it, so it only needs to be done where the font is used, e.g.

It's been considered before, and that approach will not work. Media queries are the wrong tool for this. Neutrality / bias warning: I'm co-editor of the Media Queries spec.

Media queries, by design, will switch instantly when the environment changes, stop applying the old styles, and start applying the new ones. So if you finish loading a page on your phone in your home wifi with the high-res and heavy assets, start reading, then walk outside into 3G, you'll discard the high res assets and start loading the low res ones. And if you're driving / riding a train in and out of tunnels, you'll toggle between high and low (or low and terrible) constantly, and never manage to finish loading anything, all while using copious amounts of bandwidth. This isn't a bug, this is how Media Queries work, and is the right thing to do for things where media queries are the right tool. If that's not what you want, what you want isn't a media query.

The right approach is something like srcset[1], the source element[2], or image-set()[3]: instead of switching between one variant or another based on a hard criteria, you provide the UA with all the variants you have, and let it switch intelligently.

Of course, these are UA based heurisitics, it is certainly possible that the UA will make poor decisions sometimes, but that's a lot better than the guaranteed bad behavior you'd get with Media queries.

For fonts, there isn't currently an equivalent mechanism, but we could think of adding qualifiers either the @font-face that declares the font, or font-family that tries to use it, to indicate that certain fonts are must-have, while others are optional things that are fine to skip in case of bad bandwidth or latency.

There's already one proposal in that direction, although it hasn't received much attention lately: 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] html.spec.whatwg.org/multipage/embedded-content.html#attr-img-srcset [2] html.spec.whatwg.org/multipage/embedded-content.html#the-source-element [3] drafts.csswg.org/css-images-3/#image-set-notation [4] w3c/csswg-drafts/issues [5] 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.

# Michael A. Peters (7 months ago)

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

On Dec 9, 2016, at 23:07, Michael A. Peters <mpeters at domblogger.net> wrote:

This was inspired by inspection of a style-sheet in the wild that uses screen-width to try and reduce bandwidth needs of mobile devices.

I like the concept, but very often I use my mobile devices where bandwidth doesn't matter and my laptop via a mifi where bandwidth does matter.

I would like a CSS media query for bandwidth so that I can reduce how many webfonts are used in low bandwidth scenarios. It seems browsers are already smart enough to only download a font defined by @font-face if they need it, so it only needs to be done where the font is used, e.g.

It's been considered before, and that approach will not work. Media queries are the wrong tool for this. Neutrality / bias warning: I'm co-editor of the Media Queries spec.

Media queries, by design, will switch instantly when the environment changes, stop applying the old styles, and start applying the new ones. So if you finish loading a page on your phone in your home wifi with the high-res and heavy assets, start reading, then walk outside into 3G, you'll discard the high res assets and start loading the low res ones. And if you're driving / riding a train in and out of tunnels, you'll toggle between high and low (or low and terrible) constantly, and never manage to finish loading anything, all while using copious amounts of bandwidth. This isn't a bug, this is how Media Queries work, and is the right thing to do for things where media queries are the right tool. If that's not what you want, what you want isn't a media query.

The right approach is something like srcset[1], the source element[2], or image-set()[3]: instead of switching between one variant or another based on a hard criteria, you provide the UA with all the variants you have, and let it switch intelligently.

Of course, these are UA based heurisitics, it is certainly possible that the UA will make poor decisions sometimes, but that's a lot better than the guaranteed bad behavior you'd get with Media queries.

For fonts, there isn't currently an equivalent mechanism, but we could think of adding qualifiers either the @font-face that declares the font, or font-family that tries to use it, to indicate that certain fonts are must-have, while others are optional things that are fine to skip in case of bad bandwidth or latency.

There's already one proposal in that direction, although it hasn't received much attention lately: 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] html.spec.whatwg.org/multipage/embedded-content.html#attr-img-srcset [2] html.spec.whatwg.org/multipage/embedded-content.html#the-source-element [3] drafts.csswg.org/css-images-3/#image-set-notation [4] w3c/csswg-drafts/issues [5] 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 (9 days ago)

"Michael A. Peters" <mpeters at domblogger.net> 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 <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,

Want more features?

Request early access to our private beta of readable email premium.