Re: Proposal for Extensions to HTML4

On Tue, 9 Dec 2003 andyh@collegenet.com wrote:
>>
>> The equivalent of XForms' <select1> widget is the HTML <select>
>> control, _not_ the <input type="radio"> control.
>
> Wrong.
>
> The XForms' <select1> tag indicates to the UA that the user is
> expected to select a single item from a list. How that list is
> actually rendered for the user is up to the UA [...].

How is that different from XHTML's <select>? Or rather, why do you say
that my equivalence statement is wrong? I don't understand how they
differ. Note that HTML4 (and my proposal) do not specify the
presentation of any of the Web form elements either; the conventional
rendering is just that, conventional. (Lynx, for example, can be
configured to render HTML <select> elements as lists of radio
buttons.)


>> here the controls are dotted all over the form in a structuraly
>> unrelated manner.
>
> Well that's one way to create a UI, though most people would
> advocate keeping individual elements in a selection close together
> so that users can comprehend the extent of the choices.

That's up to the UI experts to decide, but I'm not sure "most people"
actually would.

For example, Microsoft Windows' Add/Remove Hardware Wizard, on its
first panel, shows two radio buttons that are structurally unrelated,
with a descriptive label separating them. Similarly the Display
Properties control panel in Windows 2000, on its Effects page, under
Visual Effects, has a check box with a related drop down box. That
drop down box structurally separates the check box from its other
check boxes, but it is still semantically related to them.

The same is visible in multiple other applications (Opera,
Preferences, E-mail panel; Mozilla, Preferences, Advanced, Mouse
Wheel) and Web sites. A good example of a Web site that does this is
Bugzilla. Open a Bugzilla bug page:

   http://bugzilla.mozilla.org/show_bug.cgi?id=97806

...and scroll down to just below the big <textarea>, to the radio
buttons labelled "Leave as NEW" etc. They are structurally separated,
but semantically related.

Another example is at the bottom of:

   http://gleq.org/competition_registration/registration_form.html

Search for "Word-of-Mouth".

Or the New York Times login page:

   http://www.nytimes.com/auth/login

Search for "PROGRAMS FROM OUR PARTNERS".

Basically, this is something that, for better or for worse, is used
commonly enough that I cannot ignore it.


> But anyway, the theory is that layout is governed by stylesheets, so
> if you wanted your radio group widely spaced out in a vertical list
> then it would be possible.

The point is that this isn't presentational -- it's semantic. The
radio buttons or check boxes are related to the content near them.


>> In my experience, authors that are the target audience of the
>> proposal find imperative scripting easier to understand than
>> declarative scripting,
>
> and [are] therefore willing to ignore accessibility, portability,
> maintainability as well as the clarity of thinking and understanding
> that comes with data abstraction.

Yes, indeed. Most of this proposal's target audience are more than
willing to ignore all of the above. These are the same authors who are
finding going from <font> to CSS to be a huge leap of faith.

In practice, accessibility is quite good with well-written HTML forms,
so accessibility is not really an issue. (I don't see how most of
XForms' features make the accessibility any better or worse.) There is
no reason for scripting to make a site inaccessible, for instance.

Portability and maintainability are not actually a big deal either, in
practice. Portability between servers is not substantially easier with
XForms than with these extended HTML forms, since both allow the logic
to be abstracted from the content, and portability between clients is
dependent on wide implementation in deployed user agents. Similarly,
maintainability is possible today with HTML4 forms, and will not be
any harder with these extended forms (hopefully, with features such as
the repetition model, it will be a lot easier).

Admittedly, using XML Schema and separating the instance model from
the content can make the form easier to maintain for form experts, but
it raises the barrier to entry of writing forms to a high enough point
that many HTML authors are unable to follow.

The clarity of thinking and understanding that comes with data
abstraction, in my experience, is not something most authors care
about. While personally I think XForms' design is actually very nice
and clean, and I understand that it would make complex form design
easier for me to understand, I have been told by many people that they
don't "get" the concept of abstraction, and just want to tell the
browser what to do.

This is very well demonstrated by the aforementioned problem authors
have with moving to CSS. "I want my page to have green text, with this
piece of text to be bigger", is the way most people think, instead of
the generally "better" thought of "That's a header, that's a
paragraph; I want my headers bigger, and my paragraphs green.".

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

Received on Wednesday, 10 December 2003 09:03:43 UTC