Re: Proposal for Extensions to HTML4

> >>
> >> The equivalent of XForms' <select1> widget is the HTML <select>
> >> control, _not_ the <input type="radio"> control.
> >
> > Wrong.

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.

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.
HTML's markup is geared to presentation controls 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.



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

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

> Opera, Preferences, E-mail panel

Better example in terms of presentation style, but poorly executed. I can
click on the Manage accounts button regardless of which item I select, and
indeed this button is not related to the "Use Opera" choice so why on earth
is it painted where it is? Also I can choose a specific mail client
regardless of the option selected. The name of the default email client is
static and would look nicer incorporated into the label, the use of a
dimmed text box does have the implication that some set of circumstances
exist where the field becomes active and the value can be changed by the
user. I presuming that this is not the case.

(Comments based on Opera 7.10 build 2840)

> Mozilla, Preferences, Advanced, Mouse Wheel

Best example. But again there's some poor implementation. The number of
lines field is enabled whenever "Use system default" is off, regardless of
which radio button is selected. Is the intention to make the text
larger/smaller by 1 line? If these controls are valid for all options then
they should not be positioned there.
Also the use of a drop down for the modifier key is poor because the
implication is that only one modifier is ever active, but really all of
them are valid and this control is serving as a visual navigation. The
major UI flaw is that you cannot easily compare the behavior for the four
types of modifier, it is tedious to verify that you have selected distinct
actions because the user is forced to memorize their choices. I can
thoroughly recommend Edward Tufte for more on this topic, either through
his seminars or books.

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

> Search for "Word-of-Mouth".

Checkboxes again. And again the secondary boxes do not disrupt the flow of
the list of items.

> New York Times login page:

Sorry that link didn't work for me, so cannot comment.


> 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. It was you who
introduced the definition list as a means to presenting information, I
presume because it has a nice "neat" presentation style that cannot be as
easily achieved through current stylesheet support. 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?


> 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 don't see how most of
> XForms' features make the accessibility any better or worse.) 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.
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.
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. 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? The "semantic" offered by HTML4
is that the Toppings are related to Pizza through a similar visible screen
location in the final presentation.
I'm sure you've read about principles of least power [1], declarative forms
can be parsed and processed in ways currently unimagined, scripted forms
are isolated islands.


> 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. I
use a 4GL tool to generate HTML pages and even with its high level of
abstraction, it is tedious and cumbersome (and requires a programmer) to
make UI modifications or even to track another hidden field. Now with my
XForms work, my server (and the same 4GL tool) is only generating and
processing XML and is spending fewer CPU cycles doing it.



The problem with HTML4 forms (and is not addressed by your proposal) is
that it is totally unsuitable for the complex business related forms. 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. Producing a
web based version of our product is the number one user request we receive,
but with current technology we are stuck. Instead we have serious
discussions as to whether to switch to Java or FlashMX or just struggle
through with HTML/JavaScript. None of which are pleasant outcomes or where
we want to be.

XForms is a breath of fresh air through the business development community.
The staging of business applications will become a very important part of
the net in the future because of the huge advantages in deployment and
support that can be reaped by vendor and customer. Both sides want to go
there but it is currently a very dangerous and difficult path to there from
here.

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?

What we are asking for is an implementation of XForms. With the use of
namespaces, XForms can coexist with HTML4/XHTML1, so if some people want to
continue with the old way, fine with me. But without significant
improvements in forms technology (which XForms is satisfying) then the rest
of us have an undesirable future.


Implementation, through your proposal, of some of the XForms concepts by
some browsers is only going to create FUD, and will possibly kill XForms in
the minds of many people. Maybe that is the hidden agenda here.


--
Andy Heydon



Footnotes
---------------

[1] Tim Berners-Lee
       http://www.w3.org/DesignIssues/Principles

Received on Wednesday, 10 December 2003 18:54:21 UTC