Re: Proposal for Extensions to HTML4

> 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, though the author can gives hints through
@appearance. In a graphical browser the current conventions are that
appearance="full" will be rendered as a radio group and
appearance="compact" would be a drop down select list.

Actual presentation can be controlled through a stylesheet, of course.


> 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. In your scenario, the first choice is
between Pizza or Bread (or nothing), and only after that decision has been
made are we interested in the specific toppings/fillings. Placing the
toppings selection between Pizza and Bread visually interrupts that top
level choice. Now of course, in this simple example there are only a
handful of choices but as the options scale up, the UI becomes even harder
to comprehend and ever more wasteful of space and a worse user experience.

So therefore I don't care that an XForms UA does not render a <select1> as
a set of <dt> tags (and I'll leave it to the pedants to argue about the use
of a list element to represent this layout), I wouldn't want to inflict
this interface on my users in the first place.

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.


> Why would you change the _content_ in order to make a presentational
> change?

Well if we are allowed to quote technologies that are not fully realized
yet, then your answer about using XBL applies equally to XForms. Now XBL
adds yet more complexity and namespaces to the mix, which is were we come
to the same argument against XForms.


> In my experience,
> authors that are the target audience of the proposal find imperative
> scripting easier to understand than declarative scripting,

and therefore willing to ignore accessibility, portability, maintainability
as well as the clarity of thinking and understanding that comes with data
abstraction.


--
Andy Heydon

Received on Tuesday, 9 December 2003 20:58:00 UTC