[whatwg] Re: several messages
mattraymond at earthlink.net
Thu Jul 1 04:46:04 PDT 2004
> Matthew Raymond wrote:
>>> If it is:
>>> Select a breed:
>>> <input type="text" name="breed" data="breeds">
>>> <datalist id="breeds">
>>> or select one from the list:
>>> <select name="breed">
>>> <!-- ... -->
> 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
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
> 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
Your browser does not support Web Forms 2.0.
Please download a copy of MNGZilla
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">
>> <!-- ... -->
> 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
> 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|.
More information about the whatwg