UPDATE: Paul Thurrott, a Windows journalist, has featured some commentary on our post over at his Winsupersite. Check out his post, and the great discussion below it! Thanks for the input, Paul!
have me concerned that there’s a growing and false notion that IE8 is just great, and its rendering problems are the result of web developers writing non-standard code optimized for IE7.
To understand why IE8 is a legitimate disappointment, we need to start by providing background on how different browsers impact web development, both from a cost and design standpoint. If you think you already have a handle on this, you can skip ahead to our 3 straightforward examples of IE8 disappointments.
Background: Why Different Browsers Matter
In our world of web development, there’s plenty of inside baseball ranting about “inconsistent support for web standards” among the major web browsers: Internet Explorer, Firefox, Apple Safari, and to lesser extents, Opera and Google Chrome. Essentially, inconsistent support for standards means that when professional HTML and CSS developers turn graphical storyboards into actual web layouts, they encounter inconsistent and problematic results when reviewing the same code in different browsers, even when strictly obeying modern standards.
To make matters worse, catering to browser market share can mean catering to an 8 year old browser, released before some of the best standards were even drafted (I’m looking at your Internet Explorer 6, and your 25% share).
Professional web developers work around inconsistent standards support in two ways. Well, two and a half ways.
When it comes to the modern browsers (IE7+, Fx2+, Safari 3+), we mostly cater to the lowest common denominator. For example, Safari supports on the fly rendering of font shadows, but IE7 and Firefox 3 do not. As a result, if the design calls for a heading with a shadow, we have a choice: spend time and money creating (and maintaining) images for all of these headings, or walk back the design. Either approach is a degradation in potential value. The most infamous example of design / browser trade off is font type, which we’ll discuss in our examples.
Alternatively, developers can write alternative code based on the user’s browser. With the “modern” browsers, there are only a few reasons to do this (at least for capable developers), and most of those special lines of code do not conflict with each other or add significantly to the code’s heft (as we’ll discuss in our translucency and rounded corners examples). In the case of one IE6, however, there are so many inconsistencies and glitches that almost every site we develop has a special stylesheet only for IE6 users. It goes without saying that this adds time (=cost).
The “half way” is not so much a way of addressing the differences as it is a way of accepting the differences. That is, the notion of “failing gracefully.” The idea here is that if a browser like IE6 simply can’t support a non-critical feature (a “nicety”) without significant additional cost and effort, we may elect to leave a feature out, so long as it does not seriously degrade the user experience (while providing some value for 75% of the audience).
For example, if a WordPress administrator looks at the admin console from within IE6 or IE7, you’ll notice that the containers have sharp edges, which appear rounded in Firefox and Safari. As we’ll discuss, Firefox and Safari support a rounded corners style that makes it quick and painless. Adding rounded corners to IE6+ is considerably harder, and really, the cost of this value-add is not in sync with its end user value.
3 concrete examples of how IE8’s “behind the times” standards cost time and quality
Here are three very simple examples of standards IE8 still does not support, and what they mean for cost and design potential.
1. Rounded corners made simple
The first example is a favorite, because it’s a perfect illustration of a feature that can be added very quickly and easily in current versions of all major web browsers except IE8 and earlier, with a time consuming “lowest common denominator” solution.
To the right, you can see an example of a sidebar element from a site currently in development. Notice the rounded corners, both around the containing box, and the box heading. With Firefox, Safari, and Chrome, we were able to use the “rounded-corner” attribute (using non-conflicting browser specific attributes to ensure rendering) to do this quickly, and in a way that is easy to maintain. Here’s the CSS for the containing box:
div#sidebar div.module {
margin-bottom: 13px;
padding: 3px;
border: 1px solid #939393;
-moz-border-radius: 5px;
-khtml-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px;
}
We specified a general border style; 1 pixel thick, solid (as opposed to, say, dotted), and with a hex color of 939393, which is a shade of gray. To give it rounded corners, we specified a “border-radius” of 5 pixels. As we indicated, we included browser specific versions of the border radius property (i.e. -moz- for Mozilla Firefox) to ensure compatibility with some versions of those browsers that included their own implementation of rounded corners before the formal standard was finalized.
For the heading, we did something similar, and added a 1 pixel wide x 25 pixels tall background image (the gradient dark to light gray gradient), and had it repeat horizontally.
div#sidebar div.module h3 {
color: #fff;
font: 1.4em Tahoma, Geneva, sans-serif;
background: transparent url(images/sidebar_h3.gif) repeat-x;
-moz-border-radius: 3px;
-khtml-border-radius: 3px;
-webkit-border-radius: 3px;
border-radius: 3px;
height: 25px;
line-height: 25px;
overflow: hidden;
padding: 0px 10px;
}
To the right you can see what this looks like in IE8 (and earlier).
In this specific instance, the client decided it was not worth the extra expense to provide rounded corners to IE users. There are a few different approaches we could take, had we chosen to cater to the lowest common denominator. All of them, effectively, involve cutting up images with rounded corners. Below you can see one rough illustration of how we might have approached that.
Whereas the CSS approach probably would have taken a few minutes to create, and a few seconds to tweak or change later, the IE approach takes many times longer to piece together, and nearly as long to make any notable change. And Lord help you if you need to make changes and you lost your source image files!
Those of you using IE right now, take heed. Expect more web developers with cost-conscious customers to “cut corners” (pun intended) with IE, and slightly degrade your experience.
2. Achieving some overdue font diversity
The biggest disappointment of creative designers everywhere is the lack of support for anything other than a handful of standard fonts for website copy (outside of kludges like sIFR, or images, neither of which are prudent outside of some headings). Therefore, there has been some excitement around the recent emergence of a new style property, “@font-face”, that will allow developers to support almost any font type in the future (although I admit I can already anticipate the licensing abuses and headaches).
Safari already has support for this property in its current release, and improves support in the Safari 4 beta. The forthcoming Firefox 3.5 (at beta 3, still dubbed 3.1) also adds full support. Here’s what the style definitions might look like to set a font for the entire page:
@font-face {
font-family: "Alaska";
src: url("bralarc0.TTF") format("truetype");
}
body,td,th {
font-family: Alaska;
}
Here’s how this looks in Firefox 3.1 beta 3 (what will become Firefox 3.5):
And here’s Internet Explorer 8:
Now, to be fair and honest here, Microsoft does support a limited implementation of @font-face (and actually has for a long time).
The first problem is that IE8 only supports the completely proprietary “Embedded Open-Type Fonts” (EOT) format, whereas everyone else uses the common “True-Type Font” (TTF) standard as well as the “Open-Type Font” (OTF) PostScript standard. So frustration #1 is getting fonts into the Microsoft-only EOT format. Microsoft does provide a nightmare of a and IE8 opacity filters)
Why, exactly, this is disappointing
Productivity and economics, not necessarily today, but 2 years from now. It’s that simple.
As stated in the introduction, catering to the lowest common denominator means either taking more difficult approaches to product realization (time=cost), or removing desired features, at least for a portion of the audience (value reduction). Rounded corners is a great example of either possibility, and the font type is a great example of the latter. And remember – there are many more examples; these are just 3 of the most practical and concrete use cases developers like us deal with almost every week.
Now, regardless of fixes for issues like translucency, IE8’s impact in the short term is minimal. If you believe the statistics, IE users are the least likely to upgrade quickly anyhow (I suspect this is because most of the share, particularly of IE6, comes from business computers and slow to upgrade IT departments). IE6 and IE7 are a reality in our web development lives for the immediately foreseeable future.
What’s most disappointing is thinking about where we’ll be in 2 years.
The 6+ year stagnant development cycle between IE6 and IE7 was an understandable if regrettable consequence of their dominance of the web business, after driving Netscape out of business. With serious competition from Firefox, Apple’s Safari, and now even Google with Chrome, there was hope that Microsoft would be far more aggressive with IE8. The hope was that this aggressiveness would push the browser makers to standards oneupmanship (which we are getting from Apple and Mozilla), resulting in platforms and market share that, 2 years from now, would erase many of the obstacles web developers face in pushing design and development value to their limits.
We hope that Microsoft doesn’t wait another 2 years to build on IE8. Perhaps IE8 represents a baseline for a rebuilt underlying engine, and they can push out “point” updates (IE 8.1) more quickly that add better and more modern standards support.
That said, right now, far from being an innovator and challenger in the web space, Internet Explorer has become a hindrance to progress. I’ll go out on a limb here – if they just can’t keep up with the folks behind WebKit (the Chrome/Safari engine) and Mozilla (Firefox’s engine), maybe it’s time to abandon their own rendering engine and adopt an open platform like WebKit themselves.
Non of these are fully signed off “standards” so to question a browsers dedication to standards compliance on this bassi is flawed microsoft bashing. The Acid2 tests are a great example of how far IE8 is ahead of IE7, and the simple inclusion of “Compatibility Mode” allows IE8 to move towards better standards compliance without writing off sites written with IE7 as a target. Please get off your high-horse and acknowledge the improvements that have been made more honestly!
CSS3 will add various things like rounded corners, but until it’s standards are agreed then bashing non-compliance is a deluded misrepresentation! The simple practicalities of trying to provide a consistent browser, rather than a constantly patched and updated browser like open source offerings, is not appropriate for supporting non-standards that may be agreed in the future. You have to also include that firefox users may not install every update, at which point the firefox support for these issues is not 100% either, and the same pretty well applies across all other browsers. As a web developer I’d rather have more fixed targets with strong version levels than trying to support suggested features and having to explain the difference between Firefox 3.0, 3.1, 3.1.2, etc. and ensuring that all users are supporting the latest micro-version of a browser for some new feature!
James,
Thanks for your input. I’ve approved your comment in the interests of engaging discussion (which I welcome) on the subject. In the future, please avoid personal attacks on my “honesty” if you want your comment to be published (“deluded”, “high horse”, etc).
While it’s true that CSS3 is still technically a “draft” spec, there’s really no question as whether styles like “opacity” and “border-radius” are going to be formalized. Saying Microsoft should avoid these specs is really as ludicrous as suggesting that Cisco should avoid compatibility with the N-wireless spec since it’s not yet formally ratified.
In any case, I think you’ve missed a key point.
No one denies that IE8 is a step forward in terms of, really, the *minimum* standard any browser should be expected to meet (CSS2). The point is that Microsoft seems to update their browser on a 2+ year life cycle. Having to wait 2 more years before we web developers can use great CSS features like border-radius, font-face, and opacity is, as the title suggests, disappointing. There is nothing innovative about IE8 (can you name one new development innovation?).
“As a web developer I’d rather have more fixed targets with strong version levels than trying to support suggested features and having to explain the difference between Firefox 3.0, 3.1, 3.1.2, etc. and ensuring that all users are supporting the latest micro-version of a browser for some new feature!”
Let’s note that Firefox and Safari, as examples, have supported properties as basic as opacity for several versions now. These are not “micro-version” features.
Rafael Rivera, a well known and respected Windows writers and enthusiast made this comment in response to some discussion on my post over at a Winsupersite, and I think it sums up my point quite nicely:
Jake,
Going into your article, I was so sure you were just another web developer bitching about bleeding features not present in Internet Explorer… but refreshingly, I was wrong.
I think we can all agree Internet Explorer 8 is a big step in the right direction in terms of standards support, but 2 years from now, like you mentioned, it’ll be around — stifling innovation. Yet again.
That said, word is Microsoft will be trashing Trident and going either Webkit or Mozilla. Hard to swallow right now, I know. We’ll just have to wait and see.
That’s the point.
Hi there!
Concerning opacity, what about:
#whatever
{
-ms-filter:alpha(opacity=80);
-moz-opacity: 0.8;
opacity: 0.8;
}
looks okay to me?!
Kind regards,
mtness
IE8 sucks big deal. Of course it is better than IE7 but there is no way we can say that IE8 is better than Safari, Opera, Google Chrome or FF. In my opinion FF is still the best followed by Google Chrome. Another piece of #$%@ produced by MS. Have said that, I think that Internet Explorer is the Vista of Web browsers.
I know this is off topic but you seem to know a lot about cross browser compatibility
so could you help me use rounded edges which would run on all browsers.
Thanks
Atul – the only way to do rounded edges in a cross-browser way is to use images for the corners. There’s more than one way to skin this cat, but essentially, you’ll need an image at the top, and an image at the bottom. Absolute positioning two images in a relatively positioned box (bottom: -1px, left: -1px and top: -1px, left -1px to account for the border) is the way to go.
If you want us to help you implement a layout with rounded corners, use the “request a quote” button!
Very good analysis.
Although the developers of IE8 appear to be intent on making IE as good as it can be, I still doubt that senior management have fully given up on the “embrace, extend and extinguish” mentality – http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
Also, it’s worth remembering that if it weren’t for a massive outcry from web developers, MS would have made IE8 standards-compliant only with inclusion of a proprietary switch in your code – bizarrely and wrongly supported by Zeldman.
P.S. Kudos on allowing the first aggressive and rude comment. It’s curious the way some people attempt to defend in the indefensible.
David – thanks for the feedback.
There’s no doubt that IE8 is a step in the right direction. While I’m pleased that they’re *more* aggressively enforcing standards, considering this praiseworthy feels a bit like complimenting the misbehaving child for finally engaging in the minimum acceptable behavior.
There’s some indication that we may not have to wait another 2+ years for an upgrade. Apparently Microsoft is already publicly soliciting feedback for IE9 development. Let’s hope it’s a sign that they’re moving quickly.
[...] The benefits of course out-weigh the problems and @font-face is surely a nice tool to have under our belts. Hopefully our solution, or a similar one, can be created or we will just need to weed out the new breed of “animated gif” type Websites which will mutate to crazy, illegible, not-good-for-screen fonts that will start appearing. In the end, it will all be good, that is of course if we forget about IE since “to achieve custom font faces in both IE8 and with every other browser, one has to write special, IE-…” [...]
I love Microsoft, but any web developer who works extensively with HTML, CSS, and JS can tell you that their line of Internet Explorer browsers is a massive headache. I don’t think it’s going too far to say that people who disagree simply aren’t writing that much code and don’t have enough experience to know what they’re talking about.
The fact of the matter is that Internet Explorer 6 held the web back for years. Thankfully browsers like Firefox and Opera came along that were quite friendly to us web developers, and we were all expecting Microsoft’s next browser to live up to the standards set by its competition. IE7 did no such thing. Not only did it take forever to be released, and not only was it far behind its competition, but most IE users didn’t even upgrade… they just stuck with IE6, so it was like nothing happened at all.
Now, after enduring additional years of painful web development due to these antiquated browsers, IE8 arrives and doesn’t even support standards that other browsers were supporting years and years ago. Great, now we’ll likely be waiting until 2011 to get an IE that supports standards other browsers were supporting in 2007. And given their recent track record, IE9 will probably be outdated the second it’s released.
The IE team is simply too indecisive and resistant to change. If they would have gotten modern and stepped up to the competition with IE7 then yeah there would have been some short-term compatibility problems, but by now things would be fine and everyone would be happy.
“…opacity, a CSS 2.1 standard “: The property ‘opacity’ IS NOT a CSS 2.1 standard, it’s a CSS 3 standard.
–
Taken from the W3C CSS Validator Service:
***
W3C CSS Validator results for file://localhost/TextArea (CSS level 2.1)
Sorry! We found the following errors (1)
URI : file://localhost/TextArea
1 body Property opacity doesn’t exist in CSS level 2.1 but exists in [css3] : 5
***
***
W3C CSS Validator results for file://localhost/TextArea (CSS level 3)
Congratulations! No Error Found.
This document validates as CSS level 3 !
Valid CSS information
body {
opacity : 1.0;
}
***
Ricardo – you’re correct. The statement that it’s 2.1 was incorrect. The essential point that some reliable variant has been available in all browsers sans IE (and plain “opacity” is now the latest versions of *all* browsers sans IE) remains true.
We’re working on an update to this post to reflect where things stand now, with the release of Chrome 2, Firefox 3.5, and Safari 4 final. We’ll incorporate a correction in that update.
Well, it is so true.
Each day , while I work on css , same wonders cross my mind :
Correct me if I am wrong, if I say that IE was one of the first of its kind in the history of Internet
…could be even called a Dinosaurus…With Years of existence, talented developers, huge budgets etc…etc…
and here we are with some odd and very very annoying bug stories, no compatibilities and such but such a LOSS OF TIME .
Google is overcrowded by posts, topics, threads about this matters.
When Meanwhile…
recent browser vendors became fast compliant and are obviously doing their best to make our lives easier and logical.
Sorry, but cannot understand this non sense and dream of a day when users would boycott IE.
Cheers,
[...] Ask any web developer what they think of Internet Explorer 6 and you’ll hear an earful. The 8 year old web browser still commands nearly 20% of the browser market and is woefully inadequate at supporting modern standards, incurring millions of dollars for legacy support every year. IE 7 and 8 were big improvements, but as we’ve opined on before, even IE8 fails to support forward looking techniques supported by the competition. [...]
[...] Issues with IE8 and Web font rendering [...]
Oh it’s worse than all that mentioned above.
My web application is completely unusable in IE8 with volatile, random and inconsistent broken Javascript and CSS issues (it’s as if IE8 throws a pair of dice to pick a JS or CSS file not to load each time you visit or refresh). It’s not due to JS companion, not even the presence of the IE7 emulation tag helps (unless it’s running on localhost for some asinine reason that I am obviously way too stupid to comprehend).
One more thing, my web app runs exceedingly well on Chrome, Firefox, Safari, and Opera. No errors or issues what-so-ever.
I do not support improving Internet Explorer at all. I support permanently eradicating the blasted piece of detritus from the web community for all eternity.
Just found out that the support of custom fonts in IE8 is terrible… the fonts are loaded at random – sometime they are, sometimes they aren’t…
Works perfect in other browser.
Well see ya later, I’m busy writing a stylesheet for Explorer with boring fonts …
[...] Recently, we’ve seen the emergence of support for the “@font-face” property across all web browsers. This property allows developers to point the browser to a font library which visitors can then use as if it’s a native font. Think of it like embedding a font in a document. Perfect, right? Well, although Internet Explorer has actually been the longest supporter of @font-face among dominant browsers, it has its own proprietary implementation, and developers confront a conversion process (we highlighted this @font-face challenge when we expressed our disappointment in IE8). [...]
I am really fed up with having to check my websites through Internet Explorer to make sure they look ok. I dont want to tell you the amount of hours I have spent trying to get a fix so that the CSS displays properly in IE.
My latest headache is getting a simple table to display 100% height. Works fine in all main browsers, including IE7, but when viewing in IE8 its the same old issues again and again.
It would be great if we could block anyone using IE from using your site, and get them to download Firefox. However by doing this we alienate 70-80% of the users. This is why I find it annoying.
Microsoft is lacking innovation. IE-browsers suck so hard.
I just hate everything about MS…
[...] remember that with web technology, as we highlighted in our IE8 disappointments article, we developers can only move as our audience is willing to move. Almost 20% of users still browse [...]
excellent article
as most real developers, i’ve not been a fan of the “gates of hell” since the beginning. now, with this .net c# and other ms crap, it has made this a miserable business, unless, of course your working for satan himself. unfortunately, ignorance runs the world…
Tom – I have no real issue with C# and .NET, although their default front end output leaves a lot to be desired, and its not my personal preferred platform (though we do have some .NET / C# experts in house). It’s the front end technologies where Microsoft — and corporate IT departments that won’t push upgrades — hold up progress. Fortunately, IE9 looks like a huge step in the right direction. Too bad many businesses *still* running IE6 probably won’t upgrade.
This blog helped me in narrowing down some problems with the latest version, Why do they always seem to leave out vital documentation when they release a new version? It may be minor to them but not for us! I’m sure i’m not alone either.
Not only IE8 is lacking many standards, it runs like crap compared to FF, laggy scrolling and slow js animations.
Sometimes it pushes my E8400 to 50% just by opening a big lightbox.
@James Burton
Jake Goldman is spot on with these examples and is on no “High Horse”. IE WASTES my time by requiring me to conform to their irregular methods.
Perfect example:
Looks OK in Fire Fox 3 (1)
Featured Blog Posts
Contact Us
phone
fax