Re: XForms Transitional

On Fri, 16 Mar 2007, Laurens Holst wrote:

> Dave Raggett schreef:

>> XForms Transitional is the name for incremental extensions to 
>> HTML4 forms that provide simple declarative support for 
>> spreadsheet like applications. As the name suggests, the approach 
>> allows you to start using some of the functionality available in 
>> XForms which offers enterprise strength forms for XML based 
>> applications.
>> 
>> You may be interested in looking at the draft specification for 
>> XForms Transitional, along with working examples that should 
>> function in the majority of modern desktop browsers.
>>
>>     http://www.w3.org/2007/03/XForms-Transitional/
>> 
>> To enable a comparison of the two approaches, I have also 
>> prepared the same examples using Web Forms 2.0, see:
>>
>>         http://www.w3.org/2007/03/WF2/
>> 
>> You will need to use a browser like Opera 9 that supports Web 
>> Forms 2.0 to see the examples in action. I am waiting for some 
>> technical assistance with repeating fields and will add the 
>> remaining examples as soon as I can. Web Forms 2.0 is very 
>> flexible but tends to involve a more procedural approach.
>
> Hello Dave,
>
> From what I see, it is quite interesting. It would be nice if some 
> hybrid between this and Web Forms 2.0 were adopted.

Do you have any particular suggestions on hybrid features?

> Some comments, although I did only glance over it relatively 
> superficially:
>
> The expression system. Wouldn’t it be better if the expressions 
> were XPath? You could expose the fields as local variables for the 
> expression, and benefit from the full expressability of XPath. 
> E.g. $x < $y. Javascript functions could be made available as 
> XPath functions directly, too. This is what we did in Backbase 
> 3.0, and I very much liked working with it. XPath seems more 
> suitable for declarative use.
>
> A problem with your Javascript ‘eval’ approach is that 
> reserved Javascript keywords will cause errors; ‘for’, 
> ‘with’, etc. all become impossible input names, and very 
> likely cause errors in the browser unless you specifically check 
> for them, while they are not so strange or infrequent.

I agree that XPath imposes fewer constraints on field names, and 
that is one of the reasons why it was picked for XForms as an XML 
applications language. The user base for HTML tends to be more 
familiar with JavaScript and the expression syntax common across the 
family of languages derived from C. We also have the experience from 
VoiceXML which is closely analogous to HTML with menus and forms, 
and which uses JavaScript extensively for the forms data model. For 
HTML itself, the DOM1 object model exposes field names as JavaScript 
properties, e.g. document.forms[0].total for a field named "total". 
I haven't heard of any practical problems with name clashes, and it 
is easy to pick field names accordingly since these are only used 
internally and not exposed to end users.

> As for your datepicker example. I’m all for presenting the user 
> with a localised date representation, but I think it should submit 
> only an ISO date, and also make that representation available 
> through the DOM (or perhaps a Date object would be better). 
> Similarly, values for ‘min’ and ‘max’ should also be ISO 
> dates for this data type.

That would be nice and brings with it the very desirable notion of 
separating the internal value from how it is presented to the user. 
That is one of the major failings of existing HTML forms controls, 
and a challenge when it comes to providing a compatibility library 
for existing browsers. That may sound like a small detail, but 
consider the point of view of a website developer when faced with 
features that are supported on perhaps 10% of browsers compared with 
features that are supported on 99% of browsers. I am therefore 
putting considerable effort into how to emulate this separaration 
on existing browsers.

> I also don’t like too much fuzzy logic for different date input 
> formats, especially if you start considering that month notations 
> like ‘jan’ and ‘mar’ are very locale-specific (‘mar’ 
> is ‘maa’ in Dutch), it can get very complex; I would suggest 
> restricting the allowed values for manual input to yyyy-mm-dd, and 
> only one locale-specific notation (thus, not try to parse every 
> possible form). It would also be nice if this were dependant on my 
> locale and not the web site’s language/location.

This is perhaps more up to what end users want and less about us as 
web site developers. Meeting customer needs is very much a 
competitive issue. If the browser limited the input format in the 
way you describe web developers would rapidly find ways around that, 
e.g. by adapting text controls in place of the built in date 
control. I suggest that we should draw upon experience with 
spreadsheets, which are forgiving in the wide variety of date 
formats they accept, but which reformat the date to show what was 
understood by the system. Using the computer's setting for locale 
seems very reasonable, but even there I can imagine that for 
multilingual users, they might find it confusing if web page was all 
in English, but the dates had to be entered in Dutch.

> The XForms Transitional doesn’t have an ‘email’ input type 
> which I think is very important because 1. it provides a hook for 
> the browser to conveniently pop up your address book or do 
> type-ahead completion, and 2. it is one of the fields that are 
> most over-restricted with regular expressions usually. Similarly, 
> there should be an ‘url’ type, just like in Web Forms 2.0.

I agree and wonder what other data types would prove sufficiently 
valuable to standardize on. One consideration is whether the input 
could be described by a regular expression, in which case you could 
use a text control. For email addresses, there is the consideration 
of being able to offer users the means to pick addresses from their 
address book. For web mail applications, users would expect to be 
able to enter a list of addresses, in the same formats as they are 
used to. This suggests that there is a need for control over whether 
one or more addresses is permitted, and for the control to accept 
a range of address formats, and to reformat them as appropriate, in 
a manner analogous to date controls.

> The ‘editable’ attribute on the <select> contains a width 
> value, this seems a bit ugly to me, and confused me at first when 
> I saw the example (‘editable=12? what does that mean?’). I 
> understand the problem with the ‘size’ attribute, but think it 
> would be better to just derive the width from the content width of 
> the select, just like the regular HTML select box does, or use 
> CSS.

Yes, you could just have editable="editable" or editable="true"

> Final thoughts…
>
> Web Forms 2.0 focuses a lot on the DOM, too much in my opinion 
> (being used to the more declarative approach in Backbase), and the 
> proposed attributes in XForms Transitional seem very nice and 
> simple to use. However, XForms Transitional puts too little focus 
> on the DOM. Both should provide means to do the same thing, where 
> the DOM is suitable if you want to do more ‘power’-things the 
> declarative means can’t handle.

This is where it will be interesting to look at a synthesis of 
ideas, and to study the opportunities emerging from a variety of use 
cases in more detail, e.g. fully customizable presentation of error 
reports. Experience with Web Forms 2.0 on Opera shows some of the 
problem that can arise if full customization is not allowed: For 
instance the red box that appears when you try to submit the form, 
where the box shows the browser defined text "This value is not 
allowed by a script on this page" and then followed by the text 
passed with the setCustomValidity function. The application 
developer will want much greater control than that, and will resort 
to workarounds if the browser's new mechanisms aren't considered 
fit for the task.

The forminput event introduced by Web Forms 2.0 is nicer than 
hooking into keystokes and mouse clicks, and we already have the 
changed, focus/blur, and submit/reset events to play with. Another 
area of interest is to support the hierarchical arrangement of form 
data. XForms Transitional, for instance, associates a collection of 
field names with each fieldset. If there are multiple fields with 
the same name within the fieldset, then they are collected into an 
array, as as currently occurs for the form object. This is something 
that Web Forms 2.0 handles rather poorly.

> Also, I wonder how this is actually related to XForms

XForms Transitional is an incremental extension of the HTML4 markup 
and object model that enables developers to take advantage of the 
declarative power of XForms bind constraints whilst remaining within 
the framework of HTML4 and text/html. Developers can gain some of
the benefits of XForms without first having to learn about XML
namespaces, XPath and a whole new way of doing forms. XForms offers 
enterprise strength forms, and XForms Transitional provides a 
stepping stone to realizing that potential for when people are ready 
to make the transition to the power and flexibility of XML.

Regards,

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett