Re: SELECT/ OPTION GROUPS with the SIZE attribute (fwd)

Once upon a time Dan Connolly shaped the electrons to say...
>Scott Isaacs wrote:
>> Then why does this proposal define a rendering semantic that looks very
>> hierarchical to me?
>Because that is the solution that most appealed to the
>folks in the WAI HC WG that proposed it, I suppose.

A point I'd like to make.  I tried to be careful in my wording to use
'may' or 'might' and not 'will' or 'should'.  The examples given are
just examples of possibilities.  Without them we found people had a harder
time understanding the grouping being done.  

There are a variety of ways the grouping could be handled - from ignoring
it and displaying as always, to inserting non-selectable elements as
labels, to doing a true tabbed index or expanding list.  We've tried to
avoid telling UAs how to render it.  But we want to provide structure so
that UAs that DO want to do something special have a standard, valid means
to do so.

>>  If there needs to be a very simple grouping
>> mechanism, support a GROUP attribute (or something similar) on each
>> OPTION and not use a structural construct
>Thank you for providing a counterproposal.
>Dave? Al? Megazone? Comments?

This seems to be a slightly simplified version of the AXIS/AXES proposal.
Eliminating the OPTGROUP element.  It is actually something I'd though of
along the way.

But I think all of the objections to AXIS/AXES, which eventually caused us
to withdraw that proposal and go with a container element, would still hold.
It isn't as clear to users what is being grouped.  With a container it
is obvious how things are grouped.

And what about subgroups?  How would you run multiple Group elements?  This
appears to provide only one level of organization.

>Strictly speaking, all the rendering information in the
>HTML spec is hints/suggestions; i.e. SHOULD, not MUST.
>(I need to verify that, but that's my understanding.)

That is my understanding also.  And I have tried to word things carefully.

>So I expect that any solution to the long options list
>problem will carry a "suggested rendering" but no
>absolute requirements on user agents other than
>treating the new syntax as conforming HTML, i.e. not
>barfing.

That's been our anticipation.

-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com
For support requests: support@livingston.com  <http://www.livingston.com/> 
Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Received on Monday, 27 October 1997 21:35:01 UTC