[whatwg] HTML 5 : Misconceptions Documented

Sun Jan 18 11:48:57 PST 2009

On Thu, Jan 15, 2009 at 11:40 AM, Ian Hickson <ian at hixie.ch> wrote:
> 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,

Yes, the reference |forms[0].b| has to occur prior to the name change.

What do IE6, IE7 and IE8 do?

IE <= 7 are known to be buggy with the name attribute[1].

| Microsoft JScript allows the name to be changed at run time.
| This does not cause the name in the programming model to change
| in the collection of elements, but it does change the name used
| for submitting elements.
|
| * Internet Explorer 8 and later can set the NAME attribute at
| run time on elements dynamically...[1]

> again to match the spec.
>

In all browsers, if the control is referenced as:-

  document.forms[0].elements.b;

- the leak does not occur.

>> 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.
>

If I understand what you're saying, you are taking advice on what IE
does from Safari and Firefox devs. Was there a test?

I posted an earlier example "simple-leak-form-input.html" that showed
how in IE, removing a control from the document removes the property
from a form. This is generally what you want. You don't want the
browser to leak form controls. The "past names map" is not even
defined as an interface; it's a euphamism for a bug.

>
>
>> >> 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.
>

Yes, that answers my question.

[...]

>
>> 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.
>

I think I understand this position. HTML5 wants to add new
functionality without breaking any existing functionality. That is a
good goal, and an important one if it is to be accepted.

OTOH, the legacy behavior is buggy and inconsistent. It's also been
replaced by a much better feature (the elements collection). You've
not attempted to refute any of that; on the contrary, I see the spec
includes a 'past names map' and since you've not provided any
evidence, the "should not be used. It is practical to deprecate it.

There are plenty of useless/bad things browsers do. For example,
accessing a named form directly off the document, as
document.formName, or standardizing the way an identifier matching an
element ID is resolved to that element.

<html>
<body>
<div id="a">...</div>

<script>
  //[1] var a;
  alert(typeof a);
</script>
</body>
</html>

Result:
  elerts "object"

If [1] is uncommented, results vary between browsers and versions.
This quirk was a problem not too long ago for the Google Code
developers. It was filed as a Webkit bug that got "fixed".

There are other things that could be standardized, such as quirks
mode, String.prototype.anchor(surl), or any number of things that have
better alternatives.

> 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).
>

HTML5 does make distinctions for legacy content in some places, but
not with this behavior. It would be a good idea to make a clear
distinction that accessing form controls directly off the form is
legacy content.

Examples can make things clearer for authors, implementors, and
influence the accuracy of the spec. I hope I'm not beating a dead
horse -- we already seem to agree on the value of examples.

It might be a good idea to add a sentence or two that explains why
authors should not use those features and links to the examples.

Garrett

[1]http://msdn.microsoft.com/en-us/library/ms534184.aspx