W3C home > Mailing lists > Public > www-forms@w3.org > March 2005

XForms vs WebForms

From: Dean Jackson <dino@w3.org>
Date: Fri, 18 Mar 2005 00:34:21 +1100
Message-Id: <4ebb9545a0d290d960379b36c3b28c43@w3.org>
To: www-forms@w3.org


I've recently taken an interest in the WebForms vs XForms debate.
I've read the WebForms 2.0 specification. I have a few questions about
the goals and deployment. In order to make sure I have things clear
I'd like to say what I understand and have people tell me what bits
I have wrong. It seems there are a lot of emotions here - I expect
I'll get some heat, even though I'm really trying to understand the
motivations, not pick arguments. I'm sending it here because it
seems that there are people on this list that can answer.

+ The original design goals of WebForms 2.0 was that it would be
   backwards compatible and that it would "work" in existing
   user agents. IE 5/6 was the primary target due to its market
   dominance. The word "work" either meant "didn't work, but
   wasn't a showstopper" or "worked by inclusion of script or
   IE behaviours". WebForms 2.0 was also supposed to be "simple".

+ The XForms WG started out with very similar goals but concluded
   over the course of 3 years that incremental enhancement wasn't
   giving enough bang for buck. Therefore they decided to take
   a clean approach. It's an open discussion on how simple
   XForms is.

+ Feature wise, XForms is a superset of Web Forms 2.0.

+ XForms is not implemented in the major browsers, although it is
   available in them (eg the Mozilla extension or plugins). It is
   implemented in a few browsers with small market share.

+ WebForms 2.0 is not implemented in the major browsers
   (although Safari has a native implementation of a few simple
   features, eg <input type="range">). At this point, I'll note
   that I understand that WebForms is supposed to "work" in
   browsers that don't implement it (see above for "work").

+ A browser that does not implement more simple features of
   WebForms (new input types, required fields, field validation)
   still provides the ability to process the form completely. It's
   as if the WebForms features were never in the source.

+ A content developer can therefore use the more simple features
   of WebForms 2 without worrying if the browser can handle
   them. However, if she wants to be sure she gets a calendar
   widget, she'll still need to implement it (in Javascript, or
   server side). In other words, unless she knows that the browser
   can handle WebForms, supporting it will require more work
   (ie regular HTML + Javascript, then the WebForms features,
   then some extra Javascript to make sure the calendar control
   doesn't pop up if the browser does WebForms, working around any
   potential interoperability issues between browsers). For this
   extra work, she gets the benefit of having some users avoiding
   a roundtrip to the server. Some users also get a browser-native
   (but not necessarily platform-native) calendar control. She doesn't
   have control over the appearance or behaviour of the control.
   Q: is there a way for the content developer and server
   to know if the browser supports WebForms 2? I guess for the
   server it will be by the UA header eventually.

+ In comparison, XForms reduces the amount of work she has
   to do, but requires that the browser supports XForms.

+ Server-side development doesn't change (much?) with the
   use of WebForms 2. It also doesn't change with the use of
   XForms (with the exception that the server may receive richer
   data from the submitted XML model).

+ There are features in WebForms 2.0 that require browser
   support or the form does not work. This is a statement
   I expect the WebForms 2.0 people will disagree with.
   The WebForms "repeat" behaviour degrades in legacy browsers,
   but does not produce the right functionality (users cannot
   add a row). With the addition of script, the "repeat" behaviour
   can become functional in legacy browsers. However, a similar
   script could provide the same function without using the
   WebForms "repeat".

+ Due to the above, WebForms 2.0 didn't stick to
   the original goal. There are completely new features in
   WebForms that are not backwards compatible in browsers.
   Note, I'm not judging the change of goals, just pointing
   it out.

+ By comparison, all features in XForms require browser support.

+ It's arguable that the WebForms repeat functionality is
   "simple" (although, if it were universally available, it would
   be much simpler than scripting the feature).

+ WebForms 2.0 repeat seems to be similar to XForms repeat (but
   less functional). I kind of wonder why Web Forms didn't just
   use (or profile) XForms:repeat since they didn't have the
   backwards-compatibility requirement.

I'll stop there. I've rambled on long enough.

Thanks for correcting any wrong assumptions I've made.

Received on Thursday, 17 March 2005 17:08:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:14 UTC