被选中的选项被破坏还是......？ [英] Is selectedOptions broken or...?
问题描述
注意：这个问题与Knockout.js无关，但它与< select> selectedOptions 属性有关。 $ c>元素。这是参考：
Note: this question has nothing to do with Knockout.js, but it's about the selectedOptions attribute of <select> elements instead. This is the reference:
我认为这是Javascript开发人员的一个很好的功能。支持非常有限，但无论如何都在增长。 Chrome，Opera和Safari应该已经支持它。
I think it's a nice feature for Javascript developers. The support is quite limited, but it's growing anyway. Chrome, Opera and Safari should already support it.
问题在于我无法弄清楚它是如何工作的。行为应该非常简单，产生所选选项的实时集合，但结果并非如此。你可以想象，每当用户选择一个选项时， selectedOptions 就会改变，对吗？错误。我准备了一个测试用例：
The problem is that I can't figure out how it works. The behaviour should be quite straightforward, yielding a live collection of the selected options, but it turns out to be not the case. You'd imagine that selectedOptions changes everytime the user selects an option, right? Wrong. I've prepared a test case:
在这个例子中，Opera 11.64 总是返回所选的第一个值，无论如何你做了什么，而Chrome 21 dev和19 stable有一个奇怪的行为。执行以下步骤：
In this example, Opera 11.64 always returns the first value selected, no matter what you do after, while Chrome 21 dev and 19 stable have an odd behaviour. Do the following steps:
- 选择一个。在输出和控制台中，您可以获得One，正如预期的那样。
- 使用Ctrl也选择Two。在控制台中你得到一，二，在输出中它仍然是一。
- 也选择三。在控制台中它是一，二，三，在输出中它是一，二。
- 现在只选择两个。在控制台中你得到两个，输出两个（注意两个逗号）。
- Select 'One'. In both output and console you get "One", as expected.
- Select 'Two' too, using Ctrl. In console you get "One,Two", in output it's still "One".
- Select 'Three' too. In console it's "One,Two,Three", in output it's "One,Two".
- Now select 'Two' only. In console you get "Two", in output "Two,," (notice the two commas).
然而，如果你注释掉 console.log 行，你总能获得正确的输出。如果交换这两条指令，或者将值存储在一个单独的字符串中，您可以在控制台和输出中获得预期的行为，如下所示：
However, if you comment out the console.log line, you always get the correct output. You can get the expected behaviour in both console and output if you swap the two instructions, or if you store the value in a separated string, as in this:
那么，我错过了关于 selectedOptions 的内容吗？依赖这个属性是否为时尚早，可能有一个错误的实现？ console.log 在Chrome中创建问题？有什么我不知道的关于 HTMLCollection s？
So, am I missing something about selectedOptions? Is it too soon to rely on this property, that probably has a buggy implementation? Is console.log creating the issue in Chrome? Is there something I don't know about HTMLCollections?
我没有安装Safari，可以有人检查其行为？
I don't have Safari installed, can someone check its behaviour?
更新日期18/2/2013 ：我不知道什么时候发生了变化，但Chrome 24.0.1312.57和Opera 12.14似乎现在运行良好。 Firefox 18.0.2和Internet Explorer 10仍然必须实现该属性。
UPDATE 18/2/2013: I don't know when things have changed, but both Chrome 24.0.1312.57 and Opera 12.14 seems to work fine now. Firefox 18.0.2 and Internet Explorer 10 still have to implement the property.
更新2013/3/13 ：Firefox 24和IE 11预览仍然要支持财产。这是Firefox和IE8-11的简单解决方法：
UPDATE 17/9/2013: Firefox 24 and IE 11 preview still have to support the property. This is an easy workaround for Firefox and IE8-11:
Object.defineProperty(HTMLSelectElement.prototype, "selectedOptions", {
get: (function() {
try {
document.querySelector(":checked");
return function() {
return this.querySelectorAll(":checked");
};
} catch (e) {
return function() {
if (!this.multiple) {
return this.selectedIndex >= 0
? [this.options[this.selectedIndex]] : [];
}
for (var i = 0, a = []; i < this.options.length; i++)
if (this.options[i].selected) a.push(this.options[i]);
return a;
};
}
})()
});
对于IE8，它只返回数组和但不是 NodeList 。
For IE8 it returns just an Array and not a NodeList, though.
UPDATE 28/5/2014 ：它看起来比如Firefox从r25开始实现 selectedOptions 。
UPDATE 28/5/2014: It looks like Firefox started implementing selectedOptions since r25.
推荐答案
似乎问题比一个简单的bug要深一点。 WebKit和Presto都无法支持 selectedOptions 的事实正确地给出了一个提示，即它取决于该属性应该是 HTMLCollection的事实。
It seems that the problem is a bit deeper than a simple bug. The fact that both WebKit and Presto failed to support selectedOptions correctly gives us the hint that it depends on the fact that the property is supposed to be a HTMLCollection.
现在， HTMLCollection s有他们的实际行为，因为他们已被无效DOM发生事件时的渲染引擎（类的更改，节点的删除等）。但是选项的选择属性不会触发集合的失效，从而使其完全不可靠。
Now, HTMLCollections have their live behaviour because they're invalidated by the rendering engine when something happens to the DOM (the change of a class, the removal of a node and so on). But the selected property of an option does not trigger the invalidation of the collection, thus making it completely unreliable.
我想这里的问题是使实时集合失效的新方式，它可能不是很简单，因为它可能会影响解释和处理DOM的整个方式。
I guess the problem here is to make a new way live collections are invalidated, and it may be not very simple since it may affect the whole way the DOM is interpreted and handled.
目前，Chrome 21.0.1180.4已删除该属性。
At the present time, Chrome 21.0.1180.4 has the property removed.
这篇关于被选中的选项被破坏还是......？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
