W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2004

[whatwg] Quick thought on the Combo Box problem...

From: voracity <subs@voracity.org>
Date: Wed, 30 Jun 2004 17:59:46 +1000
Message-ID: <40E272F2.2050003@voracity.org>
Lachlan Hunt wrote:

> Well, then what about a list of products, shirt sizes, instruction 
> steps, a shopping list... or, hell, why not even a list of ice cream 
> flavours or endagered species, etc.

All those might be valid in different contexts (that's why we have XML). They 
are valid when when we want the reader (or UA) to treat them specially. (Of 
course, the decision of when to use special treatment is subjective. It would be 
based on how commonly authors would --- or should --- use the concept, amongst 
other things.)

 >  My point is that you'll never be
> able to mark up every different kind of list there is, and in each of 
> those completely random cases I mentioned above, it does not change the 
> fact that they are either unordered or ordered lists, or maybe 
> definition lists.  The actual type of list (whether it be data, summary 
> points, etc...) should come from the content, however the structure, and 
> the semantics of it being a list comes from the markup.

You can markup any way you like. e.g.
<flavours>
<flavour>choc</flavour>
<flavour>strawberry</flavour>
</flavours>

or you could substitute 'ul' for 'flavours' or you could substitute 'li' for 
'flavour' or substitute both and leave the flavour meaning to an agreement 
between author and reader (be it human or machine). You could even use the 
dreaded 'type' attribute (since a tag is also a specification of type). (One 
proviso would be an empty flavours list.)

However, if you want the UA to handle the flavour list in a special way, you 
have to indicate that it's a list of flavours in _some_ way. Ditto for a list of 
choices for an <input type="text"> element. We _could_ use a <ul> with an id 
that we refer to in the input and child <li value=""/> elements. But this makes 
the meaning very dependent on context, and therefore harder for machines (and 
many humans) to understand. Alternatively, we could use a tag like <cl> which 
removes the problem of context at the cost of increasing the number of tags. But 
that cost is very small in comparison to the value of _this_ particular tag for 
(documents|forms|apps).

>   As for navigation lists, <nl> is being introduced in XHTML 2, maybe 
> Web Apps should include it aswell.

I wouldn't object, though I'm not sure how it would degrade (particularly if 
nesting is allowed).

>   For popup menus, however, Web Apps may have a requirement for a 
> seperate semantic structure, other than ul, ol, dl, or nl.  However, I 
> don't like the use of <popup> as has been suggested.  This reveals too 
> much about how it is presented in a GUI.  How does anything /pop up/ for 
> an aural, text or tactile user agent?  Perhaps something like option 
> list <optlist>, or choice list <cl> because a popup menu generally 
> provides a list of choices to the user to perform certain tasks (eg. 
> cut, copy, paste), or set options (show/hide toolbars, word wrap, 
> larger/smaller text size, etc.)

I agree, 'popup' is probably not appropriate. optlist and choicelist (or cl) are 
both good because they represent the concept more faithfully (well, in english).
Received on Wednesday, 30 June 2004 00:59:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:18 UTC