CSS has experienced a colourful and unusual history. From historic slow adoption to the current slow rate of development, ugly hacks have meant filling in the gaps is par for the course.
With CSS1, we had a simple and elegant styling language that was supposed to be friendly to even non-programmers. Hence decisions like, say, lack of variables and constants, or conditional logic. (My kingdom for an if statement!)
Then CSS2 came along and provided us with some powerful layout tools. Except some browsers completely disagreed on how to implement them (the box model and floats are two examples that come to mind). Us web designers took care of that problem however, thanks to our lovely CSS hacks and filters. Using perfectly valid CSS, we were able to exploit a browser’s parsing error and specifically serve (or hide) our CSS to it. Problem solved. Lucky us.
But now that Internet Explorer 7 is looming, we’re getting ready to deal with the first really major upgrade to a browser’s rendering engine since we’ve started using CSS-based layouts in earnest. (The launch of Safari didn’t really count, since it was so capable right out of the gate.) The truth is that when IE 7 comes most of our usual hacking methods are going to fail. Afraid yet?
Here’s the nasty little secret of CSS-based development over the past few years: we’ve had a stable target. Because of IE6’s limitations, we’ve been fairly conservative in our usage. There’s really no such thing as cutting-edge CSS, since the CSS2 spec has been final since the late 90’s and CSS3 is off somewhere in the future. Anything we’ve done to date has been able to degrade as gracefully as possible in IE, so we’ve held back on even the more interesting bits of CSS2.
Sure, there are great advanced demos in the form of the CSS Playground, or CSS/edge, or even various CSS Zen Garden designs. But for production-based sites that we create for clients? Conservative CSS use has reigned supreme.
Except … some of us have been a little more than liberal in our hack usage, haven’t we? You might argue that those hacks were necessary to make any sense of the messy browser landscape we were presented with. At the end of a long day of coding, loading that beautiful new site in Internet Explorer has always been a soul-crushing experience. Almost none of us want to spend the time necessary to wrap our minds around just how on earth IE has decided to mangle our code. A few dashes of * html [1] here or _width [2] there and the problem goes away. The short term fix we applied three years ago, however, now threatens to come back and bite us in the rear.
Conditional Comments
IE7 will fix a lot of traditional CSS hacks. The Internet Explorer team has publicly expressed disapproval of the whole idea of hacks, in favour of an IE-proprietary method known as conditional comments. Instead of code like this to filter a rule to Win/IE:
* html #selector {
width: 100px;
}We should instead be using an HTML comment syntax to selectively serve up a link to an external CSS file, which will contain a similar rule. The syntax looks like so
<!--[if IE]>
<link rel="stylesheet" href="ie-specific-file.css" />
<![endif]-->And then the IE-specific CSS file in question might contain the following rule:
#selector {
width: 100px;
}In theory, this system works much better than CSS hacks ever did. Instead of specifically exploiting bugs in a browser, bugs that will obviously one day get fixed, conditional comments are an officially-sanctioned feature of the browser that won’t ever go away. They validate, and even though they’re proprietary, when used with discretion they allow us to accomplish exactly the same thing as CSS hacks.
Sidebar
The question is begged, of course: why are conditional comments implemented only in HTML, and not in CSS? I have it on good word this is something the IE team may look into for future releases. For now, we must place our conditional comments in our HTML files.
Future Updates
But this is simply one single browser updating, and there’s a larger issue here which we’re going to have to start thinking about sooner or later. I’d prefer sooner.
All popular browsers are improving at a frequent clip again. We’re not stagnating anymore; the improvements are going to keep coming. CSS3 isn’t finished yet, but various modules of it are being implemented already. The future is just around the corner.
As the modern browsers update, in what other interesting and creative ways will our code break? How are we going to test them? How are we going to selectively serve up code to various versions?
Take Safari. Version 2.0 was recently released. Apple has no provision for installing and running multiple versions side by side however, much the same as Microsoft has always done with Internet Explorer.
The practical implication here is that I simply can’t test my work in Safari 1.0 any longer. How do we test now, without needing to own a separate computer for each individual version of a browser? Microsoft suggests we buy Virtual PC and multiple Windows licenses to maintain multiple versions of IE (more of my thoughts on that here), an expensive proposition. Apple hasn’t suggested anything.
Causing web developers to buy more software and hardware simply to test seems an unlikely scenario; but somehow, test we must.
Versioning
And the problem will amplify over time, as more incremental updates are released, and the browser share fragments. In one sense this won’t be 1998 all over again with its 85 different versions of Netscape 4, thanks to browser auto-updating keeping most users current. But, not every user will keep up to date. I can’t count how many times I ignore the update nag message on my own machine, so they can hardly be blamed.
What are the odds that all those early adopters of Firefox 1.0 or 1.2 have kept updating, and made it to version 1.5? Likely not as high as we’d hope. Are we going to continue testing in each of them? How will we fix rendering issues that affect 1.0 and 1.2, but not 1.5? No CSS hack I’m aware of can address that discrepency.
Now, let’s be clear. Ever since CSS1, there’s been a very simple versioning control built into the language. If a browser can’t understand a selector or a rule, it simply ignores it. The theory being, as browsers add new support for a particular CSS property or selector, they’ll simply start rendering the rule they previously ignored all along.
Hasn’t worked out so well, has it? One fatal flaw of this method is that it assumes that support for new selectors and properties will be perfect from the start. Need I even get into the problems that have resulted in browser implementation errors? Box model, anyone?
The other, more subtle flaw in this method is that it assumes the fallback is good enough. Simply not rendering a rule due to lack of support, however, causes adverse side effects in styles that depend on that rule. Side effects that can translate into major usability problems for your site’s visitors.
The most obvious example I can give you lies within the CSS3 text-shadow property, which is supported only by Safari at the moment. By using the drop shadow as an outline, we can do things previously impossible, like set white text on a white background.
To the left, you see the results in Safari; a perfectly legible pairing. To the right, you see almost nothing at all. This is what the text looks like in every other major browser, since they ignore the text-shadow property.
Is just ignoring the unsupported property a good enough fallback? Not in this case, and there are other potential problems in this vein. Point being, this all-or-nothing method of managing change simply doesn’t cut it. We need browser-specific filtration, to account for scenarios where the fallback causes more harm than good.
"A standard is a standard - you should be able to render the same code consistently in every browser," I hear some cry. "Browser-specific authoring is a dead end." And they have my emphatic agreement. I’d love it if the real world proved that were the case. But it’s not.
Legitimate Hack Use
No matter how browsers evolve over the next few years, one thing seems relatively safe to predict - there will always be differing levels of support for web standards, whether it be a difference in rendering between major browsers, or even between various versions of the same browser.
The legitimate need for hacks arose as we discovered major browser bugs that prevented us from adopting CSS in the first place; through the use of hacks, we were able to specifically target versions of browsers and force them to comply. Even those on the W3C CSS working group recognize the need for page authors to work around these bugs; wasn’t it Tantek Çelik who gave us the Box Model Hack, after all?
But our CSS hacks are meant for an older set of browsers that will become less relevant in the near future; we don’t have any new mechanisms for filtering the current stable of browsers. How will we deal with browser discrepancies going forward, in light of potential usability problems?
Coping
I see a few ways.
- Limit yourself to only those CSS properties and selectors that you know will work across all browsers without fail. In fact, you don’t even have to wait for this, you can start today. Sure, it’s frustrating when all browsers but a single one render on your intended effect, but we’ve pretty well gotten used to that with things like
:hoversupport on non-anchor elements. So, hang on to that patience, because you’ll need it. - Perhaps this may not even be an issue. If all browsers continually improve, and we never see another repeat of Internet Explorer’s stagnation over the past 5 years, then we simply need to be patient until the effects we seek become practical, and with any luck that won’t be long.
- We could discover a whole new bag of hacks and filters. With the number of people hacking away at CSS these days, the chances aren’t small that sooner or later we’ll be able to exploit other bugs in other browsers, and get ourselves right back into this situation. I think a lot of people would prefer we didn’t go this route again, but it’s almost inevitable that sooner or later, the first IE7 and Firefox 1.0 hacks will rear their heads.
- Let’s think pie-in-the-sky here: we could get a bit of recognition that this problem is legitimate, and an official W3C-sanctioned method of browser filtration. I suspect the browser manufacturers are well aware that this is a problem; the IE team has given us a method for filtering out their own browser in the form of conditional comments, after all. Suggestions for codifying a similar method within CSS have been made to the CSS working group many times over the years, and I have it on good authority that there has been at least one formal proposal made in the past on the subject, but as far as I know, nothing has developed from either.
The danger in going this route echos what we learned about HTTP user agent strings in the late 90’s, of course. Crappy browsers will force page authors to filter them somehow. Crappy filtering will cause browsers to pose as each other. Maybe it would be better this time around, since the base technologies have matured a little bit. Maybe it wouldn’t.
The Reality
So what do I think is actually going to happen moving forward? Quite likely, a bit of everything.
Many will certainly follow the path of least resistance and simply limit themselves to code that works cross-browser. Others won’t settle for the status quo, and instead will look high and low for new hacks that target specific versions of specific browsers.
And maybe, just maybe, we’ll get a reliable method of filtering on a per-browser basis. I’m not holding my breath on that last one, but stranger things have happened.
Notes
- The Tan Hack, or * html bug as it’s also known, causes only IE to parse the CSS within the selector to which it’s applied. It will be fixed in IE7.
- The underscore hack causes only IE to parse the CSS within the rule to which it’s applied. It also will be fixed in IE7.
Dave that was one of the most enjoyable (longer) reads I’ve had in quite some time. Nice article.
I think its a good thing that IE is getting their act together a bit more nowdays but like you I’ve had a growing feeling of optimism / dread because we’re moving towards an uncertain and interesting time again. Its an awesome time to be working with technology.
Now I’m all excited again with the css reboot looming this week…
[…] The must read of the day was just posted on Vitamin by none other than Dave Shea in the form of a great read called Stop Hacking, or Be Stopped. […]
[…] Stop Hacking, Or Be Stopped by Dave Shea on Vitamin - excellent read. […]
Personally I could never quite see why anybody used hacks in the first place: it struck me as a bizarre double standard.
On the one hand, if you’re doing heavily-CSS based work, you’re probably one of these people who regularly preach the holiness of web standards and validation. Yet your approach is to fill your code with deliberately non-standard, non-validating hackery? It makes no sense!
It might just about make sense if it were the only choice, but it’s usually not. Take for example the explorer box model hack, one of the most common. OK, so IE can’t get its sums right when it comes to padding+margin -> width. Fine. So do we (a) insert mangled CSS which, frankly, could cause absolutely any result in future (or even current!) browser which we don’t know about and didnt explicitly test with? Or do we (b) ditch padding, only use margins, and live with inserting an extra div where needed?
Seems like everyone chose (a) and I just don’t get it. “But an extra wrapper div isn’t semantic!” Well… boo hoo. Purely semantic code is a nice ideal but it’s not a standard in itself, and abandoning it ever so slightly isn’t liable to cause mass breakage. Besides - going from 27 nested tables and tds to a single extra div, still seems like quite a triumph to me!
Well, anyway, yeah, that’s my rant for the day. One extra div or silly hacks which you surely should have known 3 years ago wouldn’t be future proof? No choice in my book. Now I’ll smugly carry on not fixing my hack-infested CSS for IE7, on the grounds that I never served any hacks in any of my CSS in the first place ;)
I chose the “don’t use hacks” method, as well, but not because of any feeling of righteousness - just because it was simpler.
Excellent article. It will be interesting to see what does evolve in the next little while.
Hm… Wouldn’t these proprietary conditional comments lend itself to more browser-specific exploitation? I could see some script kiddies using this in their websites to make a page that uses a conditional comment and throws in some IE exploit code if it’s IE.
Well and succinctly put. I have always been a supporter 2 simple approaches to CSS. Firstly and perhaps mor importantly, keep things simple and then you won’t need to hack. if you need to hack, re-think your design or layout, does it really need to be so complicated. And Secondly do all the filtering at a Style sheet level rather than at an element specific level. What I mean by that obviously is use specific style sheets, containing many elements and selectors, for specific browsers. Now I know this falls down for differentiating between FF and ie6 for example. So i refer you back to my first chosen approach keep it simple. I never actually did get into ie specific conditional statements, but I do support them in principle. The on eunfortuante thing about my simplisitc approach is i am unable to take advantage of what is a very powerful and useful language…oh well
Anyway and with a slightly self-debasing tone…bully for me, I won’t have to worry too much about the launch of ie7.
Steve, I’m not sure if you’ve met any of my clients, but they all want their sites to work well in IE6, and IE6 bugs are not limited (not by a long shot) to just the box model hack :)
There are many cases where it doesn’t matter how pristine and gorgeous my CSS is, IE6 will still fumble it a bit. And if I can fix that with one underscore hack like Dave said, then all is right in my world.
“Personally I could never quite see why anybody used hacks in the first place: it struck me as a bizarre double standard.”
Because we have to, we have no choice. If IE6 messes up a layout, what am I supposed to say to the client? “Sorry guys, the XHTML is really clean and it all validates, but 90% of your users will see the layout messed up and I’m not willing to fix that.” That’s not how my world works (is that how it works for you?) so until the browser the vast majority of the world’s users use can render XHTML/CSS perfectly, even the most sophisticated web designers will have to concede some hacks to our friends in Redmond.
Err.. Firefox 1.2? It went straight from 1.0.7 to 1.5…
I’d like a way to test for whether a browser supports a specific property in CSS, like in Javascript. For example:
p {
if (text-shadow) {
color: #fff;
text-shadow: #000 0 0 2px;
} else {
color: #000;
}
}
It could get a bit long and complicated and wouldn’t help in cases where a browser supports a property but not in accordance to the spec (e.g. IE box model) but testing for a specific browser seems a bit 1998 to me…
Interesting read. Working in a application development company as a designer and coder im always pushing for standards compliant code. Its not always so easy when such a large number of our clients use IE and all our developing is done in IE and not on any other browser.
Everytime I have to put together the initial code for the site its always the same debate of tables vs. CSS layouts. With the IE7 its going to make my job that more difficult to predict whats going to happen.
I want to fight for standards but even in a million dollar web app company we can always go that route and that sad.
I hope to hear more about this issue.
[…] Dave Shea legt uit “With the imminent launch of IE7 your usual CSS hacking methods are going to fail. If you want to save web design, as we know it, it’s time to take some drastic action.” […]
“Personally I could never quite see why anybody used hacks in the first place: it struck me as a bizarre double standard.”
Considering I covered exactly this in the article, perhaps you’d like to go back and (re-?)read it…
“Err.. Firefox 1.2? It went straight from 1.0.7 to 1.5…”
My mistake, clearly I haven’t been paying enough attention to point releases. (The larger point I was attempting to make obviously remains, despite the error.)
“I’d like a way to test for whether a browser supports a specific property in CSS, like in Javascript.”
I’d be okay with the idea, except that we obviously know from the Javascript experience that, just because a browser says it supports the property, doesn’t necessarily make it so. It might be more palatable to a lot of people, however, since (as we see in the comments above) the natural inclination of many is to view browser-specific rendering as too dangerous to trust the general public with.
Keep in mind that some hacks may still be effective. For example, I use the *html hack a lot. In IE7, this hack doesn’t work, but most of the bugs I’m using it for are fixed in IE7. I think you may find that many of the hacks that don’t work in IE7 may not be needed.
Another thing that I’ve been actively trying to do is avoid the need for “pixel-perfect” layouts. In many cases, I find that with some create design I can create layouts that still look fine even if things are shifted a few inches. In fact, I would argue that creating layouts in CSS that need to be pixel-perfect will lead to many of the maintainability issues that designers have with table-based layout.
My question that i didn’t see addressed here, is what level of compliance will I.E. 7 offer, as compared to earlier versions of I.E.? For example, if the I.E. 7 browser offers the level of compliance that Firefox and Safari offer, than the fact that old browser hacks are ignored, won’t be a big deal at all. It will just ignore the hacks and render everything the way it should have done all along. We are talking about I.E. however, so I am sure I am being too optimistic here.
“…if the I.E. 7 browser offers the level of compliance that Firefox and Safari offer, than the fact that old browser hacks are ignored, won’t be a big deal at all.”
Dean, that’s certainly the hope. In a lot of cases, chances are the things you previously would have used the * html hack to correct will now simply render properly, and you won’t have to change a thing.
But, of course, that won’t be universal. Not everything will be fixed/implemented. So I’m reasonably sure this will still be a relevant issue with IE7, in some respects.
“Personally I could never quite see why anybody used hacks in the first place: it struck me as a bizarre double standard.â€
Quite simply, when you’re running over-time and over-budget (and what web job isn’t?) and you’ve spent three hours trying to find the right compliant compromise, giving in to “_height” and getting the job out the door (and getting home before your kids have gone to bed for once!) seems like understandable. Suffice to say, those hacks may come back to haunt me, but it’s better than giving into the clamour of an art director that knows enough about HTML to say “WHY AREN’T YOU DOING IT WITH NESTED TABLES!? GET THAT JOB FINISHED!”
Great article, and good discussion btw… :-)
The benefit nobody mentioned about the IE team’s proposed conditional comment hack configuration is the bandwidth savings. For non-IE browsers (which simply see it as a comment), that’s one less hit to the web server, and that easily trumps external stylesheet IE-targeted hacks. For the first time, we’re looking at a hack implementation that doesn’t penalize “everyone else” with another 10-15 KB download that they’re browser is going to ignore anyway. That’s a short-term solution that scales well, and I commend the IE team for it.
Well, my opinion is that using some hacks is very useful. I’m not talking about using every kind of hacks. For example the “* html” is a useful one, as I think.
You say, that it will be a problem, that IE7 will fix this bug, but I say, that it’s quite OK, that IE7 will do it: as it will fix the main problems, too, all hacks will be unneccesary - so it can work almost perfectly. You can use conditional comments as well, but it makes my life more difficult: separating means not manageble for me: if I change something in the main CSS code, I have to check out, if there is something in IE’s code. It’s easier to keep it together.
These days, the main problem is IE. I don’t want to use super-duper tricks with CSS, I just want to lay down what the designer gave to me. If I use the “* html” hack, then I can address the problems with IE*6*, and I think it will work _mostly_ with IE*7*, too. And if not, I have to check it, any way, independently from hacks.
[…] A scary article from Vitamen about the layout wars that are on the horizon, as the web design community awaits the arrival of Internet Explorer 7 and (eventually) version 3 of the Cascading Stylesheets standard. The author sums up the problem: Here’s the nasty little secret of CSS-based development over the past few years: we’ve had a stable target. Because of IE6’s limitations, we’ve been fairly conservative in our usage. There’s really no such thing as cutting-edge CSS, since the CSS2 spec has been final since the late 90’s and CSS3 is off somewhere in the future. Anything we’ve done to date has been able to degrade as gracefully as possible in IE, so we’ve held back on even the more interesting bits of CSS2. […]
[…] David Shea (the CSS Zen Gardener) urges web designers to stop CSS hacking or be stopped. Nice article from the fledgling Vitamin website. […]
“How do we test now, without needing to own a separate computer for each individual version of a browser?”
I’ve used the online browser testing service BrowserCam.com — most of the build in Firefox & IE, then test online.
Also worth mentioning the browser archive at evolt.org:
http://browsers.evolt.org/
plus some good work to get IE7 running standalone on Windows by Jon Galloway:
http://tinyurl.com/nmn68
hth, Jake
Instead of having to worry about hacks and what will/won’t work in the future, what should be happening is the browser manufacturers stepping up to the plate and all of them fully and correctly implementing the CSS2/3 specifications.
They’ve had some 10 years to do it… It isn’t that hard to program the specifications into their browsers. Enough with all this hacks and browser rendering inconsistencies where is the moral outrage towards browser makers to do a better job? How much nicer would the web be if the language worked the way it is meant to.
Safari and Opera have shown that it can be done so what are the excuses for the others?
"The Internet Explorer team has publicly expressed disapproval of the whole idea of hacks"
Are they just ignorant hypocrites? How about our publicly expressed disapproval of their reluctance to improve their own browser. If it wasn’t for their browser’s poor implementation there wouldn’t be a need for hacks at all..
Why use a hack when you can use valid CSS?
For example, something I often have to do is clear floats using their parent container:
body {
overflow : hidden;
}
Of course IE doesn’t like this, so you have to trick it into giving the element layout:
body {
height : auto !important; height : 1%;
overflow : hidden;
}
And what do you have! Valid CSS, but every browser other than IE uses the first rule, not the second.
I don’t know how many people I’ve told about this, I’d honestly have thought I’d see it in use somewhere…
This is just too complicating. Why can’t someone come up with a proper standard to conform to, so that all the browsers can work equally well?
I have problem with the guestbook on my website. It looks alright in Firefox, but looks horrible in IE.
While I understand the “hurry up and get it done” reasoning behind using hacks I don’t understand the need when 90% of all css layout issues can be handled with a simple usage of selectors that IE doesn’t use. According to your own book Dave parent child selectors (#div1 > #div2 ) are ignored by IE yet allow better browsers to render the code better. The best thing is this method is valid, still allows semantic markup and at the end of the day causes less headaches since it allows per browser fine tuning. I make sure all of my pages are valid semantic html (if not xhtml using application/xhtml when I can) and aside from getting css warnings for lack of background colors I happily can work all day long week after week without resorting to any of the dirty hacks.
I do agree that the conditional comments idea is something good however the browsers do need to make a better effort to support the standards, especially IE.
Steve, I’m not sure if you’ve met any of my clients, but they all want their sites to work well in IE6, and IE6 bugs are not limited (not by a long shot) to just the box model hack :)
No, well, that’s fair enough.
But, what I was basically getting at is that I’ve never really come across a show-stopper of an IE6 bug which I couldn’t work around in some way other than a CSS hack. Such as an extra div (or several), or simply doing it a slightly different way. For example - no :hover on all elements is a bit of a pain if you want rollover lists, right? Well, I just make the a tag fill the li tag, and do the :hover on the a, and then it works in IE without any suckerfish js. OK I know that’s not avoiding a css hack, but you get my point… there is usually another way to approach things.
Anyway… at this stage I suppose I should freely concede that I am fortunate enough not to be in the position where I get given photoshop documents which I have to create pixel perfect or get fired ;-)
If I was, and I guess many of you are, then I would doubtless understand your position a bit better!
Luckily for me, it’s more often a case of “well you’re the web guy, you know what works and what doesn’t” and whilst ‘clients’ will say “i prefer that colour” or “can’t we align that on the right” they won’t hold me to a pixel perfect mockup.
So if I ever do run into a few IE quirks I either just change my design to avoid it, or live with it (on the grounds that pixel accurate rendering across every browser is not The Way of the Web anyway) - both options a luxury you dont have if you’re recreating psds.
Considering I covered exactly this in the article, perhaps you’d like to go back and (re-?)read it…
I wasn’t knocking your article Dave :)
FWIW zen garden is (like so many people) what fired me into learning CSS based design at all, and I read mezzoblue all the time, I’m certainly not likely to start telling you I know better than you :)
But I think you’re being a bit unfair, of course I did read your article, and I was attempting to address it… You say:
You might argue that those hacks were necessary to make any sense of the messy browser landscape we were presented with. At the end of a long day of coding, loading that beautiful new site in Internet Explorer has always been a soul-crushing experience. Almost none of us want to spend the time necessary to wrap our minds around just how on earth IE has decided to mangle our code.
For sure — that clearly explains why we need workarounds, even ugly ones we don’t really like.
But what I’m saying is why should those workarounds be css hacks when sometimes a change to the markup might be able to achieve the same thing.
Like in my box model example - tantek hack, or use extra divs? In other words: Break css standards, or abandon purely semantic markup?
So I guess what I was getting at is, why do so many web designers consider breaking css standards the lesser of those two evils, considering it is surely less future proof, and one extra div still leaves us with a 98% semantic piece of xhtml?
Does that rephrase it in a less inflamatory way than my previous effort (”double standard”) which I will concede came out a bit harsh?
Anyway… yeah… guess I got on a bit of a rant… and quite a double standard myself considering the CSS on the linked website of my first post is utterly hideous and bodged! :-D
[…] Stop Hacking, or be Stopped […]
[…] In this morning’s collection of stuff from Digg, I read this article about CSS hacks, and why they’re about to become very problematic for lots of folks. […]
I decided to take a quick look at fixing my personal site for IE7 last week - to see what kind of hell I might be in for when the final release drops, and was pleasantly surprised actually. All I really had to do was update my .clearfix CSS with zoom:1 in the conditional comments and it was sorted (I wrote this up, incidentally). I went straight back and tried the same fix on a couple of client sites and they went smoothely too.
Yes, there are going to be problems when the final release goes out but I’m not sure it’s going to be quite as bad as I, for one, had feared. That said though, I’m limited to the * html hack for the box model and the Holly hack for various and assorted IE issues. Those two seem to play reasonably nicely with our new friend…
Dealing With The Looming Internet Explorer 7 Release…
Dave Shea makes some good points in his post at Vitamin about the upcoming IE7 release and browser hacks. I started to weigh in amongst his comments, but I got a little long-winded so I figured it was better written on my own blog instead of using Dave…
Good article - thanks Dave.
I support the basic premise here, but I also support those who are debating the practical reality of it. In truth, we develop css-based sites primarily for IE6 (and will do for a good few years yet) purely because it is used by the overwhelming majority of users out there. The purity debate is largely pointless at this level, since all those copies of IE6 are already out there.
Hacks are wrong, but also inevitable I’m afraid, until the browser base is such that we can persuade clients to accept a degraded experience in IE6 (i.e. when it gets below 10% usage probably).
Why are they inevitable? Because clients do want pixel-perfect layouts, and rightly so in my book. Why should we accept lower design standards online when we can do something about it. We make our designs as sopisticated as they can be, and we always should. Sure simpler is better, it’s just that when clients are involved, simpler just is not always possible in the real-world.
Sure, the hacks are ugly to us, but not to the people using the site - and frankly they’re the only people who really matter in all of this.
I don’t mind that the hacks we all use to deal wiith IE6 problems now may cause problems later. If they deliver the best experience to the majority of users, they’re a sensible compromise until IE7 gains a foothold and we can all start cleaning out the excess rubbish needed to correct MS’s many, many past mistakes. We have to remember that we’re in a business about brands and people, and we have to serve them both as well as we can. Sometimes, sadly, that means hacks.
And does anyone really believe that it won’t always be this way to some degree? CSS 3 anyone?
[…] www.thinkvitamin.com/features/css/stop-css-hacking […]
How do you plan to handle this transition with your existing sites and customers?
I need to determine how my sites are going to render, but I’m a bit concerned about the time and effort to tweak my existing customer sites to work with IE7 (and still have to deal with IE6 support too).
Obviously I’d love to get paid for the effort, but I foresee strong resistance from my customers to cough up the cash. I also think it will be challenging to explain to the less technical customers what exactly is happening and why.
Thanks
Propietary Standards. just F’ing lovely.
Why does MSFT insist on not following conventions and standards?
A half-implemented, half-adopted mess, and the splintering of CSS and compliance continues.
Thanks MSFT.
You are, of course, assuming that IE maintains total dominance over the net. You shouldn’t think of the web development as being related to a Microsoft failure problem> program.
Long live tables. If it ain’t broke, don’t fix it. tables work fine, have worked fine and will always work fine.
Stick to tables and you wouldn’t need to worry about this. Limit CSS to rendering display text and styling form elements.
The only hack we’ll ever need to accomodate for IE’s BS is !important.
#bad {width:0px !important; width:100%;}
So let me get this straight….they’re going to fix the exploits that we use to hack CSS but not fix the rendering issues that cause us to need the hacks at all?
Brilliant.
Great article,
just one point to add:
The transition from IE 6 to 7 will be almost as long as 5 years. This stands true partly because of the older machines that aren’t quite able to run Vista (and so, IE7 aswell) will remain the downgraded for god knows how long. So removing your hacks from your pages might not be good just yet, wait atleast until Vista is deployed.
EOT
just browser sniff for IE and if they use it, put up a dialog box saying “Some stuff might not work. That’s what you get for using some crappy 5 year old browser that hasn’t been updated.”
Ok, maybe not in those exact words.
Some have argued that the use of common CSS hacks isn’t that big of a deal because IE7 will fix most of the bugs anyway. I’d like to clear up that little misconception. If you take a look at these standards support tables, tested using the “layout complete” build of IE7, you’ll see that most of the problems still remain. In fact, IE7 even has some new float bugs that I’ve run into in my websites.
For now, I think the best solution to deal with Internet Explorer is using version-specific conditional comments. At its current rate, IE doesn’t seem to have a chance at reaching Firefox’s and Opera’s level of CSS support for several more major versions.
It should be noted that
1) text-shadow is CSS2, though it may also be found in the text-module in CSS3
2) it’s actually fully implemented in Konqueror, whereas Safari is only able to draw ONE shadow instead of the list specified in the specs…
Long live tables. If it ain’t broke, don’t fix it. tables work fine, have worked fine and will always work fine.
So you suggest using tables that will fail in most portable devices? Not to mention alienating people whom access the information on the Internet differently than others. So anyone who is blind and uses a screen reader should not be allowed to access this information because their screen reader is going to read the content of the tables correctly? Good idea.
just browser sniff for IE and if they use it, put up a dialog box saying “Some stuff might not work. That’s what you get for using some crappy 5 year old browser that hasn’t been updated.â€
Same thing I just said before but apply it to browsers as opposed to screen readers.
well I was sorta kidding. But you gotta agree IE is lame lame lame. Why they can’t just at least make things work moderately well and leave it at that. Looks like everyone’s been waiting for IE7 and it turns out it’s not even gonna fix anything.
Most hacks are redundant… try and re-write the CSS and you will most likely find that you can get it to work just fine…
One important thing - make sure IE doesn’t run in quirks-mode. If IE runs in strict mode it’s math-skills does improve a lot so box-model hacks are rarely needed.
And i thought there was a way to run different builds of webkit side by side already?
http://web.mac.com/reinholdpenner/iWeb/Software/NightShift.html
Or does this replace the stable version of webkit with another one? Just tried it for 5 mins so i couldn’t tell you…
[…] thinkvitamin.com […]
Maybe I don’t get it, but if IE 7 gets it right, ignores the hacks and displays pages correctly (like, say, as Firefox does) than isn’t it perfectly OK to use the * and underscore hacks as they’ll just be ignored by IE 7???
If that’s not the case, then why the heck not?? Seems like a simple solution to me, but maybe it’s too simple and I’m an idiot.
Regardless, it’s going to take a LONG time before we don’t have to worry about IE 6 so I’m content will hacking away when I need to.
And, for the record, I usually try to avoid hacks.
Why are we all still sitting around accepting this? As a developer of ten years I don’t want to waste another second of my life working around browser irregularities.
It’s time for all browser developers to adhere to some sort of standard specified rendering behavior
This is the direct solution to the problem.
How far off from this would we be without IE in the picture? Very close.
IE7 is a trick. microsoft is releasing this to placate the public (tabs, increased security) and continue to make our jobs just hard enough that we’ll embrace XAML and avalon when they arrive… erm next year i guess. the IE7 team should have either not touched the CSS rendering or they should have done it right, not the half-assed job they shown in the betas.
for those of you who say the job is too difficult based on the current rendering engine let me remind you that in the time microsoft released IE6 and IE7 (less actually) they designed, developed and deployed not one, but two gaming systems including an entire architecture shift from gen 1 to gen 2 and an online community.
if they had wanted to, IE7 could have been a first class citizen with safari and firefox. instead we’re going to be stuck coming up with separate stylesheets for IE5, IE6 and now IE7.
The only hack I’ve ever used is the !important; hack as mentioned twice above. Been using it for years and it works great! No other hacks are needed.
The question I have is… will this be ‘fixed’ or better yet, no longer needed in IE 7?
I don’t want to sound like a troll, but to be quite honest I havn’t seen many of the major advantages CSS2 was supposed to bring. I’ve been developing sites with CSS2 for the last 5 years or so, and disregarding accessibility and semantic issues, reeling off nested tables to browser viewers, and feeding mobile browsers (not that I particularly care about mobile browsers down here in New Zealand) a seperate version would have taken the same amount of development time as creating a semantically correct and accessible CSS2-based version, yet It’s highly likely that I won’t have to face an onslaught of fixes that will need to occur if I had taken the tables route.
If you can’t see the point I am hinting at, I’ll spell it out for you: CSS2 is completely flawed. There is a very good reason why even the leading edge browsers have marginal support for the >5 year old standard; and that’s a complete lack of competence on the W3C’s part.
Maybe instead of us developers keeping our CSS simple, the W3C working group could keep THEIR CSS simple by drafting a decent standard that can be easily supported with no ambiguity in specifications. We shouldn’t be using floats to create column-based layouts. What kind of idiocy is that? The functionality we had with tables should have been provided to us with CSS2, but it wasn’t. The relativity of tables was nowhere to be found - instead we were thrown into a pool of sludge.
Personally, I write CSS for IE6/Win32, and then look to Safari and Opera for any errors/inconsistencies. I’ve found over the years that the advice many high-profilers have given regarding “code to standards (a la firefox)” actually causes the most problems.
IE6 is analogous to a lowest common denominator when it comes to CSS support in modern browsers, and using firefox to test your development while using your [basically guaranteed to be not 100% correct] understanding of CSS to avoid any IE6 problems is like setting out to build a game that will run on any Pentium-class system or higher while testing (and optimising) on a high-end Athlon64! It’s just plain silly.
I’ve found that through coding for IE6 (while mentally observing standards), and THEN fixing the more compliant browsers, I use much fewer hacks than when coding to the compliant browsers and attempting to retrofit. Basically, much of my newer work should be completely unaffected by IE7’s engine updates (unless they introduce new bugs).
Oh, and those people who keep ranting on about the IE6 box model being incorrect - use a valid doctype with URL (a la, shift into Standards Mode) and watch it follow the precious standards…
It’s IE’s FLOAT model that’s broken.
[…] It’s only just launched in the last handful of weeks, but already it’s filled with some truly substantial articles on the challenges of web design and development, the newest of which is Dave Shea’s challenging article on the risks of continued use of CSS hacks in the wake of the coming debut of Internet Explorer 7. Because Windows auto-update will begin to pester all registered Windows users to upgrade to IE7 when it ships (as well as being bundled with Windows Vista) it’s going to be well worth everyone’s while to make sure their public designs don’t split asunder when IE7 comes knocking at their doors. Dave emphasizes that the more hacks you have in your CSS, and the more you rely upon them, the more perilous and tenuous your designs will become as IE7, and other upgrades, spill into the market. IE7 is a big change in the landscape, long coming, but Dave argues that we will likely begin to see an acceleration of upgrades for most or all browsers; in other words, that the years of sterility and motionlessness are coming to an end, and the evolution could begin to bring growing pains. […]
[…] great article on IE7 and CSS read more | digg story Get small business ideas and earn extra income for your online business! Bookmark on del.icio.us […]
Hacks are there to work around inconsistencies of a given browser, by leveraging that inconsistency. If a browser gets updated (fixed) that inconsistency should be fixed as well, otherwise making websites will become impossible really fast.
The opinion or preference of the IE Team is irrelevant in this case, we shall never have to accept things like conditional comments. period. If we would, there wouldn’t be a driving force to fix problems instead of pointing back at conditional comments options, otherwise we would risk to have to code 27 different stylesheets for 27 different versions of several browsers.
So, finding the lowest common denominator and maytbe add some spice here and there for better behaving browsers is the best options of the alternatives presented here, and using some hacks that are browser-version specific to fix problems we cannot work around otherwise is OK then; just like Tantek has said a few times before if my memory serves me well.
Keeping the pressure on every web browser producer is the best way to ensure that in a (near) future, CSS implementations will converse. From a business perspective that would make sense: if your name is Disney Corporation or Citibank, I would scratch my head if I’m told that I have to maintain 27 versions of my website, just to ensure access for my customers; I think I would pressure some companies a bit harder to save myself some money.
Safari version can easily be run side-by-side - all you need to do is move them from the default location Applications/Safari.app. I am running 10.4.6 Safari next to the nightly webkit right now.
The question is not how do we do it, the question is: where do I find that old version of Safari?
In my office, we work exclusively with Quirksmode-triggering DOCTYPES. (I know, I know… it sure wasn’t my idea, although there is the benefit of not having to test on both IE 6 and 5.)
I’m getting the feeling that all the reports I’m reading on IE7 are about its performance in standards mode… Any news about IE7’s behavior in Quirks?
[…] Will ie7 be the end of the web as we know it? […]
Stop Css Hacking Or Be Stopped In IE7…
With the imminent launch of IE7 your usual CSS hacking methods are going to fail. If you want to save web design, as we know it, it’s time to take some drastic action. Read more from the fine folks at Vitamin.
……
[…] I noticed this article on using CSS hacks to get Windows Internet Explorer to behave correctly. I really do not understand the argument of the article. […]
Keith Humm:
Maybe instead of us developers keeping our CSS simple, the W3C working group could keep THEIR CSS simple by drafting a decent standard that can be easily supported with no ambiguity in specifications. We shouldn’t be using floats to create column-based layouts. What kind of idiocy is that? The functionality we had with tables should have been provided to us with CSS2, but it wasn’t. The relativity of tables was nowhere to be found - instead we were thrown into a pool of sludge.
The relativity of tables was included in CSS2 - display: table, display: table-cell etc (from memory). It’s quite handy, you can make arbitrary elements into rows and cells. Of course it wasn’t supported by IE.
Asher Haig: Sure you can run multiple versions of Safari side by side, but they will all use the same WebKit framework from the operating system and thus share the same rendering. That’s useless for testing web pages.
There is a way to bundle a specific version of WebKit inside Safari and make it use it. I’ve documented it. And I currently have nine “self-contained” versions of Safari sitting on my computer waiting for some place to host them. If someone is interested in hosting the files, drop me a note.
I’m not sure what happend to my link in the last comment, but here is what I wanted to link to:
http://www.michelf.com/weblog/2005/multi-safari/
So instead of one or more hacks in a single CSS file MS prefers we have two CSS files plus an extra 3 IE specific lines in the head of every html file …
Why does this not surprise me …
The EU should force Microsoft to make Internet Explorer comply with Web standards given the grief that it has caused the entire Web industry.
Try to imagine the cost that every stakeholder has incurred as the result of Internet Explorer’s faults: you can’t, it’s too big.
[…] Well, it looks like I was wrong. After reading this article on the wonderful new Vitamin, I realized that my precious CSS hacks will cause me a world of hurt when IE7 premieres. […]
Although I have abandoned tables and am now on the CSS band wagon you never saw this many people pulling their hair out over them. And I could put a layout together in half the time.
Unless some server side rendering engine or something like it is developed that takes the browser manufacturers out of the equation we will ALWAYS have these problems.
Frustrating.
Great article. I think you are bringing up the right points at the right time. I really feel that we–the Web developers–need to stick to standards based Web pages. And we really need to lean on browser developers to support those standards. It’s easy to say that of course, but then you have to support a corporate brand that can only be rendered by using CSS hacks. But again, if it validates and it works that should be enough.
Forwards compatibility is something that is not always attainable. There is sometimes a leap forward in technology that leaves older code in the cold.
So the leading lights roll over and present their bellies to the beast, now we know who’s been paying them. Duncun was right, ie7’s a trick. ie6 was a trick. I wonder what sort of creative javascript bugs they’ll introduce.
We’re doomed until we say “no more”, except your all too fudging yellow.
Hooray for the bshit, dude. Those are the circumstances, deal with them. Stop babling at stupid things like IE this, Firefox that etc. And throwing things known since the dawn of the the web development, won’t improve anything. And conditional comments sucks. Badly.
[…] Dave Shea has posted a great article on Vitamin which is worth a read (Hint: read it now). It’s interesting that now that IE7 is on it’s way there been a lot more activity in the web community. The folks are getting slated constantly on the IEBlog yet IE still has an 80% share in the browser market but what they are doing is having all kinds of good affects. Even if IE7 isn’t as good as Opera or Firefox it’s opening the door to allowing web developers to do even cooler things and for the web community to learn more and be more active. […]
Yeah, I love how Microsoft is being so righteous about the use of CSS hacks now.
No no no, stop using hacks and use this proprietary code instead okay!?
How about ‘no’ ?
Great article - Thanks!
should CSS that is not implemented widely be offered through javacript at times?
Along the lines of some things said by Steve K, Mark Wilson, and others:
I happen to be in an environment where my client often provides Photoshop files and asks that the final output look the same. “Pixel perfection” is implied but not explicit.
But my experience suggests that the customer doesn’t really care about cross-browser pixel perfection; they want pixel perfection in IE. In fact, they’re not going to bother viewing the page in anything other than IE. And the end-user doesn’t care at all; they don’t have the .psd file to compare in the first place. They only know if it’s usable or not.
So, I:
* develop with a Strict doctype, using no CSS hacks (though sometimes employing “non-semantic” workarounds like Steve suggests), and checking results in Firefox;
* then view in Explorer, and nudge the layout where necessary to closely match the client’s specifications.
Generally, the small remaining differences between browsers are irrelevant to the end-user’s experience anyway.
And Mark, I simply disagree that forgoing pixel perfection is a “lower design standard.” One of the environmental conditions of our medium is that pixel rendering will vary; a higher standard of design embraces that fact and accomodates for it.
The best design experiences I’ve had were when I had the luxury of working with a layout artist who, though he didn’t write code, understood the layout principles that would work in CSS. His page elements were discrete and had enough breathing room to allow for small variations in sizing. And the clients loved the results. There was no aesthetic compromise.
Yeah, i agree - stop css-hacking!!! Its only for suckers!
Conditional Comments! Use em!
This may have been mentioned more in the previous comments but I code and design websites all day long. Maybe not as long as a lot of you but for the last 2 and a half years. I have managed to avoid hacks all together by using conditional comments. It’s so easy to create a stylesheet named ie.css and to add all your explorer styles there. Lately I’ve been targeting all ie versions less than 7 in the cond comment. So when ie7 becomes used more, hopefully it wont need to see the explorer specific styles and everything will be fine. I downloaded the ie7 beta recently and havent noticed any problems. Some very small problems but nothing major.
Here’s a pretty obvious example:
Say I have a div that I want a min-height on. Well in my normal screen.css I give the div a min-height of 300px along with all the other css styling it would get. Then in the ie.css I give that div a height of 300px and no need to rewrite the other styles it needs to have. Problem solved
I dont see why people are still using hacks when we’ve known about conditional comments for so long and how easy it is. There’s really no need for hacks. Use conditional comments! :)
[…] Lo dice Dave Shea en un artÃculo publicado en Think Vitamin, asà que tendrás que hacerle caso. […]
Completely agree with Ross’ comment — conditional comments are the best way to keep your stylesheets hack-free and organized.
What about this hack ? don`t work too ?
//margin:0px
My personal opinion is that the article is intended to be sensationalistic to draw viewers to the new Vitamin site. (gee, guess that worked). The warning of dire consequences if developers continue to use, and don’t fix previously used, css hacks is not entirely true. For one, the * html hack will continue to do exactly what it has always done: serve that particular bit of css to IE6. Its true that IE7 fixes that hack, which in this case means that IE7 ignores it altogether like all other modern browsers.
So in cases where you may have used the * html hack to fix a problem with IE6, AND (big AND here) IE7 does not display those same problems, leaving the * html hack in place makes absolutely no difference. It will continue to fix IE6 as it always has, and other browsers, including IE7, will ignore it as they rightly should.
I do agree that, going forward, conditional comments are the way to go, and the gist of the article is certainly relevant. I just think its unfortunate how the message is being communicated, and in some ways, miscommunicated.
No amount of soapboxing by individuals, prominent or otherwise, should replace common sense and good old testing, testing, testing.
I think we all, and I mean EVERYONE in the web design/development community should REFUSE to fix or prepare anything for the potential issues with IE7.
Let the browser break all of your client’s sites, personal sites, friends sites, etc. etc. Then everyone will realize that the new IE is “not good” and hopefully get on firefox? Thoughts?
Eddie,
That’s not real world. Think about a client who wants a website. Most clients only use Internet Explorer and use whatever version is on their computer. They don’t know that IE sucks. Most of them have never heard of Firefox. All they care about is if their site works with their browser (IE) and their own clients’ browsers.
So having your site fall apart in their browser (IE) is not good for business. Explaining to them that IE sucks and we should all boycott it wont work because they dont care if IE sucks. To them it’s all they know and all they will use. Sure a few of them can be introduced into Firefox and will use it but for the most part the’yre happy with IE and dont know we have to go through all the pain to make it work in “their” browser.
Some good news I read today though…supposedly IE visitors to google’s homepage will now see Firefox ads. In the long run IE may lose a large portion of their base but for now we can’t ignore them. Believe me, I wish to god we could.
Conditional comments won’t work either, since they purposely stop working once a browser reaches a version number.
Let’s say you discover a bug that affects IE 6 and IE 7. Do you put the fix in a cc stylesheet targeted at IE 7 and lower? What happens if the bug persists in IE 7.5, IE8, and IE9. If your layout becomes broken in IE8 because you only put the fix in for IE7 and lower, it now becomes your fault that the site is broken since it was your decision to prevent the fix from being applied in IE8. That’s not something I’d like to explain to a client.
Hacks, on the other hand put the burden of work onto the browser developers to fix their rendering engine so that the hack is ignored and the bug that needed the hack is fixed. We’ve seen the IE team step up to the plate with IE7 by improving CSS support and ignoring the IE6 hacks, so one could argue that the system works.
Put two and two together, and you can start to realise why the IE team advocate conditional comments over hacks.
Adriand,
In my testing ie7 seems to have many of the bugs fixed. So if in your cond comment you target less than ie7 you’ll be fine. If you run into a bug or two for ie7 you can have another ie7.css stylesheet inside a cond comment targeting just ie7.
Pretty simple.
For those of you who are curious, there are some new CSS hacks that target IE7. The most practical one is *+html{} which selects the html element in IE7 like * html{} does in IE6 and below. Of course, hacks should be avoided at all costs, but the world of CSS hacks hasn’t disappeared with IE7.
Dave: a great read, thank you. The only question I have is: What about IE6 users? there’s going to be millions using it for several years and I think we still need to hack for them. or not?… Microsoft complicates everything!!!!!
“If you run into a bug or two for ie7 you can have another ie7.css stylesheet inside a cond comment targeting just ie7.
Pretty simple.”
Well, if you include an ie7 targeted cc to fix an ie7 bug, what are you going to do when IE 8,9…15 roll out with the same bug but don’t load your ie7 cc anymore? It might be fine to go back and update the cc of one site, but imagine how design agencies feel about having to do that to the hundreds of sites they may have developed over this period of time.
Yes, we face the same issues with hacks, but in theory, hacks will “expire” automatically for you once the browser has had its CSS support upgraded. Conditional comments, however, require you to guess which version numbers to apply the fix to, since you don’t know in which future version of the browser that the bug will be fixed.
[…] With the imminent launch of IE7, the usual CSS hacking methods are going to fail - from thinkvitamin.com.Microsoft’s Internet Explorer 7 team will break common CSS hacks - from blogs.msdn.com […]
[…] Früher™, anno 2003, als ich anfing mich mit CSS zu beschäftigen hatte man noch wirklich gute Chancen ein CSS-Hero zu werden. Mann musste dazu eigentlich nur einen Hack finden, der für andere nützlich war, und davon gab es reichlich. Wie das Schicksal so spielt, sind das genau diese Leute gewesen, die heutzutage den Zeigefinger heben und ermahnen keine Hacks mehr zu benutzen ;-). Heute scheinen alle Hacks schon gefunden und dokumentiert, der letzte große war der .clearfix Hack, seitdem habe ich eigentlich nichts neues aus dieser Richtung gelesen, was ja nicht unbedingt etwas schlechtes bedeuten muss. […]
I’d love to get rid of hacks all together, i recently managed to build a single CSS design that works on most recent browsers including IE6, but i have no idea if IE5 and comparable competitors butcher it or not. Afaik IE7 will not be available for XP so IE6 might be around for even longer. If you design websites for common local-town audience (and i believe such make up a big part of the web) you have to expect a Win9x environment, that’s what visitor stats remind me of all the time.
[…] link […]
[…] http://www.thinkvitamin.com/features/css/stop-css-hacking […]
Isn’t it just so disappointing that this medium we all know and love is hindered by such issues.
I think the whole thing stinks because even though it is slighly better the whole [if IE] thing is essentially a browser sniff and “code folking” has always been considered bad form. That said I believe it is probably better than the array hacks we have to implement at the moment.
Nice article anyway fella.
Paul’s right. But at the same time we’re getting dinged for charging even 1999 web design and development rates. Ugh. Try explaining any of these things to a client who just got 3 other bids hovering around $700 for his website. Unbelievable.
Dave great read as usual, thanks! Personally, I have some issues with using IE conditional statements. Firstly I see why we shouldn’t use hacks to get around problems. It isn’t logical to solve problems with another problem, however theres no other way round it in some circumstances. However isn’t the IE conditional statements just really another hack?
I can see the point in them, however if Microsoft just fixed the problems then life would be much easier for everyone.
this really seems wrong, there is nothing about IE7 that will cause our CSS to break. IE7 will become more compliant and will skip over most of the hacks just as browsers like Firefox and Opera have been doing the whole freakin time.
You’re gettin my panties all in a bunch over nothing, Stop it! :P
People are playin this nonsense like the Y2K of CSS. Get over it, there is no such doomsday coming for CSS.
*deep breathe*
[…] Update (April 25, 2006): Great article by Dave Shea about IE 7 and dealing with how different browsers treat cutting-edge CSS techniques. […]
… which is supported only by Safari at the moment…
Not true.
Safari uses the KDE HTML rendering engine KHTML. Konqueror (KDE’s Default browser) is the other one that supports this. Konq. is in fact ahead of FF in support of CSS ’stuff’ now that safari gave the hard work done to KHTML back to the community.
[…] I know, our hacks will break in IE 7, but when you’re under the gun, 1px off, and need to get some sleep, you do what has to be done. […]
Dave, You are very right that putting your (website) together using hacks is not good idea. I have come across many sites (which) do so and break on many occassions. The most important thing is that they can test the website on their server and the set of browsers they have access to but unfortunately not all.
I have myself tried to do so sometimes but the best approach I figured out was not to rely on the hacks but rely on the w3c standards based markup and css. One of the recent examples was our own site “http://www.webmirer.co.uk” where we have not even used (any) hacks (at all) but the site is looking good. Relying on hacks gives me nightmares, I know where it is going to work, but I dont know where it is not.
We have tested it in IE7 as well and it looks great. No offence but it seems that IE7 is trying to do something which our favorite firefox is doing from its inception. And this shows up definately in our recent stats from our CSSReboot Participation. Whopping 70% visitors use firefox and that really shows up that IE7 had to be a standards compliat browser if it wants to stay.
[…] Many, if not most, major websites are designed with CSS (Cascading Style Sheets). While these sites usually work acceptably well with Firefox, Netscape, Opera, and Safari, to name a few, they often require some workarounds (aka hacking) in order for them to show up decently in Internet Explorer (IE). Of course, most people use IE because Microsoft tells them they should. The result? Most websites with CSS have some amount of hacking done to them to get them to look right. Well, IE7 is coming. What does that mean? Many websites will probably cease to work right on most people’s computers. Why? IE7 is changing a lot of the core code necessary to render pages. Of course, who knows what that actually means, but the folks at Vitamin are warning web developers to start adjusting or preparing for the upcoming changes. There are a lot of folks with a lot to worry about. […]
Just a question about conditional statements. If I create an ie.css sheet, do I have to have all styles for the website or just the ones thar are a little qirky?
Thanks
Well, 3 wks into the CSS fray I eventually settled on conditional comments as the most practical, time saving compromise.
Granted, having to go the extra distance to sate M$’s Frankenstein Monster, IE, may make your skin crawl (particularly if you work on a Mac), but, hey, what ya gonna do?
1. Alot of folks will never upgrade.
2. Alot of companies will never upgrade, or are 5yrs behind the times.
3. Alot of both just don’t care.
And they’re the majority.
So there you are, sitting on the cusp, eyes misty envisioning how CSS will transform the WWW, only to turn around to see the hoi polloi still contented clicking away in the Dark Ages.
“What’s a browser?”, she said. It’s 2006 and she asked me what a browser was. :rolleyes:
Ya know what I mean?
[…] Stop Hacking, or be Stopped […]
Great article, Thanks Dave!
The one question I ask is this: Bill Gates is reported to be the the richest man in the world. On the TV this week they said he was worth 33 Billion!
What % of his fortune would it cost him to tell his minions make IE standards compliant? On most PCs windows updates take place unknown to the user. Why not update old and new versions of IE too as and when bugs become known?
Looking at the picture circulating on the Web last year of the IE 7 design team, just a hand full of folks, and noticing that while they were all holding up 7 fingers, except one who was holding up 8(!), really brought it home to me that this guy and his company are really ‘taking the piss’ (a Brit expression) out of those of us who code for the Web.
Am I alone in feeling this way?
In response to Cris:
And Mark, I simply disagree that forgoi