RE: SELECT/ OPTION GROUPS with the SIZE attribute

Then why does this proposal define a rendering semantic that looks very
hierarchical to me?  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 - everything with a shared
group can be logically grouped together and this is purely considered a
hint with  no suggested rendering semantic. The spec should define that
this grouping mechanism is to allow "chunking" of data, and we should
stay away from the hierarchical list concept and hierarchical grouping.
This leaves the door open to define a proper hierarchical list. Any
structural construct is going to limit any future proposal because we
will have created more compatibility issues. 

eg.

<SELECT>
  <OPTION GROUP="dark colors">Black
  <OPTION GROUP="dark colors">Navy
  <OPTION GROUP="light colors">White
</SELECT>

I thought my example serves as evidence that the proposal is under
specified and can't be implemented. Every time I reread the spec, I find
more issues and I have given many examples where the spec is missing
clear requirements. How much more evidence do I need?

I must be missing something about postponing this to another working
draft - what is the rush to put this in HTML 4.0 and what is the
objection to having another working draft post HTML 4.0 that addresses
this?

-Scott

> -----Original Message-----
> From:	Dan Connolly [SMTP:connolly@w3.org]
> Sent:	Monday, October 27, 1997 12:51 PM
> To:	Scott Isaacs
> Cc:	'w3c-html-wg@w3.org'; w3c-wai-hc@w3.org
> Subject:	Re: SELECT/ OPTION GROUPS with the SIZE attribute
> 
> 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:
> > eg.
> > 
> > <SELECT SIZE=4>
> > </SELECT>
> > 
> > If optiongroups were introduced, how would it effect the rendering?
> I
> > doubt the user would expect that they see only 4 rows at each
> expansion
> > level (actually I am unsure what the correct behavior would be).
> 
> I'll let Dave, Al, or somebody address that.
> 
> > I understand the goal of grouping list items for the purpose of
> > accessibility, but the current specification is going way beyond
> that
> > one requirement.
> 
> You are welcome to propose something less ambitious.
> 
> > 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.
> 
> > and as I previously said that it fails
> > to address many requirements for hierarchical lists.
> 
> The proposal does not need to address the requirements for
> hierarchical list, but only the stated accessability requirement.
> 
> >  That said, I agree
> > 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.
> 
> That's not how it works. There is no "later." There is
> "yes," "yes, but do it this way instead" and "no," but you have
> to take your "no" argument to w3c-wai-hc.
> 
> I have said this 4 times now. I'm getting tired of it.
> Please present novel evidence or stop objecting.
> 
> Please read in detail:
> 
> Message-ID: <34542DEF.1889@w3.org>
> Date: Mon, 27 Oct 1997 00:00:15 -0600
> From: Dan Connolly <connolly@w3.org>
> To: w3c-html-wg@w3.org, robert_pernett@lotus.com, w3c-wai-hc@w3.org
> CC: w3c-html-cg@w3.org
> Subject: WAI HC/HTML relationship [was: Minutes [was: Agenda for
> 971023
> HTML WG meeting]]
> http://lists.w3.org/Archives/Member/w3c-html-wg/1997OctDec/0340.html
> 
> -- 
> Dan Connolly, W3C HTML Working Group Chair
> http://www.w3.org/People/Connolly/
> phone://1/512/310-2971

Received on Monday, 27 October 1997 16:02:18 UTC