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.

[ghost]

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.

[necolas]

Hey Brad, thanks for the details on browser support. Which of those browsers doesn't run JS, and so couldn't make use of the Respond polyfill?

"Mobile-first" in my humble opinion is much more a mental thing than it is a technical technique

From the design perspective, I agree. But I think there are some inherent tensions from a development perspective that means it goes beyond just a switch in mentality.

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.

I get the feeling that that assumption has largely died. It is different to a 'wide-viewport-first' approach to development that still adapts to narrower viewports in browsers that support MQs or can run a JS polyfill. That won't provide an good experience in some environments. But that is not the same thing as ignoring the mobile landscape altogether or assuming pure-desktop browsing.

For fairly complex sites (across all the front-end layers), the experience or preferred content on mobile devices will sometimes be better served with a dedicated and optimised website. Maintenance concerns might also play a part. In those cases, it may not be wise or practical to always try and deliver all experiences from a single front-end codebase.

However, that doesn't necessarily mean that you cannot start with the base styles (for narrow viewports) first even in those cases. Which is why I'm happy to keep the MQs that build up to wider viewports as the default. If a developer wants to reverse them, it is very easy to do so. However, making the inclusion of Repond.js more visible might be beneficial and help those who aren't catering for mobiles (for whatever reason) avoid also penalising IE6-8 uses with unnecessary XHR of their stylesheets.

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

The concern was about what Respond needs to do in IE6-8. Plus, using CCs would mean that people using the boilerplate without the <html> classes would need to include an empty CC at the top of the head to prevent download blocking.

[nimbupani]

However, that doesn't necessarily mean that you cannot start with the base styles (for narrow viewports) first even in those cases.

That is precisely the kind of "good practice" we need to encourage I think. I would even argue that we should leave it at that for any browser that is incapable of understanding media queries (including IE8) and let users decide on a good solution for IE (or provide it as a snippet in h5bp-ui).

I think we need developers to think about this basic styling first rather than as an after thought. It would make sites at least readable (if not too usable) on most browsers.

[alexgibson]

using CCs would mean that people using the boilerplate without the classes would need to include an empty CC at the top of the head to prevent download blocking.

I see, ugh :-(

we should leave it at that for any browser that is incapable of understanding media queries (including IE8) and let users decide on a good solution for IE (or provide it as a snippet in h5bp-ui).

I like the sound of this. There are a few ways to approach handling IE, so let developers know the options and they can pick the most appropriate solution?

[stephrieger]

Which of those browsers doesn't run JS, and so couldn't make use of the Respond polyfill?

Most of the browsers Brad mentioned are problematic. BlackBerry pre 6.0 ranges from poor to decent depending on the browser version (pre v.4.6.1 is almost completely useless), Netfront equally so (historically and on more recent devices like Kindle).

The main thing is really that "JavaScript support" is not a binary thing. I wouldn't presume adequate support for any JS based polyfill on all those noted browsers until that polyfill has been thoroughly tested on each browser (I so far can't find specific evidence that they have). So from that point of view, you would also be wise to add most of S60/S^3 to that list, along with Nokia's S40 WebKit browser and their new S40 proxy browser.

At this stage, I would recommend removing the media query polyfill and letting devs decide what is best for their particular scenario. We (yiibu) develop everything mobile first and handle all versions of IE using a series of conditionals. This has so far worked extremely well and is a great way to introduce clients to the reality of today's browser landscape. Browsers will continue to improve (and certain techniques will become redundant as support broadens) but Amazon's latest product releases are a great example of the browser/device diversity we can continue to expect. We need to get past the (reactive) polyfill-centric approach to this diversity and work towards more future friendly mindsets and techniques.

[jswartwood]

Some food for thought...

It seems to me that on larger teams/apps, Mobile-first may often become more of a maintenance cost than benefit. I am wondering if creating a more ubiquitous backend design with true duplicated views for mobile/web/tablet (as necessary) would make more sense. In larger cases, leveraging modular view fragments for each version of the site may be a simpler strategy than constantly "overwriting" aspects for varying MQs. Then there is less bloat in all cases (except maybe your routing/controller).

If part of H5BP is good practices, we may want to help teach app architecture... not declaring the above strategy is right in all circumstances, but in many apps the feature (and design) gap between mobile and desktop is frankly just too vast. Obviously H5BP is also meant to be backend-agnostic, so I wouldn't push any harder than maybe documentation or a couple of empty view folders.

[jwlms]

There is the extra cost for IE6-8 that comes from doing mobile first and respond.js. Yes FOUC sucks, but the tradeoff for mobile users, which will eventually overtake ie6-ie8 users, is worth it.

Mobile first is awkward for developers at first, but it's the right way to approach responsive website design. You end up serving less resources to mobile devices and you will write less CSS code than designing from the desktop down. In my experience, you can build on your mobile styles for tablets and desktops with small adjustments under the appropriate media queries. The first responsive sites I built were from the desktop down, and I ended up wasting a lot of time moving my CSS between media queries, or writing more CSS than was necessary instead of just being able to make small adjustments as I do now using a mobile first approach.

[nimbupani]

In larger cases, leveraging modular view fragments for each version of the site may be a simpler strategy than constantly "overwriting" aspects for varying MQs. Then there is less bloat in all cases (except maybe your routing/controller).

Definitely. But I am not sure if most of the audience of H5BP writes such applications to begin with. I guess we would need a survey to find out.

If part of H5BP is good practices, we may want to help teach app architecture... not declaring the above strategy is right in all circumstances, but in many apps the feature (and design) gap between mobile and desktop is frankly just too vast. Obviously H5BP is also meant to be backend-agnostic, so I wouldn't push any harder than maybe documentation or a couple of empty view folders.

I think there are multiple issues at hand, one of which is styling. This issue specifically addresses the issue of media queries in CSS and not about the content or the overall architecture of the site. Those are big issues and we definitely lack any definition of best practices and probably something we would want to tackle as part of h5bp-ui.

[lewisnyman]

There are other ways to deal with non MQ browsers instead of respond.js - http://coding.smashingmagazine.com/2011/08/10/techniques-for-gracefully-degrading-media-queries/

You could say that in some use cases even respond.js isn't a good enough polyfill. This seems like the kind of thing that should be left up to the developer, it depends on the target audience of each site.

[cthedot]

@necolas: All WP7 users should be able to update, not sure if there are problems as there were with the Nodo (copy&paste ;) update in Feb. I reckon at the end of this year latest all users COULD update (does not necessarily mean they do though). IE9 on Mango actually IS nice (for what I know for now).

+1 for mobile first, I did some work using this approach (without H5BP) and after a little while it feels natural.

BTW, is a separate "mobile" BP actually needed anymore?

[jswartwood]

I think there are multiple issues at hand, one of which is styling. This issue specifically addresses the issue of media queries in CSS and not about the content or the overall architecture of the site.

I disagree that these need to be two different issues; architecture and CSS definition are not mutually exclusive. CSS minification + concatenation is cheap (if not free) for building apps these days. Including just the relevant bits and selectively inlining CSS may make more sense than MQing. Recently, I've been really interested in revisiting inlining small minified CSS snippets instead of larger concatenated (cached) common files.

An example (of all styles required on the product page) from a new version of AE.com targeted at our PoS machines (where speed is the top priority):

<!-- Common styles -->
<style>html{background-color:#f3eddd;color:#616159}a{color:#616159}.inverted{background-color:#0b1720;color:#f3eddd}.inverted a{color:#f3eddd}.lighter{background-color:#fff5e4}.darker{background-color:#eae2d2}.darkest{background-color:#e1dbc1}.bordered{border-color:#bebfaf;border-width:1px;border-style:none}.darkBorders{border-color:#616159}html,body,form{padding:0;margin:0}ul,li,h1,h2{padding:0;margin:0;font-size:1em;font-weight:normal}li{list-style:none}a{color:inherit;text-decoration:none}img{vertical-align:top;border:0}body{font:normal 10px sans-serif;width:770px;margin:0 auto 60px}.clearer{overflow:hidden;height:0;width:0;clear:both}.gridded{float:left;margin:0 10px 20px}.smallGridded{float:left;margin:0 5px 10px}.content{width:638px}.header{padding:0 10px 20px}.header h1,.header .brandLink{display:block;float:left}.header .brandLink{overflow:hidden;height:0;padding-top:31px;width:89px;background:url(/Images/lookbook/logo_brands.jpg) no-repeat 0 0}.header .b_web{background-position:0 0}.header h1 .b_web{background-position:0 -31px}.header .b_aerie{background-position:-89px 0}.header h1 .b_aerie{background-position:-89px -31px}.header .b_77kids{background-position:-178px 0}.header h1 .b_77kids{background-position:-178px -31px}.siteSearch{float:right}.siteSearch *{vertical-align:middle;font-size:12px;text-transform:uppercase}.siteSearch .question{margin:0 0 0 10px;width:172px;height:27px;line-height:27px;border-left-style:solid;border-bottom-style:solid;border-right-style:solid}.siteSearch .bttn{margin:0;border-bottom-style:solid;border-right-style:solid}.nav li{width:170px}.nav a,.nav .noLink{display:block;padding:6px 10px;text-transform:uppercase;cursor:pointer;zoom:1}.nav .menu a,.nav .menu .noLink{padding:6px 20px}.rootLink{border-style:solid;text-align:center}.nav .menu{display:none}.rootMenu{border-left-style:solid;border-right-style:solid}.flyout .rootMenu{display:none;position:absolute;z-index:10}.topNav .expanded .rootMenu,.rootMenu .expanded .menu{display:block}.rootMenu li{width:168px;border-bottom-style:solid;vertical-align:top}.rootMenu li li{border-top-style:solid;border-bottom-style:none}.sideNav{border-top-style:solid}.icons{float:right;margin-left:10px}.rootMenu .arrow,.rootMenu .minus{display:none}.rootMenu .expanded .plus,.rootMenu .emptyCat .plus{display:none}.rootMenu .expanded .minus{display:inline}.rootMenu .emptyCat .arrow{display:inline}</style>
<!-- Product page -->
<style>.pdpContent{border-style:solid}.imgViewer{float:left;width:299px;text-align:center}.imgViews{padding:6px}.imgView img{border:3px solid transparent;margin:2px}.imgViews .selected img{border-color:#000}.pInfo{float:left;border-left-style:solid;padding:20px}.pInfoInner{float:left;width:208px}.minHeightShim{float:right;width:0;height:460px}.pName,.pMarketing,.pColor,.price,.sale{margin-bottom:20px}.pName{font-size:20px;text-transform:uppercase}.tinyPrice{text-decoration:line-through}.price,.sale{font-size:20px}.sale{color:#a30320}.pColor{text-transform:uppercase;padding:6px 0;border-top-style:solid;border-bottom-style:solid}.swatches{padding-top:3px}.swatches img{margin:2px;border:3px solid transparent}.swatches .selected img{border-color:#000}.equity{border-top-style:solid}.equity li{width:206px}.equity .menu{border-top-style:solid;padding:10px;width:186px;overflow:auto}.equity .menu li{border:0;width:auto!important}.equity .menu .linePadding{margin-bottom:10px}.equity .menu a{display:inline}.equityTip{display:none!important}</style>

...Five small CSS files concatenated and minified into two CSS snippets. I know that is a very specific and simplified use case, but the lack of external requests significantly improves performance and omits any possibility of stylesheet timeout issues, etc.

I'm sure many of you will be quick to rebut that inlining these fragments will be worse in case X or case Y, and that I am choosing one evil over another... but I think that is really the moral; H5BP probably shouldn't steer people toward habits that may come back to bite them on a different project. I think education and configuration is more important than producing a one-solve-fits-all.

From HTML5 Boiler Plate README:

It does not impose a specific development philosophy or framework, so you're free to architect your code in the way that you want.

Let me tell you a quick story of which this conversation has reminded me...
We all know that CSS image spriting is great! It reduces requests, it often reduces total downloaded image size, and sometimes even reduces complexity in maintaining uniformity of site-wide imagery (by keeping everything in the same PSD). One day, one of the developers on our team started internationalizing our site; he had to implement a little flag that would show next to the country you had selected. So like any good developer would, he sprited all the little flags together into a beautiful grid. It wasn't until much later when I saw this and thought: "hm... How often does a user actually change his/her language? And more importantly, would the user ever need to see more than one of these flags at the same time?" The answers (respectively) were "Once." and "No, never.", which obviously led me to realize the error of spriting in this case (currently every user has to load every flag). I think we may need to step back w/ MQs and think about that... will the user ever need to load more than one experience on the same device? I think the answer is "very rarely".

Please remember that we all develop for the user, and I think we can all agree that the user has the best experience on a site specifically designed for the device they are using. For most sites that would use H5BP, responsive design means omitting user choice of multiple "appropriate" site versions and instead giving them a single "flexible" version. We do this because it theoretically makes our lives easier and theoretically provides the best user experience. For any given project, the developer should still remember to ask the question "Does it?"

[necolas]

BTW, is a separate "mobile" BP actually needed anymore?

The Mobile Boilerplate is primarily for mobile web apps.

[bradfrost]

@jswartwood - You're touching on a very important issue. All of these techniques we're introducing need to make solid sense for real people. A lot of responsive designs bend over backwards to account for small screens, but in doing so add a whole lot of overhead. The end result are needlessly complex designs that might not offer any real value to the people using the sites. I sometimes wonder if the designers actually USE the sites on mobile devices, or are simply doing it to do it.

For the most part, only developers and people coming from sites like http://mediaqueri.es are the only ones squishing and scaling these sites. A user on a portrait-only Blackberry Bold doesn't care that the layout is responsive. What really matters is how quickly they can accomplish their goals and get on with their day. With every polyfill, every cartwheel required to create a flexible system (especially if trying to shoe-horn an existing desktop site into a smaller frame), we're introducing more complexity, which affects performance and usability.

@necolas touched on the fact that sometimes separate mobile templates make more sense, and Luke Wroblewski also highlighted why he chose to use of separate templates: http://www.lukew.com/ff/entry.asp?1390. Media elements (images, videos and more) and source order are two of the biggest challenges I've faced when creating responsive sites.

It ultimately comes down to the project and how much the experience might change across the different form factors. Even if separate templates are used, they both should be as flexible as possible.

As far as H5BP is concerned, I'm not exactly sure what I would change, but I would encourage starting from simpler, more universal stylings then working the way up to larger screens and more complex stylings.

[millermedeiros]

This presentation is really good: Crap! It doesn't look quite right, or, how I learned to stop worrying and set my mobile web sites free

We are doing it wrong.
Our false sense of control over layout combines with other factors to make like for us on the current pan-device web very difficult indeed.

Main problem of the "mobile-first" approach is that many designs aren't fluid or couldn't be fluid/responsive (relies heavily on images, complex interaction, lots of content, etc), also because of high expectations. It's a nice concept but I still can't see it being adopted on many kinds of projects because of technical difficulties and deadlines (as some people pointed before).

I hope to follow this approach on many projects but I can't see it being adopted by most people right now.. I think this discussion was a good thing since it will make more people aware of the benefits/drawbacks of each technique and we should probably add info about this subject to the documentation so people can use it if they think it is the right approach. I think it should only become the default if the majority of users are following this approach (which I believe won't be true for a long time...)

The future friendly website contains links to useful resources/articles and a manifesto.

[wjcrowcroft]

I'm gonna throw my hands up and admit I've never designed or built a site "mobile first". Even when it's fully responsive, I always start at desktop level and scrunch everything down if needed... but I think @bradfrost has it right with:

For the most part, only developers and people coming from sites like http://mediaqueri.es are the only ones squishing and scaling these sites. A user on a portrait-only Blackberry Bold doesn't care that the layout is responsive. What really matters is how quickly they can accomplish their goals and get on with their day.

Hits the nail on the head, for me. It's not suitable for every project. Still would love to have it optional as part of the custom-build boilerplate download.

[paulirish]

on letting the developer decide..

Part of what drives threads like these is that I'm of the mind that it's not effective when its always up to the developer to decide which approach to take.

Best practices are powerful because you can put credence in them and developers save time and money not exploring their options each time. This is precisely why HTML5 Boilerplate is appreciated (i hope!); it trots out some defaults that have a lot of data behind them and we feel comfortable of these being a baseline of web developer projects.

In some cases, sure, it comes up to a judgement call. But I think in nearly all cases things can be boiled down to a few questions that point to your best recommended approach. And I feel strongly that these approaches need to have data to back them up as the right approach.

so..

Thanks everyone for weighing in here. Just gonna round up some facts, first...

• There is some threshold at which it makes sense to deliver different views to NVP (narrow viewport aka "mobile") and WVP (wide viewport). That threshold occurs somewhere along the blog ↔ webapp continuum.
• Known mobile browsers w/o MQ support: Kindle, S60/S^3, Nokia's S40 WebKit browser & their new S40 proxy browser, and old feature phones (obv)
• jQuery mobile, which is the most inclusive when it comes to mobile webapp frameworks and browser support, doesn't support browsers without media queries.
• the webkit asset download bug exists.
  • but only matters if you do WVP MQs and background-images that you'll need to cancel out

Techniques for NVP MQs:

1. Respond.js allows you NVP MQs, but at a significant perf cost.
   • no cross-domain, no em-support, no @imports
   • sorry scott that you're on vacation and i'm hating on your project. <3
2. Separate files with CCs
   • This also means requiring the empty CC to prevent blocking behavior
   • Could do one of these:

Separate files with CC approaches

<link rel="stylesheet" href="global.css">
<link rel="stylesheet" href="desktop.css" media="all and (min-width: 700px)">
<!--[if (lt IE 9)&(!IEMobile 7)]> 
  <link rel="stylesheet" href="desktop.css">
<![endif]-->

or

<link rel="stylesheet" href="global-including-desktopstyles-inMQs.css">
<!--[if (lt IE 9)&(!IEMobile 7)]> 
  <link rel="stylesheet" href="just-desktop.css">
<![endif]-->

or

“Mobile first” CSS and getting Sass to help with legacy IE by nicolas gallagher

Why do NVP-first?

• Old mobile browsers (w/o MQ support) don't get some pages designed for desktop
  • I haven't seen what these browsers actually do with web pages. I seem to remember some intelligent scaling
  • Can anyone show what a 960px-ish wide non-responsive mainstream site looks like on one of these?
  • I'm dubious about marketshare of these devices
    • I'm more dubious about "page view share" of these devices. Are people actually using the web browsers on them?
• Why cancel out your desktop styles when you could just deliver more simplistic styles up front?
  • Sensible. :)
• Avoid the webkit download bug for background images
  • But, who uses backgrond images anymore, psh! Also serving images to mobile.. you should be ashamed!

Also, zomigi's recent post on this media query business is an excellent read.

[folktrash]

oh man, i feel like we're dating now. AND I'M VERY EXCITED BY THE PROSPECT. Some moments on the internet make me so happy. Srsly.

[mathiasbynens]

Here’s why mobile first is awesome: http://www.mediawiki.org/wiki/Athena

[wjcrowcroft]

Don't suppose... was there any consensus on this?

I guess it's not something with a one-size-fits-all solution, and I should probably write some CSS instead of procrasturbating over the NVP vs. WVP issue, but would love to hear if there'd been any updates.

Great thread though!

[data-enhanced]

Great discussion.

Regarding the idea of including an ie.css, thereby removing the need for respond.js --- I understand and appreciate the goal of having only one stylesheet for all browsers. I've tried the mobile-first respond.js approach. But as we're weighing the options here, I'm liking the idea of dropping respond.js and simply providing legacy IE with desktop styles within a conditional comment.

Let me make sure I have the picture right --

1. Instead of linking respond.js at the end if the document within a conditional comment for IE 6-8 not mobile ...
2. Provide the IE 6-8 stylesheet in a conditional comment following the main stylesheet. This stylesheet will provide the desktop styles from the main stylesheet, which IE6-8 would have missed because they were tucked away under the main stylesheet's media queries.

If I understand correctly, this approach has these pros and cons:

• It adds one http request for IE 6-8 browsers only, while saving these browsers the javascript overhead of respond.js
• It lets the basic styles (normalize, typography, etc.) cascade from the main stylesheet, then brings in the desktop styles after
• It allows me the flexibility to adjust the IE conditional comment and the IE stylesheet to support whichever versions of IE 6-8 I desire. (If I don't support IE 6, I can write the conditional comment for only IE 7-8, and IE 6 would receive only the basic styles from the main stylesheet.)

Am I on target with this?

[data-enhanced]

Wait. I just followed the link provided in the above discussion to Jeremy Keith's post http://adactio.com/journal/4494/

His solution, which addresses what I just laid out above, but more elegantly, is to have two files:

• global.css to provide base styles for all devices, including mobile-first styles
• layout.css to provide layout for WVP browsers

Then he uses a media query and a conditional comment to provide layout.css only as needed:

• a media query for modern WVP browsers
• a conditional comment for IE 6-8

His code snippet with my comments:

<!-- Base styles for all browsers -->
    <link rel="stylesheet" href="/css/global.css" media="all">
<!-- Layout for wide browsers -->
    <link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!-- SAME layout file for IE 6-8 -->
    <!--[if (lt IE 9)&(!IEMobile)]>
        <link rel="stylesheet" href="/css/layout.css" media="all">
    <![endif]-->

The advantages here seem significant, as this approach:

1. provides base styles to all browsers
2. keeps the more weighty CSS layout file from being requested by NVP browsers at all
3. requires just one layout.css file (no copying and pasting into a separate file)

In addition, this approach still allows me to adjust the conditional comment to support only the versions of IE I choose to support with layout. For instance, if I do not wish to provide layout for IE 6:

<!-- layout file for only IE 7-8, excluding IE 6 -->
    <!--[if (gt IE 6)&(lt IE 9)&(!IEMobile)]>
        <link rel="stylesheet" href="/css/layout.css" media="all">
    <![endif]-->

Moreover, if I want more precise media queries for mid-width devices (like tablets) and ultra-wide monitors, I can easily take and adjust this approach to cover such cases. The easiest way may be to include tablet-width layout within a media query inside global.css and then address mongo-width layout within a media query inside the layout.css file.

[scottkellum]

Maybe you mean small screen first? Setting up media queries before designing is a bad idea IMO. Also, designs should work without media queries first, usually on a fluid page that works well on small screen. second media queries can be bundled in at design breakpoints, not device breakpoints. Mobile first doesn’t really matter at this point, but optimization should always be considered.

[necolas]

@scottkellum

Maybe you mean small screen first?

Already gone over that in one of the first comments: #816 (comment)

Setting up media queries before designing is a bad idea IMO

That hasn't been suggested. H5BP only includes placeholder MQs that we say should be customised to the needs of the design.

designs should work without media queries first

This is already how H5BP works.

second media queries can be bundled in at design breakpoints, not device breakpoints

We already recommend this and it has been discussed in various issues, including by Paul above: #816 (comment)

[matteolc]

@davidcochran Following Jeremy Keith's post http://adactio.com/journal/4494/ and your explanation, you guys say that "global.css is to provide base styles for all devices, including mobile-first styles", while layout.css is "to provide layout for WVP" and is used by media query non-compliant browsers, so if I understand correctly no media queries written there.

Questions:
Why should a media query non-compliant browser download a stylesheet with media queries? Wouldn't it be more clean/elegant to specify media queries only in the css files that gets downloaded by browsers which understand media queries (layout.css)?
Wouldn't it be cleaner to patch IE's inability to understand media queries in a specific IE stylesheet? This way the day we'll ditch support for IE LT9 (I still consider IE8, but older? nah..), we'll just remove the css and the conditional statements around it.

I personally find @necolas (http://nicolasgallagher.com/mobile-first-css-sass-and-ie/) suggested method more clean & easy to deal with -but it assumes one uses SASS, and I wouldn't know the performance hit of all those @import.

core.css
Normalization, typography, and grid (or gridless or frameless whichever one prefers) styles. No media queries.

layout.css
@media (min-width:320px) { @import "320-up"; }
@media (min-width:480px) { @import "480-up"; }
@media (min-width:780px) { @import "780-up"; }
@media (min-width:960px) { @import "960-up"; }
@media (min-width:1100px) { @import "1100-up"; }

ie.css
@import "320-up";
@import "480-up";
@import "780-up";
@import "960-up";

What do you guys think? Hopefully I haven't got anything awfully wrong!

[data-enhanced]

@matteolc

@necolas's SASS solution is a nice one, and there are folks working on analogous procedures for users of LESS.

But H5BP can't yet depend on everyone using those technologies -- and probably can't until CSS is remade to work like SASS or LESS. (Which would be great!)

Meanwhile, for non-SASS/LESS users ... the two-CSS-file solution is just really straightforward -- 1. global styles for all browsers (with everything needed by NVP browsers) and 2. desktop styles which address anything needed for IE6-8.

Because legacy IE simply ignores what's behind media queries, I can use those same two files to address browsers that do understand media queries. I can tuck layout for tablets behind a media query in global.css, and layout for extra large screens behind a media query in layout.css. IE6-8 will never know these were there.

Of course ensuring that nothing essential for IE6-8 is hidden behind a media query takes planning, but that's par for the course.

This strikes me as relatively elegant in these ways:

• does not require developers to be using SASS or LESS
• only requires maintenance of two files
• provides all styles needed by IE6-8 in a very normal way, without the extra burden of respond.js
• nothing's stopping me from including the media queries I need for modern browsers

Everybody's needs are met, and I've burdened IE6-8 as little as possible, leaving them free to live or die at their own pace.

[data-enhanced]

@matteolc

But then again -- reading you more closely now I think -- if one were to take your method and combine it with the new H5BP build script, which will inline all of the imported CSS files prior to production ...

That'd be pretty darn elegant. Except you can reduce HTTP requests by importing core.css along with your media queried styles in each case.

Which would give us something like:

modern.css -- everything needed for modern browsers

• import core.css
• import all media queried styles

legacy.css -- everything needed for IE6-8

• import core.css
• import all styles through 960

Advantages

• would be easy to do with the help of the build script
• we're not having to create separate special CSS files. We just import them differently.
• it saves us from burdening IE6-8 with respond.js
• it provides exactly one stylesheet to modern browsers, and exactly one stylesheet to legacy IE browsers (one HTTP request in each case)

[matteolc]

@davidcochran Ah, you highlighted the advantages better than me! :)

• We just import them differently. Elegant, isn't it..?
• It saves us from burdening IE6-8 with respond.js. Yes yes yes. I am personally against the usage of additional js just to cope with non compliant browsers.

And yes, if production files can be built by inlining imports, I couldn't ask for more..

So that would be, hamly speaking:

-# Layouts for MQ-capable browsers
= stylesheet_link_tag "modern", :media => "(min-width: 320px)"
-# Serve a stylesheet without @media declarations for the oldies, and skip serving it to IE mobile
/[if (lt IE 9)&(!IEMobile)]
= stylesheet_link_tag "legacy"

with:

modern.sass

@import "core"
@media (min-width:320px) { @import "320-up"; }
@media (min-width:480px) { @import "480-up"; }
@media (min-width:780px) { @import "780-up"; }
@media (min-width:960px) { @import "960-up"; }
@media (min-width:1100px) { @import "1100-up"; }

legacy.sass

@import "core";
@import "320-up";
@import "480-up";
@import "780-up";
@import "960-up";

Am I on track?

With the @imports you suggested and by inlining in production we are saving 1 further request compared to my original suggestion.

[matteolc]

Actually, I think I am going back to:

/ Core layout (no media queries)
= stylesheet_link_tag "core"
/ Layouts for all viewports (with media queries)
= stylesheet_link_tag "responsive", :media => "(device-width: 320px)"
/ Serve a stylesheet without @media declarations for the oldies,
/ skip serving it to IE mobile
/[if (lt IE 9)&(!IEMobile)]
= stylesheet_link_tag "static"

That's because IE8 will download responsive.css, thus if i place the same @import there as there is in static.css, there's duplication.
In fact, the :media => "(device-width: 320px)" might not be that necessary after all..

[data-enhanced]

Having just ready Juriy Zaytsev's examination of the performance hit caused by unused CSS selectors, such as selectors included for legacy IE (see note 13, and then the summary) ...

I wonder if this doesn't reinforce the two-stylesheet approach, whereby styles for legacy browsers that don't understand media queries are provided in a separate stylesheet -- typically provided to IE 6-8 with a conditional comment. Whether you call the second stylesheet ie.css, legacy.css, desktop.css, or what have you ...

If we can work up good ways to use a tool such as SASS or even the ANT build script to make a two-stylesheet approach more easily maintainable, we now have clear evidence of further benefits: besides saving the need for respond.js, it leaves us with trimmer stylesheets and promises snappier web apps.

[necolas]

I'd like to propose this solution...which is to provide no default solution (because there is none):

1. Remove respond.js from the Modernizr package in H5BP.
2. Create a Wiki page to document some of the more popular ways to approach "mobile first" development (and which ones cater for legacy versions of IE). People can refer to this when deciding which solution best fits their project requirements.
3. Optionally, remove the placeholder MQs from the default CSS.

[nimbupani]

Agreed with your solution @necolas +1 last item on the list too.

[bradfrost]

@necolas I think that a wiki page would be a great way to articulate these many shades of gray. As for the last point, I think including device-specific dimensions is definitely dangerous, but it's still beneficial to include examples to assist syntax and spread awareness of a great technique. Perhaps changing the dimensions to something less device-specific and possibly em-based (perhaps min-width: 35em?) would move things in the right direction.

[necolas]

@bradfrost We mention in the comments that they are placeholders which should be modified as the content requires (although I thought those comments were more obvious than they actually are).

However, I'm not sure using em units would make much difference. I see a lot of sites that use style.css (untouched) as their base css, leaving the empty MQs in there doing nothing, even if they go on to use MQs elsewhere in their code. I thought it would be better to move away from including "dummy" or "placeholder" code where possible, and in this particular case, significant code that isn't going to work cross-browser out of the box.

[bradfrost]

@necolas Yeah if you're seeing enough people just leaving them in there without touching them then perhaps it is better to remove them altogether. If they do stay, I'd still recommend changing the 480px and 768px to dimensions that are a bit more ambiguous in order to break the device-specific mental model.

[sturobson]

@necolas I totally agree with @bradfrost about changing the px based MQs to em based.
My reasoning for this became a blithering paragraph of idiocy which really just repeated Brad's last sentence regarding ambiguity and device-specific breakpoints.
As for the wiki, a great idea :D

[tchalvak]

I think that default media queries in the css are a great tool. If people are just using the boilerplate css without modification (and then making their modifications in a separate block of css), then that's a good reason to comment out the media query blocks due to the potential added overhead of unused media query blocks, but removing them altogether and relying on an external document to convey them as defaults is a pretty major step down.

P.S. I think that taking away solutions that work (as much as anything in this crazy browser ecology we live in) -before- the alternative exists is putting the cart before the horse, so let's start the wiki page first (assuming it doesn't yet exist) and get that solid before removing compatibility tools, right?

[necolas]

I've tried to strike a balance between all the concerns that have arisen here. Thanks to everyone who helped and took the time to post opinions and ideas on this issue! I hope you'll all continue to help out in the future with suggestions and info.

[nimbupani]

🍺

[Jaujon]

As of 2013-04-12, distributed version of HTML5BP Responsive is broken: media queries doesn't work on ie7 - ie8 while it does work for the online demo version!!!

[kevva]

@Jaujon, there is no media query support in IE7 and IE8. Check out https://github.com/scottjehl/Respond.

[danielhusar]

What about something like this?

<!--[if (gte IE 9)|!(IE)|(!IEMobile)]><!-->
  <link rel="stylesheet" href="responsive.css">
<!--<![endif]-->
<!--[if (lt IE 9)]>
  <link rel="stylesheet" href="all.css">
<![endif]-->

responsive.css and all.css are same, all.css just don't have media queries

Or something like this:
sass:

@import "_small";
@media only screen and (min-width: 768px) {
  @import "_medium";
}

.lt-ie9{
  @import "_medium";
}