Slashdot Mirror
Mozilla Starts Work On XForms
AnamanFan writes "The Mozilla Foundation, with Novell and IBM, announced the formation to implement the W3C's XForms 1.0 Recommendation on the Mozilla platform. XForms is the forms module in XHTML 2, developed by the W3C. The project enables developers to deliver the type of next-generation, rich, portable web-based applications desired by corporate IT. Is this one step away from the corporate world's dependence on ActiveX? We can only hope."
The standard also includes a label for every form element, which currently does not exist. This is very useful for disabled people - e.g. blind people, their screen-readers can figure out which text belongs to which form element. This is currently impossible.
You also no longer define the type of formelement (radiobutton, selectboxes,...) the browsing tool chooses the most apropriate system. For graphical browsers radiobuttons may be cool, but for screen readers it may read the form like "choose one of the following", and for small display devices a dropdown-menu maybe better as 2 radio buttons plus their label takes up too much screen space.
To me it makes sense, but I know that I wont use XForms anytime soon. Because there's still companies that have MSIE 5 as the only allowed browser in their IT-policy... Creating a web- application for them still includes crazy html and javascript hacks
Microsoft's alternative to xforms is infopath. A form of it, or something like it, will be included in Longhorn as microsoft's new web/intnet based API.
Other other major alternatives are:
Flash/Flex from macromedia.
Java applets.
While they are not all the same in the way they work or what they do they all marketed as improvements to the current web forms and a way to bring back alot of the user interface capabilities that were lost with the move to web based applications.
Actually, you have to give the input form an ID, as in:
<label for="textboxfield" accesskey="t">Input text here</label>
<input type="text" name="textbox" id="textboxfield"/>
and your example can be shortened to:
<label accesskey="t">Input text here
<input type="text" name="textbox"/></label>
I have mixed experiences with access keys in real life. IE uses the ALT key for both pulldown menus and access keys, hence ALT-F is useless (in english-language browsers, other key-combinations are used in other languages). Then there are issues with semantics. For example, if a submit button has an accesskey attribute, should we assume that using the access key submits the form, instead of just focusing on submit button?
18 Nov 2003: A preview release of Oracle's XForms processor PlugIn for Internet Explorer is now available. The XForms Processor is a plug to Internet Explorer 6 on Win2000/WinXP. A User's Guide, Datasheet and several samples are provided with the preview release install.
From the DENG web site :
"DENG is an open source Modular XML Browser, capable of rendering subsets of XForms, SVG, XHTML, XFrames, arbitrary XML(...) Currently, the footprint of the DENG Modular XML Browser is 76 KByte, allowing zero-install deployment of these W3C standards to the vast majority of today's web browsers that have the Macromedia Flash Player 6 installed."
http://claus.packts.net/
http://sourceforge.net/projects/dengmx
This is a really cute application and for those of you who'd like to see Xforms in action, there's a few working examples on their demo page : http://claus.packts.net/deng/examples
Of course, it's open source (GPL).
There are two classes of application that web browsers are very bad at: rich UI interaction - for example graphics editing - and interactive data apps.
There are workarounds and bodges that can help, but they depend on Javascript and you can't be sure that everyone will be running Javascript, let alone that there is consistency at the DOM level.
There are two things that web applications are very good at: rollout and global availablity. Wouldn't it be great if we could have it all. XForms is a step towards that, targeted at data manipulation applications.
For this sort of application, you very often need to update the information presented, at a field level. So for instance, on a desktop application, you might have a field where you can enter a name, and as you type, another control presents a list of possibilities which dynamically changes. Typing 'S' would show you 'Smith' and 'South' and 'Smart'. Adding 'm' would reduce the list to 'Smith' and 'Smart'. And so on.
To do this properly, you need to be able to have sub-page queries of the web server/web service/database/whatever, or you need to download the whole index and filter at the client (yech). And you don't want the whole page to refresh. So it's not something that HTML as it stands can do, without workarounds.
From the XForms FAQ, here's a list of some of the things that can be done with XForms that aren't possible in HTML:
* Check data values while the user is typing them in.
* Indicate that certain fields are required, and that the form cannot be submitted without them.
* Submit forms data as XML.
* Integrate with Web services, for instance by using SOAP and XML RPC.
* Submit the same form to different servers (for instance a search string to different search engines).
* Save and restore values to and from a file.
* Use the result of a submit as input to a further form.
* Get the initial data for a form from an external document.
* Calculate submitted values from other values.
* Constrain values in certain ways, such as requiring them to be in a certain range.
* Build 'shopping basket' and 'wizard' style forms without needing to resort to scripting.
If you are interested in XForms, it's also worth knowing about Web Hypertext Application Technology Working Group (WhatWG) - http://www.whatwg.org/ who are working on specifying an extensions to HTML to allow richer applications. One of the projects is Web Forms 2.0 which aims to specify form extensions for HTML and XHTML.
Both of these are excellent initiatives which could make the life of web app developers Better.
Mozilla starting work on XForms is terrific. The competition may spur Microsoft on... MS are not very keen on anything that reduces the dependence of users on desktop apps. For them, this is a very sensible strategic position because their income stream depends on continued need for their OS, and that in turn is because applications are bound to their platform. Consequently they haven't been especially fast to embrace (or extend) standards which would make it easier to deliver rich web applications.
Don't bother to weigh in with MS-bashing. You are wasting your time and this is not what the para above is about.
Jeff Veit
There is a lot of negative talk about XForms, and plenty of people asking what it is good for. I've been following the spec and would like to share why it is useful.
If you have a web application that presents a form, but the server side needs to represent the data in XML, problems abound. Throw in the potential for repeatable elements and a few conditionals in the XML Schema and your simple little form becomes a major pain to develop. I personally wrote a web front end for authoring MODS records and had to do serious JavaScript/DOM acrobatics. The result was good, but compromises were made along the way.
XForms changes this because the form constrains to an XML Schema and sends a populated XML document to the server. This simplifies matters tremendously. It doesn't obviate the need for some serious work to setup XForms, but given my initial experience testing the spec, it is a great step forward.
It is overkill for a basic form, so I hope there are some provisions in XHTML for backward support.
-- Solaris Central - http://w