Ajax makes browser choice irrelevant...but we still need standards
The former (XForms) attempts to capture a wide range of patterns that recur in web applications, such as retrieving data without replacing the document the user is viewing (yes...XForms defined that a long time ago!), client-side validation (that too), using mark-up to provide tooltips and help, rather than using script (yes...), having controls such as calendar widgets and sliders built into the language (no-one told you?) and more.
The latter (WF2) claims to add a few small improvements to HTML forms, so as not to move too far from current practice. This might be commendable in itself, but the truth is that as the WF2 specification has evolved, it has increasingly added features that make it about as similar to HTML forms as...well, XForms is. There are new attributes and elements, new interfaces, repeating constructs, new submission protocols, and so on. In fact, the truth is that the major differences between XForms and WF2 are not in terms of simplicity (XForms can do 'simple' in a way that is actually more intuitive than HTML forms) but that XForms supports an MVC architecture, and allows you to submit data without replacing the current page. It's unlikely that in 2006 anyone would want to be without either of these.
Who is using HTML forms anyway?
But the real irony with WF2 is that even if the spec had limited itself to 'small changes' instead of the large number it has added, 'current practice' is actually not to use HTML forms anyway! 'Current practice' either involves using some kind of server-side processing that hides HTML forms from you--such as Struts or Ruby on Rails--or it involves hand-coding Ajax yourself, using one of the many high quality libraries that are available.Browser-choice is increasingly irrelevant
What I find most interesting though, is the mistaken belief amongst proponents of WF2 that anyone really cares what browser manufacturers do. Unfortunately the W3C suffers from the same delusion; they recently decided that one form-related standard wasn't enough and that there wasn't quite enough confusion in world of the web, so they invited the WHAT WG to bring their quaint ideas into the fold. (One of these quaint ideas is that XML won't catch on, which would be mildly amusing if such Luddism weren't now being courted by the W3C.)Why do I say that browsers are increasingly irrelevant? Well, imagine that the Ajax libraries just keep getting better and better, and increasingly 'hide' the differences between browsers. I think that's a pretty safe bet, since the leading libraries show no signs of slowing down their development and innovation any time soon. With such a context we actually get an increase in conformance, not a decrease, and authors are able to write for all browsers rather than the "dominant" one. At a certain point, which browser your customers use becomes increasingly irrelevant.
Whereas in the past it was up to all of us to test our sites and applications in the various browsers available, now we can leave that to the Ajax library authors, which has got to be a far more efficient use of everyones time.
The browser war is therefore over, not because any one browser has won, but because developers could care less about the browser as a browser--instead one or other Ajax library becomes 'the platform'. In parallel, users will tend to use the browser already installed on their computer, or the one that is mandated by their employer--likewise making the actual choice of browser irrelevant.
Extended browsers
Actually, to be more precise, what will increasingly happen on the user side is that we will choose our browser on the basis of handy features like tabs, or task-related features like RSS readers, photo sharing, blogging tools, and so on. Whether Flock and Songbird get it right remains to be seen, but there is no doubt that people will use products such as these if they serve their purpose. And that's a far better basis on which to choose a browser than which version of CSS it supports.Standard Ajax
Then at some point the cry will go up: "Why do there have to be so many Ajax libraries? Can't we standardise on these browser enhancements? Has anyone written a tool for porting my YUI x.y application to Dojo a.b?"That, at least, will be the cry coming from developers, if it's not already; the end-user on the other hand will now be dealing with a different set of problems, and their cry will be "Why doesn't the new browser I've just installed work with my Flickr photos, my Blogger blogs, all my dates in GCal, and all my favourites stored in del.icio.us, like my old browser did?" I guess that's progress...
XForms, SMIL and the W3C
At least for developers there's some good news though, in that the XForms WG have been working for years on exactly the kind of standardisation that is needed to sort out 'the platform'. In fact, the W3C has lots of excellent work it should be making more of, such as:- SMIL: which covers a large part of most Ajax libraries, animation;
- DOM 2 Events: easily supported in script, and provides a standard eventing architecture rather than the growing number of library-specific models that are emerging;
- and so on.
The W3C therefore has an important role to play in the future of web application standards, but by using its experience in defining 'the platform' not being bounced into worrying about the future of the browser. It will only be able to help define the emerging platform if it takes seriously its tagline of "Leading the web to its full potential...", and does some leading!
Tags: webapps | programming | standards | browser | XML | HTML | web forms | WF2 | W3C | XHTML | XForms









1 Comments:
Side-note: I like web-log posts because authors use a more relaxed language, making information-intake interesting and easy. - This article is a notable example.
About the article: It has given me a good all-around look at what's fueling Web 2.0-3.x
Awaiting your YForms article,
Bihni J.
Post a Comment
Links to this post:
Create a Link
<< Home