Re: some technical thoughts about incremental improvements to forms

On Tue, 5 Sep 2006, Lachlan Hunt wrote:

> Dave Raggett wrote:

>> The HTML working group would like to import the XForms elements 
>> into the HTML namespace so that authors don't have to provide 
>> namespace prefixes. This presents some problems for documents 
>> delivered as text/html, since existing browsers would treat input 
>> as an empty element. This could be avoided by changing to a new 
>> element name, or by introducing attributes in place of child 
>> elements.
>
> Why do we even need to attempt to retrofit the XForms syntax into 
> HTML?  Why can't we work with the existing markup constraints and 
> reuse existing structures, where possible.

One consideration is syntax, the other is functionality. My point 
was that both HTML4 and XForms define an input element, albeit with 
different syntax. That's fine if they are in a different namespace, 
but there has been pressure to avoid the need for the namespace 
prefixes, hence the plan to import XForms elements into the HTML 
namespace. This would cause difficulties for existing browsers in 
the specific case of the input element. The work around is to either 
stick with input as an empty element and add new attributes or to 
choose a different element name. If we are open to using a new 
element name then we can avoid the awkwardness of the HTML4 
input/label elements, and enable easier to use and more extensible 
markup.

When it comes to functionality, I believe it is worth discussing
the requirements for different kinds of developers and for a range
of forms from simple to complex. It should be possible from a
technical perspective to provide a smooth learning curve from
beginners to advanced developers.

>> Internet Explorer honors the /> syntax for empty elements whereas 
>> Firefox and Opera, for instance, do not.
>
> IE only honours that for its non-standard, pseudo-XML nonsense 
> known as XML Data Islands.

My tests used well formed XHTML together with non-html elements,
but without the <xml></xml> element that most people think of
when talking about XML data islands.

It is practical to work around these technical problems with a
little script code. For IE and elements that aren't in an XML
namespace, you can insert them into the HTML namespace. For
other browsers you can likewise use the outerHTML property to
detect the /> syntax and then move the content after the element.
For a practical demonstration, see the code in:

              http://olav.dk/wf2/wf2/wf2.htc

and its use to support the WebForms output element in:

              http://olav.dk/wf2/demo/output.asp

That happens to rely on the non-standard CSS behaviors mechanism to 
invoke the script, and only works on IE and Opera, but it could have 
easily been written to work across a wide range of browsers using 
the script element. Similar approaches have been used to support
XForms in existing browsers.

Ideally, Firefox and Opera would follow IE by recognizing the />
syntax. I would also like to see closer agreement on the use
of DOM Node properties such as nodeName, localName, prefix and
namespaceURI.

>> I don't think the HTML4 form element is needed, as it can be
>> replaced by elements that describe how and where to submit the
>> data.
>
> WF2 allows submit buttons to have their own method and action 
> attributes for that purpose.

Yes, but I think that further discussion is needed on the ability
to support structured data as is already the case for both XForms
and VoiceXML. In addition, it would be valuable to take a look at
the mapping between the XPath and JavaScript data models. This
could bring several benefits including simpler implementations,
a more familar syntax, greater extensibility through script
defined functions, and the choice between using JSON and XML for
initializing and submitting data.

Finally, if developers care about the user experience, they should 
be willing to use a little script to ensure backwards compatibility 
with a wide range of existing browsers. The noscript element can be 
used together with CSS to deal with the cases where scripting is 
disabled, for example, by directing users to a non-scripting version 
of the page, or by providing a simplified version of the form. Rich 
Web applications tend to make clever use of scripting, independent 
of forms, but it is still important to provide fallbacks for the 
non-scripting environments. My point is that we no longer have to
feel the need to be strictly backwards compatible for the case
where scripting support isn't available.

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

Received on Monday, 4 September 2006 17:01:10 UTC