Yesterday I played with XForms. I have not yet taken the time to read the specification. Instead, I used some examples I found at Bugzilla and the Mozilla XForms project site. Not really the correct way to learn new things, especially since the implementation has some bugs and I might end up thinking such a bug is actually the correct behavior. (Anyone seeing the similarities with the CSS implementation in Internet Explorer? Take the box model for a good example.)
Although I still think XForms is rather complex and could have used some actual browser developers to help with the creation of it, you can do nice things with it without the requirement of scripting. A nice example of that is the Calculater Sample on mozilla.org. Of course, on the other hand it does require support for XPath, XML Schema, CSS 3 UI, probably CSS 2.1, and XML Events. Ok, to be fair it only requires support for XML Schema part 2, not the complete specification. (You can also find this list in the XForms specification, with the exception of CSS, but you need something to make it look like a form.)
To enable XForms you have to download a recent nightly, for example Mozilla 1.8 Beta 1, and afterwards download the extension. (You read that correct, XForms along with some of its dependencies, like XML Schema, are implemented as extension.)
The downside in the current implementation is the lack of CSS support. Although XForms and Styling is a non-normative part of the specification and therefore not required it is really nice be able to style the forms. For example, when a field is declared to be of type xsd:decimal and someone enters qwerty you really want to do something like background:red or something that does not clash with usability and accessibility standards. (Red is often confused with green if I remember correctly.) Of course, thanks to the CSS3 Basic User Interface Module that is possible using xf|input:invalid::value. However, currently you have to use xf|input[invalid] xhtml|input to style the input field in Mozilla due to some bugs. (The input field is created using the HTML input field in the implementation. Since that is obvious something not every implementation uses this may be considered a hack. A real hack. Of course, implementing XForms reusing parts of HTML form controls is perfectly legitimate. Exposing that to the end user by means of CSS selectors should not be possible however. (That would be a pain, since a lot of things, like the scrollbar, are implemented using anonymous elements.) The implementation has some little problems however. To demonstrate those and some of the qualities of XForms, an example. You need to have XForms support if you want to try it out.
In the first field you can type in a decimal number, like 1.25 and in the second field some other decimal number. The third field will give you the product of those two. And that, people, is done without scripting. Not that it is really important, web applications require scripting to be enabled anyway and you can almost not browse without it but it is still pretty cool.
You want to see some problems? That is possible. Give the first and second field an appropriate value. The product field will show, er, the product. Now focus the product field and change the value to qwerty, press tab and watch it become the same value as before but now with a red background. Similar variations are possible with entering invalid values in other fields. I also tried to make more efficient use of the BIND element. The REF attribute contains an XPath expressions that points to the element holding the value. The BIND element itself can define that value using the TYPE attribute with an evil QName inside it to refer to the XML Schema datatype. (The namespace prefix used in the QName is of course declared on some ancestor element. An example of a valid TYPE attribute value is xsd:decimal.) So since all my elements were holding the same value I thought I could drop at least one BIND element setting REF to /test/*. As it turns out, that does not seem to be possible in Mozilla’s implementation. The form went acting strange when I tried that and I should probably make some more test cases and file bugs on it if it is valid according to the specification I still have to read. (I assume it is, since it is a perfectly valid XPath expression.)
Have a nice Sunday.
With regard to that ‘hack’, it is addressed in the release notes, so not exactly unexpected...
The XForms beta currently does not support the XForms CSS pseudo classes and elements. As a TEMPORARY work around, we do set attributes on the controls which can be styled by CSS as invalid, irrelevant, etc. This will be fixed in a future build.
Keep in mind that this is a beta release, so I wouldn’t hold it against them :).
<company plug>Note that with the technology my company is developing, stuff like XForms does is already possible in the current browsers (Mozilla, IE5+). Without needing to download an extension, just using client-side javascript. Has XPath support, too, so stuff like sum(*/@value) is entirely possible.</company plug>
~Grauw
It appears you can not apply the TYPE attribute twice to a single node using different BIND elements. You can also not overwrite it. So if you used a simple shorthand, like I did with /test/* they will all have the same TYPE attribute.
Nice, Anne. Thanks for pointing us to XForms extension. I have tested it and must say, that the simplicity of "scripting" is wonderful compared to Javascript etc.
The problem you mention is now fixed :) (bugzilla bug 284101)