The WHAT WG kicked off a lot of discussion on how to improve the current state of the web languages available to us, so as to create the future web-applications. The general consensus (e.g. 1, 2, 3) appears to be we need “graceful degradation” so that it works in IE6 but offers something more elsewhere.
The argument appears to be:
- Create something that makes authoring easier but only works in the exciting new ways in Mozilla, Opera and Safari, but degrades elsewhere.
- The developer will get such a implementation gain from these improvements, that they’ll use it.
- Users will learn of the improvements in these other UA’s and switch to them.
I don’t think this argument works, it relies on authors willing to forego the enhanced performance in IE6, for the ease of authoring with the new technologies. The alternative traditional script solutions to extending the capabilities of web documents, work fine in IE6, they’re well understood (if poorly implemented) and generally work either as well, or only marginally worse in the other browsers - the ones today too, not some new ones that people need to have upgraded too.
IE6 is too important to authors and product managers, whatever the solution is we ship to IE that’s the most important, we can’t compromise that in any way. So whilst offering a calendar control that degrades to a text box might be a fair enough if we’re degrading to IceBrowser, it’s not acceptable to us for IE - We’ll ship one of the common script calendar controls that degrade to a text box when there’s no script. Our IE customers are simply the most important, they’ll get 95% of our development and testing time, in that scenario the degradation must not compromise IE6 behaviour at all.
The WHAT-WG’s approach to this appears to be javascript shims to get it working. As I often say javascript development is almost universally crap, under-tested and poorly implemented. Libraries are often the worse kind, the test requirements are simply too high to do on the huge variety of systems out there, that javascript code can run on, they’re generally not rich enough to do everything - so you’re always extending them, libraries simply haven’t been shown to work on the web. (If I’m wrong, show me some sites!).
These libraries would also need to have to no licence encumberance or risk for me to just re-use them, and most likely be free (all the script the Web Forms 2 spec offers is available for free out there now, how do I justify the cost of something new.) Who’s going to write it? There’s maybe only a hundred or so people with the script skills available, but generally they’re pretty busy doing real work, that actually puts food on the table.
But let’s suppose that authors can deliver good enough IE6 sites through these script methods that they’re willing to ship it. Great, but all that happens now is that users have no reason to move to a new browser, the pages in IE6 are just as good as they would be in those other browsers. Without the motivation to move the process of degradation as an evolutionary strategy doesn’t work, we’ll still be stuck authoring the same pages in the same styles. Only now we’ll also have to worry about a large javascript library that we have little control over.
So what’s the solution?
Flash has shown us how to ship sites which don’t degrade in IE - we use a plugin for the new features, it’s worked great, plugin solutions for IE degradation are fin. So long as what it offers the developer is something of a leap in performance (authoring, technical etc.) that they simply can’t do it in traditional HTML ways, it’s fine. This is where we can make a new technology platform, develop a real improved solution that can be rendered in an IE plugin. IE plugins can go full browser window no problem, and you can change the accept-headers of IE in the install - they don’t need to be done with HTML and OBJECT elements, in this case. Of course IE users who don’t install the plugin won’t get much other than the degradation to HTML, what the users will get though is an incentive to change, since the features will be new and offer something worth installing.
Of course, moving to this system, is a much more complicated system, it’ll take longer to come about, but I think it’s a much more likely scenario than imagining Web Forms 2.0 will really offer enough benefits to either authors, or developers to achieve anything, it’ll just be another XHTML 1.1 never used in the real world.
205a