[whatwg] Re: several messages

[Matthew Raymond]

voracity wrote:
> Matthew Raymond wrote:
>>> 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.

    My big question for this example is: "What markup ISN'T allowed in
the <datalist> element?"

[Snipped the part about using repetition blocks to had code intended for 
legacy UAs.]

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

    Do you mean to tell me that you honestly believe people won't do the 
following?:

    <datalist>
      <p>
        Your browser does not support Web Forms 2.0.
        Please download a copy of MNGZilla
        <a href="mngzilla.sf.net">here</a>.
      <p>
    </datalist>

    Well, it's not exactly what they'd put in it, but the point is that 
<datalist> could be abused in a similar way to repetition blocks.

    Furthermore, what happens if the <select> element doesn't have the 
same |name| as the <input>? Would it be valid in WF2 to include more 
than one <select> element in <datalist>? What happens if multiple 
<selects> have the same |name|.

    Not that this approach couldn't work if it had specific limitations 
and rules. It's just that it seems to confusing for the web developers 
to be workable. On the other hand, using a repetition template is 
powerful but easy to understand. My example may have used it for an 
unintended purpose, but there is no confusion about what works in a 
repetition block and what doesn't.

    On the other hand, I don't think I liked having my |list| property 
reference a <select> in a repetition template. I was exploring all the 
options, but that option raises too many question and just doesn't feel 
right to me. Better to duplicate the list contents.

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

    I believe I've expressed ideas with regard to the |context| 
attribute in previous messages adequately, but for clarity in this 
thread, I will repeat.

    The idea behind the |context| attribute, in its current form, is 
that lists created via <cl> can be used as context menus by using 
context="cl_id" in an element:

    <cl id="myMenu"><!-- Options go here. --></cl>
    <input type="text" context="myMenu" />

    So, basically, it works similar to the |list| attribute, except 
instead of clicking on a drop-down button, you perform right-click (or 
whatever operation you use to get context menus in your OS).

    That reminds me. I wanted the |list| attribute to work for controls 
other than <input>, like <button>. This would allow menus to come up 
when you click an image or a button or text rather than a UA-supplied 
button next to a textbox.

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

    This sounds like we're making up complex markup rules for the 
webmasters to memorize. The <option> elements are supposed to be inside 
a <select> element, but only when dealing with legacy-UAs. You can use 
some elements inside <datalist>, like <label> and <select>, but not 
others. You can use |data| to load options into a |select|, but not when 
the <select> is inside a <datalist>. "I" before "E" except after "C". 
While my <cl> + repetition template solution was a bit longer and 
repeated the option list, it never introduced this many rules to keep 
track of.

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

    See the above description of |context|.