Why Web Forms 2.0 isn’t far enough to make a difference
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.
Sat Jul 10 16:46:00 UTC+0100 2004
If JavaScript is almost universally crap, under-tested and poorly implemented, why are you talking about using old-style scripts instead to mimic the functionality WF2 is aiming to fill? Aren’t those crap, too? Where’s the difference? Okay, there’s the whole “tried and tested” thing, but at least in the case of a WF2-enabling script, it’s a somewhat more limited set of agents you need to worry about. There’s IE6 (when will there not be?), potentially future versions of Internet Explorer, and then a finite set of current-day agents that will in due time more to native WF2. Unless I’m horribly wrong on this point, other, more obscure agents can be safely ignored since most scripts wouldn’t take them into account, anyway (and it does at least degrade to a text box, which is admittedly sub-optimal, but no different from current implementations).
And nothing is stopping a set of dedicated volunteers from rigurously testing any such legacy-to-WF2 scripts—if there’s one thing there’s not much shortage of, it’s people willing to play with new technology.
Basically, what I’m saying is: which is better? Scripting (crap, under-tested, under-implemented) that degrades to a textbox for absolutely everyone when JS is off, or scripting (crap, under-tested, under-implemented) that degrades to a textbox when JS is off unless you’re a WF2 agent? Isn’t it better to have standardised, predictable conventions? I don’t see the problem.
Sat Jul 10 22:10:00 UTC+0100 2004
The problem with the shim approach is that in 99% of cases, it’ll be a sledge-hammer to crack a nut, and it will be being used by people who would not have considered doing such thing. For example datetime with a popup calendar as is being proposed, this is a lot more complicated than most developers will attempt - they’ll have two drop downs with simple script to change days or something. The DHTML proposals in the shims go far beyond this.
Libraries always need a much larger amount of QA than dedicated script, especially ones that have a potential impact on every element on the document.
The dedicated volunteers approach is perhaps possible, but the problem with this is, corporate QA departments generally are not willing to trust open source QA, they need a higher level of guaranteed support.
We will need to worry about a lot more than IE6, that argument I find ridiculous and offensive, there is not only IE, there are lots of Access Technologies, generally built on top of IE (because it has the best plugin architecture). These don’t run well with DHTML scripts, so these users end up with bare input elements which almost always will be less useful than what people would otherwise be creating. We can’t ignore obscure User agents - look at the repeat element, if the shim half works in some UA, then it almost certainly renders the page unusable. Degradeable javascript is stunningly hard, there’s almost always cases where it will fail, you may be happy with that, corporate QA departments and lots of developers are not.