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. Commitment to Standards and Interoperability It’s not very well aligned with our mission of staying lean and mean.
#Different versions of safari code#
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. However, having more mode switches cuts against this. These and other products all include a full-powered version of WebKit, no compromises.
#Different versions of safari android#
Some of the more prominent examples include Nokia’s S60 Browser, Apple’s iPhone and iPod touch, and Google’s Android platform.
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. So, bottom line, we’d like to see fewer modes, not more.
Either would be a huge additional barrier to entry for developers, and would make it harder to maintain the code. Another is to have a whole second copy of the layout code. One is to make all engine changes conditional on a version flag. There’s two plausible ways to add more modes. 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. Hackability is one of our core project goals. Second, implementing mode switches hurts hackability of the code. 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. Having more modes means many things need to be tested in multiple modes. 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 lots of modes raises a number of challenges for maintaining the engine.įirst, the more different modes there are, the harder it is to fully test the engine. MaintainabilityĪs you can see, this is quite a few modes already. 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. 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. 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. We actually have a few modes besides that. This is in contrast to the IE approach of completely freezing old behavior in quirks 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. Documents with newer or unknown doctypes, or sent as XML, are processed in standards mode. 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. Why, you may ask? There are a few reasons. 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. However, some have asked if other browser engines, including WebKit, would adopt a similar version switch. Straddling compatibility and Web standards is a tough job requiring tough choices.
So we’re not going to give in-depth commentary on the IE team’s decision. 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. We don’t talk much about what other browsers are doing on this blog. Others, including Dean Edwards, Robert O’Callahan and Anne van Kesteren think the proposal is a bad idea. Some web standards experts, like Eric Meyer and Jeffrey Zeldman see the switch in a positive light. The new IE8 version targeting switch, announced on IEBlog and A List Apart, has been the talk of the web.
0 kommentar(er)
