Re: Proposal for Extensions to HTML4

I renamed the draft to Web Forms 2.0 (with 1.0 being HTML4 Forms). I
hope this name is less confusing. I have also further edited the
XForms part of the introduction so that it is less controversial. I
hope these changes help reduce the issues that were raised.

On Mon, 8 Dec 2003 andyh@collegenet.com wrote:
>
> Imagine that you have a HTML page with a set of radio buttons, but
> you realize that the number of options has increased to a point
> where it is not acceptable to use that UI element and a dropdown
> select box is more appropriate. So your UI specialist hunts down a
> developer who trawls through a bunch of perl code and starts
> changing <input type="radio"> into <select> and <option> tags.

In a well designed form, the markup doesn't need to change at all.

There is nothing that forces a <select> button to look like a list
box. It could easily look like a radio button set. That is a
presentational issue, and therefore belongs in the style sheet.

Using a styling technology such as XBL or BECSS [1], all that would be
required to turn a select from a set of radio buttons would be the
following change to the stylesheet:

   /* remove: */
   select { binding: radio-group; }

   /* add: */
   select { binding: list-box; }

No change to the markup need occur at all.

This is assuming that the author used the appropriate <select> element
in the first place. The equivalent of XForms' <select1> widget is the
HTML <select> control, _not_ the <input type="radio"> control.

The "radio" control is for cases such as this:

   What kind of food would you like?

    (o) Pizza
       Select toppings:
       [x] Cheese    [x] Pepperoni
       [x] Anchovies [x] Tomato

    ( ) Bread
       Select filling:
       [x] Tuna      [x] Sweetcorn
       [ ] Mayonaise [x] Salad

    ( ) None

...where the controls are dotted all over the form in a structuraly
unrelated manner. Semantically, the radio buttons form a group, but
structurally, they are separated by related controls. (As far as I am
aware, XForms cannot represent this form. I hope I'm wrong! [3])

When the controls are not separated in this way, then the <select>
element is to be prefered.

I've added a section to explain this:

   http://www.hixie.ch/specs/html/forms/web-forms#radioSelect

Please let me know if it is unclear.


> Meanwhile in our XForms implementation, our UI specialist opens a
> html page and changes @appearance="full" to @appearance="minimal".

Why would you change the _content_ in order to make a presentational
change? That seems wrong to me.


>>> The concept of a null value is very important
>> This is simply a matter of backwards compatibility with HTML4.
>
> Which is an example of why HTML4 is broken. Null values just cannot
> be ignored.

An interesting point. Without sacrificing backwards-compatibility,
though, I don't know how to solve this. Maybe an attribute on the
form, requesting that all controls (even unsuccessful ones) be
submitted, with the unsuccessful ones having the value ""?

In XForms, how would a server deal with the case where a field was not
mentioned (due to a broken UA or malicious user)? Would the processor
handle that case as if the value had been specified but left blank, or
would the server have anomalous behaviour?

I'm trying to work out what the practical impact of this is on Web
servers. As it is very poor design to let the (inherently untrusted)
input determine how the server proceeds, I would think it would make
sense for the server to be directed by its own list of expected
fields, and if those fields are not in the input, then to treat them
as the empty string.


>> Help attribute
>
> The implementation of the XForms help element (just like everything)
> is up to the UA. A keyboard driven interface will use F1 as normal
> (and general users do not distinguish between UA help and
> application help), whereas a PDA would do something different.

Right, the same would be the case for the help attribute in this
draft. I'm not sure how the user would find this help discoverable.


>> You don't submit a form to a Web service (how on earth would the UA
>> know how to render the returning envelope?)
>
> Because the data and UI are separated!
>
> An example would be a zipcode resolver, where after a user has
> entered an address a request is made to a service/resource that
> returns the correct zipcode that is copied into the user's data.
> There is no need for the user to do anything.

Ah, you are referring to the <submission replace="instance"> case. My
bad, I thought you were referring to the replace="all" case.

The idea of submitting to a script that just returns a new data set
with which to seed the form is an interesting one. I'll have to think
it over, but I think I see a way to make it work in this proposal.


>> Hooking a little script into the submit event of a form that
>> cancels the submission and then does it manually using the
>> aformentioned interface allows this system to be used for all
>> manner of REST-based Web services.
>
> And therein lies the problem. Just because we can do it with "a
> little bit" of script doesn't mean to say that we should continue
> doing it. Afterall isn't everything just a little bit of machine
> code? It's almost 2004 and application development should be getting
> easier and clearer. Machines can write code.

Whether the code is declarative XForms actions and XPath or imperative
ECMAScript and DOM is a matter of personal taste. In my experience,
authors that are the target audience of the proposal find imperative
scripting easier to understand than declarative scripting, which is
why the rarer use cases are left for the author to solve using the W3C
DOM and ECMAScript instead of requiring that all authors master XPath
and the concept of data abstraction.


Thanks for your comments so far! They have been very helpful.


-- Footnotes --

[1] XBL/BECSS is slightly outside of the CSSWG charter, so a new task
force or working group would be required [2] to persue this technology
in a W3C context. In the meantime, the latest version of the XBL spec
is available at:
   http://www.hixie.ch/specs/xbl/xbl
While this technology is obviously not required to implement XForms or
HTML forms, it is, in conjunction with the 'appearance' property of
the CSS3 UI module, one of the most effective and customisable ways of
implementing UI widgets in Web browsers. It would probably be the
simplest way of implementing XForms in Mozilla, for instance.

[2] Due to W3C process rules, I believe I'm not allowed to say whether
or not such a working group actually is being requested. See also:
   http://lists.w3.org/Archives/Member/w3c-html-cg/2003OctDec/0054.html

[3] This was originally brought up in January 2001. See point 4 of:
   http://lists.w3.org/Archives/Member/w3c-forms/2001JanMar/0015.html

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 9 December 2003 08:50:37 UTC