doron's blaahg

If you think my blog post was attacking XForms, then you didn't read it.

Ah, ah, ah!
But well I need to agree with some of Hixie's argument - including that there is no reason why XForms would be less buggy than JavaScript + DOM...

Anyway, only time will tell who's right - and you may end being both right, with both technologies coexisting for a long time...

"Ah, ah, ah!
But well I need to agree with some of Hixie's argument - including that there is no reason why XForms would be less buggy than JavaScript + DOM...

Anyway, only time will tell who's right - and you may end being both right, with both technologies coexisting for a long time..."

Buggy has to do with implementations, not standards.

But yes, XForms is different, it is not going to replace HTML forms, and it isn't meant to. For some reason, people get all defensive and attack it. Same thing happend when Phoenix/Firebird was starting to gain steam.

It was just a freaking calculator sample I threw together. ARGH!

Take for example Lynx, could it use a JS+Forms1.0 document? no - it doesn't support Javascript, including all the 12% of people who browse with Javascript switched off (becuase the amount of gay javascript like intellitext)

If Lynx wanted to implement xForms, it could as it's standards based and does not require Javascript. If they wanted to implement JS+Forms they would have to implement the whole of Javascript because of its generic nature and the fact that any JS code what-so-ever could be placed amongst the commands.

Javscript is not accessible, and never will be - every web designer who can validate an xHTML document knows that JS is a pain, not encouraged in xHTML or even recommended in Strict and is not the best option for accessibility.

If JS+Forms ever takes off all we're going to be looking at more standardised annoying JS forms, prone to attack and misuse because of their standardisation and Javascript basis and lastly inaccessible to the vast numbers of people using Lynx and niche browsers.

Well. A lot of people spend a lot of time attacking XHTML 2 and nobody seriously sees XHTML 2 ever "make it".

Fight, fight! ;)

"But yes, XForms is different, it is not going to replace HTML forms, and it isn't meant to."

Well, that's not at all the impression you get when you look at the activities of the W3C -- as an outsider, at least. Improving HTML forms on the specification side (Web Forms 2) doesn't look like it's going to get the blessing of the W3C, even though it'd be much needed to advance practical web development.

"XForms - The Next Generation of Web Forms" rather clearly positions XForms as a replacement for HTML forms IMHO.

"it is not going to replace HTML forms, and it isn't meant to" doesn't really match what the W3C's home page for XForms says right now, nor what the chair of the XForms working group has personally told me, nor what the XForms spec says.

Also, when you say "people get all defensive and attack it", I still don't see what was either defensive or offensive about my post. I was just correcting some misconceptions. Now, if you want to talk about people being on the attack, that would be the XForms advocates, who keep talking about how great XForms is and how JavaScript-based applications are crap and how browsers that don't do XForms will be doomed and how HTML is dead, while the rest of us are trying to get on with our lives.

mkaply -- And a lovely demo it is. It perfectly shows how a lot of the myths I mentioned are just that.

"Web Forms" does not mean HTML forms, and the people who attack JS-based apps are idiots and tend to know very little about web applications.

From the people I talked to who extensivley use XForms, its meant to reduce some scripting and allow reuse of existing code (like Schema Validation, which would take quite a lot of JS to write :). Those people usually use compound documents (worst name ever!), where scripting is highly important. Hell, Formsplayer has implemented the Mozilla XBL spec (they didn't like sXBL), and XBL needs scripting :)

XForms though is more accessible, since it defines a decent event standard that screen readers can use to give the user a decent experience. If this was speced out for dhtml apps, then they too could work (and indeed, you could easily emulate XForms events in regular JS).

And as the lynx persom mentioned, XForms does scale better, but I don't agree that JS is a pain. Its a powerfull tool, and can do much more than XForms can dream of (XPath is a limited language).

"Take for example Lynx, could it use a JS+Forms1.0 document? no - it doesn't support Javascript"

Could it use an XForms document? no - it doesn't support XForms.

"If Lynx wanted to implement xForms, it could as it's standards based and does not require Javascript."

Whether it requires JS or not is irrelevant to whether Lynx could implement it. Lynx could implement JavaScript just as much as XForms. Both are standards (indeed JavaScript is more of a standard than XForms, as JS is an ECMA spec and ECMA is affiliated with ISO, unlike the W3C).

"If they wanted to implement JS+Forms they would have to implement the whole of Javascript because of its generic nature and the fact that any JS code what-so-ever could be placed amongst the commands."

And if they wanted to implement XForms they'd have to implement XPath and XForms Actions, which is infinitely extensible and any XForms Actions whatsoever could be placed amongst the commands.

"Javscript is not accessible, and never will be - every web designer who can validate an xHTML document knows that JS is a pain, not encouraged in xHTML or even recommended in Strict and is not the best option for accessibility."

This is all incorrect (as I mentioned in my blog article which sparked all this). There is nothing inaccessible about JavaScript. There are some APIs (like 'document.write' and 'style.color') that are bad, but that's not JS, that's the APIs. (Similarly, there are also ways to abuse the XForms/XPath extension APIs to be inaccessible.) There is nothing about validation that is a pain with JavaScript unless you are doing something incorrectly. Script is not discouraged in HTML Strict. Whether it is the best option for a particular purpose, in terms of accessibility, depends on what you are doing. If you want to make something work like a checkbox, then no, you should use . If you want to make something interactive like Google Maps, then appropriate JS is the best option.

"If JS+Forms ever takes off" -- It has. Look around you. This very blog uses JS+Forms. So does Google. Hotmail. GMail. Mapquest. etc etc etc.

None of this is an attack on XForms, by the way. I'm just, again, correcting some misconceptions. I happen to _like_ XForms (and although, true, I don't think it is appropriate for the Web, that is IMHO irrelevant to this discussion).

Oh, I love XHTML2.0! I'm missing features from it all the time! Like and , instead of , and . It will greatly reduce the need for s. I hope the spec will be finished soon, and Mozilla will add support for it.

And XForms is cool, of course :). I'm working with a similar technology (backbase.com), implemented in Javascript (and thus taking away the major compatibility objection), and it is great to work with. I'm glad because of this I don't have to code loads of JavaScript myself, this is much more maintainable and also less of a pain in the ass with regard to cross-browser-compatibility.

~Grauw