Ahh, Internet Explorer. For many years now, this browser has been the main cause of stress-related injuries among the web community. Supporting this browser has proven to be one of the biggest challenges for any web designer / developer who has ever had to write one line of html/css/javascript. For many years, IE didn’t really care what the web community thought of it’s product, but since version 7 hit the scene, Microsoft has been devoted towards getting IE to be a solid, standards-aware browser deserving of it’s massive market share.
The big news with IE right now is it’s upcoming release, IE8. Slated to come out “4th quater 2008″ (so… any day now, right?), IE8 is supposed to have a lot going for it from a web developer standpoint. In fact, on paper it almost looks dreamy – the IE team has decided to include a full Firebug-esque debugger console, IE7 emulation, and more. When I was at the Ajax experience last week, the IE team showed off these features briefly in their presentation. From that, I was actually pretty excited about it all, and I couldn’t wait to get back to Zenbe to install it on our PC system and try it out. Even if there were bugs, I thought, it would be okay, because of this IE7 compatibility mode.
Right? Not a chance. It’s IE, after all.
I’ve been playing around with the browser for the better half of the day and I have some interesting results to report, and not really anything good. I made a series of mini-tests, which you can view for yourselves by checking out the simple sandbox site I set up at http://rauenzahner.com/ie8.html. Flipping back and forth from compatibility mode shows the differences, which I’ll detail now.
Test A: *+html is an IE7 thing
This is actually a good thing. Although I haven’t found an IE8-specific css filter yet (if anyone knows one, a comment on it would make you a hero), it’s a bit of a relief knowing we won’t have to rework our IE7 filter fixes into the new release. Or… this could be a bad thing. It depends on your code.
Test B: hover implementation is quite buggy
You know, this is somewhat worrysome. The test is the most simplistic use of the :hover pseudo-class on earth, yet it seems to be quite finicky in IE8. The element seems to require a click before the hover effect will ‘kick in’. It frustrates me when something that previously worked is well.. bunk. Especially when it’s something as simple as :hover.
Test C: transparency support died (much like my hopes and dreams for ie8)
It appears all forms of css transparency support are gone. Correct me if I’m missing something, but I couldn’t figure out how to make it work in IE8 (side note: I wasn’t aware IE7 had limitations where only divs could be rendered transparent… how odd and limiting).
That’s it for now, but there will most likely be additions to this IE8 testing page – I covered the main issues that I encountered today in testing out Zenbe. Also, keep in mind that this is just the html/css rendering… we’re encountering some javascript problems that I haven’t done much exploring into yet, and while there’s IE7 mode for html/css rendering, there doesn’t seem to be an “IE7″ mode for the JavaScript parsing. Oops.
All of this leaves me a bit worried about the upcoming release of this browser, and how it will affect the interweb. I hope the IE team is on top of these issues and can tighten up the release for the launch at the end of this year.
Jade, I’m interested to hear your thoughts on Google Chrome. Do you think it is a real contender? Perhaps you haven’t used it much — ‘cept on Parallels..
I haven’t used Google Chrome much, mainly because of the Windows Only deal it has going on right now, but I see it as a promising browser which still has a while to go.
I love some of the innovations it brings – isolating memory and performance on a per-tab basis – it makes web surfing quicker and application development easier. It takes a lot of what’s good from the different browsers and it really will help advance web browsers in general (in the competition fosters innovation kind of way).
On the other hand, I’m not a huge fan of a few things it does. The biggest issue I have is with their JavaScript engine – they decided to go custom and we’re seeing some problems with our code at Zenbe. Not very big issues, but in my mind, if it works in craptastic IE7, it should work in Chrome. I don’t think they needed to go custom with their JS engine – I see no real reason or advantage to it, and it’s not something I really enjoy dealing with.
The other thing that I just absolutely despise, even though it’s totally minor, is the fact that they use webkit for CSS, but on text anti-aliasing they decided to go “Windows native” instead of using webkit’s text rendering methods. This results in completely unaliased text, which looks akin to IE6 (even IE7 is smart enough to anti-alias text). This just frustrates me because we’re supposed to be moving forward, not backward, and text can very easily look completely gross in Chrome and fine in everything else. So, minor, but a major pet peeve, especially since I can’t imagine why they would make consciously that choice (they said so at Ajax Experience).
So overall, while I think Chrome is going to be good for the web in general, if it came out for Mac today I would be in no rush to get it or use it. And I don’t think that will change.