Future-proof your CSS with Conditional Comments
(Last Updated on )
7 August 2008: It’s three years since I wrote this, and the browser landscape has changed considerably. A rewritten 2008 remix version is published on the Opera developer network: Supporting IE with conditional comments—please go there rather than read the article here.
The IE development team are calling on people to clean up their CSS hacks that might fail when IE7 is released, so I thought I’d tell you about how I did this for an emergency design I did for a punter a couple of months ago.
My plan wasn’t primarily to future-proof the code, but to remove as many css hacks as possible, as I’d been contracted to rewrite a small brochure site very quickly (a few hours), and hand it over to another developer whose experience and skill were unknown to me. The end result was to remove all but one hack. Another side-effect is (I believe) much better structured, more maintainable and more logical code.
What CSS hacks do
CSS hacks allow web developers to send different rules to different browsers, usually (paradoxically) to make each browser’s rendering of the site look the same. This is generally necessary as Internet Explorer 5 and 6 have many bugs, so gets “good” rules wrong.
There are two types of CSS hacks:
- Parsing Error Hacks use the fact that browser “x” stops reading a rule when it sees some wierd combination of characters (like
"}"
), while browser “y” continues unvanquished and receives the subsequent good rules. The problem with these is that they’re utterly unintuitive because they’re pretty random. If they aren’t well commented, you’ll never guess what they do. - Weak CSS Support Hacks use the fact that IE can’t support advanced css selectors, and uses those to feed a rule to an advanced browser. The problem with these is that IE7 is coming over the horizon, and it will understand these rules. There may or may not be a problem, but if you want to be sure that your site won’t break in IE7, you’d better do something about it.
There are now a gazillion documented CSS hacks, but one of the most common css hack is a box model hack to get over the broken box model in IE5. It’s a parsing error hack, most of which is to fool different browsers into seeing the hack or not. For example, all the voice family shennanigans is merely fooling IE5 not to read any more of the rule, so not overwrite its overly wide dimensions:
#buttocks{margin:0; padding: 0 15px;
width: 194px; /*IE 5.5 width - Tantek hack */
voice-family: ""}"";
voice-family:inherit;
width: 164px; /*real width*/ }
html>body #buttocks{
width:164px;}
The second rule (“html>body”) is a “Be Nice to Opera” rule, because Opera would also stop reading at the voice-family crap and inherit the 194px, which we don’t want because its box model is fine. IE<7 doesn’t understand the child selector, so doesn’t bother with the “hug Opera” rule. When IE7 is released, this won’t break, because although it will read the Opera rule, that’s the width it needed anyway, so no damage done.
Except to the sanity of the poor guy who comes after me, who’s got to maintain all this stuff. It also offends my purist’s soul, polluting the css like this. Given that all this is to overcome deficiencies in Internet Explorer, wouldn’t it be superlovelygorgeous if we could have a good, valid, hackless stylesheet and an extra one flagged as “Hey! IE5! this is for you!”? Well, we can, using use Conditional Comments.
How conditional comments work
These are html comments, with a marker so that IE parses them, and you can use them to enclose any html code – including the linking of a stylesheet. They were introduced in IE5 for Windows, so can’t be used to target previous versions of IE. The best thing is that, because these are html comments, they’re invisible to all other browsers, and they pass validation.
Here’s the syntax I use to feed rules to IE5:
<link rel="stylesheet" href="styles.css" type="text/css" />
<!--[if lt IE 6]>
<link rel="stylesheet" href="boxmodel.css" type="text/css" />
<![endif]-->
The main styles.css has this simple rule:
#buttocks{margin:0; padding: 0 15px;
width: 164px;} /*see boxmodel.css for IE5 override */
and boxmodel.css – which is only served to IE5 – overrides it thus:
#buttocks{width: 194px;} /*other rules in styles.css */
No confusing voice-family hacks or Be Nice to Opera rules! Huzzah!
IEbugs.css – correcting the main bugs and IE6 and earlier
A lot of css hacks are to feed rules to IE6 and below to compensate for the lack of many important features of modern web development, like PNG alpha transparency, CSS min-height and fixed positioning.
We can remove the hacks by calling a special override stylesheet called IEbugs.css for IE6 browsers or below, like this:
<!--[if lte IE 6]>
<link rel="stylesheet" href="IEbugs.css" type="text/css" />
<![endif]-->
Simulating min-height
Suppose you have a box that should never be less than 100px tall – perhaps you have a 95px background image that you always want displayed, but you can’t predict the quantity of content. In a standards-compliant browser, you’d use min-height, which doesn’t work in versions of IE less than IE7.
To work around it, we add a rule specifying the height (which works the same as min-height should). So if the rule in the main stylesheet says #box {min-height:100px;}
that should be supplemented in IEbugs by
#box {height:100px; overflow:visible;} /*simulate min-height */
Give GIFs to IE, PNGs to the good guys
People who are more design-oriented than I am have long used graphics in the PNG format for their layouts as it allows them much more flexibility and loveliness. Unfortunately, IE6 doesn’t do PNGs properly, so people have used another hack to send an image that’s a GIF to IE. Here’s an example, using the * html
hack that only IE understands:
#lovely {background: url(lovely.png) no-repeat;}
* html #lovely {background: url(lovely.gif) no-repeat;}
IE7 can do PNGs properly, and it will not understand the * html rule, in which case, it will receive the PNG sent by the first rule: all well and good. But as this is a rule for pre-IE7 browsers, it would be better sent to the doghouse of IEbugs.css.
Once banished, it won’t need the * html prefix, as the stylesheet is only being sent to IE<7, and will overwrite the main rule. So the main stylesheet keeps #lovely {background: url(lovely.png)no-repeat;}
and IEbugs.css adds
#lovely {background: url(lovely.gif) no-repeat;}
Stopping long words destroying layout
Contrary to spec, IE allows very long words to expand a box widthwards – which can then easily destroy a layout if other boxes are floated right. This is particularly dangerous in areas where content can’t be rigidly controlled and tested, such as where blog comments are displayed, as someone can accidentally (or maliciously!) enter a very long word and totally nuke your design.
There’s an IE-specific css extension that will fix this, but prevent validation. Personally, I’m happy to use non-validating IE-only tricks to correct IE’s bad behaviour, particularly outside of the main stylesheet. Your purist levels may differ, of course.
Add this rule to the box that holds blog comments (or do what I did, and just add it to the body tag):
body {word-wrap: break-word;}
(I don’t know if IE7 will clean up this bug, so this may be better in a stylesheet for all IE browsers – see below).
Advanced IE6 bugfixing
If your design requires the ability to hover over any element, rather than just the a
tag as IE currently restricts you to, you can add the csshover behavior in the IEbugs stylesheet:
body { behavior:url("csshover.htc"); }
(You can even go the whole hog and simulate IE7 with Dean Edwards’ JavaScript library, using conditional comments to pull in a JavaScript library.)
Another potential reason for an IE.css that I haven’t yet researched thoroughly might be to add IE Layout to certain elements, which can help stop many IE6 rendering bugs.
IE.css – serving styles to all versions of IE
Another good use for conditional comments is to seperate IE-only extentions to the CSS spec, as they’ll stop your main styles.css from validating (and aren’t necessary in a non-IE browser, so why send them?).
Such extensions would be filters on images, or coloured scrollbars.
Here’s the code for the head of the page:
<!--[if IE]>
<link rel="stylesheet" href="IE.css" type="text/css" />
<![endif]-->
If you don’t need these extensions, or you don’t care that you have stuff in your main stylesheet that won’t validate (and, in a practical world, there are absolutely no negative side-effects if you have) you can just leave this in the main stylesheet, although I prefer to completely seperate it out.
IE/Mac: the new Netscape 4
Not being gorgeous enough to be allowed to use a Mac, I haven’t tested this, but add it for completeness. I’m told that conditional comments only work for IE/ Windows.
If you need to feed rules to IE/Mac (which they say is as moribund as Netscape 4), there are hacks available, but you should consider importing a seperate IEMac stylesheet in your html header and keeping all IE/Mac rules in there:
<style type="text/css">
@import("IEMac.css");
</style>
The formatting of the import must be exactly as above. (Hat-tip)
Alternatively, you can keep your html header clean and import a separate IE/Mac set of rules from your main stylesheet via Tantek’s IE5/Mac Band Pass Filter, which is made out of fairy dust:
/*\*//*/
@import "ie5mac.css";
/**/
Update 24 October 2005: Martin Belam, of the bbc website, analysed the 30 million requests for the BBC homepage in September 2005, and found that IE/Mac was used four times as much as Firefox/Mac, so maybe it’s a little too early to write IE/Mac’s obituary if yours is a real-world site (rather than Web Geek site).
Get yer code on, baby
To recap, here’s all the code for your header (you probably won’t need all of it)
<link rel="stylesheet" href="styles.css" type="text/css" />
<!--[if IE]>
<link rel="stylesheet" href="IE.css" type="text/css" />
<![endif]-->
<!--[if lte IE 6]>
<link rel="stylesheet" href="IEbugs.css" type="text/css" />
<![endif]-->
<!--[if lt IE 6]>
<link rel="stylesheet" href="boxmodel.css" type="text/css" />
<![endif]-->
<style type="text/css">
@import("IEMac.css");
</style>
Minimising http requests
Each stylesheet pulled in requires an extra http request, which can slow things down because the http gnomes get tired easily. In order to minimise these, you can combine all IE-facing hacks into a single IE.css, but would still need a version of the box model hack in here so IE5 gets the wider box. To send 164px width to IE6, and 194 to IE5, we need the voice-family jiggery-pokery from before, but don’t need the Be Nice to Opera rule. Here’s the code:
#buttocks{width: 194px; /*IE 5.5 width - Tantek hack */
voice-family: ""}"";
voice-family:inherit;
width: 164px; /*real width*/ }
A testing Gotcha
If you’re using multiple test versions of IE, don’t freak out when it appears that your boxmodel.css hasn’t taken. Whichever version of IE you fire up for testing, the conditional comment parser always believes that you are using the latest version installed. For those who are comfortable editing the Registry (about as nerve-racking as doing the splits naked over a live lobster, in my opinion), there is a fix (Hat-tip Simon Pieters).
Using conditional comments to hide something from IE/ Win
(Update 14 Nov 05). Roger Johansson notes Lachlan Hunt’s method of hiding something advanced from IE/ Win:
<!--[if !IE]>-->
do something; IE will ignore this, other browsers parse it
<!--<![endif]-->
This validates fine.
Conclusion
Although I’ve no religious objection to css hacks, we all have to be aware that pretty soon, a big new browser is coming to market. It’s good development practice to modularise your code, especially as within a year of release, IE7 will be the biggest browser and the hacks for old IE will become less and less useful.
I personally find development a lot easier if I can develop for Firefox first, with a “clean” stylesheet. When things start to take a turn for the unexpected, the css validator is a useful diagnostic tool. This utility is compromised when the stylesheet is full of IE-facing hacks. So I like to get everything working for a modern browser, and only then apply the hacks, using conditional comments.
Whether you believe that serving different stuff to different browsers is philosophically valid or The Work of Satan and All His Minions that will result in The Destruction Of The Web is entirely up to you. You may also feel that conditional comments, being IE-specific, are worse than css hacks. So be it; that’s your right. I’m a pragmatic purist, and this methodology works for me.
So let’s see it then, Mr Wilson
It’s fantastic that Microsoft are listening to us, and communicating with us. But the time has come now to let us play with the new Standards-aware IE7 beta and see what’s hot and what’s not – and feed it back, politely and constructively, to the IE team so the program gets better.
When you should use hacks, and not Conditional Comments
I haven’t had occasion to use the techniques so brilliantly devised by Alex Robinson in his article “In search of the One True Layout”, but I’d never ever contemplate doing it without CSS hacks. It’s complex enough for a third party to maintain or amend without various chunks of it being lopped out into seperate files. (Is it IE7-proof?, I wonder as an aside).
The conditional comments technique works very well if you have a relatively set design for your site. If you have a skinnable site, with loads of alternate styles and a stylesheet switcher, you probably need to continue with your css hacks. And that’s OK; most of your hacks should work OK with IE7. (Though it would be nice to test them, eh Microsoft?)
However, I’m talking about super-skinnable, to the level of something like the Zen Garden where the whole page layout radically changes. For stylesheet switchers that play with fonts and colours (probably for accessibility reasons, like red ant design do), I’d still recommend Conditional Comments, because IE isn’t so broken that it requires seperate stylesheets to override font and background colour declarations.
I’m making a similar stylesheet switcher for punter at the moment, using conditional comments. And one day, when IE6 has gone the way of IE4, I’ll just remove the conditional comment and, with a satisfied smile and a spring in my step, I’ll quietly delete IEbugs.css from my server. One day ….
50 Responses to “ Future-proof your CSS with Conditional Comments ”
Instead of the tried-and-true box model hack, could you use:
width:164px;width /**/: 194px;
I seem to recall that works as well (as far as IE6 ignoring the second one), and it takes up less bytes.
To confirm my previous comment,
here’s a URL:
http://www.dithered.com/css_filters/css_only/property_space_comment.html
Future-proof your CSS with Conditional Comments
Bruce Lawson’s article on
Future-proof your CSS with Conditional Comments
provides inshight on conditional commenting for browser specofic CSS files.
Continue Reading…
Conditional comments are not standards compliant. A former W3C note on SGML and HTML states to include comments in an HTML document that will be ignored by the parser […], the HTML 4 specification still notes that information that appears between comments has no special meaning.
@ Brad: One could also use the Underscore Hack which takes up even less bytes 😉
I miss why conditional comments aren’t compliant. They are comments. No one care about comment content. We don’t break validation with conditional comments.
It’s not the comments that aren’t compliant (they in fact are), but IE that behave in a not “standard” way. But this is out of our control. IE isn’t standard also in the box model and in a few other things… so it also parses some form of tag inserted in comments: well, it’s up to it. We can take advantage of this or not, but conditional comment aren’t violanting any standard, and any syntax, as far as I can see.
Great write-up, Bruce! Couldn’t agree with you more.
Hello Bruce. Thank for answering.
Well, I don’t want to have a hard discussion, and I respect your opinion. Most of all, I agree with your conclusion about having to face with incorrect browser behavior in a way or another.
My point is not for the sake of mere discussion: in Italy we have a strange law about accessibility in public sites, that force the code to be valid to be ok from a legal point of view. So in our country is important to agree what is valid (x)html and what break validation.
So the spec says: “Information that appears between comments has no special meaning”. Good. But what does that mean? That you *have* to write in the comment only things that are meaningless? Well, I don’t think! You use comments to remark the code, that is, to have some meaning that help you understand the code, for your commodity. This is good. And in that sense, the comment content should be meaningful!
I think that what specs mean is rather something like “information that appears between comment will not be parsed by user agent, so please don’t expect UA to do that”. The example is exactly about that: character entities are not interpreted as such!
So I understand that what you put in your comment is up to you, just don’t expect it will be parsed. And I don’t expect that.
If IE parses some content, that is a matter of IE. I can put in the comment what I want, knowing that IE does some strange things depending on some comments content.
But from a validation point of view, I’m ok whatever I put in the comment.
If not, the spec should have said “Please note that you’re not allowed to put in the comment code to be parsed”.
This is a problem of interpretation of the specs, and I think I’m right, but I know I could be wrong. In the wide wild world this is quite irrelevant. But for our law is important. I think that spec interpretation should be as unambiguos as possible when they change from tech raccomandation to legal constraint.
Maybe this is only a point that should alert people that make laws to be aware that technical specification should not be used as legal constraint per se. But this is another problem… 🙂
I hope I explained my point. Thank you for your interesting site!
(disclaimer: I’m not a owner of a public site, and have no interest in one interpretation or another. I’m involved in methodology evaluation for the law and in teaching some good practices to public sites administrator, so I have just the need for clarity)
Hello Bruce. Some pointers to let you examin the italian law and the related technical documents:
The law (4/2004);
In contains a number of technical specification, including the 22 technical requirement for web site accessibility, mandatory for the public sites, including, at n.1, the xhtml strict valid:
There are also some other details, glossary, and a further level of specifications that include subjective analysis, with user testing, that isn’t mandatory, and, because of its cost, will have a spare chance to be followed. You can explore it by yourself.
If you’d like to know more, fell free to ask me, even privately. You’re welcome.
Anyway, I’d like to point out that the validation question is sometimes important for accessibility, and sometimes it isn’t. Tag soup is to be avoided, of course, but if I put a border attribute on most images in xhtml strict that will not result in a real accessibility barrier…
The problem arises when you have to respect that validation with tools (CMS, framework, etc) that are unfit at the moment. The public sites should change their instruments to fit the requirements? And are there such tools, at the moment?
And another problem is: what if I have a pre-existing set of tools, that I bought at high prices two years ago, or more, with the plan to use it in the next 5-7 years, and find now that those tools need to be changed but I haven’t the money to do that?
Validation is good, but, apart from defining what actually is a valid code (as in the example of conditional comment, we could have other potential disagreement on what it really is), it involves some practical and organizative questions (money, tools) that are critical in public administration. So I’d rather a strong pressure on cms and framework makers to build compliant tools in the coming years (like the WASP has done with browsers productor) than including the requirement as a law constraint right now.
This is only my point of view, and have no personal interest in the question, apart consulting and teaching (worth specifying once more, because this is not always the case here in Italy…).
Bye!
Hi Bruce:
You said: “I’m told that conditional comments only work for IE/ Windows.”
Well.. I’m not sure as to all they work on, but they don’t work for IE 4 on Windows 98, IE 5.1 Mac OS-9, or IE 5.2 Mac OS-X.
tedd
Thank you Bruce for an imformative article. I have been considering for the last few days the question of whether I should gravitate more towards CSS hacks or IE conditional comments for current and future projects. And I think this article is the proverbial straw that breaks the CSS hacks back. IE conditional comments just seem a lot more stragiht forward to me.
Wouldn’t it be nice if we didn’t have to consider this issue at all.
[…] 30; Weblinks Interactive CSS Box Model Demo Selfhtml: Box Model IE-Bug: Bye Bye Ten Hack IE-Bug: Conditional Comments […]
[…] auml;uterung von Microsoft (engl.). bs-markup.de: CSS auf Internet Explorer 7 vorbereiten. Future-proof your CSS with Conditional Comments – Br […]
There is no need to use box model hack. Do not apply padding to a sized div.
http://www.webmasterworld.com/forum83/652.htm
Bruce,
I prefer conditionals and avoid hacks. Reason: Hacks are like telling lies. You tell one, then you have to tell another to support the first, then you forget who you told what lie to and you’re life soon comes apart after that.
Better to be upfront and say, “Bozo, this rule is for you.”
Mind you, IE takes raps on the chin largely because they’re the big boy on the block. To be fair tho, they do have more legacy code and it was pretty nifty to come up with conditionals in the first place.
Which is why I’m here. Firefox understands my directive, but neither IE nor Opera do. I’ve feed the “fix” for IE, via a conditional, but I don’t know how to feed an Opera-specific directive. (Was hoping there was an Opera conditional, too).
Cheers,
-stk
Hi Bruce,
I thought you might be interested in a problem that we’ve recently discovered with conditional comments..
We’ve had a number of clients that upgraded from Win98 to XP at various times in the past and then reported that parts of our website were broken when they viewed us (we use CC’s).
The problem is caused because the XP upgrade doesn’t update the version vector in the registry, when upgrading from Win98 IE5.0 (Only when upgrading from Win98 IE5.5 onwards.)
This means that users who upgraded from Win98 IE5 to XP IE6, still have a version vector of 5.0002
When their XP IE6 browser views a webpage with CC’s it will still behave as if it were IE5
Worth bearing in mind when using CC’s, unless users manually update their registries, they will be using an IE6 that still thinks it’s IE5 and their browser will process CC contents as IE5
Kind regards,
Brian
Hi Bruce, thanks for your reply.
Sorry, didn’t mean to depress you!
We are still looking into this and don’t yet know how common this situation is or how widespread the problem might be. I would be very interested to hear from anyone else that may have noticed this before. So far, this problem has occurred with three of our clients.
Cheer up!
Brian
Hi Bruce
Great article. i learned something and enjoyed it at the same time. love the quote about the lobster!
anyway, I am going with conditional comments instead of hacks since it will be infinitely more pleasureable to one day(as you say) delete my ie_insert_hatespeach.css file rather than know that there is a bunch of useless hacks in there.
I’m bookmarking your site!
Apie
Great article – goes a long way in helping to separate IE’s browser quirks, without having to muck up shared css content. I noticed a small typo in your article, which caused the site I was working on to bomb completely when left unresolved (only in IE browsers, of course!)
In your ‘Non-IE’ snippet:
do something; IE will ignore this, other browsers parse it
The last line should be:
(Notice the extra hyphens)
Cheers,
D.
My personal preference is to stylize the body tag with…
body { font: normal 62.5% Verdana,Geneva,Arial,Helvetica,sans-serif; }
62.5% sets a page’s base text size to an equivalent of 10 pixels. Going forward I can then use something like…
.sitewrapper { font-size: 1.2em; }
It’s all a matter of semantics. For example 1.2em is basically 12px. Likewise 1.6em would be like 16px… 2.4em = 24px… and so forth.
I learned this trick from an ALA article three years ago. It’s always worked as intended. Here’s the caveat (if you were looking for one): this trick doesn’t work on older browsers like IE5.0.
As a follow-up I highly recommend using em values in line-heights. Heights will automatically adjust based on whatever you set the font-size to be.
For example:
font-size: 1.4em;
line-height: 1.1em;
If you change the font-size to 1.5em you don’t need to change the line-height; it automatically scales up.
Feeling free to add reference to the “counter-discussion” concerning CC problems in my blog – now that I come across this classic post again (see comment #5 …).
Bruce,
Great article! Enjoy reading.
Where can i get a copy of IEBugs.css please?
Bruce,
Thanks for the reply. I am trying to make the mini-heihgt working for ie6. But for some reason, this doesn’t work for me.
in IEBugs.css
.labelContent {height:100px; overflow:visible;}
in products.css:
.labelContent {min-height:100px;}
and in .aspx header
Any idea?
Thanks,
Jim
Sorry, missed part:
in products.aspx header:
Jim
Oops,still missed one. Here is again. Sorry for the mess.
<link rel=”stylesheet” type=”text/css” href=”CSS/products.css” />
<!–[if lte IE 6]>
<link rel=”stylesheet” href=”CSS/IEbugs.css” type=”text/css” />
<![endif]–>
Good article Bruce, you have convinced me I am doing the right thing but with a couple of variations:
I start with a good document structure and outline for the content first linear layout.
Next @import ‘standards.css’; filters out version 4 and IE5Mac browsers who just get the linear layout.
I add the XML prolog to the top of my pages to force IE6 into quirks mode and use if lt IE 7 condition comments to @import ‘quirks.css’;.
If required, I add @import(“ie5Mac.css”) to keep that browser happy.
Occasionally, I might move some of the content styles to linear.css and link to this file to give older browsers a better presentation of their linear layout.
All my pages validate XHTML strict and CSS. I like the clean modular approach and it has always worked well for me.
It would be nice to have a more complete version of how all IE hacks can be moved into quirks.css. This could be a point of reference.
Thanks
nice article obviously, well how about using the underscore hack for the min-height and min-width???
like
#box { min-height: 100px; height: auto !important; height: 100px; }
instead of
#box {height:100px; overflow:visible;}
I am very impressed that a discussion that with a post in 2005 is STILL active because of MS silliness.. !!!
I have learn’t a lot and I have been doing this stuff for a while and have a times simply resorted to a table so I can get the damm thing up all the while feeling guilty about breaking the accessibility guidelines…
However if there was a definitive list of IE specific CSS screwups (that someone could point me too) that was clearly laid out that I could plan to pick my way around from the outset then i could die a happy web master !!!!
[…] Go here to read the rest: Bruce Lawson’s personal site : Future-proof your CSS with Conditional Comments […]
[…] per quelli che necessaitano di particolari correzioni. I commenti condizionali sono stati di grande aiuto in questo senso, ma sfruttate anche le vecchie combinazioni di @import e media, che vi permettono […]
I’ll try this first, is this ok for Firefox. Do you think it will not come up with an error? Thanks for this
[…] Future Proof Your CSS With Conditional Comments […]
[…] Future-proof your CSS with Conditional Comments from Bruce Lawson is a great comprehensive collection of CSS’s that, when combined, addresses most of CSS issues with different browsers. […]
I also strongly recommend a screen protector such as the Zagg Invisible Shield.
The case is also easy to fit with a snap together design.
Some stores have big bulletin boards at the entrance which will allow
local businesses to post flyers or advertisements, just make sure you have a good way for people to
take your company name and phone number with them and this is usually done with slits along
the bottom of the ad that customers can just
tear off.
Also visit my webpage: dien thoai gia re giam gia
Damn! Was it difficult to code IE well from the beginning?! Agh … and now if I forget some hack in CSS I must explain to the customers that it wasn’t mine the error, but IE’s? And how to reply to the people I bored with the forward-accessibility and CSS, if now I have to change all? 😐