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."
You're talking about plugins. This is something different.
What is meant are things like "rich textarea" with some MS Office Word-like editing (through activeX) in it. Other uses are in very specific applications like the windows update and the such...
Why is it that in every damn press release I see online, not one of the URLs is ever a live, clickable link? Is there some press office union rule that insists only people with the skill and knowledge to use copy-and-paste should ever get to look into the background of one of these blurbs?
Sheesh.
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.
Maybe for intranets it could be used,
Actually, that is quite significant if the intranet is coporation-wide.
What sys-admin really wants IE on a corporate desktop anyway as it attracts so much adware and other unauthorised crud to end up on the machines. How much support time does that take up?
A recommendation which no doubt will shortly split into 'mobile' 'standard' and 'full', each available at 'level 1' or 'level 2', each in three simultaneously maintained versions called 'Original W3C recommendation', '1.0', and '1.1b'?
I'm not actively going out of my way to be mean here, and I do love SVG despite the issue mentioned above, but the W3C sure seems to focus a lot more on creating documents to justify their staffing levels than on, say, identifying clear needs.
I wasn't able to turn up a simple useful 'what are the benefits of XForms' document anywhere, but looking at the other docs (http://www.w3.org/MarkUp/Forms/2003/xforms-for-h
PS I realize all this stuff is terribly worthy and open and all, I'm just wondering whether anyone thought of a way to use it.
Whence? Hence. Whither? Thither.
As long as backward-compatibility through browsers exists, a clean break could be a great idea if handled properly.
// I will show you fear in a handful of jellybeans.
Same question arose with XSL... some of the most notable objectors btw to XSLT were the chaps developing Opera who advocated JavaScript+DOM as opposed to XSLT.
A little JavaScript and a little DOM isn't a standard approach.... You're using a little JavaScript+DOM, I'm using a little Python+DOM and he's using a little Perl+DOM
Now choice is great, but not for documents that you're publishing to a worlwide audience and which aspire to be unerversally readable.
As an aside you mean ECMAScript+DOM... the standard isn't JavaScript, it's ECMAScript.
Assuming we overcame diversity of language choice and madated ECMAScript+DOM the diversity of implimentation of any given task is FAR FAR broader in ECMAScript than it is in a declarative standard, say like XSLT.
Lastly, because XFORMS like XSLT *is* XML it benefits from application of schema, intigration with existing XML tools, mechisms for transport... and generally can be worked with like a regular XML document for instance one might generate your XFORMS via XSLT from existing XML manifests. While this can be done with ECMAScript+DOM, the task is more complicated, is open to diversity of implimentation, is less usable by other parties... and overall is less standard.
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.
Yes,and if you're rolling out a £10000 web application for a company that is one of those, then you should just tell them they have to upgrade all their boxes in defiance of corporate policy?
On a non-critical site I'm all for using standards and techniques that, in theory, make for a better experience for the user, but there are times that it just isn't practical.
Stuart
It's all fun and games until a 200' robot dinosaur shows up and trashes Neo-Tokyo... Again
So now with xforms we get a 3rd way to do some things that today can be done either through javascript or server side.
The server side way gives you full flexibility, you can use any language/technology to validate, structure your parameters, regenerate the page. The cost is some efficiency (round trips, having to regenerate full pages except if you use lots if (i)frames which can be very hard to handle).
Now what exactly is the place of this 3rd posibility? Could it really replace javascript? It may eliminiate the need of 60% of todays javascript, but I don't think it can handle all cases.
So the result is, developers need to learn and stay current still with javascript and their server technology of choice (e.g. asp, jsp) and additianlly need to learn xforms and related technologies (xml, xpath).
While submitting structured parameters is nice, what exactly is the point? While validating input values for ranges or types is nice, you still have to repeat the validation on the server side (you never know what manipulated or buggy client comes at you). The server side still has to convert all those text parameters into really structured types/classes.
So I see little benefit but great cost. One or two tricks would be really useful as an addition to current HTML standards (e.g. the partial replacement of pages which can help on large/complex pages without having to resort to frames).
I think this is a typical result of strandards groups that have grown too large and now don't know how to stop and limit themselves. To justify their existance, they keep putting out an ever growing stream of "useful" standards and loose touch with their "customers".
Yes,and if you're rolling out a £10000 web application for a company that is one of those, then you should just tell them they have to upgrade all their boxes in defiance of corporate policy?
They'd have to be used to constant (weekly) security upgrades if they are using MSIE, and the associated MS OSes. I'd also bet those applications stop working every now and again, as the upgrade changes (breaks) the way something works.
On a non-critical site I'm all for using standards and techniques that, in theory, make for a better experience for the user, but there are times that it just isn't practical.
I don't know whether to laugh or cry. I can't understand who would use MSIE for a critical site these days, with all the associated security problems. Even the Department of Homeland security recommends against using it (not that that means a lot, although it is unusual for a government department to come out against any particular software product).
I'm quite aware people can't just drop one software product for another. However, regarding MSIE, people should be starting their migration plans away from it now.
It makes financial sense to move to standards based web applications. For a start, a larger (larger being >1) variety of web browsers are available. If you have trouble with one browser, you aren't locked into it. Nor are you locked into the OS it sits on.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
Great that the client can verify data, but too many shoddy web programmers will use that as an excuse to not verify data on the web server too, as if only valid data can escape the client browser.
Infuriate left and right