Re: Proposal for Extensions to HTML4

On Wed, 10 Dec 2003 andyh@collegenet.com wrote:
>>>>
>>>> The equivalent of XForms' <select1> widget is the HTML <select>
>>>> control, _not_ the <input type="radio"> control.
>
> Look at your statement again where you say that <xforms:select1> is
> _not_ the equivalent of <html:input type="radio">. That is where you
> are incorrect. The <html:select> and <html:input type="radio"> both
> perform the same semantic purpose of letting the user choice a
> single item from a list. This is the semantic that <xforms:select1>
> describes and can be rendered as either of those two html elements.

Ok, fair enough. The equivalent of the XForms <select1> in HTML is
either the <select> element (for structurally adjacent options) or
<input type="radio"> (for structurally distant options).


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


> HTML's markup is geared to presentation controls

I don't see how this is the case. It is perfectly possible to render
controls in whatever fashion is wanted; there is no presentational
semantic involved.


> and therefore any development should fully utilize that fact (if for
> no other reason that a grep through the code will find the right
> controls). XForms markup is geared to semantics; to the intention of
> what the author wants to achieve and the presentation is totally
> separate.

This argument (especially given the "appearance" attribute) seems
strange. The two languages seem to provide the same control (indeed
the XForms one gives slightly more control, through its presentational
hint attribute), with the only exception being that HTML provides two
alternatives, one for structurally adjacent controls and one for
structurally split controls.


>> Microsoft Windows' Add/Remove Hardware Wizard, on its first panel,
>> shows two radio buttons that are structurally unrelated, with a
>> descriptive label separating them.
>
> Not a good example. The descriptive text under the labels, to a user's
> eye, are really part of the labels. Yes the buttons are spaced out, but
> there are no additional data entry controls between them.

They are still not structurally together. I'm not arguing that users would
care either way, I'm arguing that the XForms <select> or <select1>
controls are not able to structurally represent the UIs mentioned, whereas
the HTML4 controls are.

(Note that I am _not_ talking about the presentation, nor am I talking
about the semantics. I'm talking about the structure of the documents.)


>> Display Properties control panel in Windows 2000, on its Effects page,
>> under Visual Effects, has a check box with a related drop down box.
>
> But the dropdown does not appear under the "Use transition effects"
> check box. Anyway the list of visual effects are checkboxes and
> therefore not mutually exclusive or dependant on each other. So not a
> valid comparision.

HTML <select multiple> and XForms <select> are both equivalent to
checkboxes, the argument applies equally well to checkboxes as it does to
radio buttons. (In the case of XForms, I am basing this on the example in
section 8.1.10, which is similar to the Windows 2000 example above.)


>> Opera, Preferences, E-mail panel
>
> Better example in terms of presentation style, but poorly executed.

You won't get any arguments from me there. I was just trying to
demonstrate that I have a market need here, which I must address, and
which XForms does not solve for me. (It's not the only requirement
that XForms doesn't address; backwards compatibility is the main one.)


>> Mozilla, Preferences, Advanced, Mouse Wheel
>
> Best example. But again there's some poor implementation.

Again, no argument from me there. I'm not demonstrating good UI, I'm
demonstrating market need.

The two are often unrelated, unfortunately.


>> Open a Bugzilla bug page ... They are structurally separated,
>> but semantically related
>
> There is no vertical split between the radio buttons because the secondary
> input fields are over to the right of list as your eye scans the page.

There is a structural split -- the radio buttons could not be replaced by
an HTML <select> (or XForms <select1>) while keeping the same UI structure
in the markup. (You would have to have very hard-coded CSS styles for this
case, which would not interact well if the CSS was disabled or overriden.)


>> The point is that this isn't presentational -- it's semantic. The
>> radio buttons or check boxes are related to the content near them.
>
> Exactly, which is why XForms is all about semantics.

And yet in XForms, it is impossible to link the radio buttons or check
boxes with their structurally and semantically related controls. So by
this logic, HTML Forms is more semantic than XForms. ;-)


> XForms can still achieve the semantic for the form, so why claim that it
> is a failure of XForms that it cannot present information in a
> particular style? Surely that is a failure of our presentation
> technology and not the form?

Presentation here is completely unrelated, IMHO.


>> These are the same authors who are finding going from <font> to CSS to
>> be a huge leap of faith.
>
> And that is a sad indictment.

I'm not sure what you mean by a "sad indictment" in this context, but yes,
it is indeed a sad state of affairs.

Unfortunately, it is also not one that is going away any time soon.


>> (I don't see how most of XForms' features make the accessibility any
>> better or worse.)
>
> Because the form is described in semantics, not in terms of presentation.

Your implication appears to be is that HTML is presentational, which, as
is clearly stated in the HTML specification (see for example section
2.3.2), was certainly not the intent of the HTML working group, and is
not, in my opinion, the case.


> Back to our Pizza/Bread example. In XForms, there would be a declarative
> association between the first choice of Pizza or Bread and the secondary
> Topping or Filling question. The choice of Filling is not relevant
> unless Bread is selected, therefore a screen reader (for example) can
> completely ignore this part of the markup until that initial choice is
> made.

There is a similar statement in the Web Forms 2.0 version of the form [1],
in the shape of a dynamic setting of the appropriate disabled attribute
based on the selection of the radio button.

The XForms one uses XPath declarative scripting in the model:

     <bind nodeset="toppings" relevant="../dish = 'pizza'"/>
     <bind nodeset="fillings" relevant="../dish = 'bread'"/>

The Web Forms one uses ECMAScript imperative scripting associated with
the controls:

      <select multiple="multiple" name="toppings"
              onformchange="disabled = !dish[0].checked">
      ...
      <select multiple="multiple" name="fillings"
              onformchange="disabled = !dish[1].checked">

It would be simple to define a declarative subset of ECMAScript and
the relevant DOM attributes so that the Web Forms version would also
be declarative, but the value of doing so would probably be lost on
the typical Web Forms author.


> Alternatively a cell phone only has the real estate to ask one question
> at a time and so will use the response to the first one to determine the
> next one.

I don't see how a cell phone could do this based on this form. Could
you show how the form should be structured to allow this? (Especially
how this would be addressed by XForms rather than by HTML forms -- the
obvious solution of simply skipping all disabled controls would work
in both, as far as I can tell.)


> HTML4 does not have that explicit semantic, except tenously through
> scripting and do you really expect cell phones/PDAs to have to parse
> through script to decide what to do next?

Yes. I work for a company which targets phone devices as one of their
primary markets and it has been our experience that ECMAScript is more
useful to our users than XPath. It is one of the reasons Opera was
negative about XForms in its original PR Review comments.

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'm sure you've read about principles of least power, declarative
> forms can be parsed and processed in ways currently unimagined,
> scripted forms are isolated islands.

Of course. This is why for the more common tasks facing Web authors
today (as based on direct feedback from those authors), the proposal
offers completely declarative solutions. For the other less common
tasks, scripting is provided for, as in XForms, but, unlike in XForms,
it is treated as a first-class citizen, provided with powerful DOM
interfaces, and given free reign to solve the problems as the authors
sees fit.


>> Similarly, maintainability is possible today with HTML4 forms,
>
> But the reality of the vast majority of sites (with their <font>
> tags) have their generated dynamically by servers, which means that
> the UI is intractably linked with the business processes. This is
> maintenance hell.

That is not an intrinsic limitation of HTML, as far as I can tell. And
it is definitely not an intrinsic limitation of Web Forms 2.0, which
has addressed most of the reasons for the dynamic generation (by
providing data="" attributes on <form> and <select> elements, and
declarative repetition mechanisms).


> The problem with HTML4 forms (and is not addressed by your proposal)
> is that it is totally unsuitable for the complex business related
> forms.

Aboslutely. That is what XForms is for.

The problem with XForms is that it is totally unsuitable for the
simple non-business related forms.

That is what Web Forms is for.


> Those of us (and in your experience it is a small number, but it is
> not small in my world) who are traditional database and
> client/server programmers do "get" the concept of abstraction and
> the division of duties.

Absolutely. I am one of these people; I think XForms is a great
design. I've said so many times.


> So basically because there exists a "large" number of people who
> can't or won't understand some basic software engineering concepts,
> the rest of us have to suffer?

Who said you had to suffer? As the Web Forms 2 proposals says: "This
specification is in no way aimed at replacing XForms 1.0".


> What we are asking for is an implementation of XForms.

There are many, as working group members have pointed out to me
several times:

   http://www.w3.org/MarkUp/Forms/#implementations

I understand mozilla.org has stated they are very open to an XForms
implementation (provided it satisfies the same code quality
requirements as all mozilla.org contributions must, be it for CSS,
HTML, MNG, or any other technology, proprietary or not).

Microsoft have apparently no intention of implementing XForms (or, for
that matter, any further W3C technologies beyond what they already
have implemented), although they have not stated their reasons.

Yet other vendors, for example Opera, have stated both technical and
social reasons why they do not intend to implement XForms, and have in
the past suggested that if the issues they had raised were addressed,
that they may reconsider. Those technical issues (for example
dependence on technologies such as XPath) were not even remotely
addressed, which is why Opera has been persuing its own solutions, in
the shape of this Web Forms proposal.


> Implementation, through your proposal, of some of the XForms
> concepts by some browsers is only going to create FUD

Fear: I have spoken to people who have told me they tried to look at
XForms and were actually scared by its complexity.

Uncertainty: Other authors have expressed confusion as to why the W3C
is developing technologies that are non-backwards-compatible,
requiring them to learn whole new skill sets.

Doubt: Most of these authors have also told me they are unsure as to
whether they should bother, especially given IE's lack of development.

With all due respect, I don't really think Web Forms is going to
create any more FUD than is already present.


> and will possibly kill XForms in the minds of many people.

The target audience of Web Forms is basically the people to whom
XForms is _already_ dead.


I _like_ XForms. I think is is a very well designed model. I hope that
Web Forms being implemented on clients can be helpful to people who
are trying to implement XForms-to-Web-browser transforms; developers
have already told me that they think it will help them do this and
have given me suggestions on how to make Web Forms more helpful for
this task.

Cheers,
Ian

-- Footnote --

[1] The original form structure was:

   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

Represented with XHTML and Web Forms 2.0, this looks like:

   <fieldset xmlns="http://www.w3.org/1999/xhtml">
    <legend> What kind of food would you like? </legend>
    <fieldset>
     <legend>
      <label>
       <input type="radio" name="dish" value="pizza" checked="checked"/>
       Pizza
      </label>
     </legend>
     <label>
      Select toppings:
      <select multiple="multiple" name="toppings"
              onformchange="disabled = !dish[0].checked">
       <option value="cheese">Cheese</option>
       <option value="pepperoni">Pepperoni</option>
       <option value="anchovies">Anchovies</option>
       <option value="tomato">Tomato</option>
      </select>
     </label>
    </fieldset>
    <fieldset>
     <legend>
      <label>
       <input type="radio" name="dish" value="bread"/>
       Bread
      </label>
     </legend>
     <label>
      Select filling:
      <select multiple="multiple" name="fillings" disabled="disabled"
              onformchange="disabled = !dish[1].checked">
       <option value="tuna">Tuna</option>
       <option value="sweetcorn">Sweetcorn</option>
       <option value="mayonaise">Mayonaise</option>
       <option value="salad">Salad</option>
      </select>
     </label>
    </fieldset>
    <p>
     <label>
      <input type="radio" name="dish" value="none"/>
      None
     </label>
    </p>
   </fieldset>

The same structure can't be represented in XForms 1.0 as far as I can
tell, but the following close equivalent can:

   What kind of food would you like?
   (o) Pizza
   ( ) Bread
   ( ) None

   Pizza:
      Select toppings:
      [x] Cheese    [x] Pepperoni
      [x] Anchovies [x] Tomato

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

This would, I think, be represented as follows:

   <group xmlns="http://www.w3.org/2002/xforms">
    <model>
     <instance>
      <data xmlns="">
       <dish>pizza</dish>
       <toppings/>
       <fillings/>
      </data>
     </instance>
     <bind nodeset="toppings" relevant="../dish = 'pizza'"/>
     <bind nodeset="fillings" relevant="../dish = 'bread'"/>
    </model>
    <select1 ref="dish">
     <label> What kind of food would you like? </label>
     <item>
      <label>Pizza</label>
      <value>pizza</value>
     </item>
     <item>
      <label>Bread</label>
      <value>bread</value>
     </item>
     <item>
      <label>None</label>
      <value>none</value>
     </item>
    </select1>
    <group>
     <label>Pizza:</label>
     <select ref="toppings">
      <label> Select toppings: </label>
      <item>
       <label>Cheese</label>
       <value>cheese</value>
      </item>
      <item>
       <label>Pepperoni</label>
       <value>pepperoni</value>
      </item>
      <item>
       <label>Anchovies</label>
       <value>anchovies</value>
      </item>
      <item>
       <label>Tomato</label>
       <value>tomato</value>
      </item>
     </select>
    </group>
    <group>
     <label>Bread:</label>
     <select ref="toppings">
      <label> Select toppings: </label>
      <item>
       <label>Tuna</label>
       <value>tuna</value>
      </item>
      <item>
       <label>Sweetcorn</label>
       <value>sweetcorn</value>
      </item>
      <item>
       <label>Mayonaise</label>
       <value>mayonaise</value>
      </item>
      <item>
       <label>Salad</label>
       <value>salad</value>
      </item>
     </select>
    </group>
   </group>

I couldn't work out if there was a way to avoid having the "toppings"
and "fillings" elements in the instance data being included in the
submission (details of which in both cases have not been included)
unless they were relevant, so it isn't exactly equivalent, but that is
not really relevant to the argument above.

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

Received on Sunday, 14 December 2003 09:16:24 UTC