Surfin' Safari

Versioning, Compatibility and Standards

Posted by Maciej Stachowiak on Tuesday, January 22nd, 2008 at 11:51 pm

The new IE8 version targeting switch, announced on IEBlog and A List Apart, has been the talk of the web. Some web standards experts, like Eric Meyer and Jeffrey Zeldman see the switch in a positive light. Others, including Dean Edwards, Robert O’Callahan and Anne van Kesteren think the proposal is a bad idea.

We don’t talk much about what other browsers are doing on this blog. While we’re happy to collaborate on web standards and testing, and sometimes share a little friendly rivalry, we try to keep our focus on making the best Web browser engine we can, not on the competition. So we’re not going to give in-depth commentary on the IE team’s decision. Straddling compatibility and Web standards is a tough job requiring tough choices.

However, some have asked if other browser engines, including WebKit, would adopt a similar version switch. For example, the original announcement asks, “I, for one, hope other browser vendors join Microsoft in implementing this functionality.” I can’t make any definitive statement for all time, but such an approach does not seem like a good idea to us currently. Why, you may ask? There are a few reasons.

Mode Switches in WebKit

WebKit, like most browser engines, has a quirks mode that is triggered by certain old HTML doctypes, or lack of a doctype declaration in text/html. Documents with newer or unknown doctypes, or sent as XML, are processed in standards mode. Like Mozilla and Opera, we apply only a limited set of nonstandard behaviors in quirks mode, and otherwise fix bugs across both modes, if they do not have a specific significant impact on Web compatibility. This is in contrast to the IE approach of completely freezing old behavior in quirks mode.

We actually have a few modes besides that. A handful of doctypes trigger what is called “almost standards mode”, which is standards mode with one minor deviation, mainly affecting how images lay out in table cells; this is copied from Mozilla. In addition, we have a few rendering and DOM differences between documents served with an XML MIME type and those served with an HTML MIME type, but we are trying to reduce these over time. And finally, we have a Dashboard compatibility mode that has a few extra quirks beyond quirks mode, to handle Dashboard widgets that were coded to depend on old WebKit bugs.

Maintainability

As you can see, this is quite a few modes already. Having lots of modes raises a number of challenges for maintaining the engine.

First, the more different modes there are, the harder it is to fully test the engine. We have an aggressive approach to automated testing, and our layout tests often find critical problems before they are shipped or even checked in. Having more modes means many things need to be tested in multiple modes. So that’s more tests, more time for developers to run the test suite, and more chances of missing code coverage, especially when different modes interact.

Second, implementing mode switches hurts hackability of the code. Hackability is one of our core project goals. It’s part of the reason new contributors can dive in quickly, and enables us to rapidly develop new features, while improving performance, stability, and security.

There’s two plausible ways to add more modes. One is to make all engine changes conditional on a version flag. Another is to have a whole second copy of the layout code. Either would be a huge additional barrier to entry for developers, and would make it harder to maintain the code.

So, bottom line, we’d like to see fewer modes, not more.

Mobile-Readiness

In addition to maintainability, an important feature of the WebKit engine is the ease with which it is deployed on limited-capability devices such as mobile phones. Some of the more prominent examples include Nokia’s S60 Browser, Apple’s iPhone and iPod touch, and Google’s Android platform. These and other products all include a full-powered version of WebKit, no compromises.

However, having more mode switches cuts against this. The extra code (possibly whole extra copies of the engine, at the very least a whole lot of extra if statements) would be a significant burden on mobile devices. It’s not very well aligned with our mission of staying lean and mean.

Commitment to Standards and Interoperability

Yet another reason we feel more mode switches are not a good idea for WebKit is our commitment to Web standards, and to interoperability with other browsers. We strongly believe that Web standards are the path forward for interoperability, and we work closely with Web standards groups and other browser vendors to align behavior.

Part of this commitment is delivering standards-compliant behavior out of the box. We don’t ask you to set a special preference, or to add extra markup to your web page, or anything else beyond the long established standards mode switch. That means WebKit can truly pass standards-based tests like Acid2 and someday the forthcoming Acid3, and we’ll work more like other standards-based browsers over time. In general, web developers are happy to get automatic ever-advancing standards support from our engine, and indeed our support for advanced CSS3 properties has unleashed a wave of creativity in iPhone web apps.

Reducing Engine Fragmentation

Another key reason to avoid more modes is to reduce the number of different compatibility profiles that web content authors have to deal with. With many different vendors shipping WebKit-based products, we rely a lot on the fact that uptake of WebKit-based browsers is really fast. Already many web developers are focusing primarily on Safari 3 and not Safari 2, because in only a few months the majority of users have upgraded.

But locking in compatibility would mean you have to think about the compatibility profiles of old browsers a lot longer. And no one wants to think about the state of the engine in Safari 2 – I sure don’t! We made thousands of fixes and improvements and those fixes deserve to stick.

We Don’t Really Need It

Finally, while we sympathize with the tough road that the IE team has to travel to achieve a high degree of standards compliance, we haven’t really experienced the same problem. The IE team has mentioned severe negative feedback on the IE7 release, due to sites expecting standards behavior from most browsers, but IE6 bugs from IE.

But WebKit already has a high degree of standards compliance. And we are not in the enviable but tough position of being the most widely used browser. The fixes we do for standards compliance rarely cause widespread destruction, and when they do, it’s often a sign that the standards themselves may need revision. We do not get complaints from web content authors about their sites breaking, on the contrary we get a lot of praise for each version of the engine handling web sites better.

Conclusion

So, in conclusion, we don’t see a great need to implement version targeting in Safari. We think maintaining multiple versions of the engine would have many downsides for us and little upside. The IE team is, of course, under different constraints and free to make their own choices.

14 Responses to “Versioning, Compatibility and Standards”

  1. jeremedia Says:

    Independent of this specific article’s content, I have to mention how much I appreciate your insightful , well written commentary on this important subject. The web is one of the most important technologies humanity has ever developed, and your decisions have real impact. Big thanks for taking the time for helping us better understand your choices.

    This comment may be a bit overwrought, but I am sincere. :)

  2. Niko Neugebauer Says:

    I do not believe in version targeting: every version will have errors beyond expectations and specific targeting will ensure in a lot more problems. I think that content should be dependent on the HTML standard and not on the specific browser. Lets say i create my new super browser and will make all developers include it in their pages – sounds stupid.

    One special case where i understand this need is in IE8 – way too many people “suffered” with IE7 because they did not do their homework, and this time Microsoft wants to play for sure. I understand this, but i do not agree with the vision that it might work for the future and for everyone.

  3. dreimiller Says:

    Is there a way to determine which mode Safari is using to render a particular web page? Seems to me there ought to be a way to determine that, perhaps something in the Debug menu that I’m overlooking.

  4. Mark Rowe Says:

    @dreimiller: File a feature request for Safari.

  5. Kody Bryson Says:

    It’s an interesting problem that IE faces. Microsoft gets a lot of push from people, usually IT departments with no budgets or people to change anything for backward compatibility. It’s not cnet.com or digg.com that wants it, it’s Bob in AT&T’s IT department and other Bobs all over the world that have web documents that haven’t been touched in 5 years. Bob has an environment that’s exclusively Windows and IE so there was no need to test against standards or other browsers. In fact the HTML in Bob’s organization is probably malformed would make most web developers cringe. Bob has made a mistake, but a very human mistake busy IT departments make every day.

    Apple doesn’t (yet) let itself get held back by this as much. They’d probably like to have this problem, but since they don’t they’re growing as a company and Safari as a web browser very fast. Microsoft is stagnating. It’s very hard to make change happen inside Microsoft now. You can make half a change because the people inside Microsoft talk a good change. But then there’s always the painful compromise. This meta tag is the painful compromise.

    In a way you can’t blame Microsoft. They have market share to maintain and the current climate already promotes change away from Microsoft. However there will be a breaking point. The code will get too complex and change will be further limited. Firefox and Safari will be faster. People will just slowly switch to get away from meta tags. Microsoft doesn’t understand that essentially they have no choice but to issue a kind apology, html translation tools, and some tough love to their customers. It’s either that or die. Sounds like hyperbole, but believe me, it isn’t. Keep watching.

  6. squareman Says:

    Regarding the “bobs” in IT: Maybe MS should just provide a new application called “Intranet Explorer” and go ahead and make Internet Explorer 8 a proper Web player.

    Frankly, I’m hoping all this bloat of providing multiple engines will just make other browsers more attractive. Go for it Microsoft! ;)

  7. NtroP Says:

    In a way you can’t blame Microsoft. They have market share to maintain and the current climate already promotes change away from Microsoft.

    I disagree. Microsoft is entirely to blame for their predicament. It was their decision to intentionally break standards in order to leverage their position in the market to stifle any competition and force the world to use their twisted offerings. The amount of pain and suffering we web developers have been put through because their arrogance has ensured each and every one of their developers and management their own special place in Hell.

    They made their bed, now they must lie in it. They are losing market-share and mind-share. As soon as this reaches critical mass, even those poor souls who live in a completely isolated MS world will realize they’ve been the laughingstock of the rest of the industry for years. In fact, as I was writing this one of my coworkers came in to ask why something wasn’t working in their browser while it worked fine for their secretary. While I was digging for more information the secretary came in and said: “I figured it out. You are using IE. You need to use FireFox or Safari…”

    I’m so proud of her! Even my boss, who is a die-hard MS supporter has come to the sad realization that using IE is just more trouble than it’s worth when compared to FireFox. The forced upgrade from IE6 to IE7 and the problems that it caused was the first nudge. The policy that all future internal and external web documents were to be standards-based and section 508 compliant was the next blow. It didn’t take long for her to realize all the work that was required just to make allowances for IE when preparing the documents for *all other browsers* was trivial.

    I used to be a Microsoft developer. As long as you never leave their sheltered little dystopia life is great – they really do offer a good suite of self-referential products. It reminds me of the movie Pleasantville. When I was working exclusively in that environment I was I was happy. Ah well, we were all young and foolish once.

    I didn’t mean to turn this into a rant. I appreciate the level-headed tone and clear thinking in the article. I guess I just have a visceral response this topic. It’s like the revelation that I had when I started working outside the MS fold. I felt like the old, pious, priest that finally got to see the original, hand-of-God, version of the Bible that all other copies were made from, only to come weeping from the secret room saying “It’s CELEBRATE!”

    Anyway, great article.

  8. Nicholas Shanks Says:

    Have those inside Apple got a roadmap for the removal of modes, or the reduction of old modes’ footprint within the code base? For example you say there is a mode for Dashboard compatibility. Widget authors seem fairly responsive from my point of view, they are active and can fix things if they are told that there is something wrong. Competent users can even fix other people’s widgets on their behalf (though re‐releasing them might be problematic, legally). If widgets in Dashboard compatibility mode caused a small error message to be displayed elsewhere on the dashboard, outside of the widget’s normal bounds, both authors and users could update, and this mode could be retired. People who don’t update their browser aren’t likely to update their widgets either, so would be oblivious.
    A list of known XHTML vs. HTML rendering inconsistencies would be very useful too. Perhaps this already exists?

  9. DJCarbon43 Says:

    Well said NtroP! :D

    “…their sheltered little dystopia…” and “…it’s CELEBRATE!” hahah made my day!

  10. Kody Bryson Says:

    @NtroP

    I was referring to the fact that you can’t blame them for their current actions to try to maintain backward compatibility to prevent loss of market share. That’s a logical goal for them. And even then it’s only “in a way” because I also state this is still a bad idea.

    I totally agree with you that they are responsible for the situation they are in now and everything else in your comment.

  11. richcon Says:

    One solution to the pages-rendering-differently-in-different-versions-of-Safari problem would be, simply, to make the current version of WebKit available to all past versions of Mac OS X that has shipped with some version of Safari. Instead of having to support people with outdated versions of WebKit, you could be getting everyone onto the latest and greatest version. Slap it into System Update, and it’ll trickle down to every Safari install out there. No need to support older engine versions anymore.

    (If you’re worried about breaking other OS services that use WebKit, then keep the old WebKit in /library/frameworks and stick the new one in Safari directly.)

    I know plenty of people who still use (gasp) 10.2, and their version of Safari seems broken in comparison. When I design for the web, if I really want to reach the whole of the Mac community, I have to think about how the page will look in those older Safari versions.

  12. David Smith Says:

    One problem with that is that it would likely involve backporting quite a bit of the rest of the system as well. 10.2 doesn’t have CoreText, for example, or many many other APIs. WebKit is relatively independent of its host OS, but it still doesn’t live in a vacuum.

  13. mbear Says:

    From the original Beyond Doctype article:

    “In an ideal world, of course, all specifications would be perfect from the get-go, and their implementation in user agents would be immediate and flawless. In a slightly more down-to-earth version of an ideal world, browser vendors would immediately integrate regularly updated standards into new user agents—and users would have instant access to the latest version of those browsers without having to lift a finger.”

    When I read that I thought “Doesn’t my antivirus software do this every day?” Each day at 2 AM it downloads an updated database of virus information and automatically installs it. Maybe the thing to do for Microsoft (and others) is to create a “standards database” that can be updated every so often automatically by the application.

    In fact this could easily function as an improvement of or extension to the Firefox/IE/Opera update mechanism that alerts me that a new version is available. Just tell me that an updated “DTD entry” is available and tell me to install it. Or even better, have the browser automatically pull it down and install it.

    (yes, this is pretty much a copy of another comment I posted at A List Apart and Ars Technica and the IE Blog. The more times I say it the better chance someone will see it.)

  14. kgretton Says:

    I think this sums up the Internal IT Department issue quite well. However, the use of the additional modes and version identifiers will simply server to continue the problem.

    Any developer designing web content today needs to understand web standards or remain where they are today. Therefore, IE8 should only have two modes: Standards-compliant mode and Quirks mode – much in the same way that WebKit does (with a few internal workaround modes no doubt). The Quirks mode should be no different between IE7 and IE8, IEx. ie. the only mode that is updated and fixed going forwards is the web standards mode.

    What does this achieve? Well all of the Bob’s will be forced to fix their existing sites and content (which they are being forced to do anyway) to work with IE 7 either by updating the content to use standards (unlikely) or removing a DOCTYPE that should not be there and fixing any other issues.. IE 7 is frozen in time and no new functionality added, no rendering changes introduced for any version thereafter.

    IE 8′s web standards mode can then rapidly progress in the same way as all the other browsers – particularly WebKit – are doing without needing to worry about breaking quirks mode. Then we can get monthly bug fixes and enhancements to the IE web standards compliant modes and regular (say annual) major engine updates without breaking the old quirky stuff.