W3C home > Mailing lists > Public > www-forms@w3.org > January 2004

Re: Proposal for Extensions to HTML4

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 6 Jan 2004 00:21:29 +0000 (UTC)
To: andyh@collegenet.com
Cc: www-forms@w3.org
Message-ID: <Pine.LNX.4.58.0401052346260.13203@dhalsim.dreamhost.com>

On Mon, 15 Dec 2003 andyh@collegenet.com wrote:
> > >
> > > The problem with saying that a <html:select> can be presented as a
> > > radio group and <html:input type="radio"> as a drop down selection
> > > list through a stylesheet is that it makes the maintainance so much
> > > harder and obtuse.
> >
> > I don't understand why it is any harder than in XForms. Could you
> > expand on this?
> The HTML elements describe the exact representation of a control

This is a misconception. HTML elements are just as far from presentation
as XForms elements are. I'm not sure why you say otherwise.

It is true that HTML form elements have de-facto default renderings, but
when XForms becomes popular, the same will happen there: UAs end up having
to closely mimic each other or else cnn.com will look out of shape, and
your users will complain (or whatever, that's just an example).

This is a natural result of a technology maturing and being dominated by
one implementation (Netscape 4.x, in the HTML forms case). Authors target
that implementation, depend on its behaviours despite them being
UA-specific, and competing products are forced to mimick the supposedly
UA-defined parts in order to stay relevant.

> > They are still not structurally together. [snip] I'm arguing that the
> > XForms <select> or <select1> controls are not able to structurally
> > represent the UIs mentioned, whereas the HTML4 controls are.
> Err, so this XForms fragment is not what you want?
> <xf:select1 ref="task" appearance="full">
>       <xf:label>Select the hardware task you want to perform, and then
> click Next.</xf:label>
>       <xf:item>
>             <xf:value>A</xf:value>
>             <xf:label>Add/Troubleshoot a device</xf:label>
>             <xf:hint>Choose this option if you are adding a new device to
> your computer or are having problems getting a device working.</xf:hint>
>       </xf:item>
>       <xf:item>
>             <xf:value>U</xf:value>
>             <xf:label>Uninstall/Unplug a device</xf:label>
>             <xf:hint>Choose this option to uninstall a device or to prepare
> the computer to unplug a device.</xf:hint>
>       </xf:item>
> </xf:select1>

I retract that particular example. The others stand.

> > HTML <select multiple> and XForms <select> are both equivalent to
> > checkboxes,
> Yes, <html:select multiple> and <xforms:select> are equivalent.
> But they are _not_ equivalent to checkboxes.
> The use of a checkbox in a multiple selection list is just a (relatively
> recent) presentation style that is friendlier to the user. Under Windows,
> the check boxes are controlled through the LVS_EX_CHECKBOXES style on a
> List-view control and appear _within_ the border of the list box widget.
> There is no way to separate them out.
> Individual checkboxes (as in the W2K Display Properties panel) are separate
> and distinct controls equivalent to <html:input type="checkbox"> and
> <xforms:input xsi:type="xsd:boolean">.

Checkboxes with different names are distinct controls. Checkboxes with the
same name have exactly the same semantic as a multiple select box, the
only difference being that they can be structurally separated.

This is clear when you examine the possible outputs sent to the server,
for instance.

>> Your implication appears to be is that HTML is presentational
> HTML forms are presentational because they are focused on widgets, you have
> to specify the type of control on the input tag.

Well, HTML4 forms have very few types, so the de-facto default renderings
can make it appear that way. The Web Forms 2 proposal shows that this is
not really the case though -- the types do represent types, not widgets.

For example you don't say type="drop-down-calendar" or type="spin", you
say type="date" or type="number".

> Anyway your original example uses the very presentational aspects
> (<DL></DL>) that this statement is guarding against. There is absolutely
> no purpose for using <DL><DT><DD> in your document other than as
> shorthand for achieving a certain look. Your form is not a definition
> list.

Agreed, my example had a poor choice of elements for grouping.

> > The Web Forms one uses ECMAScript imperative scripting associated with
> > the controls:
> The problem with scripting is that anything _is_ possible and it cannot be
> guaranteed that the @onformchange does something as simple as your example.
> Therefore are UAs expected to be supremely clever, or are they more likely
> to stick this in the too hard-to-handle pile and move on. For example, you
> could just have easily have written:
>       <select multiple="multiple" name="toppings"
>               onformchange="disabled = dish[1].checked">
>       ...
>       <select multiple="multiple" name="fillings"
>               onformchange="disabled = dish[0].checked">
> or
>       <select multiple="multiple" name="toppings"
>               onformchange="set_disabled()">
>       ...
>       <select multiple="multiple" name="fillings"
>               onformchange="set_disabled()">
> All of which makes it harder, if not practically impossible, for a UA to
> determine the relationships and dependencies between controls.

Yes. This, in practice, is not a big deal. You just run the script. Even
phones have JavaScript engines now -- they have to, in order to render
the Web usefully. Since the power is there, using it seems sensible.

Once you've run the script, you can tell what is disabled and what is not,
and can skip the disabled ones (if that is what the stylesheet requires).

> XForms processors are more spreadsheet like in that they can determine the
> dependencies between controls and hence questions are presented in the flow
> when they become relevant.

While I understand this is theoretically possible, I have yet to see an
example that actually uses this feature. I would be interested in seeing
one. (I mean an actual UA that does this, not the markup for it.)

Also, most Web authors would be much more comfortable actually coding
those presentation aspects themselves, as then they can control it in
detail. Control is important to most Web authors; just look at the
questions of the kind "how do I prevent people from zooming my Web page"
in Web developer forums.

HTML4 + DOM + CSS + ECMAScript gives them this control in a way they can
understand and work with.

> > Indeed, as was just pointed out to me, most phone Web browsers don't
> > even support XML, let alone XPath, yet they support HTML, ECMAScript
> > and the DOM.
> I would suspect that this is historical because the latter three are
> older and display a more immediate need. If the history of our industry
> shows anything then it will only be a matter of time before XML and
> XPath and other technologies are implemented, so I'm not sure what your
> argument is here.

My argument is that _right now_ they are not there. Right now, XForms'
requirements are not implemented on phones. HTML4 forms are implemented,
writing incremental improvements to those features is cost effective and
can be done using existing deployed technologies today.

> I am well aware of the current XForms implementations. The issue is that
> there are no major browser vendors on that list. I fully appreciate MS
> is not going to do anything but follow their own agenda.  And other
> browser vendors punting on W3C recommendations only reinforces their
> approach. A "Web Forms 2.0" proposal has no more chance of being
> implemented by MS than XForms, so again the same argument applies: "why
> bother?".

By that line of argument, we might as well give up and go home.
Unfortunately that puts me (and my colleagues) out of a job, so it's not
really an attractive option.

> > The problem with XForms is that it is totally unsuitable for the
> > simple non-business related forms.
> >
> > I have spoken to people who have told me they tried to look at
> > XForms and were actually scared by its complexity.
> This is a topic I would like to explore further, but probably in another
> thread, and probably after the holidays as I'm going to be offline for a
> couple of weeks.

I would be very interested in discussing this.

As a starting point, the comments on the recent Slashdot article reviewing
Micah's excellent XForms book:


First comment:

| xforms is indeed intriguing and anyone developing a complicated web
| tool could find this technology a godsend. However from what I've seen
| it's extremely complicated (on the scale of p3p) and difficult to use.

These are the authors I am targetting with Web Forms.

> In the footnote, in theHTML example you are using <fieldset> to group a
> single radio button and a corresponding <select>. But those inner
> <fieldset>s cannot be treated as individual and automonous blocks. A
> non-graphical browser would have to go down into each block to find all
> of the "dish" radio buttons in order to present a meaningful prompt. So
> I'm not sure what is really gained. Nor is it a model that lends itself
> to further relationships, eg. what if there was another later question
> that was dependant on an answer of "pizza", or what if there was a
> follow up question on the type of cheese? You don't have to scale very
> far before you hit the limitations of HTML forms.

You don't _have_ to use radio buttons in this way, you can use a <select>
instead an limit yourself to XForms structures. The point is simply that
this is something HTML4 can do, which XForms can't, despite it being used
on the Web today.

Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 5 January 2004 19:21:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:11 UTC