Re: SELECT/ OPTION GROUPS with the SIZE attribute

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.

>  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?

> - everything with a shared
> group can be logically grouped together and this is purely considered a
> hint with  no suggested rendering semantic.

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.)

Adherence to "suggested rendering" stuff in the HTML spec
is a quality of implementation issue, not a conformance
issue.

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.

> 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>

Thanks for the details.

> 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?

Sorry; I misunderstood. I took your SIZE=4 example as evidence
that the proposal was unclear, rather than evidence that it could
not be implemented.


> 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?

While it may seem that this week is rushed, the process of
integrating WAI issues into HTML 4 has been going on since
the May meeting in Sophia.

The objection to moving WAI items post 4.0 is that HTML 4.0 is
the only scheduled deliverable of this working group. Anything
pushed past HTML 4.0 is at-risk.

Again, the history and "rules of engagement" are detailed at:
http://lists.w3.org/Archives/Member/w3c-html-wg/1997OctDec/0340.html

> 
> -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:29:46 UTC