search

h5bp / html5-boilerplate

A professional front-end template for building fast, robust, and adaptable web apps or sites.
https://html5boilerplate.com/
MIT License
56.34k stars 12.21k forks source link

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

Closed paulirish closed 12 years ago

paulirish commented 12 years ago

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 commented 12 years ago

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

addyosmani commented 12 years ago

Agreed ^.

chuanxshi commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

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 commented 12 years ago

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

necolas commented 12 years ago

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 commented 12 years ago

Argument from the other side..

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

tchalvak commented 12 years ago

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 commented 12 years ago

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

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

@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 commented 12 years ago

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 commented 12 years ago

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

The Mobile Boilerplate is primarily for mobile web apps.

bradfrost commented 12 years ago

@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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

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?

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

paulirish commented 12 years ago

If we..

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

jswartwood commented 12 years ago

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.

paulirish commented 12 years ago

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 commented 12 years ago

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

lewisnyman commented 12 years ago

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

stephrieger commented 12 years ago

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

andreasbovens commented 12 years ago

@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 commented 12 years ago

@anderasbovens wrote:

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.

Andreas, I know you know this, but just a reminder for the benefit of the
group: requests on NVP are not necessarily expensive, nor are they
necessarily cheap on WVP. We're calling it "mobile" here, but when we
speak of NVP and WVP, we're only dealing with viewport width and this says
nothing of our connection.

necolas commented 12 years ago

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

sturobson commented 12 years ago

@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 commented 12 years ago

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?

necolas commented 12 years ago

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

sturobson commented 12 years ago

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

oli commented 12 years ago

@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 commented 12 years ago

@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 commented 12 years ago

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!

necolas commented 12 years ago

@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 commented 12 years ago

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

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.

♥

necolas commented 12 years ago

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 commented 12 years ago

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.