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."
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
XHTML 2 has a number of problems, from backwards-compatibility to human editability. A much better successor for HTML forms is Web Forms 2.0, which is also being worked on by Mozilla, as well as other major players in the industry. Obviously the real challenge is forcing Microsoft to support it.
- Allen Pike
Altering time, one time at a time.
From the announcemnt,
"XForms is key to realizing the vision of a future where people can access information online on any device--and do everything from shopping and banking to checking their e-mail or calendar."
Hmmmm?? I do all that on the web - shopping, banking, email, calender - right now just fine with the current generate technology. What's really new in XForms? Is there a XForms show-case or something like that out there?
Osho
Sad to say it, but if Microsoft doesnt implement XForms into IE, then it doesnt have much of a future. I'm sure visitors would just LOVE to see a site error message "I'm sorry, you must download Mozilla 8.0 to view this website". Maybe for intranets it could be used, but not on the general internet.
Has Microsoft expressed interest in implementing the standard? I hope so, since it looks pretty cool. However, it looks like MS already tackled a lot of the issues with ASP.NET (such as validation controls) so maybe they dont want to reinvent the wheel (or implement something that will help them lose one of their server platform's competitive advantages)
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
When IE development stopped it really hampered new development. It's now clear that longhorn will be introducing a whole pile of new proprietary offerings with its new browser to facilitate the much needed improvement in web apps. But with details locked up, presumably until release, I'm very glad that other browsers are now looking ahead in their own direction. With any luck Microsoft will be pressured into supporting XForms. Heck, I'd settle for a 3rd party plugin. But anything to give developers a solid full-featured cross-platform solution. We can't let ourselves continue to be locked into microsoft products. It's unhealthy :)
Phew.. I was starting to get really scared that the web would be developing at the speed of Macromedia and Sun for the next while. This really is something big and new we can look forward to as well.
I wonder what kind of working timeline they have. With those big corporate spenders helping out, I'd like to think they are really pushing forward at a good pace.
Like SVG for graphics, I think XForms is not only a useful concept if the browser supports it. I like the idea that I can currently create SVG on the server, render it on the server and send it to the browser as a PNG. I believe that there are currently products and projects available that if you have a set of XForms, allow you to turn them into a standard CGI-like application- all of the work of transforming into HTML etc. is done on the server.
I hope (cross-fingers) that in the future that I can send the original SVG/XForms/whatever to browsers that support it, and render on the server for everything else.
It's also good writing things using standards compliant products. I've currently just moved a website that relied on XSLT a lot from one software toolkit to another. This wouldn't be possible if I'd used a non-standard technology (in the sense that it worked with one toolkit only).
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.
How many little things like this has various Mozilla people working on it? I'd say "ho hum", except that this project has the backing of two leading Open Source citizens, IBM and Novell. I surely hope this means increased recognition of the importance of web standards. There are too many specs that sound exciting, but never go anywhere, except to be described in some hard-to-read document on w3.org.
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).
For those who didn't know this: one of the great things about XML is that it allows for the mixing of namespaces in a single document.
This means that different XML technologies (like XHTML, SVG, MathML, and yes, XForms) can be used in a single file.
Now if the display device (ie. browser) has support for all the used technologies, some funky things become possible.
For example, a web page could use XHTML for structuring a document, SVG for graphics, MathML for formula display and XForms for data input.
Throw in some scripting, and you could for example do a function plotter as a web application, in a single document.
At this point it's not just about structured data anymore, but also about mixing-and-matching technologies to create applications. And XForms is one of the building blocks that will hopefully make this possible.
Wenn ist das Nunstruck git und Slotermeyer? Ja!... Beiherhund das Oder die Flipperwaldt gersput!
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.
Sounds great in theory, but in practice the design monkeys are going to insist on their chosen control type be implemented as they want it. I've even had an argument where the designers wanted a bunch of check boxes with validation control to ensure only one could be ticked at a time, i.e. functionally equivalent to a group of radio buttons. Took a lot of time to convince them to change as they felt the checkboxes looked better than the radio buttons.
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