- From: Yay295 <yay295@gmail.com>
- Date: Fri, 9 Dec 2016 09:09:08 -0700
- To: Jonathan Zuckerman <j.zuckerman@gmail.com>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, "Michael A. Peters" <mpeters@domblogger.net>
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@gmail.com> wrote: > Michael - I think "high" and "low" are very relative terms, defining those > terms for all users for all time doesn't seem possible. Also, > connectivity/bandwidth are subject to change at any moment during the > lifetime of a page. Current media queries like `max-height` or > `min-resolution` would respond to changes, have you thought about how your > proposed addition would behave? > > Currently you can use javascript to figure out if the network will support > your enhanced experience (and you're free to define what that means) and > add a classname to the document to trigger the css rules for that > experience, so you can build the feature you're asking for using existing > parts. It's not baked into the platform, but because of the nature of the > web and vagueness of the requirements, I'm not sure it's possible to do any > better. > > On Fri, Dec 9, 2016 at 9:07 AM Michael A. Peters <mpeters@domblogger.net> > wrote: > > > This was inspired by inspection of a style-sheet in the wild that uses > > screen-width to try and reduce bandwidth needs of mobile devices. > > > > I like the concept, but very often I use my mobile devices where > > bandwidth doesn't matter and my laptop via a mifi where bandwidth does > > matter. > > > > I would like a CSS media query for bandwidth so that I can reduce how > > many webfonts are used in low bandwidth scenarios. It seems browsers are > > already smart enough to only download a font defined by @font-face if > > they need it, so it only needs to be done where the font is used, e.g. > > > > pre { > > font-family: 'monoFont-Roman', monospace; > > } > > pre em { > > font-family: 'monoFont-Italic', monospace; > > font-style: normal; > > } > > pre strong { > > font-family: 'monoFont-Bold', monospace; > > font-weight: normal; > > } > > pre em strong { > > font-family: 'monoFont-BoldItalic', monospace; > > font-style: normal; > > font-weight: normal; > > } > > pre strong em { > > font-family: 'monoFont-BoldItalic', monospace; > > font-style: normal; > > font-weight: normal; > > } > > @media screen and (device-bandwidth: low) { > > pre strong { > > font-family: 'monoFont-Roman', monospace; > > font-weight: 700; > > } > > pre em strong { > > font-family: 'monoFont-Italic', monospace; > > font-weight: 700; > > } > > pre strong em { > > font-family: 'monoFont-Italic', monospace; > > font-weight: 700; > > } > > } > > > > That right there cuts the number of fonts the low-bandwidth device needs > > in half, and could have even gone further and used fake italic if the > > fake italic for the font looks good enough. > > > > The small increase in CSS file size doesn't matter with high bandwidth > > clients and is justified for low-bandwidth as it reduces the content > > that needs to be fetched. > > > > It would be up to the client to define the device-bandwidth, web > > developers should create the CSS for high bandwidth and only have the > > alternate CSS kick in when a media query says it is low. > > > > Honestly I think low or high are the only definitions needed with low > > being the only one that a site should have conditional styles set for. > > > > -=- > > > > The same concept could be applied to html5 media too. e.g. I could serve > > the 64 kbps opus to clients that don't define themselves as low, and the > > 32 kbps opus to clients that do define themselves as low. > > > > How to handle media in situations where a service worker pre-fetches > > content I haven't thought about, because a client may pre-fetch content > > before the bandwidth constraint changes, but I suspect there's a clever > > solution to that (e.g. always fetch high bandwidth when async pre-fetch > > and then use high bandwidth when cached even if in low bandwidth mode) > > > > But html5 media can be figured out later, CSS is what I really would > > like to see a bandwidth media query for. > > > > Thoughts? > > >
Received on Friday, 9 December 2016 16:09:42 UTC