- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 26 Aug 2013 21:35:41 -0400
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: whatwg@lists.whatwg.org
On 8/26/13 7:13 PM, Ryosuke Niwa wrote: > https://bug-120328-attachments.webkit.org/attachment.cgi?id=209688 > IE10 passes all test cases but WebKit and Gecko fails 2nd, 4th, 6th, and 7th test cases. You must be testing Firefox 23 or earlier? Firefox 24 or later passes all these tests. In any case, the 2nd, 4th, 6th, and 7th tests are about properties not disappearing when they should, so those are not relevant here as far as I can tell. That said, looking at this more closely, it seems like you and I may be in violent agreement. Right now the spec says: If an element listed in the form element's past names map is removed from the Document, then its entries must be removed from the map. which is all the testcase above tests as far as I can tell, since it removes the control from the DOM after setting its @form. The testcase doesn't test what happens when @form is set on a control without removing it from the DOM. What happens in Firefox 24 and above is that when an element stops being form-associated with a form it is in fact removed from the past names map for that form. I asked for a spec bug to be filed to that effect in https://bugzilla.mozilla.org/show_bug.cgi?id=879319#c4 but I'm not sure that ever happened.... :( > What I mean is the form content attribute of a form control element used as in: myInputInput.setAttribute('form', 'myForm'); Ah, I see. Yes, ok. So in particular, the spec already requires that elements be removed from the past names map when removed from the DOM, so the only issue is with @form changes, and there is not likely to be much content relying on @form changes _not_ removing from the past names map. I wholeheartedly agree. -Boris
Received on Tuesday, 27 August 2013 01:36:10 UTC