Just throwing this out there since I've been trying to figure out, for more then 4 hours, why IE7/8 crashed on my Omega 4 theme when I enabled Repond.js and enabled CSS aggregation.

It seems IE7/8 can't handle the (aggregated) stylesheets generated by Sass + Respond.js when the Sass output style is set to "expanded". When I set the output style to "compressed" the site also works in IE7/8.

Maybe somebody could check/confirm if this is happening on their theme(s) also because I couldn't find anything googling this problem. This is rather strange since this problem should occur on other mobile-first, Sass based themes with Repond.js if the output style (expanded) really is the cause.

Comments

fubhy’s picture

Status: Needs review » Active

That definitely sounds weird.

However, have you considered NOT using respond.js at all and instead going with the @breakpoint mixin and no-query fallbacks. Now, with all these nice things that the @breakpoint gem is capable of there is basically no more excuse to use respond.js except if you are really lazy or just can't be arsed to do it properly for that project you are working on :). The thing is: respond.js basically is useless. It brings media queries to IE8 and below... Okay, but WHY?! What's the point? The versions of IE that don't support media queries are IE's that run on desktop devices anyways. Why would they need to be responsive? What's the point? So, given that you are following the mobile-first ideology (I always do) then all you need now is a proper fallback for IE since otherwise IE would end up with the mobile version of your CSS (we don't want that). The solution to that problem lies within the @breakpoint gem and no-query fallbacks. They are easy to use and work beautifully.

Please read more about that here: https://github.com/Team-Sass/breakpoint/wiki/No-Query-Fallbacks

Also, take a look at the extended starterkit (latest version from beta-7). It includes most of what you need to get started (including a fallback.scss file and the PHP code that adds it with IE-conditional comments).

However, I am still going to check out what's up with that apparent bug you described. :)

Percept’s picture

Yeah, I know of the IE fallback in breakpoints, just haven't figured out yet how this exactly works.

fubhy’s picture

Status: Active » Fixed

Hmm... I just tried this and my test IE did not crash as described here. Does this problem still persist for you? Please feel free to re-open if it does and you still need it to be investigated further.

Did you figure out how the no-query fallbacks work? We now have pretty good examples in Omega 4.x-dev if you want to check it out from git again to see how it works. You can take a look at Ohm for that for example. Or, alternatively, create a new sub-theme for testing using the extended starterkit. It will come with a pre-built no-query fallback file now.

Percept’s picture

Yeah, I figured out the Susy at-breakpoint class fallback but ran into a bug in Sass -> http://stackoverflow.com/questions/18955213/at-breakpoint-fallback-cause...

You can close this since I'm not sure yet what way I will proceed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.