[whatwg] Re: several messages

[Ian Hickson]

Just to clarify -- in my post I included two syntax examples. They are
actually the same syntax, and both would be allowed. Whether you use one
or the other is a matter of choice (dependent on whether you want legacy
UAs to just have a text box, or have a text box and a select box).

On Wed, 30 Jun 2004, Matthew Raymond 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>
>
> How is this not backward compatible? For both UA types, the a single
> value is submitted under the name "breed". In both cases, the input
> submitted is available for editing in a textbox prior to submission.
> ECMAScript can be used to implement the drop-down menu on non-WF2 user
> agents. Seems rather backward compatible to me.

Yes, it's backwards compatible. I wouldn't have proposed it at all if it
wasn't! :-) However, the list is not available to legacy UAs.


>> 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>
>
> Well, this could be done, but it's not very clean markup, plus non-WF2
> UAs would be submitting two values under the same name. You could use
> scripting to solve this, but then what's the advantage over the first
> example?

The advantage is that in non-scripting UAs, it shows the list.

Again, both examples would be possible if we take my proposal.


> Then again, the webmaster may not have a problem with the way the values
> are returned to the server. In that case, however, there's another way
> to accomplish the same thing:
>
>     <cl id="breeds">
>       <option value="Abyssinian"></option>
>       <option value="Alpaca"></option>
>       <!-- ... -->
>     </cl>
>
>     <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">
>           <option>Abyssinian</option>
>           <option>Alpaca</option>
>           <!-- ... -->
>         </select>
>       </label>
>     </p>

This is equivalent to my proposal, except with list="" instead of data="",
<cl> instead of <datalist>, and using a repetition template to hide the
legacy content instead of <datalist>.

I don't mind using list="" instead of data="". In fact I'm not really
happy with using data="" since it isn't a URI like the other two data=""
attributes in WF2.

I prefer <datalist> to <cl> because I generally don't like short names,
especially for things that won't be used as much as <p>.

I much prefer using <datalist> rather than a repetition template, because
calling that a template is a misuse of semantics and could, e.g., severely
confuse assistive technologies.


> The only drawback to this method is that the list is repeated. But
> perhaps we can fix that:
>
>     <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>

Apart from the name of the "list" attribute, that would work with what I
proposed.


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

There was not supposed to be anything subtle about it -- sorry! :-)

I do not think that an autocomplete list and a context menu have any more
in common than an <ol> and a <select>.

Menus have to allow for nesting, for radio selections, check marks, icons,
status bar hints, onclick events, can be disabled, can be the default, can
have separators, can be linked to toolbar buttons, etc.

An autocomplete list in this context is just a list of values.


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

<li> and <table> don't have <option> children. By "any element" I meant
any element with an ID; you would still be looking for <option>elements
and would therefore still require a <datalist> or <select> somewhere in
there. I don't really see there being much advantage to allowing it to
point to any element to be honest, except it being easier to implement.


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

Yes, we really need an attribute name that implies "here are some more
values to add to the autocomplete list".

Although in the case of, e.g., a type="range" control, I would expect the
values to simply denote where the UA should put the snap-to tick marks.


>> 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>
>
>     ...Versus this...
>
>     <cl id="breeds">
>       <option>Abyssinian</option>
>       <option>Alpaca</option>
>       <!-- ... -->
>     </cl>

vs this, which is also allowed in my model:

     <datalist id="breeds">
       <option value="Abyssinian">
       <option value="Alpaca">
       <!-- ... -->
     </datalist>

I prefer this last one, if you don't need it to fallback for legacy UAs.
And if you do, there is the first one.


>> This doesn't address all the problems I raised earlier. In particular, it
>> is still possible for legacy UAs to end up submitting two values. It has
>> advantages though, like you can leverage the data="" attribute on the
>> <select> element:
>>
>>    <input type="datetime" data="calendar" name="d">
>>    <datalist id="calendar">
>>     <select data="calendar.xml"></select>
>>    </datalist>
>
> This doesn't make sense. Why should we have the <select> load the data
> when the <select> isn't even rendered? Granted, it would be a good
> attribute for a <select> on its own, but not in this context.

Whether something is rendered or not has no effect on anything else it
does. Something not being rendered just means it has display:none.

As an example, <input type="hidden"> is not rendered, but it still gets
submitted.


>> Or maybe we can simply allow data="" on the <datalist>:
>>
>>    <datalist id="calendar" data="calendar.xml"></datalist>
>>    <input type="datetime" data="calendar" name="d">
>
>     Better idea:
>
>     <cl id="calendar" data="calendar.xml"></cl>
>     <input type="datetime" list="calendar" name="d">

(I slightly tweaked the two examples above so they were both HTML, not
XML, and so that they both had the list before the input. This makes them
easier to compare.)

> It's much cleaner, and you don't get confused by the differing uses of
> the |data| attribute, because it only has one use.

Yes, I agree that "data" is a poor name for an attribute. Other than that,
though, they seem equivalent.

Ok, unless someone comes up with an even better name, assume my proposal
uses "list" instead of "data" as the attribute on input elements.


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

Web Apps 1.0 will do something list that.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'