Slashdot Mirror
Opera Claims Microsoft Has Poor Interoperability
Noksagt writes "Opera CTO Hakon Lie has countered the claims that Bill Gates made regarding Microsoft's superior interoperability last week. He points out their invalid webpages, MS's unwillingness to serve the same content to different browsers, IE's poor CSS support, tardy documentation and limitations of their XML format, and more." From the article: "You say you believe in interoperability. Why then, did you terminate the Web Core Fonts initiative you started in 1996? You deserve credit for starting it, but why close down a project which could have given you yet much good will? (Verdana sucks, but Georgia is beautiful!)"
Dave Hyatt, who writes a blog about his development on Apple's Safari, has an amusing anecdote about developing CSS2 support in Safari, and how IE's piss-poor support of standards forced him to remove it in Safari.
From the blog:
"Sometimes trying to support the standards can be a real pain.
While trying to improve our CSS2 compliance, I recently did a big cleanup of our block layout code, including the code for handling floats. I made what I believed to be a fairly innocuous correction to follow the CSS2 specification. Here's the scenario.
Lets say you have a div that is set to 300 pixels in CSS. You then put a 250 pixel wide float inside that div. Immediately after that you have a 100 pixel wide overflow:hidden div. All sizes have been specified in CSS.
Now here's the pop quiz. What do you think the layout should be? Should the overflow div:
(a) Be on the same line with the float and spill out of the enclosing 300 pixel div
(b) Be placed underneath the float, automatically clearing it because there is insufficient space for
the overflow div next to the float
Before I give an answer, lets see what the CSS specification has to say on this issue. Section 9.5 on floats, fifth paragraph.
'The margin box of a table or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space.'
My interpretation of this language is that there must be sufficient space for the table or overflow:hidden element to fit within the containing block. If not, you should clear. That's what I implemented. So in my opinion the correct answer to the question above is (b).
I decided to see what other browsers did. I started with Gecko. Gecko chose (a). Gecko always does (a). It is at least consistent if - in my humble opinion - incorrect. Gecko chooses (a) regardless of whether you pick strict, almost strict or quirks mode.
Next I tried WinIE, and this is the part that blew my mind. Depending on whether the float was an image or a table, the float was left or right aligned, the table specified that it floated via the align attribute or the float CSS property, and on whether or not the normal flow element was declared as a sibling or not of the float, I could get completely different results! The level of inconsistency was astonishing.
I was able to watch WinIE do clipping in one case, to wrap in a second case, to not wrap in a third case, to overwrite content in a fourth case, all by just tweaking the parameters outlined above. It's no wonder Web designers have no idea how to code a page to standards when they have to deal with a layout engine that is so horribly inconsistent and buggy.
Naively I opted to implement (b) and to hope for the best. Unfortunately the bugs immediately started pouring in. finance.yahoo.com was broken for example because it used an old-style align table and relied on it not wrapping underneath the float. Undaunted, I simply added a strict mode/quirks mode check and opted to do (a) in quirks mode and (b) in strict mode.
The bugs kept coming in though. Next was versiontracker.com, a page that is actually in strict mode and relies on an overflow:hidden div to spill out of a containing block rather than wrapping.
So now I really have no choice. This is an example of where the CSS2 standard simply can't be followed because buggy layout engines have set a bad precedent that the rest of us have no choice but to follow.
It's a shame that Gecko does not do the right thing in strict mode at least, but I suppose they had no choice in the matter either."
And more info here, where the Opera crew explains how M$ deliberately cripples www.msn.com pages.
Robert Scoble, Microsoft's chief humanising officer has posted a response to Hakon's letter.
Apparently, they are working hard to fix it in IIS 7.0 and the next version of ASP.NET.
Apparently.
Ziga
I'm working on my first .Net project at work, where I have to provide compatible HTML. We spent three hours figuring out all the oddball stuff .Net does to HTML, then I spent a day writing up documentation on it. During the documentation review, we opened a demo page in Mozilla instead of IE, and all the Panel-control-created div tags were replaced with table sets. Imagine our surprise.
As we started digging, we started finding lots more stuff like this; for example, tables get a style of "border-collapse: collapsed" by default in IE, which is a tag that IE uses to tighen up table structures (into non-standard measurements) while other browsers ignore the tag. There's no reason for this tag to be there, except to guarantee that tables will look different in IE as compared to other browsers.
The punch line, of course, is that this "feature" can't be turned off. So now we either have to burn a lot of extra effort to validate multiple sets of rendered HTML, or we have to give up alternative-browser compatibility -- which I am sure was the point in the first place.
(few things microsoftie make me seethe, but this one does...)