Revert mobile-first media queries and remove respond.js

[paulirish]

IE6-8 require respond.js to act as a polyfill because H5BP uses mobile-first media queries.

I'm not convinced mobile-first media queries are best.

1. Clearly they have this extra cost for IE baked in.
2. Secondly, it's a little awkward, as a developer, to write your styles mobile first.

What mobile browsers (in use, currently) do not support media queries? Moreover, of the ones who don't, are there browsers that don't scale the content to somehow adapt to the small screen size?

I don't know enough of the Blackberry/Nokia product line to know what's up on this front. But I have a feeling the mobile-first MQ setup is a lot of work. And the payoff is not worth the effort.

[wookiehangover]

IMO the mobile first approach might be better suited to the mobile boilerplate

[addyosmani]

Agreed ^.

[chuanxshi]

I almost never used mobile-first approach for a site with many JS-heavy components and various layout; for a portfolio site or blog, maybe mobile-first could be an approach. It's defintely not a default in my opinion.

It's ok to have it in mobile boilerplate because it has a mobile focus.

I know the general grumblings around are supposed to be 'write mobile first', but I can't get my head around writing for mobile when the testing tools are so well tooled for the desktop currently.

+1 for removing respond. If you need to build a mobile-version of your site, you can stick the media queries in yourself or use some htaccess to push the user to the appropriate mobile page (built with mobile boilerplate), it's really too-specific to the use-case for the general nature of H5BP.

[mathiasbynens]

Secondly, it's a little awkward, as a developer, to write your styles mobile first.

Care to elaborate on that?

Soon there will be more mobile Internet users than desktop users — in some countries this shift has already happened. I agree it’s a bit awkward to get used to this (since we’re all used to develop for “desktop first”), but I can’t help but feel mobile first is the direction we need to go in. We’ll have to adapt to the large number of mobile surfers eventually.

[necolas]

It's pretty easy to switch between either approach to development. Just switch the placeholder MQs to use max-width rather than min-width. The issue of the extra IE6-8 cost would involve pulling Respond.js out of the custom Modernizr build (probably into its own file to be optionally included).

Maybe it's worth separating "mobile" from "narrow viewport". What we've got as the starting point in H5BP is narrow-viewport-first (although, as mentioned, it's trivial to switch back to wide-viewport-first). One of the benefits of the narrow-viewport-first approach is that it is a continuation of "progressive enhancement" and provides a simple way to ensure that your content is widely accessible, if not optimised. Older browsers are naturally shielded behind media queries from your more complex layout styles. However, since people want IE6-8 to receive more than this base style, you burden those already-weak browsers with extra JS in the form of a MQ (and other) polyfills. I'm not sure how much of a penalty this turns out to be for those browsers.

It's one thing to design for mobile first. It's quite another to try and use one front-end code base to cover fully-fledged, optimised experiences on all devices and built up from narrow viewports first. Easier for simple sites, pretty hard for more complex ones. It's a delicate dance of writing your HTML primarily for wider viewports while writing your CSS to start from a narrow viewport perspective...not to mention the JS. That's quite apart from the ease-of-maintenance issue and the work that you might have to put into modifying images and other bandwidth-hungry assets if you're fully committing to this approach.

There are going to be times when the "mobile" context is going to demand tailored content and design that diverges significantly from what is served in non-mobile contexts. Basically, a dedicated "mobile website". That is beyond the scope of the H5BP project and just using media queries.

But if we remove all the narrow-viewport-first stuff by default, we risk opening the door for people to build H5BP bolt-ons to enable it. Some of those that have cropped up in the past were not properly tested or maintained. I don't think that is very good for the community.

So I guess I'm not opposed to leaving the narrow-viewport-first MQs in there by default (as they are only placeholders). Simple sites can make good use of the approach, while developers working on larger sites will make their own choice. But perhaps we should pull Respond.js out of Modernizr and into its own file to give people clearer control over its inclusion in the project?

IMO the mobile first approach might be better suited to the mobile boilerplate

The Mobile Boilerplate is geared around providing a starting point for mobile webapps. So it's not really that you switch to the Mobile Boilerplate if you want to develop "mobile first". You can still use the HTML5 Boilerplate.

use some htaccess to push the user to the appropriate mobile page

Browser UA string sniffing? This is a pretty flakey approach.

it's really too-specific to the use-case for the general nature of H5BP

It's not too specific at all. We're just not convinced that it is practical for more complex sites.

[paulirish]

This stemmed from an emerging belief that all CSS polyfills are a decent amount of trouble in the hands of a great developer, and lots of trouble in the hands of a less experienced one.

From a perf standpoint, they seem very similar to <script>s in the <head>. Well, in fact most of the time they are.. :)

• CSS polyfills either cause FOUC or block page rendering as they parse your CSS.
• Parsing isn't free either.. As the full text of a stylesheet isnt available from the DOM, they must XHR in the file again to parse it
  • Especially on mobile, extra HTTP RTTs are hugely costly.
• Parsing CSS is tricky as even a spec-conformant parser will get hung up on some CSS hacks.

What I think is a good rule of thumb is.. if you can lazily initialize the polyfill (after DOMContentLoaded) with a reasonable UX (not keeping the page invisible until its ready), then you're good. Otherwise I think the perf overhead is too significant. Clearly we're low on hard data here, though. :/

[paulirish]

fwiw todd (filament group) believes WP7 (not mango) was the only mobile device to require respond: https://twitter.com/#!/toddmparker/status/126325865561866241

[necolas]

Can WP7 users upgrade to 7.5? Or do we need to wait for those devices to leave the ecosystem before IE7-on-mobile is no more?

[paulirish]

Argument from the other side..

http://www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-yiibu slides 87-101

[tchalvak]

I don't know about you guys, but I've had quite a bit of trouble getting even a single desktop emulator for any mobile browsing testing to work for me. Oh, uh, that may be because I'm on linux, but yeah, it's a pretty tricky problem anywhere, I expect (testing on the desktop as if you were browsing on android required setup of a weird virtualmachine that had major performance issues for me, and I didn't find any way to replicate iOS).

As such, I haven't been able to approach h5bp from a mobile first perspective, only from a narrow-width perspective by silly things like decreasing the browser width and such.

So I'd love to hear how you guys approach this problem if you're doing so successfully. For lowly me, mobile first is effectively a no-op.

[bradfrost]

PPK is tracking media query support here: http://www.quirksmode.org/mobile/tableViewport.html#mediaqueries

• WP7 (pre-Mango) is running IE7 so doesn't support MQs
• Blackberries (pre 6.0) don't support MQs. You might say "screw them" but here's a breakdown of subscribers by OS: http://us.blackberry.com/developers/subscribers_by_os_lg.jpg from the page http://us.blackberry.com/developers/choosingtargetos.jsp
• Netfront, which is amazingly-shitty, also falls into the would-be "screw you" category. However, Netfront powers the now-$79 Amazon Kindle, which has the potential to be around for a long time. It also powers the Sony PSP, which for several of our more youth-oriented clients actually has substantial traffic coming from it.
• Future devices - This is important. While we can cross our fingers and hope that future browsers will get better, the fact remains that we can't count on it. With Moore's Law still in full-effect, there's about to be a ton of cheap, web-enabled, "good-enough" devices flooding the market.

I'm going to modify the second point: "Secondly, it's a little awkward at first, as a developer, to write your styles mobile first."

That addition of at first is important. We're right now in the middle of a massive transition away from the desktop and towards a mobile future. The writing is on the wall. It requires changing the way we think. We've artificially created an "ideal" width for our websites in order to maintain control. It's been an assumption that's been a convenience for designers and developers alike. However, the desktop-first approach falls apart pretty quickly. Take this example:

.section {
      width: 50%;
      float: left;
}
@media screen and (max-width: 600px) {
    .section {
              width: 100%;
             float: none;
        }
}

By assuming desktop-first we introducing unneeded complexity into the code. Here's the mobile-first version:

@media screen and (min-width: 600px) {
    .section {
              width: 50%;
             float: left;
        }
}

Much better. Instead of having to override desktop styles, you simply define properties as they're needed. It's more efficient and way easier to maintain.

"Mobile-first" in my humble opinion is much more a mental thing than it is a technical technique. It's another extension of progressive enhancement. We don't automatically assume geolocation, accelerometer and touch event support in browsers; we detect for their presence then act accordingly. We need to apply that same logic to something as simple as screen width (and to other comfortable assumptions like connection type). The "user is totally on a desktop" assumption needs to die as soon as possible in order for the web (as viewed through a browser) to continue to be viable in our mobile future.

[vasilisvg]

Correct me if I'm wrong but I believe that the mobile first approach with media queries was invented to prevent the downloading of big background-images on small viewports. That is a very valid reason.

Now, if you don't use background-images the need to use this appoach is not as urgent anymore. But I do agree with @bradfrost that it will result in cleaner and smarter code.

From a day to day web development practice I see that OLDIE's are rapidly becoming less important and small viewports are becoming more important. This is true even for big corporate clients. Using polyfills (or hacks) for IE might seem like a complex solution right now but it does result in better code for all modern browsers. I guess that's a best practice.

What I'm not sure about is if media queries should be grouped on viewport level or on component level. I think I prefer the component level approach and I wouldn't know how to put that into the H5BP.

So. That didn't answer the question at all, did it? (-:

[paulirish]

For the record, the asset downloading bug was fixed in WebKit 534.6.0 back in August 2010.

That means Safari 5, iOS 4.3 and Android 3.0 do not yet have this fix. Safari 5.1 does. I can't tell if iOS 5 Mobile Safari does... (I would think the fix is in there.)

bug link: https://bugs.webkit.org/show_bug.cgi?id=24223

[alexgibson]

If the main issue is the overhead created by respond.js for IE6-8, is there a reason why you can't remove it and use a single conditional comment for IE/IE Mobile, as-per Jeremy Keith's post here?

http://adactio.com/journal/4494/

Forgive me if I'm covering previously discussed ground, or missing out on something else obvious. I know some don't like using CC's, but from a development and performance point of view I quite like this approach.