18645 2012-08-21 18:43:31 +0000 [Shadow]: HTMLSelectElement should have an insertion point 2012-10-31 22:20:33 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED LATER P2 normal --- 18428 1 dglazkov dglazkov bugs dominicc shinyak public-webapps-bugzilla oldest_to_newest 72501 0 dglazkov 2012-08-21 18:43:31 +0000 The way it behaves in real world, the HTMLSelectElement should have one insertion point that selects "option" elements. 72527 1 shinyak 2012-08-22 04:52:14 +0000 Actually a <select> element will get not only the direct children <option> but also get non direct children. For example, ​<select> <option>foo</option> <p><option>bar</option></p> </select>​​​​​​​​​​​​​​​​​​​​​​​​​​ both 'foo' and 'bar' will be used in this case. It seems this description is not accurate enough. I'm not sure we have enough descriptive power to explain this behavior using Shadow DOM. 72538 2 dglazkov 2012-08-22 16:59:32 +0000 (In reply to comment #1) > Actually a <select> element will get not only the direct children <option> but > also get non direct children. > > For example, > > ​<select> > <option>foo</option> > <p><option>bar</option></p> > </select>​​​​​​​​​​​​​​​​​​​​​​​​​​ > > both 'foo' and 'bar' will be used in this case. Right, but in this case, the HTML parser is playing tricks on you. Look at the resulting DOM tree: you'll see that <p> is silently dropped. However, if still you try to create this structure imperatively, you'll see that only <options> that are direct children are shown: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cselect%3E%0A%3Coption%3Efoo%3C%2Foption%3E%0A%3Cp%3E%3Coption%3Ebar%3C%2Foption%3E%3C%2Fp%3E%0A%3C%2Fselect%3E%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%0A%3Cscript%3E%0A%0Avar%20option%20%3D%20document.createElement('option')%3B%0Aoption.textContent%20%3D%20'baz'%3B%0Avar%20p%20%3D%20document.createElement('p')%3B%0Ap.appendChild(option)%3B%0Adocument.querySelector('select').appendChild(p)%3B%0A%0A%3C%2Fscript%3E 72574 3 dominicc 2012-08-23 02:33:07 +0000 I think <select> should not have an insertion point. The spec should be amended to treat it along with input, etc. The spec should ensure that: <select> {SR} <option>Asparagus <content> <option>Banana <option>Pear should render "Asparagus", and not a select box (and definitely not a select box with Asparagus, Banana, Pear.) The reason being that the selectedIndex of Asparagus does not make sense. Asparagus is not in the data model of the select element. 72575 4 dglazkov 2012-08-23 02:59:54 +0000 (In reply to comment #3) > I think <select> should not have an insertion point. The spec should be amended > to treat it along with input, etc. > > The spec should ensure that: > > <select> > {SR} > <option>Asparagus > <content> > <option>Banana > <option>Pear > > should render "Asparagus", and not a select box (and definitely not a select > box with Asparagus, Banana, Pear.) The reason being that the selectedIndex of > Asparagus does not make sense. Asparagus is not in the data model of the select > element. It can't render "Asparagus", since options are not rendered. Can you explain the problem you're seeing with <select> having an insertion point? 72608 5 bugs 2012-08-23 14:18:03 +0000 We should not add any special cases to Shadom DOM at this point. Once the spec is otherwise stable, there could a yet another spec defining additions to HTML elements (if really needed). 72613 6 dominicc 2012-08-23 16:07:47 +0000 (In reply to comment #4) > It can't render "Asparagus", since options are not rendered. That is OK. > Can you explain the problem you're seeing with <select> having an insertion > point? On reflection I think my beef is not with whether it has an insertion point, it is the relationship between option elements in the flattened tree and the HTMLSelectElement’s data model (selectedIndex, etc.) 72614 7 dglazkov 2012-08-23 16:11:42 +0000 (In reply to comment #6) > (In reply to comment #4) > On reflection I think my beef is not with whether it has an insertion point, it > is the relationship between option elements in the flattened tree and the > HTMLSelectElement’s data model (selectedIndex, etc.) Ah. the data model shouldn't need to worry about the flattened tree. It only looks at the children of <select>. Having an insertion point inside of a <select> doesn't seem to influence that in any way. 72615 8 dglazkov 2012-08-23 16:14:30 +0000 (In reply to comment #5) > We should not add any special cases to Shadom DOM at this point. > Once the spec is otherwise stable, there could a yet another > spec defining additions to HTML elements (if really needed). Yup. That type of spec would be an awesome improvement for http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#bindings