Re: [whatwg] [html5] Attaching option elements to select elements in different documents
Boris Zbarsky bzbar...@mit.edu wrote: On 3/3/10 12:11 PM, Stewart Brodie wrote: As far as I can tell, this affects: HTMLSelectElement.add(), HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(), Node.insertBefore(). Is it option-specific, though? Last I checked, various browsers implicitly adopted on append/insert/replace, period. Since when? I was sure that they didn't used to do this. DOM Core is extremely clear on this issue (both in level 2 and level 3). You appear to be correct: Firefox and Opera both just ignore the standard and get this wrong. Chrome just seems to get confused. -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
On Mar 4, 2010, at 2:27 AM, Stewart Brodie wrote:
Boris Zbarsky bzbar...@mit.edu wrote:
On 3/3/10 12:11 PM, Stewart Brodie wrote:
As far as I can tell, this affects: HTMLSelectElement.add(),
HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild
(),
Node.insertBefore().
Is it option-specific, though? Last I checked, various browsers
implicitly adopted on append/insert/replace, period.
Since when? I was sure that they didn't used to do this. DOM Core is
extremely clear on this issue (both in level 2 and level 3). You
appear to
be correct: Firefox and Opera both just ignore the standard and get
this
wrong. Chrome just seems to get confused.
In WebKit, we originally implemented the rule required by the DOM
spec, but found that was insufficiently compatible with the Web. Below
see our current rule. I think this should be errata'd in the DOM to
give a more reasonable behavior.
// WRONG_DOCUMENT_ERR: Raised if newChild was created from a
different document than the one that
// created this node.
// We assume that if newChild is a DocumentFragment, all children
are created from the same document
// as the fragment itself (otherwise they could not have been
added as children)
if (newChild-document() != document()) {
// but if the child is not in a document yet then loosen the
// restriction, so that e.g. creating an element with the
Option()
// constructor and then adding it to a different document
works,
// as it does in Mozilla and Mac IE.
if (!newChild-inDocument()) {
shouldAdoptChild = true;
} else {
ec = WRONG_DOCUMENT_ERR;
return;
}
}
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
On Thu, 04 Mar 2010 11:27:23 +0100, Stewart Brodie stewart.bro...@antplc.com wrote: Boris Zbarsky bzbar...@mit.edu wrote: On 3/3/10 12:11 PM, Stewart Brodie wrote: As far as I can tell, this affects: HTMLSelectElement.add(), HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(), Node.insertBefore(). Is it option-specific, though? Last I checked, various browsers implicitly adopted on append/insert/replace, period. Since when? I was sure that they didn't used to do this. DOM Core is extremely clear on this issue (both in level 2 and level 3). You appear to be correct: Firefox and Opera both just ignore the standard and get this wrong. Chrome just seems to get confused. This changed a while ago due to compatibility problems. Consensus at the time was to change DOM Core. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
Anne van Kesteren ann...@opera.com wrote: On Thu, 04 Mar 2010 11:27:23 +0100, Stewart Brodie stewart.bro...@antplc.com wrote: Boris Zbarsky bzbar...@mit.edu wrote: On 3/3/10 12:11 PM, Stewart Brodie wrote: As far as I can tell, this affects: HTMLSelectElement.add(), HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(), Node.insertBefore(). Is it option-specific, though? Last I checked, various browsers implicitly adopted on append/insert/replace, period. Since when? I was sure that they didn't used to do this. DOM Core is extremely clear on this issue (both in level 2 and level 3). You appear to be correct: Firefox and Opera both just ignore the standard and get this wrong. Chrome just seems to get confused. This changed a while ago due to compatibility problems. Consensus at the time was to change DOM Core. Is this documented anywhere? By compatibility problems, presumably you mean bugs in Firefox that were then exploited by content authors who didn't know better? From Maciej's description of WebKit's behaviour, it looks like either they didn't know about this consensus or they didn't implement it compatibly. This definitely needs to be documented in HTML5. Are there any more retrospective changes to fundamental behaviour specified in DOM Core in the pipeline that I need to know about? I already know about the one in DOM Event about capturing listeners being called in the target phase. That leaves the issue of how adoptNode() affects the [[Prototype]] of the node objects, which is currently inconsistent between desktop browsers. Opera Chrome agree with each other (that the [[Prototype]] is unchanged); Firefox disagrees (it changes the [[Prototype]] to be that it would have been if the node had been created anew in the destination document). -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
On Thu, 04 Mar 2010 13:05:13 +0100, Stewart Brodie stewart.bro...@antplc.com wrote: Is this documented anywhere? On some W3C mailing list archive I think. By compatibility problems, presumably you mean bugs in Firefox that were then exploited by content authors who didn't know better? From Maciej's description of WebKit's behaviour, it looks like either they didn't know about this consensus or they didn't implement it compatibly. I forgot the details. This definitely needs to be documented in HTML5. It seems it should be specified in the new version of DOM Core. Are there any more retrospective changes to fundamental behaviour specified in DOM Core in the pipeline that I need to know about? I already know about the one in DOM Event about capturing listeners being called in the target phase. Well, features that are not implemented are planned to be dropped. Don't recall anything else right now. That leaves the issue of how adoptNode() affects the [[Prototype]] of the node objects, which is currently inconsistent between desktop browsers. Opera Chrome agree with each other (that the [[Prototype]] is unchanged); Firefox disagrees (it changes the [[Prototype]] to be that it would have been if the node had been created anew in the destination document). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
Apart from compatibility issues, there's also the fact that requiring explicit adopt/import is a pointless burden on authors. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[whatwg] [html5] Attaching option elements to select elements in different documents
The algorithm in the HTML5 specification for attaching an option element to a select element is incomplete, because it doesn't describe how to handle the case where the option element does not belong to the same document as the select element. It seems that HTMLOptionElement objects are immune to WRONG_DOCUMENT_ERR exceptions on any tree modifications. Thus the HTML5 specification also needs to note that it is overriding the rules from DOM Core about what may be attached to what. I've written some proposed changes further below. As far as I can tell, this affects: HTMLSelectElement.add(), HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(), Node.insertBefore(). My tests show that this isn't even confined to the cases where the new parent node is an HTML select element - any cross-document attachment of option elements operates as though the same-document check has been bypassed. In fact, the behaviour I'm seeing looks very much like an implicit adoptNode() call has occurred. I'm basing that suspicion on a comparison of the (equally inconsistent) behaviour of adoptNode() in different browsers[*] I'm testing this from ECMAScript in my test page which is at: http://www.metahusky.net/~stewart/css/html-options/ In all browsers, if the insertion of the option succeeds, then the inserted option element compares strictly equal to the option in the receiving select element. i.e. the option tree has not been cloned. In some browsers, the [[Prototype]] of the HTMLOptionElement is reset to be HTMLOptionElement.prototype of the receiving document's script context; in others, it does not get changed. However, in all browsers, all the nodes in the option's subtree are affected similarly (i.e. if the option's [[Prototype]] changes, so does the text node's) In some browsers, you can only insert the option element if the option element is not currently attached to anything else. In some browsers, the option isn't inserted at the right index into the receiving select, but I think that must just be a different bug. I propose the following changes to the specification: Change 1: Renumber existing step 7 to step 8 and insert a new step 7 in http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmloptionscollection 7. If _element_ does not belong to the same document as _parent_, then act as if the DOM Core adoptNode() method was invoked on the _parent_ node's ownerDocument with _element_ as the parameter. [Aside: whilst in the vicinity, shouldn't step 3 be using node rather than element i.e. If _before_ is a *node*, but that *node* ...? Otherwise, I could legitimately insert it before any text node anywhere in the document. Should it require that _before_ has to be an option or optgroup?] Change 2: Append some text to section 2.2.1 (Conformance Requirements - Dependencies) to indicate the change to DOM Core, and include a link to the text added by change 3: Some requirements in this specification are a wilful violation of constraints imposed by the DOM Core specification [DOMCORE]: * attaching _option_ elements to different documents is permitted Change 3: append explanatory text, linked from change 2's text to: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-option-element If any attempt is made to attach an _option_ element to a node in a Document other than the Document of the _option_ element, then the user agent must not throw a _WRONG_DOCUMENT_ERR_ exception. If the tree change would otherwise succeed, then the user agent must behave as if a call to the DOM Core adoptNode() method has been made so that the Document of the _option_ element is updated. This affects the DOM Core appendChild(), insertBefore() and replaceChild() methods. Actually, all of these changes might have to say _option_ or _optgroup_. [*] Opera 10.10, Chrome 5.0.307.11 beta, Firefox 3.5.8, and our own ANT Galio 3.1.0 -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
Was your testing done with option elements created with document.createElement(option) or new Option? I ask because I seem to recall the behavior being different for at least some types of elements. -- Darin
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
Darin Adler da...@apple.com wrote: Was your testing done with option elements created with document.createElement(option) or new Option? I ask because I seem to recall the behavior being different for at least some types of elements. That's a good idea - I forgot to test that. I've updated my test so that it tries both. The behaviour seems to be the same, regardless of how the option is created. -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
On 3/3/10 12:11 PM, Stewart Brodie wrote: As far as I can tell, this affects: HTMLSelectElement.add(), HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(), Node.insertBefore(). Is it option-specific, though? Last I checked, various browsers implicitly adopted on append/insert/replace, period. -Boris
