[whatwg] HTML 5 : Misconceptions Documented
dhtmlkitchen at gmail.com
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">
>> <title>Change Control Name</title>
>> <form action="">
>> <input name='b' id="x"/>
>> document.getElementById('x').name = "a";
>> document.write("(document.forms.b === undefined) " +
>> (document.forms.b === undefined )+ ".");
>> (document.forms.b === undefined) true.
> That matches the spec, too. Add this line at the start of your script:
> ...and you'll see the behavior change, at least in Firefox and Safari,
Yes, the reference |forms.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.
| 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...
> again to match the spec.
In all browsers, if the control is referenced as:-
- the leak does not occur.
>> What is the reason for introducing the "past names map" behavior to the
> 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.
// var a;
If  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
> 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
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.
More information about the whatwg