The new year started great for front-end development. On January 12th, Microsoft ended support for old versions of Internet Explorer. Millions of developers worldwide rejoiced at the news. The last vestiges of the Browser Wars that defined the beginning of the new millenium were finally put to rest.
For at least the last decade, the various versions of Internet Explorer have been the bane of web designers and front-end developers everywhere. The rise of Firefox, Opera and later Chrome showed the world that the web can be so much greater, faster and more secure. Yet, in fear of breaking the web for those who didn’t (or couldn’t) move away from Internet Explorer, we were forced to jump through hoops and bend over backwards to cater to the quirks of these legacy browsers. There is a well known pie chart image (the oldest appearance I could find was in 2007 on www.dezinerfolio.com) that showcases the feelings of the community:
Fortunately things are a lot better now. We only have to deal with the last incarnation of the Trident engine, namely Internet Explorer 11, which is already a solid modern browser on par with its competition. It is thus the time to clean house and throw away the deprecated tools, processes and techniques. Out with the old…
No More Browser Hacks
The first weapon we had in our arsenal was the browser hacks. A hack is a seemingly incorrect declaration that exploits some parsing errors in the rendering engine. It is used to overwrite the standard declaration with a value that will make the layout look and function properly on that specific browser. There were hacks that targeted single versions of Internet Explorer, while others covered multiple versions. A further classification can be made depending on the format of the hack:
- Selector hacks: These hacks usually are used to exclude old versions of IE that don’t understand the new syntax.
- Property/value or attribute hacks: These are the original hacks — exploiting holes in the parsing engine to target specific old versions.
- Media query hacks: They are used to target/filter various versions of browsers (not only Internet Explorer) based on the support of the syntax for
@mediadeclarations. - JavaScript hacks: They are used for “browser sniffing”, detecting specific versions of Internet Explorer based on various features supported by the JavaScript engine.
The use of hacks was both complicated and frustrating. Sometimes you had to cascade several hacks one after another, as some parsing errors (that allowed the existence of the hack) were fixed in following versions without removing the rendering problem that required the hack in the first place. Let’s see a few examples of such hacks, restricted to the three versions recently retired:
[code language="css"]
/*========== Selector Hacks ==========*/
/* Internet Explorer 10+ */
_:-ms-input-placeholder, :root .selector {}
/* Everything except Internet Explorer 9 and lower */
html[lang='\
en'] .selector
{}
/*========== Property/Value Hacks ==========*/
/* Internet Explorer 6-8 */
.selector { property: value\9; }
.selector { property/*\**/: value\9; }
/*========== Media Query Hacks ==========*/
/* Internet Explorer 8 */
@media \0screen {}
/* Internet Explorer 10+ */
@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {}
/*========== JavaScript Hacks ==========*/
/* Internet Explorer 6-10 */
var isIE = !!window.ActiveXObject;
/* Internet Explorer 8-10 */
var isIE = document.all && document.querySelector;
[/code]
For a more comprehensive list of hacks to remove from your code, visit Browserhacks.
Bye Bye Conditional Comments
As we have seen above, the use of CSS hacks is messy, prone to malfunction and (for those of you who are obsessive about their code) making the stylesheet fail validation. Things had escalated to the point where, in November 2005, the guys at Microsoft stepped in and made a call to action for the demise of CSS hacks, urging developers to use conditional comments instead.
Initially conditional comments were used to load extra stylesheets for certain versions of Internet Explorer. At that time the code differences between standard-compliant browsers and Internet Explorer were large enough to make the practice a valid one. When HTML5 became a reality, this was also used to load polyfills that provided the missing support for the new features (we’ll touch this topic later in the article). While this practice was mainly used to target code for IE6–7, you might still encounter it in some legacy code. Let’s have a look at some code samples:
Conditional Comments Used to Load Extra Stylesheets
[code language="html"]
<!--[if lte IE 8]><link rel="stylesheet" href="lte-ie-8.css"><![endif]-->
<!--[if lte IE 7]><link rel="stylesheet" href="lte-ie-7.css"><![endif]-->
<!--[if lte IE 6]><link rel="stylesheet" href="lte-ie-6.css"><![endif]-->
[/code]
Conditional Comments Used to Load JavaScript Polyfills
(code excerpt from the default Bootstrap starting template)
[code language="html"]
<!--[if lt IE 9]>
<script src="http://ift.tt/1ouFrwz;
<script src="http://ift.tt/1Wufk3o;
<![endif]-->
[/code]
The main issue with this approach was that each version of Internet Explorer targeted this way made extra HTTP requests. The developers were forced to search for approaches that offered higher performance. The result was to deploy conditional comments to add extra classes to the <html> tag. This practice was a lot more popular, being used, among others, by the HTML5 Boilerplate framework. By that time Internet Explorer 6 could either be ignored or treated using graceful degradation, while the differences between the more modern versions (IE7–9) and their competition (Firefox, Chrome, Safari and Opera) were small enough not to warrant entire extra stylesheets. The few minor tweaks could be achieved due to the extra specificity provided by classes added to the <html> tag. This is the example most likely to be encountered today, as illustrated in the examples below:
Continue reading %Cleaning House after Internet Explorer%
by Adrian Sandu via SitePoint
No comments:
Post a Comment