- From: Dean Jackson <dino@w3.org>
- Date: Fri, 18 Mar 2005 00:34:21 +1100
- To: www-forms@w3.org
Hi. 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. Dean
Received on Thursday, 17 March 2005 17:08:23 UTC