This is the story of how SitePoint tried to give Internet Explorer a fighting chance … and it lost anyway.
If you’ve been paying attention, you’ll have caught the subtle (and not-so-subtle) hints that SitePoint has been quietly working on a series of references, beginning with The Ultimate CSS Reference.
What hasn’t been revealed (until now) is that this reference will be released not just as a slick SitePoint book, but also as a freely-accessible Reference section right here on sitepoint.com! Our aim with this project is to produce the definitive CSS reference, both on the Web and in print.
Obviously, a big part of assembling this reference has been compiling browser compatibility information. And although our hard-working authors might disagree, one of the trickiest parts of the project has been determining how that information should be presented.
The Inherit Issue
A good example of this is the inherit value, which according to the spec is supported by all CSS properties. A little over a year ago, David Hammond’s site that rates browser standards compliance generated an uproar on Chris Wilson’s blog when it counted the lack of support for inherit as a point against IE for each and every CSS property.
Our reference will similarly indicate the level of support for each property in each of the major browsers, but what level of support do we indicate for IE, which doesn’t support the inherit value? Do we count this as a failing in IE’s support for each and every property, or do we set that aside as a single unsupported feature, and rate IE’s support of properties in the absence of inherit?
On the one hand, declaring that IE fully supports a property when one of its supported values doesn’t work could be seen as misleading. On the other hand, if the best support level we can list for any property in IE is ‘partial’, then you can’t tell at a glance when IE does fully support a property (within the limitations of its CSS implementation), and our reference becomes that much less useful.
After lengthy discussion with the authors, we decided to treat inherit as a separate unsupported feature, and to list properties that would work perfectly in IE if not for inherit as fully supported. The vote was certainly not unanimous, but I felt like we were doing the right thing by IE—giving the work that Microsoft did in IE7 a chance to shine.
Except … it didn’t
In ignoring inherit when rating property support, our intention was to enable the many newly-supported CSS features in IE7 to show up in our compatibility tables.
After all, IE7 now supports position: fixed across all elements, completing (except for inherit, of course) support for that property. And IE7 introduced plenty of other new features, such as support for the child selector (>). It would be nice for our compatibility tables to reflect this, we thought—naively, as it turns out.
Once the authors had compiled all this compatibility information, what we discovered was that arguing about the difference between ‘partial’ and ‘full’ support in IE had been an academic exercise … because the vast majority of CSS features are too buggy in IE to rate either!
The position property does support fixed in IE7, but setting this property to anything but static causes that browser to mess up the stacking of overlapping elements by incorrectly establishing a new ’stacking context’, so we are forced to rate this property as ‘buggy’.
And Microsoft did implement the child selector as a brand new feature in IE7, but even in this golden age of standards, this new feature came with obvious parsing bugs (e.g. A > /* comment */ B will fail to work).
After racking my brains for a CSS feature that would have newly achieved ‘full’ support in IE7 without being afflicted by bugs, I happened upon the dimension properties. width and height had serious bugs fixed in IE7, and IE7 added support for min-height, max-height, min-width, and max-width. And as of the current draft of our CSS reference, these properties are listed with ‘full’ support in IE7! Hooray!
Sadly, a little research has revealed reports of a bug in IE7 that affects all of these properties. We have yet to confirm this bug, but if it’s the kind of thing that will impact real-world use of these properties, they’ll lose their ‘full’ rating as well.
Internet Explorer Still Stinks
All this adds up to Internet Explorer making a very poor showing in our compatibility tables, despite us going out of our way to give it a fighting chance.
CSS features that we can honestly list as having ‘full’ or even ‘partial’ support in IE are few and far between (color is one, font-size is not). Most of them are ‘buggy’, even in IE7 … and we expect even more IE bugs to come out of the woodwork once we release the Web version of the reference for public comment.
Obviously, with IE7 Microsoft made great strides in correcting the most glaring and painful issues that plagued developers in IE6. But the unavoidable truth revealed by this reference is that Internet Explorer is still miles behind the competition.
Perhaps the new layout engine and other improvements coming in IE.Next will make up some of the difference … or perhaps Microsoft just isn’t interested in fixing (and in the case of IE7, avoiding) bugs that aren’t painfully obvious.
This article provided by sitepoint.com.
![]()
Share This
There were whispers of an online storage project by Google in the past, and word has it that this project is about to be unveiled pretty soon. The gDrive project as it is known is actually a service that enables users to store their essential information on a virtual hard drive. While no concrete details are available, it seems that internal documents have referred to the gDrive as “My Stuff” and “GDrive” on numerous occasions. Currently, additional Gmail and Picasa storage cost anything from $20 per year for an additional 10GB and up to $500 for a whopping 400GB of space. I don’t know about you, but the completed gDrive ought to come with 100% compatibility with Google’s other Web 2.0 applications.
Courtesy Adasa.com 
Entries (RSS)