Re: HTML forms, XForms, Web Forms - which and how much?

On May 3, 2007, at 3:51 AM, Mark Birbeck wrote:

>
> Hi Anne,
>
>> My question was what the equivalent XForms would be.
>
> I see. I had already showed it, but here it is again:
>
>> >  <xf:input ref="firstname">
>> >    <xf:label>First name:</xf:label>
>> >  </xf:input>
>> >
>> >  <xf:input ref="surname">
>> >    <xf:label>Surname:</xf:label>
>> >  </xf:input>
>> >
>> >  <xf:output value="concat('Hello, ', firstname, ' ', surname)" />

Is that actually a complete document? As in, you can put that in a  
file and load it, and it will work? I think that was Anne's question.  
I'm guessing it wouldn't, since, for example, there is no root  
element, and nothing defines the "xf" namespace prefix, so it's not  
namespace well-formed XML.

> There's already been a discussion on performing calculations like the
> ones above, using 'event-plus-script', but in my view a better
> illustration of the declarative approach is the simple example of
> mouseover hints or 'tooltips'. These are currently achieved in most
> browsers by using @title, but we all know that this is limited. Most
> Ajax libraries provide some kind of rich messaging feature, but you
> still need to wire the messages up to event handlers. XForms, however,
> provides the following:
>
>  <xf:input ref="firstname">
>    <xf:label>First name:</xf:label>
>    <xf:hint>
>      Please enter your <strong>first</strong> name.
>    </xf:hint>
>  </xf:input>
>
> It's a nice and simple way to indicate that you want some tooltip text
> displaying...but note that we don't say anything about the 'mouse in'
> or 'mouse out' events, which means this mark-up could be used
> unaltered in a system with no mouse, such as a telephone voice system.
>
> To continue the example, what if we wanted to add a hint to the output
> that shows the first-name/surname string, perhaps with an image in the
> tooltip? In XForms everything is nice and consistent, and we simply
> place another output in the hint:
>
>  <xf:output value="concat('Hello, ', firstname, ' ', surname)">
>    <xf:hint>
>      Hello <xf:output value="firstname" />, this is a picture of you:
>      <xf:output value="concat('http://pictures.com/', surname,
> '.png')" mediatype="image/*" />
>    </xf:hint>
>  </xf:output>

Seems like this is solely the result of the mouseover hint being in  
an element, not in an attribute. It has nothing to do with  
declarative capabilities. Furthermore, something similar could be  
done in Web Forms 2, modulo the limitation that title can only take  
text, not markup:

<output
     onforminput="value = 'Hello, ' + firstname + ' ' + surname;
                          title = 'Hello ' + firstname + ', this is a  
URL for a picture of you: <http://pictures.com/' + surname + '.png>.'">

Having tooltips that can express full markup, unlike the title  
attribute, could be useful. However, it is difficult, perhaps  
impossible, to design such a feature that degrades gracefully. One  
would have to consider the benefit of using arbitrary markup vs. the  
cost of having to enter the title twice to support older browsers as  
well. I think we all understand the accessibility and usability  
reasons not to make essential information available only through a  
mouseover hint, so we should keep that in mind as well.

>> Compatible with HTML4 and DOM Level 2 HTML with modifications to  
>> those
>> specifications that are required to support existing content is  
>> what I
>> mean. XForms doesn't build on top of that.
>
> But WF2 is not 'more compatible' than XForms just because you say it
> is. WF2 requires new features, so does XForms. But they both make use
> of DOM 2 Events, for example, and both can be incorporated into
> existing browsers, if implementers chose to. (In other words they are
> both an evolution, it's just that XForms solves a much larger range of
> problems, and so provides more features.)

WF2 is more compatible in two senses:

1) WF2 syntax is designed so that most constructs will degrade  
gracefully to reasonable behavior in browsers that only support  
HTML4. Clearly that is not true of XForms. The fact that WF2 does  
this better isn't just a matter of opinion.

2) WF2 is designed so that it can actually replace HTML4 forms and  
still support existing content, rather than being a second parallel  
mechanism. HTML4 forms support can't be removed without a  
syntactically compatible replacement. This too is not just a matter  
of opinion.

> I apologise. All I'm trying to suggest is that if we know that
> developers want to do simple things and complex things, then we seem
> to have two choices--create one language, or two.
>
> Creating two languages seems easy enough, but the problem arises when
> our developer wants to move from one 'mode' to another, i.e., they
> want to do simple tasks today, but as they learn more, and get more
> confident, they want to tackle more difficult jobs. Why should they
> have to switch languages? Surely the most desirable goal is one
> language that can cope with their evolution?

Wouldn't this be an argument to rescind XForms? Since it's not  
syntactically compatible with HTML4 Forms, it effectively requires  
two languages to exist, since HTML4 Forms support can't be removed.

> Now, you could argue that this is what WF2 is trying to do--extend the
> existing language (HTML forms) to cope with more complex tasks. But my
> argument is that WF2 has nothing at the 'top end', so really it gets
> nowhere the level of complexity that authors are having to deal with
> (as illustrated by interest in Ajax libraries).

What Ajax libraries do has very little to do with the kinds of  
features XForms provides. Ajax libraries allow asynchronous loading  
of data from the server to be used to replace some of the contents of  
a page without the need for a full page load (and often without any  
kind of submission action taking place). These days, they have also  
evolved to provide more app-like layout capabilities, animation  
features, drag and drop support, charting and graphics, and so forth.

> On the other hand, XForms is clearly able to cope with the more
> complex tasks.

It very much depends on whether your task is the kind of task XForms  
has thought of.

One of the few common features in Ajax libraries that actually is  
directly related to forms is the 'Ajax combobox', a text input field  
with a drop-down autocomplete list populated by a dynamic server  
query. Here's how to do it using Web Forms 2:

<input name="search" type="text" list="suggestions"  
onkeypress="list.data = '/suggest?prefix=' + value">
<datalist id="suggestions" data="/suggest"></datalist>

This would fall back to a vanilla text field, with the option to add  
the suggestion box by script if desired. I couldn't find an easy way  
to do this with XForms, but perhaps I'm missing something.

Regards,
Maciej

Received on Thursday, 3 May 2007 20:47:53 UTC