[whatwg] Re: several messages

[voracity]

Matthew Raymond wrote:

> Ian Hickson wrote:
>> If backwards compatibility is not important:
>>    <p>
>>     <label>
>>      Select a breed:
>>      <input type="text" name="breed" data="breeds">
>>      <datalist id="breeds">
>>       <option value="Abyssinian">
>>       <option value="Alpaca">
>>       <!-- ... -->
>>      </datalist>
>>     </label>
>>    </p>
> 
> [snip] Seems rather backward compatible to me.

I agree. If it weren't, I wouldn't have supported it.

However, I think what Ian means is that the list won't render in non-JS pre-WF2 
UAs (would this apply to current versions of lynx and accessibility browsers?). 
I don't believe it's important to support the richer interface in that class of 
browser (since they would almost certainly implement WF2 if it became common), 
but I might be wrong.

>> If it is:
>>    <p>
>>     <label>
>>      Select a breed:
>>      <input type="text" name="breed" data="breeds">
>>     </label>
>>     <datalist id="breeds">
>>      <label>
>>       or select one from the list:
>>       <select name="breed">
>>        <option>Abyssinian
>>        <option>Alpaca
>>        <!-- ... -->
>>       </select>
>>      </label>
>>     </datalist>
>>    </p>

Hmmm, I don't mind this. It's nicer than the first example in the sense that I 
would not have to write any JS for either WF2 UAs or legacy UAs under any of the 
use cases I described earlier (with additional attributes). However, the first 
example is much cleaner for what is probably the most common case.

I'm not sure which I prefer. On these examples _alone_ I think I prefer the 
second (so long as WF2 _does_ submit 2 values). However, Matthew raises some 
interesting possibilities for choicelists/datalists.

> [snip] there's another way to accomplish the same thing:
>
 > [snip]
> 
>    <p>
>      <label>
>        Select a breed:
>        <input type="text" name="breed" list="breeds">
>      </label>
>      <label repeat="template" repeat-start="0">
>        or select one from the list:
>        <select name="breed" id="breeds">
>          <option>Abyssinian</option>
>          <option>Alpaca</option>
>          <!-- ... -->
>        </select>
>      </label>
>    </p>
> 
>    Here, the data is loaded from the <select> in a template. Since the 
> |list| attribute requires WF2 to work, and the repetition template 
> requires WF2 to prevent it from being rendered, the rendered template 
> and the list are mutually exclusive.

Hmmm, I don't know. Again, I find this less attractive because it uses an 
unrelated WF2 property (repeat) to get legacy and WF2 agents to render properly.

>    It may just be me, but it seems like the first and second examples 
> are intentionally written to disregard my suggestion of using the same 
> structure for both combo items and context menus. In fact, the whole 
> construction of this example seems to subtly undermine such an approach. 
> You have the element named <datalist> instead of <optlist> or <cl> 
> (short for "choice list"). You use the attribute name |data| instead of 
> |list|. But perhaps I'm overreacting...

I can't speak for Ian, but it looks like he's just trying to optimise things for 
_this_ specific function. You may want to explicitly suggest that you believe a 
choicelist can work well as a general element. (And also give a compelling 
argument for why you believe it should be used that way.)

>> Basically, we add a "data" attribute to <input> elements which applies to
>> the "text", "uri", "email", "number", "range", and date- and time- 
>> related
>> types. This attribute points to a <datalist> or <select> element (or 
>> maybe
>> any element).
> 
> 
>     Any element that handles lists: <select>, <li>, <table>, et cetera.

Almost all elements are a list of something, but it would seem a bit strange to 
point to a <p> that contains a set of <em>'s. So perhaps a restricted list like 
this is a good idea.

>  > The list of values that the UA can show as autocomplete
> 
>> values consists of all the <option> elements inside the <datalist> or
>> <select> element (as in, getElementsByTagName('option')). If those
>> elements have "value" attributes, they are used as the value. Otherwise,
>> the contents of the <option> elements are used.
> 
> 
>    Most webmasters will think that the |autocomplete| attribute would 
> handle this, only it currently handles values that the UA remembers for 
> you. Then again, this is a pretty common behavior for a combo box, so 
> perhaps such control of autocompletion is not necessary...

I'm not sure I understand the second sentence. Certainly with a combo box, the 
UAs autocomplete would never be on (because of 2 competing popup lists). 
Alternatively, autocomplete could take the form of highlighting entries in the 
WF2 UA that you've chosen before, and preferring those when it searches the list.

>> All the contents of <datalist> elements are hidden on WF2 UAs, and can
>> thus be used as the fallback rendering for legacy UAs. Controls inside
>> <datalist> elements are never successful in WF2 UAs. <datalist> doesn't
>> take any attributes other than the common attributes.
> 
> 
>    As I stated before, I don't like the idea of having a wrapper around 
> markup intended for legacy UAs, especially since it results in a greater 
> amount of markup on WF2-only pages. Compare:
> 
>    <datalist id="breeds">
>      <select>
>        <option>Abyssinian</option>
>        <option>Alpaca</option>
>        <!-- ... -->
>      </select>
>    </datalist>

It wouldn't look like that in markup for WF2-only. It would look like cl below, 
with 'datalist' substituted for 'cl'. Also, a problem with my original <combo> 
suggestion was that there was no _incentive_ to support legacy clients. Ian's 
second example deals with this.

>    ...Versus this...
> 
>    <cl id="breeds">
>      <option>Abyssinian</option>
>      <option>Alpaca</option>
>      <!-- ... -->
>    </cl>
> 


> [snip]
> 
>    Better idea:
> 
>    <cl id="calendar" data="calendar.xml" />
>    <input type="datetime" list="calendar" name="d" />
> 
>    It's much cleaner, and you don't get confused by the differing uses 
> of the |data| attribute, because it only has one use.

I agree. The dual use of the |data| attribute is confusing. I think Ian 
suggested it because it would parallel the |data| attribute on <select>. 
However, in all the examples discussed (not including my original <combo>), a 
datalist is not like a select since it is never displayed.

>    Hmm... That give me an idea:
> 
>    <cl id="cutcopy" data="cutcopy_items.xml" />
>    <input type="text" name="d" context="cutcopy" />

I still don't understand why you want <cl> to do both combo lists and context 
menus. You seem to be hinting at an important, widely applicable generalisation, 
but I can't tell what it is. For instance, why would you object to, say, a 
'choicelist' AND a 'datalist'? Parsimony can't be the reason, because it is 
countered by the bigger loss in clarity due to dual uses.