Make Stark use a responsive layout

This looks great!

We might as well start this discussion somewhere: which media query approach should we use?

I see both min- and max-width conditions in #4. I find myself constantly avoiding max-width. I find it easier to grok one condition, and feel it's more predictable in terms of overriding rules later in the document. Some might mention the mobile-first aspect, but in this case there are no mobile styles to override whatsoever, so we're doing that either way.

And what about location of queries? For Stark I am in favor of one stylesheet containing all media queries (as the patch is now). All of our core themes are simple and lightweight enough that single-stylesheet will probably be the best option.

Thanks for getting this started, John! I don't think anyone objects to you making the first move :)

Good to see the first step to responsive base themes!

@rupl: I also try to avoid max-width conditions, especially for base styles like these. Why is it being limited with a max-width in this case?

Can we get some momentum here? This is a tiny patch (hurray!). Whats left before RTBC?

Here's the #4 patch rerolled against today's HEAD. Will circle back and provide another patch that takes my thoughts above into consideration.

What about IE support for these media queries? I've pushed an 8.x branch of respond.js module to help people test, but that's probably the biggest blocker for this issue.

I don't like the idea of hardcoding too many polyfills into Drupal's default output, so unlike #1077878: Add HTML5shiv to core, we should add the JS to each theme itself instead of common.inc.

+1 to adding respond.js to each theme individually. As mentioned above, not all themes will need it.

#3 sounds fine to me too. Would be great to keep this one moving along.

Ok, yet another roadblock: respond.js now includes MIT/BSD-licensed matchMedia.js. They are not keen to add a third license.

I'd like to get an opinion in here from someone familiar with the status of the Drupal third-party packaging whitelist to understand it more thoroughly. Namely, does this whitelist apply to distros only, or can we put these whitelisted libraries in core itself?

Here's the new respond.js (v1.1.0rc1) with matchMedia.js included: https://github.com/scottjehl/Respond/commit/cb581e52f8d2bb76cc5929781779...

I spoke with webchick about respond.js and did a little research. We can commit respond.js to core at git.drupal.org. We just need an exception as per http://groups.drupal.org/node/14734#comment-51709 and http://groups.drupal.org/node/14734#comment-49264. I don't see an immediate need to open an infra issue as suggested this is a prominent core issue where Dries is expressing support.

So, feel free to proceed with respond.js.

Perhaps we should call a Skype conference to make a plan on this issue?

I was thinking about this issue just last night and wanted to reconsider the first option John listed above. Why not just use the conditional comments built into core to provide IE with double stylesheets? It's a smaller performance hit than the JS, and we're avoiding the dependency. Even with no comparison data, it appeals to me. There might be minor maintenance issues, but they wouldn't be any more complex than existing issues with RTL CSS staying in sync with LTR.

Given that we've dropped IE6/7 support, we would be adding respond.js for a single browser (IE8). While reconsidering the progress of this issue (before Moshe posted comment #17) I came to the conclusion that it's a bit heavy-handed to saddle core with the library to cover what we will likely consider to be an edge case in August 2013 (D8's proposed launch date). Finally, there's this issue with respond.js:

Respond.js doesn't parse CSS refrenced via @import, nor does it work with media queries within style elements, as those styles can't be re-requested for parsing.

Drupal 7 and 8 output @imports by default, only printing <script> when CSS aggregation is enabled. That means this script will have no effect on a default installation of Drupal. I have to keep a separate section on my contrib page because I get so many questions about this. That's a big -1 for out-of-the-box functionality.

To conclude:

1. Sorry for taking this conversation in circles :) I'm just trying to sort out the best solution.
2. Thank you for the licensing info, Moshe! I'd still like to whitelist respond.js regardless, so that I can ship the contrib module without requiring the user to download the library.

Just a note: Firefox < 3.5 also doesn't support media queries, although Firefox 3.5 is over 2 and a half years old now. Is that going to be dropped in Drupal 8?

I've been using technique 1 (conditional stylesheets) for dealing with IE < 9 for a while, because I found respond.js to be too buggy and not worth the effort for IE. Below is what's in my theme if it's of interest.

John: you mentioned 320 and up in your initial post: have you thought about using this CSS framework instead of a desktop-first approach?

/* template.php */

function mytheme_preprocess_html(&$vars) {
  css_320_and_up(&$vars);
}

/*
 * We're using media queries to handle progressive enhancement of our templates.
 *
 * Because IE 6-8 doesn't handle media queries (and the current JavaScript solutions create other issues),
 * let's insert a conditional comment for IE < 9 to display all or media-queried stylesheets. IE < 9 won't
 * load the media query stylesheets, and other browsers won't load these ones.
 *
 * Note: this is a little more complicated than it possibly should be, because Drupal doesn't let us use the
 *       same stylesheet twice.
 */
function css_320_and_up(&$vars) {
  $original_css = drupal_add_css();
  $media_queried_css = drupal_get_css();
  $vars['media_queried_css'] = $media_queried_css;  // Store the current CSS in a variable for later use.
  drupal_static_reset('drupal_add_css');            // Reset the CSS Drupal has stored, so we can add it in again below.

  // For each appropriate stylesheet, duplicate for < IE9 using conditional comments.
  foreach ($original_css as $path => $attributes) {  
    if ($attributes['group'] == CSS_THEME && preg_match('/^(all|screen|print|handheld)$/i', $attributes['media']) == 0) {
    
      // Window 7 Phone gets the 320px stylesheets only.
      $ie_browsers = (preg_match('/min-width: 320px/i', $attributes['media']) !== 0) ? 'lt IE 9' : '(lt IE 9)&(!IEMobile)';

      drupal_add_css($path, array(
        'browsers'    => array('IE' => $ie_browsers, '!IE' => FALSE),
        'data'        => $attributes['data'],
        'group'       => CSS_THEME,
        'media'       => 'screen',
        'preprocess'  => $attributes['preprocess'],
        'weight'      => $attributes['weight'],
      )); 
    }
  }

<!-- html.tpl.php -->

<!-- For all browsers -->
<?php if(isset($media_queried_css)){print $media_queried_css;}; ?>

<!-- For IE < 9 -->
<?php print $styles; ?>

I would say FF 3.5 usage will be too low to care in 2013. It is negligible even today. I don't know of a definitive source for global browser usage, so here are two different graphs. When this comment was posted, one showed FF3.5 at 0.47% - the other didn't list it.

http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcust...
http://gs.statcounter.com/#browser_version-ww-monthly-201101-201201

We've already decided to use technology that we know will marginalize less capable web browsers. It doesn't mean Drupal won't be able to support them, just that out of the box it won't offer full support.

Chiming in on the above debate about putting response.js in core vs. in each theme (even though it's not at hand for Stark anymore. I'm going to use respond.js as an example to make a broader point):

If people decide to use respond.js in one of the core themes, or use another polyfill library to fix up something, I believe those libraries should be added to each theme, and not to core itself. Now I know, it could be argued that it's redundant — adding respond.js to Stark, and then adding it to Bartik, and then adding it to a new-to-D8-theme might seem like a hassle or too many bits or a waste. But adding a library to core itself has a completely different effect than simply supporting all the core themes... adding something like respond.js to core says: hey everyone building website in Drupal from 2013-2018, we are convinced this is a pretty great solution for your needs. Adding it to core themes instead (even all of them) says: hey everyone, this library is needed for theme X, let me explain in the comments why, you might want to do something similar in your theme, check it out / hey person who never looks at code, this just works, you are welcome.

I don't like the idea of adding respond.js to core, imposing it on all Drupal projects evar. I love respond.js. I use it on every project I build these days. But it's still changing. The way I use has changed more than once in the last year. Best practices are changing. I will likely stop using respond.js at some time in the future and replace it with something else. As mentioned above, if I use Modernizer, I don't use respond.js. And this is true with all of the detailed solutions to the hiccups in mobile-first responsive web design. It's a fast moving world right now. Lots of options. People are popping up with new versions of this and that, new ideas to solve the same little problems. One is faster than the other. Another is easier than the "best practice" of two months ago. A third solves a problem we didn't even realize we had, while wiping out the need for the thing you were using before.

If Drupal core — the level of Drupal that provides code for all sites, not just the ones using a core theme — institutes a solution, it needs to be only because that solution is a best practice that's fairly locked down and not changing any time soon. And an important solution that is pretty much required for every site. The HTML5 Shiv is a great example of such a thing. The code hasn't changed in years. It's required for every HTML5 site. No one in the broader web design community has debated yes/no to the HTML5 Shiv in many years. There's no reason to not include it in core itself.

But most of these other things.. they will come and go. Something that's super important and awesome in Spring 2013 might become an old and tired solution, long replaced by something else by Summer 2014. We've run into pain of trying to keep jQuery and jQuery UI updated. jQuery-in-core soon lags years behind while jQuery update module can lag months behind. (It's still the best solution, imo, to have jQuery in core. We just have a good example of the downside of including solutions from the world outside of Drupal in Drupal core, and should see if there are ways to avoid the hassle and lag.)

I'd hate to be filing issues over and over to update respond.js, update ios-orientationchange-fix,js, update query.widowfix.js, update imgsizer.js, update selectivizr.js… these are all libraries I use on every project, and I'm sure I have a different favorite combination in the future. I don't want to either impose a particular formula on every Drupal project, or keep thrusting aged-versions that have been long abandoned. Let's instead add libraries to core themes, even if that means including something more than once. (They are tiny files btw). So if it's deemed best to not use respond.js for Stark, but people want to use it in a new theme for Drupal 8 — then let's not use it in Stark, and just add it to that new theme. If a group takes a look at imgsizer.js and wants to use it in every core theme, then lets add it to every core theme — and not core itself. That way we don't have to worry about updating it or replacing it. These libraries aren't going to break. They will keep working just fine for anyone using a core theme for their site. I feel no need to go back to sites I built last year and replace respond.js with the new version. (Staying current with emerging best practices are simply about making the sites we make have longer shelf-lives and supporting more devices as those devices are discovered or invented. The "old" technique of month-before-last isn't going to explode anything.)

By adding these libraries to each core theme, and not core itself, we allow everyone who builds a new website in Drupal 8 from 2014 to 2018 to use a particular library or not use it, to add it to their custom theme or not, to use whatever Drupal-contribute base theme they want (and the maintainer of that theme can make the call / keep up with industry best practices… or not), without people wondering in 2016 why Drupal is making them use a technique that hasn't been in favor for years, or wasting time trying to figure out how to disable what Drupal is forcing on them in order to do what's the current best-practice. We already have enough of that going on. Let's not add more.

As for the question at hand, I prefer to use body (or html) classes like '.ie8' to allow me to write ie8-specific CSS inline with all the other CSS. It's a technique more and more front-end developers are using these days, now that we don't have to write as many i.e.-bug fixes.

The use of such classes should be consistent throughout core though, imo. This should not just be for the media queries, while the older bug-fix CSS is called by conditional comments. We should change the way core handles all i.e. CSS. Which is a larger issue beyond Stark and beyond responsive design. It will affect all of Drupal theming.

For reference, JohnAlbin pointed to this discussion of classes vs separate stylesheets, pros and cons: http://mathiasbynens.be/notes/safe-css-hacks

I just filed an issue to drop IE8 support in Drupal 8. It might sound crazy today but for when Drupal 8 will be released (August 2013?) and for when it will start to be used extensively (2014?) we might see it having a marginal marketshare. Look at the issue for all the motivations. #1465948: [meta] Drop some IE8 coddling from Drupal core
That would mean native support for media queries (and HTML5). Yes!

Conditional classes on the html tag cause IE to ignore the meta X-UA-Compatible tag and show the compatibility mode button. IE9 still uses this horrid compatibility mode.

A solution for D8 could be to use the conditional classes on the body tag, if in fact the reason this is not the current practice is because of IE6 support, and with many body classes already used, that browser not working with dot classes (.class.otherclass).

Apologies if this is considered cross posting, with what I originally posted in the Zen issue cue #1468104: conditional classes on html tag cause IE to ignore meta X-UA-Compatible tag and show compatibility mode button, which has more summary and references, but the body tag solution is not for D7.

as a follow-up to John's post above, the ticket in question is here: #1471382: Add IE-conditional classes to html.tpl.php

And since IE8 is the only desktop browser that D8 supports that doesn't have media query support, we should just feed it a desktop-specific layout.

Yes this is what I do now, totally dropped respond.js usage, too many issues to deal with and forcing the use of drupal_add_css(), I still support the option for using it, but its off by default (contrib projects).

I really discourage the inclusion of respond.js directly in any contrib theme. It's extra work for a theme maintainer to support, it's another piece of code to keep up to date, and it's just generally a pain. After writing that sentence I'm not sure why I created the module :) But it is ultimately a good set of reasons not to include respond.js within Stark or any core theme.

I very much agree with the no respond.js / d8 desktop approach.. How are others handling this Ina mobile and up setting?

Many of you are already participating in #1471382: Add IE-conditional classes to html.tpl.php, but for those who aren't, reviews on #1471382-47: Add IE-conditional classes to html.tpl.php would be much appreciated. Thanks!

Bumping priority, at least for as long as Drupalcon is on.

I'm working on this during the DrupalCon mobile sprint. Per @JohnAlbin's comment #27, I'll be using conditional stylesheets so that we can get this done and committed. Once #1471382: Add IE-conditional classes to html.tpl.php is hashed out, we can move things around accordingly.

Here's a new version of @rupl's patch in #9 with the following changes:

Add ie.css and include it using a conditional statement. IE 8 and lower should render using desktop layout (>960px)
Move the growing number of CSS files into /css.

This patch has not been tested in IE 8 (still getting an environment setup on my laptop), so it needs review and testing. Expected behavior is that Stark is non-responsive in IE 8 and lower.

Whoops - attached the wrong patch in that last comment. This patch is the correct one.

#39: 1322794-39-responsive-stark.patch queued for re-testing.

Small addition.
When we have 2 sidebars, we let the blocks in the second sidebar use the width of the page.

Test most recent patch please

This might be better

A bit better

Tested patch with a couple of devices and together with this patch: #1488754: Add mobile friendly meta tags to the Stark theme
- iOS 5.1 iPhone 4S
- Android 4
- Android 2.3.5
- Android 2.1
- Kindle Fire
- Nokia N900
- Safari 5.1.4
- Firefox 10
- Chrome 17
- Internet Explorer 9

I created some Menus and Nodes via Devel and for all devices it works as expected with the responsive Design.
Tested these Block Settings:
- No Left Sidebar, Right Sidebar
- Left Sidebar, No Right Sidebar
- No Left Sidebar, No Right Sidebar
- Left Sidebar, Right Sidebar

With IE 8 it gracefully degrade to non responsive and works as Stark as usually.

Also tested in Internet Explorer Mobile 6 which loads the narrow layout (1 sidebar and content, right sidebar below) but then fails in correctly floating. But because we don't support IE6 this is fine.

There is only one problem, if applying this patch after #1488754: Add mobile friendly meta tags to the Stark theme it fails because it also tries to add a new template.php to Stark Theme.

If it helps: I support this particular pattern for how we reflow regions here, I was there when we chose it during the sprint.

I asked to add some screenshots of how things look for different screen sizes. There's an additional tweak we're adding here: when the right sidebar drops below the content area, we reflow the block in it to float: left, widht: 33%.

here some screenshots of the testsite which shows the usage of "Column Drop" and RWD.
Check the narrow.jpg, it shows how the blocks of the right sidebar are shown in a 33% grid

#46 works as expected in
Chromium 17 on Linux
Firefox 10 on Linux
Opera 11.61 on Linux
Internet Explorer 9

But on Internet Explorer 8 it always uses the narrow layout, as in 1 column layout.

mhh for me it works in IE8 as expected: normal desktop layout.

Let me test this again on a fresh D8 install.

Regarding #53, testing in IETester isn't as reliable as using actual copies of IE.

Also, I've read that IETester doesn't always load HTML5 shivs/shims correctly.

@dcmouyard: Thanks for the heads-up. Will try to install IE8 and see if it's IETester bugging.

Still the same problem with IE8 native.

strange, tested on an 8.0.6 and it works.

will update now to 8.0.7

I'm not seeing the ie.css loaded in the HTML output when viewing the page in IE8, or am I missing something?

Apparently it was a cache problem on my part. After clearing the cache Stark uses the normal non-responsive layout in IE8. Back to RTBC, sorry for holding this up! Learned a lesson there.

Great testing on IE - thanks!

retested this patch because of the removing of target-densitydpi=160dpi with a lot of different devices:
- Android 4
- Android 2.3
- iOS (Ignores the target-densitydpi completely)
- Firefox
- Chrome
- IE 8, 9

Committed to 8.x at the DrupalCon Denver code sprint.

follow up patch fixing the \ No newline at end of file in ie-rtl.css and ie.css

It's a fair cop guv.
I missed that.
Thanks Stephane!

Committed to 8.x. Thanks!

YAYYY!

I just wanted to add a short notice here:
The Theme will work on Mobile devices only perfect if the Mobile Friendly Metatags #1468582: Add mobile friendly meta tags to the html.tpl.php are also commited.

Patch to remove IE8 special layout CSS: #1645494: Allow core themes to display single-column on IE8: do not compensate for lack of media query support.