- From: <bugzilla@jessica.w3.org>
- Date: Fri, 30 Apr 2010 01:10:27 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9624 --- Comment #1 from Jonas Sicking <jonas@sicking.cc> 2010-04-30 01:10:27 --- 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. -- 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 Friday, 30 April 2010 01:10:29 UTC