2004-05-28 17:16 UTC Spring 2004 Travelog: Part 2 (Backwards Compatibility)
The CSS working group meeting is now over, and so I've now flown over to the bay area for the workshop. I'm staying at dbaron's, who kindly offered to let me use his couch. We have both been asked to give short presentations at the workshop next week, so I've been thinking about some things to help underscore our point about how backwards compatibility is a requirement, at least for solutions that are to come in the near future.
I think the best way to explain it is to use examples.
Look around the Web. What parts of CSS2 are used? (Not counting those that were already in CSS1.)
The answer is "absolute positioning". Pretty much none of the other new features from CSS2 are used. Why? Because of those new features, pretty much only absolute positioning is supported by Windows IE6.
Many sites still use HTML table elements for layout. Why? Because the CSS2 table model isn't supported by Windows IE6. Authors often ask how to do things like fixed positioning, but lose interest when they are told Windows IE6 does not support them.
Many pages on the Web claim to be XHTML (according to their DOCTYPE) but they are almost all sent as
text/htmlinstead of the more correct
application/xhtml+xml, despite all browsers except Windows IE6 supporting the latter.
Authors use PNG. Authors don't often use PNGs with eight bit alpha channels. Windows IE6 only supports PNG that don't have eight bit alpha channels. Authors frequently ask how to use semi-transparent bitmaps with their site designs, but again lose interest when told that Windows IE6 won't render them correctly.
- Flash is frequently used on the Web
Windows IE6 ships with a binary plugin for rendering Macromedia Flash files. Flash is very widely used on the Web, especially for application-like content, in particular games and interactive multimedia.
- SVG is rarely used on the Web
Windows IE6 does not ship with a binary plugin for rendering SVG files, although one is available at no cost. SVG is rarely used on the Web, at least compared to Flash.
- Non-standard features
Many pages depend on features that aren't in the specs, but are implemented in IE, despite the features being available in the specs using other methods, and despite those other methods being implemented in IE. For example,
document.allis used all over the place despite its standards-compliant equivalent
getElementByIdbeing implemented in Windows IE6.
Similarly many pages use
innerHTML, and the like, which has forced other browser vendors to implement support for those features.
I think these examples demonstrate quite strongly the need for any successful solution to be one that can be deployed in Windows IE6. Adding new functionality to Windows IE6 without using binary plugins is quite possible, as demonstrated by the quite impressive IE7 project.
The long term solution would be to move users from the dead IE platform and the proprietary Windows platform to the actively developed, open, and standards-based alternatives. Once users are using products with (relatively) rapid update cycles, it will be possible to introduce more radical new technologies, and expect to see them adopted by authors.
However, moving users to a different platform is an entirely different problem than providing authors with new technologies. Users use Windows because vendors use Windows as their default operating system. Users use Windows IE6 because Windows uses IE6 as its default Web browser. Very few users ever change either of these, much like very few users ever change their preferences, mostly because they simply are not aware that the alternatives exist.
Therefore before we can create a long term solution for authors developing Web applications we need operating system manufacturers and Web browser manufacturers to significantly step up their marketing campaigns and significantly increase the effectiveness of their lobbying of vendors. Until that happens, there is not much point inventing new languages, since they won't be used in the near future, and will probably no longer be adequate when they can be.
However, in the meantime, authors still want to write Web applications, and the currently deployed standards are inadequate. Since completely new standards won't cut it (as discussed above); this leaves us with the solution we (Opera and Mozilla) have been advocating: updating HTML and the DOM.
Pingbacks: 1 2 3