Re: Proposal for Extensions to HTML4

> > 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 and
therefore the code sets up a certain expectation. If you then have a style
sheet that in effect says "this orange is really an apple", it makes it so
much harder to understand the code because the source does not match the
final rendition. People in a project change and so earlier design decisions
get lost and the use of "clever" tricks impede the learning of new project
members.

Yes it is technically possible to provide any presentation to any HTML tag,
as is the case in XForms, but the level of development within HTML is much
lower because you are specifically indicating the type of control. You are
the one always arguing that the abilities of HTML authors cannot handle the
abstraction of XForms and yet you are arguing for such flexibility in the
presentation level. You cannot have it both ways.



> 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>

Add a bit of styling (for a graphical UA) for the <hint> and you have a
pretty good facsimile to the original dialog box. Everything is
structurally related and in a neater package than the HTML equivalent.



> 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">.



> 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. The 2.3.2 section talks
about presentation elements and attributes and I think you would be
hard-pressed to say the <input type=""> falls into that grouping.  I would
guess that the comments in the 2.3 section are aimed at getting people away
from <font> and other elements described in chapter 15 and into CSS, which
was the big new thing at that time. 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.



> 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.

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.



> 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.



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?".



> 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.



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.

In the XForms version, only the relevant toppings/fillings block would
typically be displayed, and hence the additional group labels would
probably be dispensed with.
(Also your first <group> is in the wrong place, it should be between
</model> and <select1>).


--
Andy Heydon

Received on Monday, 15 December 2003 18:44:32 UTC