Show a warning to admins if respond.js is enabled but CSS aggregation is disabled.

+1

Has anyone succeeded in getting respond.js to work at all with Omega? I've tried adding it via the info file, but it doesn't appear to be working (I've turned on CSS caching to get the CSS included via links rather than @import which is required in order for respond.js to work at all).

Thanks.

Colin

Placing it in the .info file of a theme causes Drupal to aggregate it with other JS files, which should never happen.

Try using http://drupal.org/project/respondjs

This module takes the guesswork out of placement, and helps standardize how Drupal sites are using respond.js.

Nice. Thanks. I was beginning to wonder how I was going to untangle it from the aggregated scripts and whether or not it was being loaded in the correct order :)

Have you managed to actually get respond.js to make Omega work in IE though? I'm seeing it being loaded, but the layout is not responsive at all. My understanding is that it just enables the min/max width media queries in IE, and that that is how Omega is implementing the responsive layout, so I'd expect it to "just work" once it's being included in the right place.

I have not tested yet as the respond.js module only just got a full release the other day (was a sandbox project for the last few months). I will be doing some testing in a few days and will report back

Let me know how I can help (other than posting "it's not working for me").

I'm also trying to get this working and having no joy. I've tried loading both respondjs and css3-mediaqueries.js, both with the same result which is no change in IE8. Any ideas?

Core CSS aggregation needs to be turned on for respond.js to work.

Also looks like http://drupal.org/project/modernizr includes respond.js as well, along with some other goodies to help HTML5 and CSS3

I've installed the Respondjs module and enabled CSS aggregation. Unfortunately the site is still rendering at a fixed width in IE8. Anybody have any tricks yet on getting this to work? I haven't tried Modernizr yet.

I've tried both the Respond module and the Modernizr module, and no joy in IE8 (and, I'm assuming, IE7 or 6). Unfortunately, MS keeps promising to force the latest IE on users, but so far it hasn't happened (and since it requires Windows Updates to be enabled, in my experience the sort of people who are still using relics like IE are exactly the sort who don't have automatic updates enabled). I'm not holding my breath that the IE problem is going to go away any time soon.

Does anyone know what the problem is?

Check out http://drupal.org/node/1388898. It looks like the IE specific CSS file(s) are preventing the respond.js file to not work. I removed the IE specific stylesheets and changed ['browsers']['IE'] from gte IE 9 to TRUE. This seems to work for me. I added the following code to my omega subthemes template.php file.

function omega_subtheme_css_alter(&$css) {
	foreach ($css as $key => $value) {
		if (preg_match('/^ie::(\S*)/', $key)) {
			unset($css[$key]); 
		} else {
			$css[$key]['browsers']['IE'] = TRUE;
		}
	} 
} 

I could only get my Omega subtheme (www.comicout.com) to work with IE - including IE9 - by enabling BOTH responjds and modernizr modules AND implementing zipymonkey's hack (#12). Thank to you all folks!

hmm Respond and modernizr installed enabled CSS aggregated all IE conditional calls pulled from the html.tpl.php and zipymonkeys caode added to the template.php cache flushed five times and still no responsive IE 8 :( any ideas what I missed?

+1 to kill IE8 and bellow.

Directly from the respond.js readme:

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.

Unfortunately, that's exactly how Omega refrences CSS, so there you go :)

Thats wrong, sorry! @import is what Drupal outputs when not set to aggregate CSS (admin/system/performance). Once you configure your site to output aggregated CSS it won't use @import anymore.

Oh wow, I never knew that! I usually only aggregate before deployment, probably that's why. Never noticed the herd of @imports up until Omega. Was this in D6 as well?

#12 worked for me!

#12 also worked for me.

thx
blueblot

#12 worked indeed, but this should be configurable via a setting.

#12 worked for me too. Thanks !

#12 works fine! Thanks!

Thats wrong, sorry! @import is what Drupal outputs when not set to aggregate CSS (admin/system/performance). Once you configure your site to output aggregated CSS it won't use @import anymore.

Because I've overlooked this so many times myself, there's an admin warning built into the respondjs module to warn you when you're running into this situation.

Because I've overlooked this so many times myself, there's an admin warning built into the respondjs module to warn you when you're running into this situation.

That's a good idea. I could add that here too. Thanks! :)

In Omega 4.x there is already a setting which allows you to rebuild the CSS aggregates on every page load... This does have quite a massive performance impact but allows you to easily debug CSS for IE including respond.js because it allows you to enable CSS aggregation without the hassle of having to clear caches everytime you change something.

That's done. Sorry for everyone stuck in 7.x-3.x land, I can't really fix it there without breaking existing sites. Settings this to fixed. http://drupalcode.org/project/omega.git/commit/c8f0a13

I still can't get respond.js to work in Omega 3.x and IE8.

Could anyone share what settings you included in Modernizer? I'm attaching a screenshot of my settings.

For the template.php function, I need to replace "subtheme" with my subtheme name, correct?
This is all that I have in the template.php file:

<?php

/**
 * @file
 * This file is empty by default because the base theme chain (Alpha & Omega) provides
 * all the basic functionality. However, in case you wish to customize the output that Drupal
 * generates through Alpha & Omega this file is a good place to do so.
 * 
 * Alpha comes with a neat solution for keeping this file as clean as possible while the code
 * for your subtheme grows. Please read the README.txt in the /preprocess and /process subfolders
 * for more information on this topic.
 */

function omega_mysubthemename_css_alter(&$css) {
    foreach ($css as $key => $value) {
        if (preg_match('/^ie::(\S*)/', $key)) {
            unset($css[$key]); 
        } else {
            $css[$key]['browsers']['IE'] = TRUE;
        }
    } 
} 
?>

I have emptied the cache repeatedly after every change.

#12 worked for me. Thanks