W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2009

[whatwg] HTML 5 : Misconceptions Documented

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 15 Jan 2009 19:40:55 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0901151933320.29785@hixie.dreamhostps.com>
On Thu, 15 Jan 2009, Garrett Smith wrote:
> 
> If I understand this correctly, given a FORM with an INPUT named 'b', if 
> I change the name of that INPUT to 'a', then form.b should return the 
> element with name="a".
> 
> That isn't how it works in Firefox, Opera, or Safari. Here is an example 
> of changing a control's name. The changed control does not remain as 
> property on the form.
> 
> <!doctype html>
> <html lang="en">
> <head>
> 	<title>Change Control Name</title>
> </head>
> <body>
> <form action="">
> <input name='b' id="x"/>
> </form>
> <script type="text/javascript">
> document.getElementById('x').name = "a";
> document.write("(document.forms[0].b === undefined) " +
>     (document.forms[0].b === undefined )+ ".");
> </script>
> </body>
> </html>
> 
> Result:-
> (document.forms[0].b === undefined) true.

That matches the spec, too. Add this line at the start of your script:

   document.forms[0].b;

...and you'll see the behavior change, at least in Firefox and Safari, 
again to match the spec.


> What is the reason for introducing the "past names map" behavior to the 
> form?

Compatibility with a legacy IE bug required (acording to Safari and 
Firefox devs) by legacy content.


> >> It sounds as if an HTMLFormElement is a collection, minus the 
> >> 'namedItem' and 'item' methods.
> >
> > Not even minus namedItem and item, in fact, it has those methods too.
> 
> Is HTMLFormElement a collection? If so, what collection?

It doesn't explicitly implement any of the collection interfaces, if 
that's what you mean.


> The spec does not say that HTMLFormElement is an HTMLCollection (or 
> HTMLFormControlsCollection); it defines delegating behavior in a very 
> non-DRY way.

Yup.


> In current implementations such as Firefox, Webkit, Opera, 
> HTMLFormElement is not an HTMLCollection.

Indeed.


> It sounds like you want that to change so that HTMLFormElement *is* an 
> HTMLFormControlsCollection.

No, why would we do that?


> Making HTMLFormElement implement HTMLFormControlsCollection would be a 
> big change to HTMLFormElement. Surely there has got to be something more 
> than typing convenience to justify such change.
> 
> It seems more justifiable to advocate that authors not do that, perhaps 
> providing an example in an appendix of nonstandard behavior.

The idea of HTML5 is to make sure that a browser that implements all of 
HTML5 is compatible with legacy content. This is one of the things that 
legacy content requires, so the spec has to require it too.

The idea is to make it so that browsers don't feel forced to add _any_ 
non-standard behavior (other than experimental innovations using vendor- 
prefixed names and stuff).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 15 January 2009 11:40:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:09 UTC