- From: voracity <subs@voracity.org>
- Date: Thu, 01 Jul 2004 16:57:26 +1000
Matthew Raymond wrote: > 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> > > [snip] Seems rather backward compatible to me. I agree. If it weren't, I wouldn't have supported it. However, I think what Ian means is that the list won't render in non-JS pre-WF2 UAs (would this apply to current versions of lynx and accessibility browsers?). I don't believe it's important to support the richer interface in that class of browser (since they would almost certainly implement WF2 if it became common), but I might be wrong. >> 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. > [snip] there's another way to accomplish the same thing: > > [snip] > > <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. 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. > 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... 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.) >> 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. Almost all elements are a list of something, but it would seem a bit strange to point to a <p> that contains a set of <em>'s. So perhaps a restricted list like this is a good idea. > > 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... I'm not sure I understand the second sentence. Certainly with a combo box, the UAs autocomplete would never be on (because of 2 competing popup lists). Alternatively, autocomplete could take the form of highlighting entries in the WF2 UA that you've chosen before, and preferring those when it searches the list. >> 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> 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. > ...Versus this... > > <cl id="breeds"> > <option>Abyssinian</option> > <option>Alpaca</option> > <!-- ... --> > </cl> > > [snip] > > 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. I agree. The dual use of the |data| attribute is confusing. I think Ian suggested it because it would parallel the |data| attribute on <select>. However, in all the examples discussed (not including my original <combo>), a datalist is not like a select since it is never displayed. > Hmm... That give me an idea: > > <cl id="cutcopy" data="cutcopy_items.xml" /> > <input type="text" name="d" context="cutcopy" /> 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.
Received on Wednesday, 30 June 2004 23:57:26 UTC