[whatwg] HTML 5 : Misconceptions Documented

Ian Hickson ian at hixie.ch
Wed Feb 11 22:38:28 PST 2009

On Sun, 18 Jan 2009, Garrett Smith wrote:
> What do IE6, IE7 and IE8 do?

I only tested IE8 and IE8's IE7 compatibility mode, and I don't recall 
exactly what the results were, but they were taken into account when 
writing the spec here. (In particular, IE doesn't distinguish between the 
form and its .elements array, which doesn't match HTML5 or DOM2 HTML.)

> In all browsers, if the control is referenced as:-
>   document.forms[0].elements.b;
> - the leak does not occur.

In IE, the above and


...are exactly the same.

> >> 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 take advice on what the spec should say from everyone. I test things 
independently also.

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

Unfortunately, as with many weird behaviors on the Web platform, it is a 
"bug" that is required for compatibility with legacy content.

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

I don't really understand what you mean here.

I'm not deprecating anything in HTML5. Things are either allowed or not 
allowed (obsolete). With scripting, I've erred on the side of not 
obsoleting things, since there doesn't seem much point in doing so, 
especially for such minor non-features as this.

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

HTML5 covers this case, IIRC.

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

Quirks mode is in HTML5. The String prototype is an ECMAScript issue and 
is out of scope here.

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


Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list