Skip to content
This repository

Revert mobile-first media queries and remove respond.js #816

Closed
paulirish opened this Issue October 17, 2011 · 74 comments
Paul Irish
Owner

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.

Sam Breed

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

Addy Osmani

Agreed ^.

Shi Chuan

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.

Nathan DeGruchy

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.

Mathias Bynens

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.

Nicolas Gallagher
Owner

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.

Paul Irish
Owner

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. :/

Paul Irish
Owner

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

Nicolas Gallagher
Owner

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?

Paul Irish
Owner
Roy Ronalds

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.

Brad Frost

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.

Vasilis van Gemert

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? (-:

Paul Irish
Owner

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

Alex Gibson

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.

Nicolas Gallagher
Owner

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.

Divya Manian
Owner

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.

Alex Gibson

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?

Stephanie Rieger

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.

Jacob Swartwood

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.

Josh Williams

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.

Divya Manian
Owner

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.

Lewis Nyman

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?

Jacob Swartwood

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?"

Nicolas Gallagher
Owner

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

The Mobile Boilerplate is primarily for mobile web apps.

Brad Frost

@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.

Miller Medeiros

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.

Joss Crowcroft

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.

Paul Irish
Owner

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.

Paul Irish
Owner

If we..

  • toss out broke-ass mobile browsers (which I'm nearly content with (pending any answers to the above questions)),
  • and we toss out respond.js (sorry, again, scott!) then...

mobile-first needs two files (for oldIE), but desktop-first can be done with one.

  • authoring-wise, it's a tough call.
    • desktop-first seems to align better with our tools
    • mobile-first makes sense to many folks in this thread
  • perf-wise
    • it comes down to the question: how much in css do you need to download that the mobile will never use?
    • and then.. is that size worth more than the cost of an extra HTTP request.
    • this question I've been trying to get an answer to for a while and there is no good way to ascertain the solution
Jacob Swartwood

With either of those calls, you are still pushing a responsive layout design. Is that a definite "good practice" that H5BP wants to instill?

...no argument, just asking.

Paul Irish
Owner

Yes, H5BP wants to do responsive and do it right.

And it also wants to point to where people can learn the best way to write media queries around breakpoints in their content, moreso than devices, but still be aware of the very many screen sizes that will view your content. This is an authoring detail that I haven't seen fleshed out sufficiently yet. (Scott was going to write this but he's afk now...) Anyway this is off-topic of this ticket.

But first, we need to identify the implementation best practices...

Oli Studholme
oli commented October 25, 2011

IE6 (and prolly IE7) ignored complex media query rules, so you could use MQ and IE would still get the styles. However IE8 “fixed” this without adding support for complex media query rules.

Here’s the research I did looking for the magic filter that’d let IE8 media queries behave like IE6 — I failed, but if you can find it we could do single stylesheet mobile-first media queries (no JS, no CC), while still giving IE6-8 the desktop styles as appropriate. And a heavenly chorus will sing your name!!

Lewis Nyman

It's a moot point anyway Oli. Paul crushed my dreams this morning by pointing out that those complex queries in the opera article are always parsed by media query supporting browsers. :(

Stephanie Rieger

@paulirish

I haven't seen what these browsers actually do with web pages. I seem to remember some intelligent scaling

What 'these browsers' do is highly variable but the majority simply do what all browsers do. They parse the HTML as best they can (div soup makes this harder...semantic markup makes this easier) then try to apply the styles and functionality they can based on their support level. There is rarely any special scaling built in so if fixed pixel values have been used, content often extends past the viewport and prompts horizontal scrolling or in some cases are clipped (e.g. Blackberry often clips images, data tables and other elements if they are too wide).

Some browsers have in the past implemented a 'thumbnail view' approach where you see a small version of the entire rendered page and can manipulate a marker (often a red square) around the page to indicate which area you want to zoom into. Others simply include zoom controls.

The very oldest browsers may offer none of this and simply load whatever they can based on normal document order.

So in general, the rule is expect nothing other than normal browser behaviour with (if you're lucky) a few UI constructs to help users sort out layouts that are (for whatever reason) too wide for the viewport.

Can anyone show what a 960px-ish wide non-responsive mainstream site looks like on one of these?

I will see if I can post some later on. The older the device, the harder it is to take a screenshot (often it's impossible) but I can probably dig some up....but really...the site will look as it does on the desktop...unless some aspect of rendering or behaviour is unsupported. And of course, the more complex the layout, the more likely it is that aspect of it will fail.

I'm dubious about marketshare of these devices

The market share is huge. It's the modern smartphones that have the lowest market share (although this is changing but is still years away from being the reality). This Gartner report provides a good example. It classifies what we think of as smartphones as 'free OS devices' and shows that these are still only 26% of global shipments. Within that 26%, Android is leading, followed by iOS, Symbian and RIM (all with similar numbers) and of course...this shifts all the time.

http://www.gartner.com/it/page.jsp?id=1622614

Of course, modern smartphones often have higher usage as they have much better browsers and often come with a certain level of free data access but in many markets (including the UK and other EU countries) there is considerable traffic from devices that don't support media queries and/or have poor JS so can't rely on a polyfill to solve support problems. (Important to make the distinction here that these are not only featurephones. Many of these devices are slightly older smartphones or much cheaper smartphones.)

Here are a few examples from sites whose stats i've been able to review (can't name two of them due to NDA)

  1. Large EU brand, e-commerce based mass-market products. iOS is over 50% of the traffic but also includes a long tail of 30-40 Android devices (screen sizes ranging from 240 to pseudo-tablet sized), half a dozen Blackberry and Nokia smartphones along with 10-15 frequently sold early smartphones (e.g. early Samsung/LG touch devices with a very basic touch OS/browser, resistive screen, very low dpi and highly underpowered with no media query support). Very little featurephone traffic as the site is quite complex and probably won't load at all on old devices.

  2. Large UK brand with a very content heavy, high-traffic site. iOS is over 50% of traffic but also includes huge long tail of Android devices (several hundred distinct screen sizes indicating lots of web use within app web views). Also decent number of the 1st generation touch devices mentioned in example 1. One of the most common screen sizes is 240 x 320 which is basically synonymous with sub-$100 Android devices. Similar to the old Samsungs, these are typically highly underpowered, with very low dpi display and slightly older versions of Android.

  3. http://browser.nokia.com - designed responsive, mobile first with a mixture of server-side and client side adaptation (to minimise or eliminate the client-side load) and the mandate to support as many Nokia devices as possible due to site business goals/call to action of updating your mobile browser. Vast majority of site traffic is from devices that you would like to toss out, including over 100 distinct Nokia devices, lots of Android and global traffic from over 140 countries (including heavy EU and US traffic...it's not all emerging economies and India as one might expect given recent Nokia market share). More info about the project here http://www.slideshare.net/yiibu/pragmatic-responsive-design

I'm more dubious about "page view share" of these devices. Are people actually using the web browsers on them?

The Nokia site I mentioned derives much of its page views from these devices. Although they don't release specific stats, I would bet that Facebook and Twitter are the same. All you need to look at is the list of primary Facebook markets...for example, Indonesia has been in the top 5 (and often the top 2-3 for quite some time). Given the state of the Indonesian mobile market, there is no way that all that traffic is from high end smartphones. I've heard similar numbers from Twitter. This is also why Facebook zero rated itself (i.e. subsidises the cost of access through the free 0.facebook.com domain) in many emerging economies. The mobile devices is the primary access point for many of their users and all these people definitely don't have an iPhone.

The other good example is always Opera Mini's stats. The vast majority of their proxied page views come from featurephones and low-end smartphones. There is tons of data on this at their State of the Mobile Web site http://www.opera.com/smw/ So in this case the answer is yes and no. They are not using the native browser but are using a more appropriate browser that they have installed on their own.

Overall however, we have noticed that the more optimised your site is, the more traffic you will get from devices that you would otherwise maybe not have expected. Many people simply glance at their logs, notice lots of iOPS and assume that's all there is. This causes the obvious vicious circle when people visit, get a crummy experience, then don't go back. It is also interesting to see how broad traffic can be when the information on the site is something people actually need rather than simply want (e.g. medical information, government/taxation/benefits related content, banking/insurance, breaking news etc). And of course, need vs want is quite subjective and also temporal, which is why mobile traffic is growing so quickly.

It's also unfortunate at the moment that Google Analytics provides vastly different data depending on whether you've chosen the mobile or 'normal' script. Some of this is for good reason (e.g. they derive intelligence from the UA string for the mobile version so miss out on some of the stuff that client-side queries can provide) but there are also lots of seemingly random decisions about what they do and don't track (e.g. distinct Android devices never appear in the logs...only a figure for the Android platform as a whole). I'm hoping the upcoming GA update will solve some of that.

it comes down to the question: how much in css do you need to download that the mobile will never use?
and then.. is that size worth more than the cost of an extra HTTP request.

In my experience, a few extra http requests...when well chosen and delivered for reasons that will benefit the user are always worth it.

The most useful example is to contrast this with all the http requests that you cannot control such as 3rd party requests within Facebook widgets, analytics, utility services such as comment hosting and even certain polyfills. (see slides 26-34 in http://www.slideshare.net/yiibu/pragmatic-responsive-design)

While i'm not advocating ignoring the number of http requests, the decision regarding how to structure your CSS and related files can have a massive impact on everything you are able to do after that point. It will impact future design decisions and many of those will in turn impact performance. To somewhat arbitrarily make this decision based on the worry of 1 extra http request is a real shame and in the end, is completely counterproductive. Which then leads to the last point below...

Yes, H5BP wants to do responsive and do it right.
And I feel strongly that these approaches need to have data to back them up as the right approach.

The unfortunate fact at the moment is that there is no one correct answer to a lot of these problems. Mobile first RWD has been proven to be beneficial when targeting large numbers of lower-end devices (or simply developing in a forward-thinking way that doesn't presume you will know the capabilities of each requesting device) but it doesn't simply end at style sheet placement and this is where developers will need to decide what is best for their project. I don't think this is a cop out, it's just the reality that we're increasingly going to be faced with and it's actually a good thing. For one, it encourages people to take a good look at their logs and understand where their traffic is really coming from. As Brad mentioned, some huge global brands are having to support bizarre devices such as a the Sony PSP because not doing so would be throwing away as much traffic as their IE audience (and we know most of us don't want to do that...) This is not the kind of thing you can include in a boiler plate and for good reason.

Andreas Bovens

@paulirish:

it comes down to the question: how much in css do you need to download that the mobile will never use?
and then.. is that size worth more than the cost of an extra HTTP request.

If I understand it correctly, you cold use an @import inside a WVP-targeted MQ. This does not trigger an extra HTTP request on Opera Mobile/Mini and recent Webkit (possibly others), which only download external resources if the MQ is applied. This means that your HTTP request only happens on WVP devices (aka desktop), where it's less expensive.
Older Webkit versions and possibly other browsers download everything although they don't need it - not sure if that's a major issue though.

Or is that not what you're talking about? :)

@stephrieger

They are not using the native browser but are using a more appropriate browser that they have installed on their own.

Quick fyi: Opera Mini does support media queries (and viewport), but requires a refresh for the media queries to be recalculated when switching between portrait and landscape.

@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.

Have you tried http://www.opera.com/developer/tools/mobile/ ? It should run fine on Linux.

stephenhay
Nicolas Gallagher
Owner

@sturobson We never mentioned excluding Respond.js for IE6-8, that is the primary reason it is included at all. The idea was to pull Respond out of Modernizr so that its inclusion is more visible and open to removal. But we might remove Respond by default anyway.

In my first comment I mentioned the distinction between 'mobile' and 'viewport', which is indeed important in the context of this MQ discussion. However, "responsive/adaptive design" is not just about viewport dimensions or devices. It is a far broader term that can encompass any process or final product that is flexible and adaptive to the browsing context.

Stuart Robson

@necolas - I retract most of what I typed. 2 hours sleep in 44 hours has shown itself. I've just deleted that comment plus about four paragraphs of potential waffle in this one cos I'm sure you'd disagree and I'm too tired.

folktrash

Maybe I'm missing some larger point here (no, srsly), but why do we care about media queries for ie6-8 at all? In my experience, one conditional comment for ie < 9 & not mobile* with the contents of the desktop media query pasted in, is horn o' plenty. Yes, the empty CC first.

The fact that we can see a site squishily re-arranging itself as we resize the browser window isn't the point of media queries, mobile first, or responsive web design. It's about contextual change, not browser window size change. The fact we get to trigger it via that is just a convenience. And also, sexy and makes the web feel more alive (but mostly for developers I think).

If the application is a static brochure-ware portfolio page/site, then maybe all that's going on is media queries. Yet for anything more complicated, there is a javascript layer that may not respond to window resizing. It may be doing feature detection or some gack agent sniffing.

I don't see why "getting media queries to work" in < ie9 is something worth doing.

Mobile first feels way funny at first, but the consideration of alternate contexts - from the beginning - is worth it's wait in extra css (see what i did there?!). Plus, cache and minify.

I think I can dig the reason for the debate at all though, if it's in the boiler plate, it'll get blindly implemented. Just search on some of the comments. I find that stuff unedited in production source all the time.

Also, happy tuesday. Much love. Big hugs. Etc.

*
that not mobile 7 is a nice new tiddy bit - thanks!
so, is the new mango hotness ie9 mobile then?

Nicolas Gallagher
Owner

@sturobson :( Doesn't matter if you think I might disagree (I might not and I might be wrong anyway!), I'd be glad to read your thoughts.

Stuart Robson

@necolas thanks, I think I'll catch up on some much needed sleep first & clarify what I've written before hitting 'Comment' :)

Oli Studholme
oli commented October 25, 2011

@lewisnyman — yeah, most sad :( We thought you were onto something big! Hopefully someone will find a hack for IE8 to make it emulate IE6-7 behaviour.

@folktrash — IE6-8 support simple media queries, but IE6-7 also ignore complex media query rules. If we could only find a way to extend this behaviour to IE8, we could then do a single mobile-first stylesheet that still exposes MQ’ed styles to Mr. OldIE. Currently we can do that for IE6-7, and IE9+ support MQ properly, but IE8 is the stopper. None of the current “minimal” alternatives are anywhere near as nice.

folktrash

@oli the approach that seems reasonable to me - is to have a conditional comment to an ie.css which contains the contents of the "desktop" media query in the mobile first style.css. win win. it's an extra http request, but so is respondjs. plus, it's not broken, they're getting the "desktop" version. AND ie6-8 only exists in a "desktop" context.

near as nice as what? all that hacky media query-ness? that makes me want to throw up in my mouth.

i don't understand the push to get media query support for an agent that only exists in a desktop context. just to get the size to seem squishy when we resize the window? srsly, i don't understand that.

To me the conditional comment approach is the best approach given all data. It's simpler. It's more performant. It's set it and forget it style (perfect for a boiler plate). And it keeps all the new hotness juice focus forward (not backward) where it should be.

I don't see how the added complexity (and 'be careful doing thingx and thing y' in css) of respondjs is better than a simple file/css-based solution.

plus, if one were script wizard happy, one could have the computer generate the ie.css file autoMAGICally. boom.

#please-don't-hate-me-i-just-don't-understand-how-this-is-a-question
my vote: yes, remove respondjs. & no, keep it mobile first.

folktrash

I totally lost my comment. Boo. Re-summary?
Nice as what? The hacky media query syntax? No thanks.
CC ie.css is elegant. Simple. Performant. And via machine script, could be generated (I find the copy&paste fine).

ie6-8 ONLY exists in the desktop context. how is this even an issue?

So, it's thursday, and I'm still in love with the internet even though, clearly, it HATES ME!

Nicolas Gallagher
Owner

@folktrash Please try and keep things to a discussion. I promise you, we're not all idiots :). We're just talking about options, and like in any debate, it's important to have people represent all sides (even if you aren't convinced by it when you represent its pros/cons).

it's an extra http request, but so is respondjs

Not when it is included in Modernizr or concatenated with any other head scripts by the build process.

AND ie6-8 only exists in a "desktop" context

The IE7 rendering engine is used in Windows Phone 7

I don't see how the added complexity (and 'be careful doing thingx and thing y' in css) of respondjs is better than a simple file/css-based solution.

There is no added complexity. Write your CSS for modern browsers and Respond takes care of IE.

We're going to try out a handful of options and consider what solution, on balance, is the least problematic and most future-proof available. Continued discussion, ideas, and testcases are still encouraged though! It's great to have so many people sharing their experience and expertise. Thanks

folktrash

Oh, I'm the idiot here, not y'all. Srsly.

  • not an extra request when concatenated. check.
  • the ie7 (/8 hybrid) windows mobile agent (engine) - doesn't that change with mango tho? plus, we can solve for that with the !mobile CC either way right?
  • ah, i was under the impression that respondjs got tripped up by certain css things.

Cast my vote for least-problematic and future-proof for the CC ie.css file approach! (obviously)

Thanks for being nice and such. I've been away from h5bp for a while, and was surprised to see respondjs in there at all.

Nicolas Gallagher
Owner

doesn't that change with mango tho? plus, we can solve for that with the !mobile CC either way right?

yep!

ah, i was under the impression that respondjs got tripped up by certain css things.

it's definitely not perfect, which is one of the reasons to consider removing it from the default boilerplate...and the CSS method, while ugly, is pretty solid.

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.

Mathias Bynens

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

Joss Crowcroft

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!

David Cochran

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?

David Cochran

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.

Scott Kellum

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.

Nicolas Gallagher
Owner

@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)

Matteo La Cognata

@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!

David Cochran

@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.

David Cochran

@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)
Matteo La Cognata

@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.

Matteo La Cognata

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..

David Cochran

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.

Nicolas Gallagher
Owner

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.
Divya Manian
Owner

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

Brad Frost

@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.

Nicolas Gallagher
Owner

@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.

Brad Frost

@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.

Stuart Robson

@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

Roy Ronalds

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?

Nicolas Gallagher necolas closed this issue from a commit January 24, 2012
Nicolas Gallagher Update Modernizr to remove Respond. Change placeholder Media Query.
Previous version of Respond was known to cause problems in IE8.
It was not necessary for developers who chose to write their CSS
in a 'mobile first' manner. Furthermore, there are some concerns
about the performance penalty Respond imposes upon legacy versions
of IE. If a future version of Respond is shown to be performant
and more reliable, it may be reconsidered for inclusion.

Along with this change is a simplification of the placeholder
Media Queries. Now there is only 1 Media Query example and it is
more clearly labelled as an example. The use of `em` units in the
condition is to reinforce the idea that Media Query breakpoints
should not be device-specific.

Fix #816
af98e6f
Nicolas Gallagher necolas closed this in af98e6f January 24, 2012
Nicolas Gallagher
Owner

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.

Divya Manian
Owner

:beer:

Ben Kutil benkutil referenced this issue from a commit February 04, 2012
Commit has since been removed from the repository and is no longer available.
Sébastien JONAS

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!!!

Kevin Mårtensson
kevva commented April 12, 2013

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

Daniel Husar

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";
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.