[Bug 9624] datalist should not filter options with no value

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9624


Jonas Sicking <jonas@sicking.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




--- Comment #3 from Jonas Sicking <jonas@sicking.cc>  2010-08-24 21:10:09 ---
(In reply to comment #2)
> The problem is that if we strip out <option> elements with no value=""
> attribute, you can't reuse a <select>.

The request was to *not* filter out <options>.

Perhaps there was a misunderstanding of what was requested? What we're
requesting is that all <option>s which are direct children of the <datalist>
are included in the HTMLDataListElement.options NodeList.

> In practice, you already have to do everything you describe for <select>, as
> far as I can tell.

Where would we need to filter out <option>s with a empty-string .value today?
Consider the following markup:

<select>
  <option value="">foobar</option>
  <option></option>
  <option>hi</option>
</select>

In both gecko and in webkit this results in three options both in the rendered
UI, and in the .options NodeList.

This bug is filed specifically *to* allow us to reuse the code used for
<select>.

In fact, we likely couldn't implement the filtering that is specced for
<datalist> for <select>. The performance would simply be too bad. The code for
<select> was heavily optimized for dealing with huge lists of <option>s which
for some reason appear in some pages, so we basically don't look at the
<option>s at all until they are rendered in the UI.

> However, I don't feel that strongly about this. If the perf cost (presumably
> only an issue while a user is editing an <input> -- which doesn't seem like
> it'll happen often anyway) and implementation cost is really that high, then
> reopen and I'll simplify it. But that would make the language rather
> inconsistent. As it is now, you can implement <option> in a way that abstracts
> this out, and then <select> and <datagrid> can both use the data in the same
> way.

The spec as written is certainly implementable since it won't affect
performance on any existing pages, as no pages today use <datalist>. However I
would expect it to affect performance of future pages that do use <datalist>.
If absolutely necessary, this is something that those pages would just have to
deal with, however as far as I can tell, there doesn't seem to be any
significant advantage for pages?

Or are we for some reason expecting pages to have lots of <option>s with an
empty value?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 24 August 2010 21:10:11 UTC