Re: Use cases for a few elements: datalist

Hi Lachlan,

On Sep 6, 2007, at 3:52 AM, Lachlan Hunt wrote:

>
> Robert Burns wrote:
>> there are several elements that I haven't been able to get my mind  
>> around just from the draft or reading the discussions on this  
>> list. So to help me — and presumably other members — I'd like to  
>> start some discussion of those elements. Perhaps this thread  
>> should immediately fork into element-specific threads. Feel free  
>> to do so.
>> DATALIST [5]
>> -------------------------
>> The datalist element also looks very much like a select element,  
>> though with a slightly different presentational UI. Is this  
>> something that would be better handled through CSS? If not, why not?
>
> This provides the ability to markup combo boxes, where the user can  
> either select a predefined value or type their own.  These are  
> quite often simulated using various JavaScript and CSS techniques,  
> with varying degrees of success.  Datalist makes it significantly  
> easier for authors to use combo boxes and allows UAs to provide  
> more consistent interfaces.
>
> Use cases:
>
> * Many web sites that ask users for personal information often ask  
> for their title and typically provide a few default options like  
> Mr, Mrs, Ms, etc.  But there are many people who would prefer to  
> use, for example, Dr, Capt, etc. and its impractical to list every  
> possibility in a single list.  Many sites implement this by  
> providing an "Other" option in the list and an additional text box  
> nearby for the user to enter it.
>
> * Surveys often ask users questions and provide a set of the most  
> common options for the user to select.  e.g. "How did you find this  
> site?" is a fairly common question, with answers like "Search  
> Engine", "Advertisement", "Referral from a friend", etc.  Such  
> questions usually also provide an "Other" field for the user to  
> provide a different response.
>
> I use a datalist on my own "Echo Content" tool for selecting or  
> entering MIME types.  I list the most common ones in the list for  
> convenience and allow users to enter any other they wish.  It uses  
> a <select> with JavaScript as a fallback in browsers that don't  
> support <datalist>.  You can try it out in Opera, which has an  
> early implementation of it already.  The list will display when the  
> text box has focus.
>
> http://html5.lachy.id.au/output

My question about datalist was more about how such semantics should  
be addressed in HTML5. In other words we have an 'select' element  
that authors currently use to signify a user selection. Currently it  
does not easily support other selections. Authors and users may also  
elect to present the 'select' element in different ways. So my  
question about datalist is more about why we want to introduce a new  
element rather than providing more flexibility for the existing  
select element.

For example, the 'select' element could have a boolean attribute  
added for allow 'other'. Setting the boolean could allow users to  
select an "other....' menu item and be provided with a modal dialog  
to enter other. Such a boolean would address some of the use cases  
you mention. To address the other use cases, we could liaison with  
the CSS WG to add *select* specific properties for presentation. A  
'select' element might be presented as a combolist or as an editable  
browser/list view. or as a pop-up menu with the before mentioned  
'other...' menu item.

So I'm more trying to understand why a new element with an entirely  
new name is preferred over adding better support for the existing  
'select' element. Adding the improved support to the select element  
would allow it to degrade gracefully automatically. Also in this case  
and backwards compatibility aside, I can't imagine why we would want  
two separate elements — "select' and 'datalist' — to allow users to  
make a selection.

Take care,
Rob

Received on Thursday, 6 September 2007 20:11:20 UTC