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.
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.
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.