administration mode
Pssst...Ferdy is the creator of JungleDragon, an awesome wildlife community. Visit JungleDragon

 

Responsive JungleDragon - update VII »

FERDY CHRISTANT - FEB 1, 2013 (12:17:58 PM)

Welcome to edition 7 of my documented journey into making JungleDragon responsive. In previous editions, we've applied modern web techniques to make several screens and components responsive. 

The approach so far has been to not cater for any particular browser or device, not even for any particular viewport size. And overall, with the right principles in mind, this works great. Both desktop and mobile browsers nowadays behave quite well as it comes to the technologies we've been using.

But then comes the inevitable horror page in every web story: old IE. IE8 and below do not support media queries at all. Not only that, it doesn't understand CSS3 or HTML5 at all. Both are pillars of the new JungleDragon design. In this post I'll therefore not be focusing on the creation of new screens, this one will be all about making our screens work in the first place, in old IE that is. If you think common responsive web design is tricky or complex, this part is even worse.

Viewport meta tags

Before we enter the horror that is old IE, let us first look at a more positive improvement I've made to JungleDragon V3: the ability to zoom on touch devices (by pinching). Yes, this is a standard capability of mobile browsers, but often it is disabled by web designers. There's a good chance that if you open the HTML source of a responsive web site that you will find this snippet:

 <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">

Effectively, this disables page zooming completely. The reason is that mobile browsers may decide to zoom in or out your web page as it sees fit (pun intended). In many web designs, this may lead to undesirable layout issues. In addition, if the browser isn't zooming your page, the user may do so, and most web designs cannot cater for this.

It is understandable why designers limit this to stay insane, but then again it is not. It is the same broken reasoning of the past, where we assumed fixed desktop viewports (960px) or fixed font sizes. A user wanting to zoom a web page by pinching is a wonderful and powerful capability, not a design risk. If our design cannot cope with it, our design is the issue.

Anyway, to make a long story short, I too was using the above snippet. I changed it to this:

<meta name="viewport" content="initial-scale=1">

Yes, I'm still preventing the browser from zooming the page, but not the user. The user is free to pinch and zoom. It is easy to see how this is a powerful capability in JungleDragon. Zooming photos clearly adds value:

See above, a user is opening a photo page. The page is snapped into its initial zoom state. 

See above, we now have an in-your-face cricket closeup thanks to the ability to pinch and zoom. None of this breaks the JungleDragon design, because our media queries are em-based, not pixel-based. And because JungleDragon photos have a lot of head room in pixels, zooming this way is quite wonderfull.

There you go, we have restored a standard powerful capability of mobile browsers. 

Back to old IE

Back to the heart of this post, old IE. Let us first look at the characteristics of these browsers. As for IE6 and IE7, their market shares are tiny now. Users actively using it are:

  • Largely in China, presumably on (cracked) XP machines
  • Within corporate firewalls, in companies that still believe this problem will solve itself
  • Not in China or corporations, but generally clueless about the web and used to a broken web experience

Given that major web companies no longer support these browsers as well as Microsoft discouraging their use, it is safe to not support IE6 and IE7 in my case. The only support I'm willing to give is that content is visible, meaning you can see the content (photos and text), albeit in a broken layout. Furthermore, I give those users a message to encourage upgrading their browser:

<!--[if lte IE 7]>Your browser sucks, but you probably don't know what a browser is</div><![endif]-->

Ahem, the real message is of course slightly more professional :)

IE8

With IE6 and IE7 abandoned, the problem child that is IE8 remains. It currently has a market share of about 12%, and this number will differ greatly per specific site. Although Google is planning to drop support later this year, some report it to still be the world's 2nd most popular browser. At the time of this writing, not supporting it is a bridge too far. Nothing has changed. 10 years ago we were coding for IE specifically, we still are now, and we will continue to do so in the years to come. It is a seperate category of browsers that we cannot afford to ignore.

Onwards, let us see how I managed to get IE8 to behave in JungleDragon's responsive design.

IE8 - media queries support

IE8 does not support media queries at all, so it will not respond to any styles within a media query rule. Whether this is an issue depends on your responsive design approach: desktop-first or mobile-first.

In a desktop-first approach, your default CSS styles will cater for a desktop viewport. Specific styles are only created for smaller viewports. In the case of IE8, this means IE8 will use the desktop styles only and ignore all others. In many cases this is quite acceptable, maybe you don't even have to do anything.

It's an entirely different story for a mobile-first design as used in JungleDragon V3 though. The default CSS styles will cater for the smallest viewport, and are enriched for larger viewports. Since IE8 does not understand media queries, only the mobile styles will apply, and on a desktop viewport, the result is quite horrible:

Ouch. Mobile styles on a desktop browser: not so good. There are many advantages to a mobile-first design approach, but IE8 support isn't one of them. Luckily, we can solve this quite easily:

Respond.js comes to the rescue. I've placed that library in a file called IE8.js, which I load conditionally like so:

<!--[if lte IE 8]><script src="js/ie8.js"></script><![endif]-->

The result is that IE8 (and below) now does understand media queries:

See above, we still have more problems to solve, but at the very least IE8 is now responding to media queries and is being served the correct styles.

Note: If you are hosting that respond.js library on a seperate (sub)domain, you need to follow these instructions.

IE8 - background size

In previous posts, we have paid a lot of attention to photo thumbnails. We are forcing the image container to be square, after which the image itself is centered and scaled within it. It works quite nicely, no matter the image dimensions or aspect ratio.

At the very basis of this layout is a wonderful CSS3 feature: background-size:cover; That single magic property makes sure that these highly variable images are always properly centered and scaled.

IE8 does not support CSS3, and therefore does not support background-size. You can see the messed up result in the screenshot above. As this is a fundamental part of the design, this one should be fixed no matter what.

I first tried using an IE proprietary filter, when configured to the "scale" mode, old IE will attempt to scale and center the image in its container. The problem though is that it does not respect the image's aspect ratio, leading to squeezed or stretched images.

After several hours of research I came across the wonderful backstretch plugin. And it works:

See above, the backstretch fix produces a result similar to the CSS3 background-size: cover rule. It is noteworthy to mention how I am applying this fix:

if(!Modernizr.backgroundsize) {
  imglink.backstretch(img.attr('src'));
}

Instead of hard-coding a fix for IE8 and below, I'm testing for a feature. Feature detection instead of browser detection. This means any browser not supporting background-size will get the fix, not just IE. Likewise, any browser that does support the feature will use CSS3's background-size rule and no fix is applied. Elegant.

IE8 - web fonts

JungleDragon V3 makes heavy use of web fonts, in particular the icon font FontAwesome. Where before I was using sprite images to load various icons, web fonts are superior in that they are light and responsive.

Web fonts nowadays have excellent browser support, so there is no reason not to use them. However, it can be difficult at times to make them work reliably, so here are a few pointers...

In order to make a web font work for as many browsers as possible, you require several types of font files (woff, ttf, eot, svg) along with an odd syntax to load them. The syntax is key here. Paul Irish is maintaining an excellent blog post that shows the most bullet-proof syntax.

Another issue may arise due to cross-domain issues. If you host your font files on a seperate (sub) domain,  you need to set the right HTTP headers. You may run into this issue even if you think you're not hosting on a seperate domain, particularly if your site is accessible both with and without the "www" sub domain.

As for old IE, it will be using the eot font file, which is a horrible proprietary format. These eot files are typically generated from a ttf file, and even the tiniest of mistakes in that conversion may lead to old IE not loading your web font. As you can see from earlier screenshots in this post, I too had the issue of IE8 not loading the web font. The solution: I had to edit the TTF file using an obscure font editing program, reset the metadata of the font, and regenerate the eot file using FontSquirrel. That fixed it, don't ask me why.

IE8 and HTML 5

If you're using HTML5 elements in your markup (for example "header", "article", "section"), IE8 and below will not allow you to style those elements. This is easily solved by this single line of markup:

<!--[if IE]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->

IE8 and CSS3 styling

We have solved some major layout and design issues for IE8. Still, if you look at the intended design...

...and compare it to earlier screenshots, you'll notice some major styling differences. The reason is my heavy usage of CSS3 styling rules, notably border-radius, RGBA color, text-shadows and background gradients. IE8 will fail to understand any of them. 

Since in this stage of development my styles are subject to a lot of change, I will only fix these issues when I get closer to the end state. Generally though, most issues can be solved by providing IE fallback colors. 

Example:

background:'IE color here' url(../img/bg_noise.png);
background:rgba(0,0,0,1/10) url(../img/bg_noise.png);

Comment headers in JungleDragon are styled by RGBA colors. Effectively, it is a relative color, a somewhat darkened color of the page background color. This is quite cool, because if I change the color of the page background, several other colors will automatically calculate in relation to that main color.

Since old IE does not understand RGBA colors, the fallback is to proceed it with a fixed color, as shown in the code above. Old IE will pick up the only rule it understands, the non-RGBA color. Modern browsers will pick up both rules, but due to the order of rules, only the last one will actually apply.

In this example, we're effectively implementing IE-specific CSS fixes as part of our overall CSS. If you prefer to isolate such fixes, you can do so in two ways. One way is to use conditional comments to load an IE specific CSS file, that only contains the fixes. 

Alternatively, you can use Modernizr to do feature detection rather than browser detection:

.no-rgba {
// your RGBA fallback styles here
}

I believe this to be a more elegant solution, but it can be somewhat of a challenge keeping your main CSS and fallback CSS in sync this way.

Wrapping up

A decade ago, we were coding IE fallbacks. We're doing it now, and we will continue to do so for the years to come. It is not so much an issue of these IE browsers being bad upon launch, it's an issue of them not retiring.

On the upside, no longer should old IE limit our design aspirations for browsers that do behave. The community in recent years has come up with solid fallbacks and elegant ways to seperate fallbacks from proper standards. As such, the pain remains, but it has become a whole lot more manageable.

I hope this post showed some insight in how I am dealing with old IE in a modern responsive web design, and perhaps it offers some tricks you can apply in your own IE horror stories.

 

Share |

Comments: 2

COMMENT: MARK BARTON emailhomepage

FEB 1, 2013 - 01:54:26 PM

comment » Great article Ferdy - as usual.

I feel your pain re IE.

Did you consider a CSS pre-processor (LESS, SASS etc) just a thought if you were trying to maintain a fallback CSS file. You can also define stepped colours where a colour is 10% of a base colour etc which would solve the RGB issue. «

COMMENT: FERDY

FEB 1, 2013 - 15:48:37

comment » @Mark: Thanks. I'm definitely using a CSS pre-processor, SASS in my case. I wouldn't dare doing this redesign without it.

And yes, I happen to have a fallback partial and also plan to use the SASS darken method to produce relative colors. In fact, I'm already using it in some places.

Looks like we're thinking very much alike :) «

RATE THIS CONTENT (OPTIONAL)
Was this document useful to you?
 
rating Awesome
rating Good
rating Average
rating Poor
rating Useless
CREATE A NEW COMMENT
required field
required field HTML is not allowed. Hyperlinks will automatically be converted.