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.
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.
Wow these are great features, it seems you like them, and see benefit in them for a number of people, including the disabled.
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
Yes, let's all give up, MSIE is the best browser in the world, we shouldn't try to show how standards can make things better.
Thankfully there are enough people in the world who won't just accept the status quo such that improvements keep coming. Sadly, you don't seem to be one of them.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
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.
I'm not so sure of your glib statement of corporate dependence on ActiveX. I've worked for a large US corporation (top 20? top 10?) and I know the security boys would smack you upside the head if you even thought of emebedding an Active X control in their intranet infrastructure.
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.
I think it's great that Mozilla's looking to finally implement this. I've been watching the bug (97806) for about six months, and it's been very contriversial, at least partly for the reasons you mention.
Having said that, XForms do seem like absolute overkill for a lot of tasks, and it'd be a shame to see them deprecate and presumably replace the limited (but simple) forms that HTML has at the moment.
My own gripe is that in my own experience, existing forms could be so much more convenient to use if only there was an accepted standard for a couple of extra data types.
Specifically, I'd very much have liked to see <input type="date" />. and <input type="time">. (Browser pops up a relevant calendar selection dialogue as appropriate.)
Those two inputs alone, if designed with appropriate properties for things like time zones and granularity, could prevent a huge number of headaches in web programming. Offering some very simple client end type checks for other types of inputs could prevent even more headaches.
XForms is just overkill for a lot of this, but javascript is a very yucky and unreliable alternative. Oh well.
I hope the spec includes tab indexes. One of the downsides to the ASP.NET framework is if you have multiple "forms" on the page (which are all within 1 form tagset), controlling which element gets focus on a tap of the tab key is a nightmare. Usually it "doesnt" go where you want it, and worse yet, most the time hitting the ENTER key presses the wrong buttons. Bottom line is, IMHO, the browser shouldn't be guessing what comes next in a tab or enter keypress (unless its unspecified), the developers should decide.
I'm Rick James with mod points biatch!
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".
ActiveX is being dropped by MS anyway. as even they realise it's insecure. Xforms is really going to come up against Infopath and Avalon which are both new tech's Ms is rolling out. And if mozilla does not provide an alternative it will be left behind again as netscape was in the browser wars. So all in all this is a good thing, perhaps it would be even better through web forms but as per a prior poster the foundations is working on them already. If anything the foundation needs more coders to help roll it out quickly. The web is a fickle place and whoever builds new tech first gets the jump on the market, and as such gets to keep that market.
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
Excuse my ignorance about XForms ...and perhaps about ActiveX as well. You are excused on both counts--I'm not exteremly well versed on them either ;-)
but it doesn't look anything like ActiveX technology to me!
I'm confused. You say that like it's a BAD thing!
ActiveX as a concept seems cool, but the implementation makes me cringe--it should be eradicated from the planet!
How is XForms supposed to replace QuickTime, RealPlayer, Flash, Shockwave, JAVA applets, VRML plugins
XForms is NOT an ActiveX replacement, and it isn't meant to replace ANY of those things. It is a proposal for an elegant, standard implementation of interactive form display and processing--compared to the complete mess we have today (DOM+Javascript, or *particular* ActiveX controls, flash, etc). Ironically, XForms support of sorts is ALREADY available for IE6 in the form of an ActiveX plugin. I suppose that at least allows one to replace a myriad of nonstandard controls with one plugin that implements the bells-and-whistles using an actual standard.
In my opinion NONE of the above plugins are of great use to me and in 90 percent of cases where they are used they only serve to be annoying. To the web authors out there--PLEASE THINK TWICE before using them. Don't use Quicktime, WMP9 or Real unless you are hosting a site dedicated to video and/or sound (I prefer to launch the player externally rather than embedded in the page anyways)! If you aren't making a web-based game then DITCH THE DAMN FLASH AND JAVA--PLEASE!
I want simple, fast-downloading, compatible and easy-to-use interfaces. Proprietary plug-ins and bloated code get in the way. If XHTML with XForms, etc. can make some of the above crap obsolete it'll be a great step forward for the internet.