W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Elements should be removed from the past names map once it's no longer associated with the form element

From: Ryosuke Niwa <rniwa@apple.com>
Date: Mon, 26 Aug 2013 16:13:53 -0700
Message-id: <24F84694-2924-4176-A12C-0883C37F23DA@apple.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg@lists.whatwg.org

On Aug 26, 2013, at 3:53 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 8/26/13 5:45 PM, Ryosuke Niwa wrote:
>> I propose to change the specification to remove any elements that are no longer associated with the form from the past names map:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#past-names-map
> Are you sure this doesn't break web pages?  What do UAs do here?  What did they use to do?

IE10 passes all test cases but WebKit and Gecko fails 2nd, 4th, 6th, and 7th test cases.

>> It's strange for elements to linger around forever in the past names map after the element get associated with a new form element.
> I agree, though it's an obvious consequence of certain past implementation strategies.

I think we overlooked it when we added the support for dynamically changing the owner form element.

>> Since IE didn't support form attribute for a long time (or maybe still hasn't?), I don't think there is any compatibility concern.
> I'm not sure what this sentence is saying.

What I mean is the form content attribute of a form control element used as in: myInputInput.setAttribute('form', 'myForm');

> form.foo works in IE last I checked.  So what are you saying IE didn't or doesn't support?

Yes. IE does have that behavior.  What IE doesn't is keeping a form control element in the past names map of a form element once the control got disassociated with the form element.

I think IE's behavior is much saner than what we've implemented in WebKit and Gecko.

- R. Niwa
Received on Monday, 26 August 2013 23:14:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC