W3C home > Mailing lists > Public > w3c-wai-hc@w3.org > October to December 1997

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

From: MegaZone <megazone@livingston.com>
Date: Mon, 27 Oct 1997 18:11:46 -0800 (PST)
Message-Id: <199710280211.SAA21908@server.livingston.com>
To: w3c-html-wg@w3.org, w3c-wai-hc@w3.org
Once upon a time Dan Connolly shaped the electrons to say...
>Scott Isaacs wrote:
>> There are ambigious cases in the current proposal. When you define a
>> size on a select is usually displays constrained to 4 rows at a time:
>> </SELECT>
>> If optiongroups were introduced, how would it effect the rendering?  I

There are other elements with multiple attributes that conflict.  In my 
vision of this, 'SIZE' would be incompatible with grouping being used.  They
are alternate methods of rendering.

If a vendor wanted to be ambitious they could present "SIZE" worth of 
selections at each level of grouping, scrolling if need be.  But HTML is
for structure, IMHO.

>> I understand the goal of grouping list items for the purpose of
>> accessibility, but the current specification is going way beyond that
>> one requirement.

It started way back with a conainter proposal.  That later evolved into
an AXIS/AXES based proposal which grew in complexity.  From that complexity
it evolved back into a container proposal which is between the two in
complexity and capabilities.  

We chose a container because end users easily understand "container == 
grouping".  It was felt that attributes on each OPTION or similar systems
were too conplex and confusing for end users.  And therefore would be less
likely to be used, or more likely to be used mistakenly.

With a container it is obvious what is part of which group.  And it should
be simple to implement.

>> I do not believe you can create an interoperable
>> implementation based on the spec
>That's argument by assertion, and it's not very constructive.
>Please present evidence.

Scott, you've mentioned the desire for a pure, flexible hierarchical list

To me this sounds like a *new* element.  Something like <BUTTON> being added
in 4.0.  Am I mistaken?  Did you mean modifications to <SELECT> that will
produce hierarchical list capabilities?

One of the overriding concerns in the development of this proposals has
been backwards compatibility with existing UAs.  The SELECT list should 
still be accessable to older UAs even with grouping in place.  In practice
that means that even newer UAs don't have to do anything special.  But
the grouping is there to be used for UAs that can make use of it.

If you do indeed mean a new element, how will modifications to SELECT
block the later development of a wider use element?  This proposal is 
fairly straightforward and provides many of the features authors use hacks
to achieve today.  Unless demonstratable interference with future features
can be shown, I don't think that is a sufficient reason to reject this

A hierarchical list element would be most welcome.  But, as Dan has said,
we're concerned with the present at the moment.  Anythign post-4.0 is vapor
right now, and putting off an advancement for the possibility of a future
element appears too risky to me.

>> with the WAI's intent that a grouping mechanism with broader reach than
>> accessibility should be defined.  I request that the group work on this
>> proposal in a more timely fashion rather than rushing to including this
>> in HTML 4.0. I assume a separate working draft can be published as the
>> group works through these issues.

I agree, and would like to work on the development of such an element, but
what about the present?  Can we count on an HTML 4.0+ in the short term?
I wouldn't think so.

The issue as I see it:

Does the present proposal produce unavoidable interference with the future
development of a truly multi-role hierarchical list element?

If not, then I do not see justification for eliminating this proposal.

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:18:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:35:00 UTC