Basically the problem is one of performance and complexity in implementation, which seemingly very little gain for the end user.

As the spec is written now, if an <option> doesn't have a value attribute, you have to check each option to see if it contains any non-empty text nodes. Including ignoring any comment or element nodes that are in there.

Additionally, you have to watch for modifications, additions and removals of text nodes so that if any <option> changes from non-empty to empty, or from empty to non-empty, you have to update the list of <option>s accordingly.

This is certainly possible to implement, however it comes with added complexity and lost performance. This would be ok if this dealt with any important use cases, however as far as I can see this is just nice-to-have-just-in-case sugar in case someone accidentally inserts an empty <option>.

This also means that we can't reuse existing code that we use to implement most other NodeLists. All other NodeLists filter solely on elements and its attributes itself. I.e. things like getElementsByTagName, getElementsByClassName, HTMLTableElement.tBodies, HTMLTableElement.rows, etc are all affected only by an element and its attributes, never the elements children.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

The problem is that if we strip out <option> elements with no value="" attribute, you can't reuse a <select>.

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

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.

(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?

> What we're
> requesting is that all <option>s which are direct children of the <datalist>
> are included in the HTMLDataListElement.options NodeList.

That's already the case.

If that really is what you're requesting, then apologies for the earlier misunderstanding. If it's not, then apologies for this misunderstanding. :-)

Please don't hesitate to reopen if there is something more to this.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: no spec change
Rationale: This seems to have been fixed already.