[whatwg] Re: several messages

[Matthew Raymond]

Ian Hickson wrote:
> 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.

    Is |list| okay, then, or would you prefer another name? It's not a 
big deal to me, but |list| seems the most logical name.

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

    Understood, thought I think I'd prefer the name <optlist> if we're 
going to have longer names.

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

    I've been thinking about this. I was wondering if we couldn't 
introduce elements specifically for handling legacy materials:

    <legacy value="Web Forms 2.0">
      <!-- Put your non-WF2 markup here. -->
    </legacy>

    The <legacy> element would be used to hide content that does not 
apply to the browser that supports the standard listed in the |value| 
attribute. Similarly, we could have an element that does the opposite:

    <specific value="Web Forms 2.0">
      <!-- Put your WF2-only markup here. -->
    </specific>

    This second element obviously wouldn't work of non-WF2 clients, but 
it could be used for all clients that implement standards on top of Web
Forms 2.0. In combination, the two elements could be used to ensure new 
or proprietary standards can be used without fear of conflict:

    <legacy value="Web Apps 5.5">
      <legacy value="Web Apps 1.0">
        <br />
      </legacy>
      <specific value="Web Apps 1.0">
        <ultrawidget1 />
        <ultrawidget2 />
        <ultrawidget3 />
      </specific>
    </legacy>
    <specific value="Web Apps 5.5">
      <ultrahypermegawidget />
    </specific>

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

    Really? /me scratches his head...

    Your model supports calling the list from a <select> within a template?

>>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! :-)

    Yeah, I was about to say, if you thought that was subtle, you need 
subtle lessons. ;)

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

    Okay, you just described the menu features in XUL, and yet you have 
repeatedly stated that you don't know if the XUL markup is the best way 
to represent this. Every time I try to suggest a simpler or more generic 
method of supporting menus, this seems to happen. Aside from changing 
the name of the <menu> element so that it doesn't conflict with the 
depreciated HTML 4.01 element of the same name, we could drop the entire 
XUL menu model right into HTML with no conflicts. The only problem I can 
see with this is that some of the people in W3C will offer it up in high 
sacrifice to the semantic gods.

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

    I don't have a problem with the |context| attribute pointing to the 
ID of a different structure. I was just worried about getting this stuff 
past the Semantic Nazis.

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

    I was generally hoping we could get a model for prepopulating a 
number of different structures. This might be useful when used in 
conjunction with the repetition model...

> vs this, which is also allowed in my model:
> 
>      <datalist id="breeds">
>        <option value="Abyssinian">
>        <option value="Alpaca">
>        <!-- ... -->
>      </datalist>

    Yeah, this was pointed out in another message.

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

    Yeah, but as you just pointed out, <datalist> doesn't need the 
<select> for WF2 UAs, and |data| only works in a WF2 UA, so the example 
you suggest is inferior to the following:

    <input type="datetime" list="calendar" name="d">
    <datalist id="calendar" data="calendar.xml"></datalist>

    By introducing |data|, you threw legacy rendering out the window.

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

    /me just up and down in glee, with "We are the champions" playing in 
the background.

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

    Yeah, file it under "random brainstorming".