I can see the appeal, but I wonder if this might not be better accomplished with an HTTP header that would explicitly give the viewport dimensions and/or some information about the connection type/speed.
Viewports can change in size once the page has loaded. A Connection-Quality: GPRS, 512kbps; header would be nice. But then you still get an issue when phones must report or the user toggles on WiFi as soon as they see a few bad (low bitrate) assets.
Yeah, suggesting viewport dimensions was a lazily considered and unfortunate choice on my part. Screen dimensions -- probably in particular the larger device width -- would be better, and now that pixel density is an issue, that as well.
Hm - I don't think the particular example they used (where the function called by onresize just changes a variable) really needs a clear/setTimeout variable.
I see what you mean though, if the function called by onresize was actually making visual changes to the page, the designer would very quickly figure out they need an clear/setTimeout layer.
Sad to see another site making the mistake of thinking that Opera 12 and below are the same as Opera 15 and above, despite the two sharing literally zero code.
Has any work been done on identifying the browsers connection speed so that we may serve high quality vs. low quality assets? The only thing I've been able to find for this is the MaxMind GeoIP Netspeed database, but I have no idea if the data is accurate enough to be valuable. I suppose you could measure latency, but not during the initial page load..
I really like Jeremy Keith's approach to "responsive javascript". He uses `:after` and updates the content property based on media queries. It keeps it nice and DRY. Here's a small demo: http://jsbin.com/meqon/2/edit?css,js,output
more things that take the control out of the user. and add lots of complexity for no good reason.
why on earth have javascript to do CSS's work?
and why do you care about screen size changes? the only good thing it does is hint you about device orientation. But who says when i change from portrait to landscape i want a whole new site? sometimes turning a device just mean i want to fit one image better in the screen. not change all my navigation elements to fit the designer dream of multi-screen shenanigans.
yeah, i sound like the old fart who don't like shinny things and change. but people impressed by this sound like the kids adding animated gif after animated gif to their geocities page. now get off my lawn!
Some behaviour may need to be initialised depending on the width of the viewport. For example: I may want to provide a side swipe menu in my mobile version that I do not want to initialise and become available in the web version.
Yes, you don't need a whole new site. But I as a developer may want to provide a better experience with the additional horizontal space I just received in the landscape mode. Or I may want to sneak in some ads on the side.
Media queries go only so far but they cannot help you to create behaviour that depends on the width of the viewport.
The one problem I've found with this approach is making sure that the CSS and JS breakpoints stay in sync as a site is maintained. At my previous job, we came up with a way of changing JS behavior based on CSS changes to DOM objects. http://blog.cloudfour.com/behavioral-breakpoints/
In my experience, setting a handler for every onresize event can lead to performance problems if you've got a complex layout. It's better to wrap it in something like Underscore's throttle function (1) and only let it fire every 200ms or so.
25 comments
[ 2.9 ms ] story [ 79.2 ms ] threadDo now need to send every possible view port with the original header?
Thanks for spreading the word.
I see what you mean though, if the function called by onresize was actually making visual changes to the page, the designer would very quickly figure out they need an clear/setTimeout layer.
I guess the second mention of "Javascript" should be "CSS", right?
Edit: How he got there is a neat, quick read for anyone interested: http://adactio.com/journal/5429/
why on earth have javascript to do CSS's work?
and why do you care about screen size changes? the only good thing it does is hint you about device orientation. But who says when i change from portrait to landscape i want a whole new site? sometimes turning a device just mean i want to fit one image better in the screen. not change all my navigation elements to fit the designer dream of multi-screen shenanigans.
yeah, i sound like the old fart who don't like shinny things and change. but people impressed by this sound like the kids adding animated gif after animated gif to their geocities page. now get off my lawn!
Yes, you don't need a whole new site. But I as a developer may want to provide a better experience with the additional horizontal space I just received in the landscape mode. Or I may want to sneak in some ads on the side.
Media queries go only so far but they cannot help you to create behaviour that depends on the width of the viewport.
See you are just adding complexity to development and use of the site.
1: http://underscorejs.org/#throttle