A Hack Free Standards Future
There has been a lot of news recently about the up coming new version in Internet Explorer, IE7. Media coverage has been high, but none more than in the web standards camp. Internet Explorer, the aging current Microsoft browser, always seems to be under fire, and most of it is completely justified because of it’s poor support for standards.
An important tool for anyone learning web standards and CSS-based design is to know the limitations of different browsers, their quirks and especially the work-arounds. These are must-know areas if you want to become successful in creating semantic websites driven by CSS design. However, because of the promise of better CSS support and bug fixes in IE7, these hacks are looking a lot less professional and future proof.
Internet Explorer is well-known, in the industry, for its lack of support for “web standards” and this is often a hinderance to new developers and well as an annoyance for veterans. Work-arounds are, unfortunately, an important part of the web development scene nowadays. Below are three of the most commonly used CSS hacks.
* HTML HTML > body head + body
The first, the “star HTML selector bug” is the one I often use. It’s both simple apply and to understand. Only IE, versions 5 and above on both Mac and PC, reads these selectors. The reasoning; IE thinks there is a super-seeding element to the HTML container, which there shouldn’t be.
The second is called the ChildHack and lastly the adjacent sibling selector. Both of these selectors target browsers supporting CSS2.1, which IE doesn’t fully support. This means any of the selector rules starting with these will not be applied by IE.
Internet Explorer 7 is commited to supporting better levels of CSS, as well as fixing quirks/bugs of existing CSS. Great! or is it all it cracks up to be? Also, the IEblog calls for developers to ditch hacks which are currently being used to fix problems with IE.
If Internet Explorer 7 supports the selectors that most developers want to use, as well as removing the star HTML selector bug, then I think that the transition should be pretty uneventful. If the bugs are removed, and CSS support improved, then Internet Explorer 7 will just use the CSS Firefox, Opera and Safari currently apply, and, hopefully, render well. The only problem that I can see is if this doesn’t happen.
If the bugs (which are currently used to target IE) are removed and support isn’t improved (to a decent level) then this could cause major headaches. The solution? The Internet Explorer team says “Conditional Elements”. These are proprietary HTML elements the Internet Explorer team have implemented in many versions of their browser.
Marko Dugonjić explains how to use Conditional Comments in his article Essentials of CSS Hacking For Internet Explorer.
Just Passing The Torch?
It may seem that the Internet Explorer team are just passing the torch, by moving the separate stylesheets from one place to another. In some respects this is true, but there is a good reason behind it. Conditional Elements, although proprietary, are officially supported by Internet Explorer, whereas hacks take advantage of bugs in the software, which can be patched/fixed.
Since CSS has become more mainstream there have been fixes for the majority of issues, and extremely complex CSS has been avoided. With the arrival of Internet Explorer 7 only the extreme complex styling will remain out of reach. However, it is important to remember that Internet Explorer 6 will not simply need to be unsupported on the web. Far from it. Because Internet Explorer 7 is only for Windows XP and the upcoming new operating system codenamed Longhorn, users of Windows 2000, those who do not feel they need to upgrade and those who physically can’t upgrade their browsers will be left using the old technology.
It seems like common sense to use conditional elements now, but as previously stated if all the major bugs are erased hopefully there will be no need to change anything. It is best practice to separate hacks out from the main stylesheet anyway, whether it be at the bottom of the stylesheet or in a separate file completely. If this best practice is followed then it should be pretty simple to migrate to different methods of selecting offending browsers.
A CSS-based versioning system to target the worse offending browsers could be implemented, instead of adding extra markup just to get a purely presentation fix. Ideally, Internet Explorer 7 will support the majority of selectors and advanced CSS (as well as much needed PNG support) developers will need for the immediate future.