[whatwg] Re: several messages

[Matthew Raymond]

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>

    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.

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

    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>

    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>

    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.

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

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

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

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

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

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

    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.

    Hmm... That give me an idea:

    <cl id="cutcopy" data="cutcopy_items.xml" />
    <input type="text" name="d" context="cutcopy" />

> What do people think? Did I miss a critical use case?

    Not that I can think of offhand, but there are more qualified people 
in this mailing list to answer that question.