Re: [whatwg] HTML 5 : Misconceptions Documented

[Ian Hickson]

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

   document.forms[0].b

...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.
> 
> 
> 
> ...
> 
> 
>   //[1] var a;
>   alert(typeof a);
> 
> 
> 
> 
> 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.

Why?

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

Re: [whatwg] HTML 5 : Misconceptions Documented

[Ian Hickson]

On Sun, 18 Jan 2009, Mike Wilson wrote:
> 
> Now I am just being curious ;-) but how on earth do you find all quirks 
> (and if they have been specially dealt with) - is it up to reports on 
> the mailing list or are you reading source code? :-)

Lachlan answered most of your questions, but I just wanted to add that 
another source of information we have used is studies of actual existing 
content. Several independent studies have been done on data sets of sizes 
varying from hundreds of pages to literally billions of pages, and we use 
that to inform our decisions too. For example, browser vendors said that 
it was required that the parser treat "" as "", and when we 
looked at actual pages, we found that indeed about 0.2% of pages required 
this, including some pretty high-profile ones. 

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

Re: [whatwg] HTML 5 : Misconceptions Documented

[Boris Zbarsky]

Boris Zbarsky wrote:
Note that since this isn't a core DOM behavior, but rather an artifact 
of the JS-to-DOM glue, in this case the behavior will depend on whether 
you've accessed the control by name on the form in the past; if the 
first such access is after the name change in Gecko, the control will 
only be visible under the new name.


As another side-effect, by the way, Gecko has
 which doesn't
sound like the right thing to do per current spec text.

Also as discussed in
 there is shadowing
going on where "the old name will shadow a new form control that is
inserted with the old name".  That's not per current spec text either,
though "IE has the same problem" as of 2001.  Did this change in later
IE releases?  Is it not required for website compat?  Again, I'd like to
see the data if possible.

-Boris

Re: [whatwg] HTML 5 : Misconceptions Documented

[Lachlan Hunt]

Mike Wilson wrote:

Lachlan Hunt wrote:
There will not be, at least in Opera, Firefox or Safari, new 
modes added beyond the existing no quirks, limited quirks and 
quirks modes.


Do you reckon all, or only some of, these modes will implement the
HTML5 spec? (and differ only in css/rendering) 


As far as the HTML quirks are concerned, they will all hopefully be 
specced.  The three modes are defined in the spec already and many of 
the quirks have already been documented, or are at least mentioned as an 
issue in the spec.


See this section:
http://www.whatwg.org/specs/web-apps/current-work/#no-quirks-mode

Some of the rendering quirks may be addressed in the rendering section 
of this spec, though it would be nice if the CSS WG would document a lot 
of the relevant issues themselves.  However, I don't believe they have 
any plans to do so at this stage.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [whatwg] HTML 5 : Misconceptions Documented

[Mike Wilson]

Lachlan Hunt wrote:
> 

Thanks for all the information, it sounds good and reasonable.
Well done!

>  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).
> > 
> > Do you think this will happen with the current popular browsers, 
> > ie will they actually remove existing code that implements 
> > workarounds that don't make it into HTML5?
> > Or will they employ some "legacy vs HTML5" mode switching where
> > their custom workarounds are only in legacy mode?
> 
> 
> There will not be, at least in Opera, Firefox or Safari, new 
> modes added beyond the existing no quirks, limited quirks and 
> quirks modes.

Do you reckon all, or only some of, these modes will implement the
HTML5 spec? (and differ only in css/rendering) 

Best regards
Mike

Re: [whatwg] HTML 5 : Misconceptions Documented

[Garrett Smith]

On Thu, Jan 15, 2009 at 11:40 AM, Ian Hickson  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.
>>
>> 
>> 
>> 
>>   Change Control Name
>> 
>> 
>> 
>> 
>> 
>> 
>> document.getElementById('x').name = "a";
>> document.write("(document.forms[0].b === undefined) " +
>> (document.forms[0].b === undefined )+ ".");
>> 
>> 
>> 
>>
>> 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.



...


  //[1] var a;
  alert(typeof a);




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 t

Re: [whatwg] HTML 5 : Misconceptions Documented

[Lachlan Hunt]

Mike Wilson wrote:

Ian Hickson wrote:

On Sat, 17 Jan 2009, Mike Wilson wrote:
So I wonder what is your process 
for determining if a "quirk" should be included in HTML5 or not?
It basically boils down to "did Web browser vendors find that if they 
didn't implement it, enough people complained to justify spending the 
resources to implement it after all?".


Ah, so your process is really to look at if browser vendors
historically have added special handling for individual quirks
and then mimic "popular" solutions in the spec?


For some things, yes.


Now I am just being curious ;-) but how on earth do you find
all quirks (and if they have been specially dealt with) - is it
up to reports on the mailing list or are you reading source 
code? :-)


Some things are known based on experience, because they occur so 
freqently in practice.  But in general, when trying to spec a particular 
feature, a lot of time is spent testing and reverse engineering it using 
a variety of techniques including black box testing, reviewing past bug 
reports or even looking at the source code of the open source browsers.


For some examples of this, take a look at these articles
http://ln.hixie.ch/?start=1037910467&count=1
http://ln.hixie.ch/?start=1137799947&count=1
http://ln.hixie.ch/?start=1155195074&count=1
http://ln.hixie.ch/?start=1158969783&count=1
http://ln.hixie.ch/?start=1161042744&count=1
http://ln.hixie.ch/?start=1161121410&count=1


And do you generally find concensus among the non-MS vendors or
are there many quirks that are only worked around in a single 
browser, and how do you handle that?


If possible, we try to spec the behaviour that has the most 
interoperability among the browsers. i.e. If 3 out of 4 browsers do A, 
and the the other does B, and there's no significant evidence of 
compatibility problems with A, then the spec is likely to define A.


If there's no interoperabiliy at all between the browsers (i.e. All 
browsers do something completely different), then we have a little more 
freedom to pick the most sensible alternative, taking into account any 
compatibility issues with real world content.


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


Do you think this will happen with the current popular browsers, 
ie will they actually remove existing code that implements 
workarounds that don't make it into HTML5?

Or will they employ some "legacy vs HTML5" mode switching where
their custom workarounds are only in legacy mode?


If the spec omits something that we implement and there's evidence to 
suggest that we need to keep it for compatibility, then we'll try to get 
that added to the spec.  If it's something minor that no other browser 
does and it doesn't appear to be needed for compatibility with anything, 
then we're more likely to drop it.  There will not be, at least in 
Opera, Firefox or Safari, new modes added beyond the existing no quirks, 
limited quirks and quirks modes.



I guess what I am really thinking about is whether there will
ever be a "strict to standard" HTML5 implementation, or a
reference implementation, that stays exactly on what is written
in (or easily interpolated from) the HTML5 spec...?


There won't be any implementation considered to be the reference 
implementation. But the hope is that all implementations will eventually 
converge on implementing things in the same way, and that the spec will 
match.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [whatwg] HTML 5 : Misconceptions Documented

[Mike Wilson]

Ian Hickson wrote:
> On Sat, 17 Jan 2009, Mike Wilson wrote:
> > So I wonder what is your process 
> > for determining if a "quirk" should be included in HTML5 or not?
> 
> It basically boils down to "did Web browser vendors find that if they 
> didn't implement it, enough people complained to justify spending the 
> resources to implement it after all?".

Ah, so your process is really to look at if browser vendors
historically have added special handling for individual quirks
and then mimic "popular" solutions in the spec?

Now I am just being curious ;-) but how on earth do you find
all quirks (and if they have been specially dealt with) - is it
up to reports on the mailing list or are you reading source 
code? :-)

And do you generally find concensus among the non-MS vendors or
are there many quirks that are only worked around in a single 
browser, and how do you handle that?

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

Do you think this will happen with the current popular browsers, 
ie will they actually remove existing code that implements 
workarounds that don't make it into HTML5?
Or will they employ some "legacy vs HTML5" mode switching where
their custom workarounds are only in legacy mode?

I guess what I am really thinking about is whether there will
ever be a "strict to standard" HTML5 implementation, or a
reference implementation, that stays exactly on what is written
in (or easily interpolated from) the HTML5 spec...?

> Feel free to add questions to the FAQ, even without answers; 
> someone will fill them in! :-)

Magic! :-)

Best regards
Mike

Re: [whatwg] HTML 5 : Misconceptions Documented

[Ian Hickson]

On Sat, 17 Jan 2009, Mike Wilson wrote:
> 
> I'm impressed with the level of detail that you strive for in 
> documenting real-world HTML :-)

It more or less is forced upon us if we want the spec to fulfill the role 
of a document that accurately depicts how to write a user agent (be it a 
browser, command-line tool, or whatever) that actually works with today's 
content. But thanks. :-)


> Still, seeing this quite non-trivial "feature-bug" being standardized, I 
> see the potential for making the standard unnecessary complicated if 
> including a lot of these legacy quirks. So I wonder what is your process 
> for determining if a "quirk" should be included in HTML5 or not?

It basically boils down to "did Web browser vendors find that if they 
didn't implement it, enough people complained to justify spending the 
resources to implement it after all?".


> Is there any listing of other quirks together with a yes/no decision 
> whether to include them in HTML5?

I'm not aware of anybody keeping track of this closely, no.


> Also, what is the general ambition for compatibility with legacy 
> content? Until reading this thread I personally thought HTML5's legacy 
> compatibility revolved mainly around rendering and document validity, 
> but now I realize it has a lot to do with script compatibility as well?

Scripting (or rather, the HTML DOM API) is a big part of HTML, so insofar 
as HTML5 (the spec) defines those APIs, we have to consider the impact of 
legacy pages on the implementations of those APIs.

The same should apply to all specs, really, though so far not all Web 
specs have received this treatment. (Of note are XMLHttpRequest and 
WebIDL, and to a lesser extent CSS2.1.)


> And please do not take this message as criticism, these are just 
> interesting (to me) questions that I couldn't find the answer to on the 
> whatwg FAQ.

Feel free to add questions to the FAQ, even without answers; someone will 
fill them in! :-)

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

Re: [whatwg] HTML 5 : Misconceptions Documented

[Anne van Kesteren]

On Sat, 17 Jan 2009 14:18:07 +0100, Mike Wilson   
wrote:

Ian Hickson wrote:

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


That's a good thing. Still, seeing this quite non-trivial
"feature-bug" being standardized, I see the potential for
making the standard unnecessary complicated if including a lot
of these legacy quirks.


Well, the Web is unnecessarily complicated and browsers are by extension.  
If we want to allow new browsers to enter the market space, existing  
browsers to be able to compete more effectively, and be able to add  
extensions on top of the existing platform, specifying it and striving for  
convergence is the best bet we have.




So I wonder what is your process for
determining if a "quirk" should be included in HTML5 or not?
Is there any listing of other quirks together with a yes/no
decision whether to include them in HTML5?


There is no exact list and some of the weird bits are done by other  
specifications.




Also, what is the general ambition for compatibility with
legacy content? Until reading this thread I personally thought
HTML5's legacy compatibility revolved mainly around rendering
and document validity, but now I realize it has a lot to do with
script compatibility as well?


Yes, and parsing, and interpreting weird attribute values, etc.



And please do not take this message as criticism, these are
just interesting (to me) questions that I couldn't find the
answer to on the whatwg FAQ.


Feel free to add questions there and answer questions you know the answer  
to.



--
Anne van Kesteren

Re: [whatwg] HTML 5 : Misconceptions Documented

[Mike Wilson]

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

I'm impressed with the level of detail that you strive for in
documenting real-world HTML :-)

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

That's a good thing. Still, seeing this quite non-trivial
"feature-bug" being standardized, I see the potential for 
making the standard unnecessary complicated if including a lot
of these legacy quirks. So I wonder what is your process for
determining if a "quirk" should be included in HTML5 or not?
Is there any listing of other quirks together with a yes/no 
decision whether to include them in HTML5?

Also, what is the general ambition for compatibility with
legacy content? Until reading this thread I personally thought
HTML5's legacy compatibility revolved mainly around rendering 
and document validity, but now I realize it has a lot to do with
script compatibility as well?

And please do not take this message as criticism, these are 
just interesting (to me) questions that I couldn't find the 
answer to on the whatwg FAQ.

Best regards
Mike Wilson

Re: [whatwg] HTML 5 : Misconceptions Documented

[Ian Hickson]

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.
> 
> 
> 
> 
>   Change Control Name
> 
> 
> 
> 
> 
> 
> document.getElementById('x').name = "a";
> document.write("(document.forms[0].b === undefined) " +
> (document.forms[0].b === undefined )+ ".");
> 
> 
> 
> 
> 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.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] HTML 5 : Misconceptions Documented

[Garrett Smith]

(back on list)

On Wed, Jan 14, 2009 at 2:04 PM, Ian Hickson  wrote:
> On Tue, 13 Jan 2009, Garrett Smith wrote:
>> On Tue, Jan 13, 2009 at 6:41 PM, Ian Hickson  wrote:
>> >
>> > There were a number of e-mails on this thread regarding how Collections
>>
>> Which thread are referring to?
>
> The one entitled "HTML 5 : Misconceptions Documented".
>

Sorry.

>
>> > and other interfaces worked with respect to properties being exposed.
>> > I have now updated the HTML5 spec to take into account the new
>> > features in WebIDL that expose these properties. Please let me know if
>> > I missed one.
>>

I see. It looks like you've mimicked current methods of HTMLCollection
- item - and - namedItem - on the form. These methods delegate to
same-named methods on the elements collection.

I see several paragraphs that describe how HTMLFormElement has
same-named methods that delegate to HTMLCollection.

http://www.whatwg.org/specs/web-apps/current-work/#htmlformelement

The specification does not say that HTMLFormElement implement HTMLCollection.

The spec has defined new behavior, "past names map":-

| Each form element has a mapping of names to elements called the
| *past names map*. It is used to persist names of controls even when
| they change names.

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.




Change Control Name






document.getElementById('x').name = "a";
document.write("(document.forms[0].b === undefined) " +
(document.forms[0].b === undefined )+ ".");




Result:-
(document.forms[0].b === undefined) true.

If the  |b| element were in the form's 'past names map', shouldn't the
result indicate document.forms[0].b as an object?

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

>> | The elements collection is also mirrored on the HTMLFormElement object.
>> | The length DOM attribute must return the number of nodes represented by
>> | the elements collection. The indices of the supported indexed properties at
>> | any instant are the indicies supported by the object returned by the 
>> elements
>> | attribute at that instant. The names of the supported named properties at 
>> any
>> | instant are the names supported by the object returned by the elements
>> | attribute at that instant.
>>
>> 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 would be a good idea to mention the implications and side effects.
>> I would propose an example:-
>>
>> 
>>   
>> 
>>
>> document.forms.testForm.submit();
>>
>> - and explain what should happen. It would also be a good idea to
>> mention the implication for implementors.
>
> My plan is to add examples in late Q2 early Q3. If I don't include this
> example at that point (and assuming you still think it would be useful
> given the other examples that will be added) please remind me.
>
>
>> There are problems with referencing a control directly off the form:-
>>   1) controls may be returned out of order
>>   2) after a control is removed, it may still exist as a property of the form
>>
>> If the specification is going to define a collection, it should be clear
>> how the collection works. If the collection is to work exactly as an
>> HTMLCollection, then the specification should say so. Current
>> implementations are buggy with referencing a form control directly from
>> the form.
>
> As far as I can tell, the spec is exactly defined now. Is there anything
> left ambiguous?
>

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

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

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

Is this what you are proposing? If so, why?

The only benefit that was mentioned was convenience, as in:
var elements = document.forms.myForm;
elements.firstName.value = "Ian";

- instead of -

var elements = document.forms.myForm.elements;
elements.firstName.value = "Ian";

Now that may be a little less typing, but not much. I don't find it
much more convenient to reference controls directly from the form.


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.

Garrett

> --
>

Re: [whatwg] HTML 5 : Misconceptions Documented

[Ian Hickson]

There were a number of e-mails on this thread regarding how Collections 
and other interfaces worked with respect to properties being exposed. I 
have now updated the HTML5 spec to take into account the new features in 
WebIDL that expose these properties. Please let me know if I missed one.

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

Re: [whatwg] HTML 5 : Misconceptions Documented

[Garrett Smith]

On Mon, Nov 10, 2008 at 12:56 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Aug 2008, Garrett Smith wrote:
>>
>> There is no note in the WF 2.0 specification, nor the HTML 4.01, nor the
>> HTML DOM specifications that an element should not be named "submit" or
>> "action" to avoid such consequences. Was this considered?
>
> I don't think we want to limit these names, since this would be an
> unbounded set of names that made older documents non-conforming as the
> language evolved.
>
>
>> What is the decision for advocating the coding practice of
>> form-as-collection?
>
> It's convenient.
>

It is an ill-advised practice that has been known to be a source of problems.

http://www.jibbering.com/faq/faq_notes/form_access.html#faComMis

>
>> What is the rationale for standardizing it?
>
> Browsers support it.
>

They don't really do a very good job of supporting it in a way that is
reliably useful.

We can see that if a control is name "item", for example, the form
will, in Opera, end up with an item key that ends up in the loop
twice:-




   length twice






var f = document.forms[0].elements, a=[];
for(p in f) {
   a.push('"'+p+'" : ' + f[p]);
}

document.write(""+a.join(",\n")+"<"+"/xmp>");




Opera:
"0" : [object HTMLInputElement],
"length" : [object HTMLInputElement],
"length" : [object HTMLInputElement],
"item" : function item() { [native code] },
"namedItem" : function namedItem() { [native code] },
"tags" : function tags() { [native code] }

We can also see that there is a memory leak created in Firefox and
Webkit when accessing form controls directly off the form.
http://jibbering.com/faq/names/simple-leak-form-input.html

It is advisable to not use form as a collection. It provides no added
convenience. It provides safety. Also, it is defined.

If WF 2.0 is going to define form to be a collection, it should do so
in a way that is clear an unambiguous. One way to do this would be to
clearly define the collection type, e.g. "The HTMLFormElement extends
the HTMLFormControls collection". However, it should be the case that
this is true in the majority of desktop browsers. Currently, it is
not; accessing controls directly from the form works a little
differently.

WF 2.0 should also define conflict resolution between properties of
the form (which may be readonly) and getters, which may be present ont
the form's prototype chain (this is legal and implementation
dependent).

>
>> The implied expectation of the specification is that the values for
>> form.action and form.submit will be replaced by elements of the
>> corresponding name. It could be expected that an element named "length"
>> or "tagName" would create a "length" property on the form, except for
>> the fact that form.length is defined as readonly[1] in another
>> specification. What should happen in that case? Can a readonly property
>> be replaced? What is the suggested approach for submitting to an API
>> that requires a parameter named "submit" or "action"?
>
> WebIDL will define these cases.

It seems that your Web Forms API specification has already done so:
http://www.whatwg.org/specs/web-forms/current-work/#additions

- and we can witness yet again an early adoption in Webkit.

http://jibbering.com/faq/names/form_override_change_name.html

Safari 2 result:
FAIL: The following 80 form properties should have been an INPUT element:

Safari 3 result:
PASS - All Form Properties Replaced by an Element

We can clearly see that Safari 3 is more compliant to the API than
Safari 2, and without any WEB IDL to describe what should happen when
replacing readonly properties or setting value to a property that has
a getter in the prototype chain.

It would be a good idea to not use examples which directly access
controls off the form in non-standard fashion. I also recommend that
the relevant sections of Web Forms 2.0 be removed. At the very least,
the relevant sections should be amended with a note describing that
the problem has not yet been resolved.

Also, you should change "elements array" so that it is not called an
array. Calling the elements collection an array will only add to the
misconception.

Garrett

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

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg12183.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20081110&amp;o=newest&amp;f=1">2008-11-10</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Ian+Hickson%22&amp;o=newest&amp;f=1">Ian Hickson</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Thu, 14 Aug 2008, Garrett Smith wrote:
>
> There is no note in the WF 2.0 specification, nor the HTML 4.01, nor the 
> HTML DOM specifications that an element should not be named "submit" or 
> "action" to avoid such consequences. Was this considered?

I don't think we want to limit these names, since this would be an 
unbounded set of names that made older documents non-conforming as the 
language evolved.


> What is the decision for advocating the coding practice of 
> form-as-collection?

It's convenient.


> What is the rationale for standardizing it?

Browsers support it.


> The implied expectation of the specification is that the values for 
> form.action and form.submit will be replaced by elements of the 
> corresponding name. It could be expected that an element named "length" 
> or "tagName" would create a "length" property on the form, except for 
> the fact that form.length is defined as readonly[1] in another 
> specification. What should happen in that case? Can a readonly property 
> be replaced? What is the suggested approach for submitting to an API 
> that requires a parameter named "submit" or "action"?

WebIDL will define these cases.

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

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg12182.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20081110&amp;o=newest&amp;f=1">2008-11-10</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Ian+Hickson%22&amp;o=newest&amp;f=1">Ian Hickson</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Tue, 29 Jul 2008, Garrett Smith wrote:
>
> I took a brief look at the WF 2.0 document yesterday and found some
> serious misconceptions and examples of "programming by coincidence."
> These reflect very poorly on html5.
> 
> The errors can be found on the link:
> http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
> 
> Doc Bugs:
> 1) Treating a a form element as an HTMLCollection.
> 2) The use of - with - to augment the scope chain is not necessary.
> 3) Calling the "elements" HTMLCollection an "array"
> 
> (1) The definition of HTMLFormElement does not have a specialized 
> [[Get]] for element names (nor should there be, as this is known to be 
> problematic). The example in the documetation depends on such behavior.

It actually does at this point.


> (2) - with - augments the scope chain with the object. This is 
> completely unnecessary here and will create problems if, for example, 
> there is an element named "watch". It is a bad practice and I see this 
> influence in the popular libraries.

This is a non-issue in the HTML5 spec, it seems.


> (3) There is no specification for a special [[Get]] for the "elements" 
> HTMLCollection as a shortcut to "namedItem", either (though this would 
> not seem to be a problem, and all implementations have supported this 
> behavior for quite a long time). I did notice that the elements 
> collection is mistakenly called an 'array'. This is a serious 
> documentation mistake of the worst kind: The spreading of 
> misinformation. It will continue influence the muddy knowledge that is 
> so common among most developers who tend want to call "push" et c 
> directly on that NodeList object (see the "dojo.NodeList" for details). 
> The elements Collection should be called an HTMLCollection and this 
> should be changed immediately.

Is this all resolved in HTML5?

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

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10949.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080820&amp;o=newest&amp;f=1">2008-08-20</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Thu, Aug 14, 2008 at 1:18 AM, timeless <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 12, 2008 at 12:53 AM, Kristof Zelechovski
> <[EMAIL PROTECTED]> wrote:
>> I have considered inline response.  I have two options: do it by hand (I am
>> rather busy) and do it for every reply (which makes business people angry).
>
> err. i didn't realize you were using outlook.
>
> http://home.cs.tum.edu/~jain/software/outlook-quotefix/
>
> just install it. you can easily enable/disable it.
>

Or get Thunderbird:
http://www.mozilla.com/en-US/thunderbird/

Garrett

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10878.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080816&amp;o=newest&amp;f=1">2008-08-16</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Thu, Aug 14, 2008 at 6:15 PM, Garrett Smith <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 13, 2008 at 2:02 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>> On Wed, 13 Aug 2008, Kristof Zelechovski wrote:
>>>
>>> While we are at collections and arrays, it is worth noting that the
>>> {coll.length} attribute is a misnomer.  I would always ask for
>>> {coll.count} when I was learning and meditate upon why it did not work.
>>
>> It's too late to change that kind of thing, and consistency is better at
>> this point, so we should keep using 'length'.
>>
>
> of course.

I meant: Of course it's too late to change to 'count'. It's not too
late to deprecate form.length, since form.elements.length provides a
more reliable alternative.

My other questions remain, along with the questionable parts of Web Forms 2.0.

Garrett

>> --
>> Ian Hickson   U+1047E

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10874.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080814&amp;o=newest&amp;f=1">2008-08-14</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Wed, Aug 13, 2008 at 2:02 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Aug 2008, Kristof Zelechovski wrote:
>>
>> While we are at collections and arrays, it is worth noting that the
>> {coll.length} attribute is a misnomer.  I would always ask for
>> {coll.count} when I was learning and meditate upon why it did not work.
>
> It's too late to change that kind of thing, and consistency is better at
> this point, so we should keep using 'length'.
>

of course.

However, there is the possibility of changing the WF 2.0 documentation to:
1) call the collection a collection (not an array)

2) access elements via the - form.elements - property, not treating
the form as a collection and .

In Web Forms 2.0 we have:

| If a name is used by more than one control, the
| form object has a property of that name that references
| a NodeList interface that lists the controls of that name.
|
| If a name is used by exactly one control, the form object
| has a property of that name that references that control.

This explicit standardization encourage authors to treat the form as a
collection.

That practice is a problem because it creates ambiguity with property names.

It is a fairly common mistake for a developer to use the following construct:



It is historically a problem dating back to Netscape 4.

The problem is that it would create an issue with the form's submit()
method in most browsers. There is no note in the WF 2.0 specification,
nor the HTML 4.01, nor the HTML DOM specifications that an element
should not be named "submit" or "action" to avoid such consequences.
Was this considered?

What is the decision for advocating the coding practice of form-as-collection?

What is the rationale for standardizing it?

Modern browsers, for compatibility, have implemented the older
Netscape 4 functionality. Pages use this type of coding less and less.

The implied expectation of the specification is that the values for
form.action and form.submit will be replaced by elements of the
corresponding name. It could be expected that an element named
"length" or "tagName" would create a "length" property on the form,
except for the fact that form.length is defined as readonly[1] in
another specification. What should happen in that case? Can a readonly
property be replaced? What is the suggested approach for submitting to
an API that requires a parameter named "submit" or "action"?

==




 Form as Collection - submit, length, name,
  tagName and action replacement  
  
  http://www.whatwg.org/specs/web-forms/current-work/#resetFromDataDOM"/>
  
.fail {
  background: #F33;
}
#pass {
  display: none;
  background: #0f0;
}
  



  
  
  
  
  

PASS


var form = document.forms[0],
  failed = false;
  form.elements.sub.name='submit';
  form.elements.act.name='action';
  form.elements.nam.name='name';

if(!form.submit.name) {
  fail('submit() was not replaced: ' + form.submit.name);
  failed = true;
}
if(form.action === "a") {
  fail('action was not replaced.');
  failed = true;
}
if(form.name === "n") {
  fail('name was not replaced.');
  failed = true;
}
if(form.tagName.value === "d") {
  fail('tagName was replaced with element: ' + form.tagName);
  failed = true;
}
if(form.length.value === "-1") {
  fail('length was replaced with element: ' + form.length);
  failed = true;
}

if(!failed)
  document.getElementById('pass').style.display
= "inline-block";
function fail(s){
  var f = document.createElement('div');
  f.className = 'fail';
  f.appendChild(document.createTextNode('FAIL: '+ s));
  document.body.appendChild(f);
}



==

Results in Firefox 3, Spidermonkey, Opera 9, Safari 3, IE7:

FAIL: tagName was replaced with element: [object HTMLInputElement]
FAIL: length was replaced with element: [object HTMLInputElement]

But we can witness early adoption this specification by observing what
will happen in an older version of Safari.

FAIL: submit() was not replaced: undefined
FAIL: action was not replaced.
FAIL: name was not replaced.
FAIL: tagName was replaced with element: [object INPUT]
FAIL: length was replaced with element: [object INPUT]

While not ideal, this seems to be a more desirable result than what
Safari 3 produces. It seems undesirable (as well as a standards
conflict) to assign form.tagName an INPUT object.

Rather than give a form a corresponding property for each named
element, it seems much better design to use the elements collection
for this behavior, and the specification should encourage such use
with words and examples.

The only reason I can see standardizing this further is that browsers
implement this today and it is (I was wrong) standardized[2] (though
vaguely).

Considering the vague wording of the DOM 2 HTML Spec:
| The FORM element encompasses behavior similar
| to a collection and an element. It provides direct
| access to the contained input elements as well as
| the attributes of the form element. See the FORM
</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10863.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080814&amp;o=newest&amp;f=1">2008-08-14</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22timeless%22&amp;o=newest&amp;f=1">timeless</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Tue, Aug 12, 2008 at 12:53 AM, Kristof Zelechovski
<[EMAIL PROTECTED]> wrote:
> I have considered inline response.  I have two options: do it by hand (I am
> rather busy) and do it for every reply (which makes business people angry).

err. i didn't realize you were using outlook.

http://home.cs.tum.edu/~jain/software/outlook-quotefix/

just install it. you can easily enable/disable it.

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10853.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080813&amp;o=newest&amp;f=1">2008-08-13</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Ian+Hickson%22&amp;o=newest&amp;f=1">Ian Hickson</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Wed, 13 Aug 2008, Kristof Zelechovski wrote:
>
> While we are at collections and arrays, it is worth noting that the 
> {coll.length} attribute is a misnomer.  I would always ask for 
> {coll.count} when I was learning and meditate upon why it did not work.

It's too late to change that kind of thing, and consistency is better at 
this point, so we should keep using 'length'.

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

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10846.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080813&amp;o=newest&amp;f=1">2008-08-13</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Kristof+Zelechovski%22&amp;o=newest&amp;f=1">Kristof Zelechovski</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
While we are at collections and arrays, it is worth noting that the
{coll.length} attribute is a misnomer.  I would always ask for {coll.count}
when I was learning and meditate upon why it did not work.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Monday, August 04, 2008 7:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented

I&#x27;m a little surprised at the lack of response here, so I&#x27;m replying
to myself here, just to keep this issue active.

I did a little more research and found that the misconception is more
common that I thought: DOM objects that have indexed properties are
often mistaken for arrays. This is the &quot;misconception&quot; that I found
documented in HTML5.




</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10826.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080812&amp;o=newest&amp;f=1">2008-08-12</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Kristof+Zelechovski%22&amp;o=newest&amp;f=1">Kristof Zelechovski</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
While 'form.elements' is not obsolete, 'form.elements.something' (to mean
'form.elements.namedItem("something")') is.  Actually, it is some news to me
that such syntax is supported; I was only aware of the syntax
'form.something' (obsolete, but convenient) and
'form.elements("something")'.  That 'form.length' mirrors
'form.elements.length', while still supported, is just ridiculous; I missed
that as well.  Everything you say is true, except that the merrie olde
syntaxe is not that ambiguous as you present it.  Indeed, I cannot see any
ambiguity at all.
I am not using MSDN as the source of information what the Web should look
like; I am using it to understand existing code that the standard does not
cover, e.g. 'form.control' or 'new Image()' (incidentally, this is
'Image.Create()' in Visual Basic Scripting Edition).
Thanks for pointing that out.
Chris




</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10825.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080812&amp;o=newest&amp;f=1">2008-08-12</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Tue, Aug 12, 2008 at 4:06 AM, Kristof Zelechovski
&lt;[EMAIL PROTECTED]&gt; wrote:
&gt; The attribute FORM.length is not parseable: it cannot be defined in the HTML
&gt; source and such definition should be ignored.  The intrinsic computed length
&gt; attribute should take precedence over the imported control name which can be
&gt; retrieved calling form.elements.item(&quot;length&quot;).

Please stop posting this type of code. This is nonstandard and will
only work in IE and browsers that strive to closely emulate IE
(Opera). Same goes for document.all or other things you&#x27;ll see on the
MSDN site. MSDN is useful for other things, but it is not a standard
reference.

&gt; Chris
&gt;
&gt; -Original Message-
&gt; From: [EMAIL PROTECTED]
&gt; [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
&gt; Sent: Wednesday, August 06, 2008 8:24 PM
&gt; To: Maciej Stachowiak
&gt; Cc: Cameron McCormack; [EMAIL PROTECTED]
&gt; Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
&gt;
&gt; Testcases to determine what implementations do and what are the worst
&gt; problems to avoid would be the most useful at this point. For example,
&gt; a HTMLFORMElement with the name &quot;length&quot;, and attribute &quot;length&quot; on
&gt; the form.
&gt;
&gt; 
&gt;  
&gt; 
&gt;
&gt; Please do make up some test cases. You can post these to the list.
&gt; Talk to Ian about where to upload them for reference.
&gt;
&gt;
&gt;
&gt;

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10824.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080812&amp;o=newest&amp;f=1">2008-08-12</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Mon, Aug 11, 2008 at 2:53 PM, Kristof Zelechovski
&lt;[EMAIL PROTECTED]&gt; wrote:
&gt; I have considered inline response.  I have two options: do it by hand (I am
&gt; rather busy) and do it for every reply (which makes business people angry).

The audience for this list is developers.

&gt; I am sorry for the inconvenience it causes.

It adds more confusion to the misinformation and wrong arguments. It
makes communication more difficult and makes whatever you are trying
to argue seem harder to get the point of. It makes the discussion
harder to follow.

&gt; The item method on a collection when the argument passed is a string that
&gt; cannot be coerced to an integer is equivalent to namedItem.

MSDN is not a reference for web standards information. Thank you for
pointing that out.

&gt; A form element
&gt; does not have an intrinsic length property; it can be added as an embedded
&gt; named control or by a script.  The elements collection has the intrinsic
&gt; length property and it cannot be shadowed.

It would be more correct to say: elements.length is readonly.

&gt; My source of information is MSDN, as you have correctly guessed.

I didn&#x27;t actually guess.

&gt; If you
&gt; have contradictory information on legacy interfaces, please share it with
&gt; us.  Note that there is no way we can say it is correct or not; it is an
&gt; obsolete interface after all.

the &#x27;elements&#x27; property of an HTMLFormElement is not obsolete[1]

An HTMLFormElement, is not an HTMLCollection. elements is an
HTMLCollection. The form has no item() no namedItem(). These are
operations that can be carried out on an HTMLCollection.


&gt; However, if it is consistent and all major
&gt; implementations support it, there is no reason to think it is false.
&gt; The name &#x27;ell&#x27; I used is a name of an embedded control in order to make it
&gt; different.  I am not sure about undefined versus null; I rather use Visual
&gt; Basic Scripting Edition and I get Nothing (not Empty) for a property an
&gt; object does not have.  It may as well be undefined under JavaScript.

Undefined is the return value from [[Get]] when a property does not
exist. It seems reasonable to expect that [[Get]] on a Host object
would behave in the same way.

&gt; Chris
&gt; See also &lt;http://msdn.microsoft.com/en-us/library/ms536460(VS.85).aspx&gt;.
&gt;

That is useful, but should not be a reference as to how the item()
method works or should be expected to work. It is a proprietary
extension that Microsoft took. It isn&#x27;t something that script authors
rely on because it&#x27;s not cross browser.

Garrett

[1] DOM Level 2 HTML http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357


&gt; -Original Message-
&gt; From: Garrett Smith [mailto:[EMAIL PROTECTED]
&gt; Sent: Monday, August 11, 2008 10:37 PM
&gt; To: Kristof Zelechovski
&gt; Cc: WHATWG List; Maciej Stachowiak
&gt; Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
&gt;
&gt; On 8/11/08, Kristof Zelechovski &lt;[EMAIL PROTECTED]&gt; wrote:
&gt;
&gt; Hi Chris,
&gt;
&gt; Thanks for taking the time to respond to some things I was writing
&gt; about. I think these are important things that deserve attention, too.
&gt;
&gt; If it&#x27;s not too much to ask, have you considered inline style response?
&gt; http://en.wikipedia.org/wiki/Posting_style#Inline_replying
&gt;
&gt; I tried to restore posting order, but since you are using Outlook, it
&gt; was not effectively possible.
&gt;
&gt;&gt; Neither the expression &#x27;form.elements.$name&#x27; nor its expanded form
&gt;&gt;  &#x27;form.elements[&quot;$name&quot;]&#x27; is supposed to be defined even if $name is an
&gt;&gt;  identifier of an embedded control.  The correct way to address the
&gt; control
&gt;&gt;  is &#x27;form.elements(&quot;$name&quot;)&#x27;,
&gt;
&gt; Can you cite a reference for this?
&gt;
&gt; AFAIK, this is an IE feature that was copied.
&gt;
&gt;&gt; which is a shorthand notation for
&gt;&gt;  &#x27;form.elements.item(&quot;$name&quot;)&#x27;.
&gt;
&gt; No, that is wrong. Doubly wrong, I think. The item method retrieves a
&gt; node by ordinal index (based on depth-first traversal).
&gt;
&gt;  now if you had wrote:-
&gt;
&gt; form.elements.namedItem(&quot;$name&quot;)
&gt;
&gt; That would at least be partially correct. If namedItem is what you
&gt; meant, then please supply a reference to back up your claim. I do not
&gt; think the claim:
&gt;
&gt; | The correct way to address the control is &#x27;form.elements(&quot;$name&quot;)&#x27;
&gt;
&gt; is true and correct. I think it&#x27;s an MSIE invention that other
&gt; implementations copied.
&gt;
&gt;&gt; These two should not be confused.
&gt;&gt;  Therefore, the bug in Opera is not about shadowing the length property
&gt; but
&gt;&gt;  about defining the corresponding property at all (in particular,
&gt;&gt;  &#x27;form.elements.ell&#x27; should be null no matter what).
&gt;
&gt; Are you referring to the example I supplied?
&gt;
&gt;&gt;  </pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10817.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080812&amp;o=newest&amp;f=1">2008-08-12</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Kristof+Zelechovski%22&amp;o=newest&amp;f=1">Kristof Zelechovski</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
It is probably too late for that but I like the concept of a default
property much better than metaattributes like IndexGetter.
For example, document.forms(0) means &quot;call forms on document with argument
0&quot;.  That is impossible because forms is not a function so we look into
forms collection and we see that it has the default method named item.  So
we proceed by expanding it to document.forms.item(0) and we see it works.
I like it because it is simple, elegant and generic, whereas IndexGetter and
what you have looks ad-hoc.
I have never seen document.forms.main used to get at the form named &quot;main&quot; 
but probably I have not seen that much.  I wonder how common it is.
Of course, I agree that it is best to be explicit and not to rely on such
tricks at all.  The downside is that, for example, while
a.getAttributeNode(&quot;href&quot;).value = url is technically superior to a.href =
url, it is much harder to read so care must be taken not to overshoot.  But
form.elements.item(&quot;main&quot;) is just fine.
Regarding how the named elements get to be true properties, the shadowing
behavior can be specified without recurring to getters.  It is sufficient to
say that an intrinsic property is never replaced by a constructed shortcut
property and we get the same result.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, August 06, 2008 8:49 AM
To: Thomas Broyer
Cc: [EMAIL PROTECTED]
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented

On Tue, Aug 5, 2008 at 4:02 PM, Thomas Broyer &lt;[EMAIL PROTECTED]&gt; wrote:
&gt; On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
&gt;&gt; On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
&gt;&gt;&gt;
&gt;&gt; First off, the IndexGetter behavior on the HTMLCollection[1] is the
&gt;&gt; authors imagination.
&gt;
&gt; Aren&#x27;t &quot;document.forms[0]&quot; and &quot;document.forms.myform&quot; working?
&gt;

Can you be more specific and direct in your reply? It isn&#x27;t clear what
your point is.

&gt;&gt; The following example shows that indexed Properties exist on
&gt;&gt; NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
&gt;&gt; There is no [[ IndexGetter ]] as Cameron likes to make pretend.
&gt;
&gt; This is an &quot;implementation detail&quot; of the ECMAScript binding.
&gt;

In EcmaScript, the property access operators seem to look like a
&quot;getter&quot; to Cameron. What they really do is provide access to
properties added to the collection, or, in one case (on one
implementation), this seems implemented as a &quot;getter&quot;. A &quot;getter&quot; is a
method that gets the value of a property of that name.




</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10815.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080812&amp;o=newest&amp;f=1">2008-08-12</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Kristof+Zelechovski%22&amp;o=newest&amp;f=1">Kristof Zelechovski</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
The attribute FORM.length is not parseable: it cannot be defined in the HTML
source and such definition should be ignored.  The intrinsic computed length
attribute should take precedence over the imported control name which can be
retrieved calling form.elements.item(&quot;length&quot;).
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, August 06, 2008 8:24 PM
To: Maciej Stachowiak
Cc: Cameron McCormack; [EMAIL PROTECTED]
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented

Testcases to determine what implementations do and what are the worst
problems to avoid would be the most useful at this point. For example,
a HTMLFORMElement with the name &quot;length&quot;, and attribute &quot;length&quot; on
the form.


  


Please do make up some test cases. You can post these to the list.
Talk to Ian about where to upload them for reference.




</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10801.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080811&amp;o=newest&amp;f=1">2008-08-11</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Kristof+Zelechovski%22&amp;o=newest&amp;f=1">Kristof Zelechovski</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
I have considered inline response.  I have two options: do it by hand (I am
rather busy) and do it for every reply (which makes business people angry).
I am sorry for the inconvenience it causes.  
The item method on a collection when the argument passed is a string that
cannot be coerced to an integer is equivalent to namedItem.  A form element
does not have an intrinsic length property; it can be added as an embedded
named control or by a script.  The elements collection has the intrinsic
length property and it cannot be shadowed.  
My source of information is MSDN, as you have correctly guessed.  If you
have contradictory information on legacy interfaces, please share it with
us.  Note that there is no way we can say it is correct or not; it is an
obsolete interface after all.  However, if it is consistent and all major
implementations support it, there is no reason to think it is false.  
The name &#x27;ell&#x27; I used is a name of an embedded control in order to make it
different.  I am not sure about undefined versus null; I rather use Visual
Basic Scripting Edition and I get Nothing (not Empty) for a property an
object does not have.  It may as well be undefined under JavaScript.
Chris
See also &lt;http://msdn.microsoft.com/en-us/library/ms536460(VS.85).aspx&gt;.

-Original Message-
From: Garrett Smith [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 11, 2008 10:37 PM
To: Kristof Zelechovski
Cc: WHATWG List; Maciej Stachowiak
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented

On 8/11/08, Kristof Zelechovski &lt;[EMAIL PROTECTED]&gt; wrote:

Hi Chris,

Thanks for taking the time to respond to some things I was writing
about. I think these are important things that deserve attention, too.

If it&#x27;s not too much to ask, have you considered inline style response?
http://en.wikipedia.org/wiki/Posting_style#Inline_replying

I tried to restore posting order, but since you are using Outlook, it
was not effectively possible.

&gt; Neither the expression &#x27;form.elements.$name&#x27; nor its expanded form
&gt;  &#x27;form.elements[&quot;$name&quot;]&#x27; is supposed to be defined even if $name is an
&gt;  identifier of an embedded control.  The correct way to address the
control
&gt;  is &#x27;form.elements(&quot;$name&quot;)&#x27;,

Can you cite a reference for this?

AFAIK, this is an IE feature that was copied.

&gt; which is a shorthand notation for
&gt;  &#x27;form.elements.item(&quot;$name&quot;)&#x27;.

No, that is wrong. Doubly wrong, I think. The item method retrieves a
node by ordinal index (based on depth-first traversal).

 now if you had wrote:-

form.elements.namedItem(&quot;$name&quot;)

That would at least be partially correct. If namedItem is what you
meant, then please supply a reference to back up your claim. I do not
think the claim:

| The correct way to address the control is &#x27;form.elements(&quot;$name&quot;)&#x27;

is true and correct. I think it&#x27;s an MSIE invention that other
implementations copied.

&gt; These two should not be confused.
&gt;  Therefore, the bug in Opera is not about shadowing the length property
but
&gt;  about defining the corresponding property at all (in particular,
&gt;  &#x27;form.elements.ell&#x27; should be null no matter what).

Are you referring to the example I supplied?

&gt;  This could potentially be described in the EcmaScript bindings. But it
&gt;  would be a good idea to explore some edge cases. Particularly, if the
&gt;  case was the order of definition of properties: One such case would be
&gt;  an HTMLCollection with an element named &quot;length&quot;. In that case, the
&gt;  readonly &quot;length&quot; property would have to be the actual length of the
&gt;  collection; the value should not be replaced with an element of that
&gt;  name/id.
&gt;
&gt;  
&gt;
&gt;  document.forms[0].elements.length
&gt;
&gt;  Opera9: [object HTMLInputElement] &lt;-- BUG
&gt;  FF3: 1
&gt;  Saf3: 1

There was no element in my example with a id or name &#x27;ell&#x27;, so I would
have to say that form.elements.ell would be undefined, not null.

Where is this - ell - coming from?

&gt;  OTOH, the expression &#x27;form.length&#x27; is a perfect equivalent for
&gt;  &#x27;form.elements(&quot;length&quot;)&#x27;, provided a control with such a name is
contained.

form.elements has a readonly property named length.

That property can&#x27;t be changed (legally) just because a parse  event
found an element named (or id&#x27;d) &quot;length&quot;.

The length property of a form - form.length - refers to:

&gt;  Have you reported this to Opera technical support?
&gt;  I can see no harm in principle in assigning a value to &#x27;form.length&#x27;
because
&gt;  length is not an intrinsic property the form object.
&gt;

Chris, I have stated at least twice prior to this email that an
HTMLCollection has a readonly length property.

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506
| length of type unsigned long, readonly
| This attribute specifies the length or size of the list.

Garrett

&gt;
&gt;  Chris
&gt;



</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10800.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080811&amp;o=newest&amp;f=1">2008-08-11</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On 8/11/08, Kristof Zelechovski &lt;[EMAIL PROTECTED]&gt; wrote:

Hi Chris,

Thanks for taking the time to respond to some things I was writing
about. I think these are important things that deserve attention, too.

If it&#x27;s not too much to ask, have you considered inline style response?
http://en.wikipedia.org/wiki/Posting_style#Inline_replying

I tried to restore posting order, but since you are using Outlook, it
was not effectively possible.

&gt; Neither the expression &#x27;form.elements.$name&#x27; nor its expanded form
&gt;  &#x27;form.elements[&quot;$name&quot;]&#x27; is supposed to be defined even if $name is an
&gt;  identifier of an embedded control.  The correct way to address the control
&gt;  is &#x27;form.elements(&quot;$name&quot;)&#x27;,

Can you cite a reference for this?

AFAIK, this is an IE feature that was copied.

&gt; which is a shorthand notation for
&gt;  &#x27;form.elements.item(&quot;$name&quot;)&#x27;.

No, that is wrong. Doubly wrong, I think. The item method retrieves a
node by ordinal index (based on depth-first traversal).

 now if you had wrote:-

form.elements.namedItem(&quot;$name&quot;)

That would at least be partially correct. If namedItem is what you
meant, then please supply a reference to back up your claim. I do not
think the claim:

| The correct way to address the control is &#x27;form.elements(&quot;$name&quot;)&#x27;

is true and correct. I think it&#x27;s an MSIE invention that other
implementations copied.

&gt; These two should not be confused.
&gt;  Therefore, the bug in Opera is not about shadowing the length property but
&gt;  about defining the corresponding property at all (in particular,
&gt;  &#x27;form.elements.ell&#x27; should be null no matter what).

Are you referring to the example I supplied?

&gt;  This could potentially be described in the EcmaScript bindings. But it
&gt;  would be a good idea to explore some edge cases. Particularly, if the
&gt;  case was the order of definition of properties: One such case would be
&gt;  an HTMLCollection with an element named &quot;length&quot;. In that case, the
&gt;  readonly &quot;length&quot; property would have to be the actual length of the
&gt;  collection; the value should not be replaced with an element of that
&gt;  name/id.
&gt;
&gt;  
&gt;
&gt;  document.forms[0].elements.length
&gt;
&gt;  Opera9: [object HTMLInputElement] &lt;-- BUG
&gt;  FF3: 1
&gt;  Saf3: 1

There was no element in my example with a id or name &#x27;ell&#x27;, so I would
have to say that form.elements.ell would be undefined, not null.

Where is this - ell - coming from?

&gt;  OTOH, the expression &#x27;form.length&#x27; is a perfect equivalent for
&gt;  &#x27;form.elements(&quot;length&quot;)&#x27;, provided a control with such a name is contained.

form.elements has a readonly property named length.

That property can&#x27;t be changed (legally) just because a parse  event
found an element named (or id&#x27;d) &quot;length&quot;.

The length property of a form - form.length - refers to:

&gt;  Have you reported this to Opera technical support?
&gt;  I can see no harm in principle in assigning a value to &#x27;form.length&#x27; because
&gt;  length is not an intrinsic property the form object.
&gt;

Chris, I have stated at least twice prior to this email that an
HTMLCollection has a readonly length property.

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506
| length of type unsigned long, readonly
| This attribute specifies the length or size of the list.

Garrett

&gt;
&gt;  Chris
&gt;
&gt;  -Original Message-
&gt;  From: [EMAIL PROTECTED]
&gt;  [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
&gt;
&gt; Sent: Saturday, August 09, 2008 2:06 AM
&gt;  To: WHATWG List
&gt;  Cc: Maciej Stachowiak
&gt;  Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
&gt;
&gt;  On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak &lt;[EMAIL PROTECTED]&gt; wrote:
&gt;  &gt;
&gt;  &gt; On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
&gt;  &gt;
&gt;
&gt;  I&#x27;d like to put this back on the list, and it doesn&#x27;t contain anything
&gt;  personal, so I&#x27;m taking the liberty here.
&gt;  &gt;
&gt;  &gt; I&#x27;m not sure what you mean by &quot;in the binding&quot;.
&gt;
&gt;  I meant the EcmaScript binding.
&gt;
&gt;  &gt; Do you mean in Web IDL&#x27;s
&gt;  &gt; definition of how to map Web IDL interfaces to the ECMAScript language, or
&gt;  &gt; one-off in the HTML5 spec for every interface this applies to?
&gt;
&gt;  Narrowing the scope in the interest of not creating bugs seems like a
&gt;  very good idea.
&gt;

&gt;
&gt;  Another consideration would be a form element with an attribute
&gt;  &quot;length&quot;. That would be a problem as neither the attribute, nor the
&gt;  Netscape 4 DOM &quot;named items&quot; are specified as &quot;readonly&quot;. So that&#x27;s
&gt;  one reason for not specifying the Netscape 4 DOM and for removing that
&gt;  example from WF 2.0
&gt;  http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
&gt;
&gt;  &gt;
&gt;
&gt;

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10798.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080811&amp;o=newest&amp;f=1">2008-08-11</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Kristof+Zelechovski%22&amp;o=newest&amp;f=1">Kristof Zelechovski</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
Neither the expression &#x27;form.elements.$name&#x27; nor its expanded form
&#x27;form.elements[&quot;$name&quot;]&#x27; is supposed to be defined even if $name is an
identifier of an embedded control.  The correct way to address the control
is &#x27;form.elements(&quot;$name&quot;)&#x27;, which is a shorthand notation for
&#x27;form.elements.item(&quot;$name&quot;)&#x27;.  These two should not be confused.
Therefore, the bug in Opera is not about shadowing the length property but
about defining the corresponding property at all (in particular,
&#x27;form.elements.ell&#x27; should be null no matter what).
OTOH, the expression &#x27;form.length&#x27; is a perfect equivalent for
&#x27;form.elements(&quot;length&quot;)&#x27;, provided a control with such a name is contained.
Have you reported this to Opera technical support?
I can see no harm in principle in assigning a value to &#x27;form.length&#x27; because
length is not an intrinsic property the form object.

Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Saturday, August 09, 2008 2:06 AM
To: WHATWG List
Cc: Maciej Stachowiak
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented

On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak &lt;[EMAIL PROTECTED]&gt; wrote:
&gt;
&gt; On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
&gt;

I&#x27;d like to put this back on the list, and it doesn&#x27;t contain anything
personal, so I&#x27;m taking the liberty here.
&gt;
&gt; I&#x27;m not sure what you mean by &quot;in the binding&quot;.

I meant the EcmaScript binding.

&gt; Do you mean in Web IDL&#x27;s
&gt; definition of how to map Web IDL interfaces to the ECMAScript language, or
&gt; one-off in the HTML5 spec for every interface this applies to?

Narrowing the scope in the interest of not creating bugs seems like a
very good idea.

This could potentially be described in the EcmaScript bindings. But it
would be a good idea to explore some edge cases. Particularly, if the
case was the order of definition of properties: One such case would be
an HTMLCollection with an element named &quot;length&quot;. In that case, the
readonly &quot;length&quot; property would have to be the actual length of the
collection; the value should not be replaced with an element of that
name/id.



document.forms[0].elements.length

Opera9: [object HTMLInputElement] &lt;-- BUG
FF3: 1
Saf3: 1

Another consideration would be a form element with an attribute
&quot;length&quot;. That would be a problem as neither the attribute, nor the
Netscape 4 DOM &quot;named items&quot; are specified as &quot;readonly&quot;. So that&#x27;s
one reason for not specifying the Netscape 4 DOM and for removing that
example from WF 2.0
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default

&gt;


</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10790.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080808&amp;o=newest&amp;f=1">2008-08-08</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
>

I'd like to put this back on the list, and it doesn't contain anything
personal, so I'm taking the liberty here.
>
> I'm not sure what you mean by "in the binding".

I meant the EcmaScript binding.

> Do you mean in Web IDL's
> definition of how to map Web IDL interfaces to the ECMAScript language, or
> one-off in the HTML5 spec for every interface this applies to?

Narrowing the scope in the interest of not creating bugs seems like a
very good idea.

This could potentially be described in the EcmaScript bindings. But it
would be a good idea to explore some edge cases. Particularly, if the
case was the order of definition of properties: One such case would be
an HTMLCollection with an element named "length". In that case, the
readonly "length" property would have to be the actual length of the
collection; the value should not be replaced with an element of that
name/id.



document.forms[0].elements.length

Opera9: [object HTMLInputElement] <-- BUG
FF3: 1
Saf3: 1

Another consideration would be a form element with an attribute
"length". That would be a problem as neither the attribute, nor the
Netscape 4 DOM "named items" are specified as "readonly". So that's
one reason for not specifying the Netscape 4 DOM and for removing that
example from WF 2.0
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default

>
> I think the Web IDL spec should correctly define how to map Web IDL to
> ECMAScript, while not precluding the possibility of mapping to other
> languages.

It's a good idea to understand what is happening in the language we're
concerned with: EcmaScript implementations (browsers) are where the
phenomenon was noticed and from where the concern was raised.

Aren't [IndexGetter] and [ NameGetter] are really doing the same thing
in most cases?

Why differentiate between "number" properties and "name" properties?

Is "added as properties" an accurate description?

For example:
For each item in the collection object, a corresponsding property is
present on that object. The property's name is the ordinal index and
the value is the result of calling the collection's item() method.

>From the Web IDL WD:
http://dev.w3.org/2006/webapi/WebIDL/#IndexGetter

| An ECMAScript implementation would have an internal [[Get]]
| method that allows values to be retrieved from the  map as
| properties, and a corresponding [[Put]] method for setting values
| in the map:
| ECMAScript
|
|  // Assume map is a host object implementing
| //  the OrderedMap interface.
| var map = getOrderedMap();
| var x, y;
|
| x = map[0]; // Same as: x = map.getByIndex(0)
| map[1] = false; // Same as: map.setByIndex(1, false)
|
| y = map.apple;  // Same as: y = map.get('apple')
| map.banana = 123;   // Same as: map.set('banana', 123)
`--

It seems that the expectation is that [[Get]] will differentiate
between and typecheck the Expression. This is not how property access
works. In the above, the Expression in map[0] is 0. This 0 is
converted to the string "0".

| The production MemberExpression :
| MemberExpression [ Expression  ] is evaluated as follows:
|
| 1. Evaluate MemberExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate Expression.
| 4. Call GetValue(Result(3)).
| 5. Call ToObject(Result(2)).
| 6. Call ToString(Result(4)).

In step 4., we call GetValue(Result(3)

| 8.7.1 GetValue(V)
|
|  4.. If Type(V) is not Reference, return V.

Type V is not a reference, it is a Number, 0, so 0 is returned to
property access algorithm step 4. In step 6, property access calls
ToString(Result(4)),

| 9.8.1 ToString Applied to the Number Type

This is a little involved, and includes exponential notation, but the
result of ToString(0), will be "0",

map[0] has the same effect as map["0"].

I don't know if any other languages have this functionality.

Now the same cannot be said for [[Put]] because Arrays have a special
[[Put]] method that does do some checking on the Expression. Array's
[[Put]] can change the length of the Array, or, if the property name
is 'length', can cause indexed properties to be deleted. Special
[[Put]] functionality might apply to the HTMLSelectElement, which in
all browsers will create/remove options when the length is changed.
However, a "[NameSetter]"  seems over the top.
http://dev.w3.org/2006/webapi/WebIDL/#NameSetter




Magic-Select [[Put]]




var a = document.forms[0].elements.aaa;
a.length = 12
a.options[3].text = "pass";
a.selectedIndex = 3;




Wouldn't it be better to just have a simple note in the HTML 5 spec
what happens when a Select's length property is set?

Garrett

> This may include hints that are relevant to ECMAScript but not
> for most other language bindings. Indeed [IndexGetter] is such a hint, and
> the Web IDL spec includes other aspects </pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10761.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080807&amp;o=newest&amp;f=1">2008-08-07</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Maciej+Stachowiak%22&amp;o=newest&amp;f=1">Maciej Stachowiak</a></span>
</div>
<blockquote><span class="msgFragment"><pre>


On Aug 7, 2008, at 1:51 PM, Garrett Smith wrote:

On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:


On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:


On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:





I think Web IDL should provide a formalism to cater to this,  
because

nearly
all bindings with special dynamic properties work like this  
afaik. But I
think it would have to involve a pseudo-method for the  
"hasOwnProperty"

check (which "in" is based on).


hasOwnProperty is ECMAScript-specific.




Yes it is.

The Web IDL includes specific requirements for how to map an  
interface
specified in Web IDL to ECMAScript. So, indeed, that would be the  
part of

the Web IDL spec that would be the best place to define this.



Since Maciej is probably considered to be an EcmaScript expert and I
am not, and since he had stated that 'in' calls 'hasOwnProperty', and
even continued to argue the claim, it is necessary and appropriate to
demonstrate proof that the 'in' does not call 'hasOwnProperty'.

The following example shows that no implementation calls
hasOwnProperty with use of 'in' operator.


The more accurate way to put it would be that the 'in' operator  
performs the same check at ever item in the prototype chain (including  
the original object) that the original value of hasOwnProperty  
performs on only the object itself. You are correct that replacing  
hasOwnProperty either on an object or in its prototype chain will have  
no effect on operation of the 'in' operator.



'hasOwnProperty' is EcmaScript specific. Whether or not ordinally
indexed properties should be 'own' properties is not a place for IDL
to decide.


It is just as relevant to specify whether a property is an own  
property as it is to specify whether it is visible to the 'in'  
operator. Both are edge cases that may affect interoperability but  
likely won't (since most authors will just get the property, and not  
check for presence). Visibility to the 'in' operator seems to  
observable difference on which you base your distinction between  
'having a getter' and 'having a real property'.


Regards,
Maciej


</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10760.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080807&amp;o=newest&amp;f=1">2008-08-07</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
>
>> On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
>>>


>>> I think Web IDL should provide a formalism to cater to this, because
>>> nearly
>>> all bindings with special dynamic properties work like this afaik. But I
>>> think it would have to involve a pseudo-method for the "hasOwnProperty"
>>> check (which "in" is based on).
>>
>> hasOwnProperty is ECMAScript-specific.
>

Yes it is.

> The Web IDL includes specific requirements for how to map an interface
> specified in Web IDL to ECMAScript. So, indeed, that would be the part of
> the Web IDL spec that would be the best place to define this.
>

Since Maciej is probably considered to be an EcmaScript expert and I
am not, and since he had stated that 'in' calls 'hasOwnProperty', and
even continued to argue the claim, it is necessary and appropriate to
demonstrate proof that the 'in' does not call 'hasOwnProperty'.

The following example shows that no implementation calls
hasOwnProperty with use of 'in' operator.

If an implementation were to do that, that would be a bug.

There should be an alert on the second button and no alert on the
first. After both buttons have been clicked once, there should be a
green PASS.




  hasOwnProperty
  
#fail { background: red; }
#pass { background: #0f0; }
.res { display: none; font-weight: 700; }
  




  var rec = {}, failed;
  var mo = {
name : "Maciej",
title : "unknown"
  };

  Object.prototype.hasOwnProperty = function(p) {
if(p == "unknown") {
   document.getElementById('fail').style.display='inline-block';
   failed = true;
   }
alert('calling hasOwnProperty: '+ p);
  };

   function testIn(){
   rec['name'] = true;
   checkPass();
   'name'in mo;
   }

   function testHasOwnProperty(p){
   rec['title'] = true;
   checkPass();
   mo.hasOwnProperty('name');
   }

   function checkPass(){
   if(rec['name'] && rec['title'] && !failed)
   document.getElementById('pass').style.display='inline-block';
   }

testIn()
testHasOwnProperty;

FAIL
PASS



=

Result in IE8b1, FF3, Webkit, Op9, Saf2.04
* alert on second button,
* PASS

the 'in' operator does not call 'hasOwnProperty'.

'hasOwnProperty' is EcmaScript specific. Whether or not ordinally
indexed properties should be 'own' properties is not a place for IDL
to decide.

Garrett

> Regards,
> Maciej
>
>

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10729.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080806&amp;o=newest&amp;f=1">2008-08-06</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Wed, Aug 6, 2008 at 7:03 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Aug 6, 2008, at 11:23 AM, Garrett Smith wrote:
>
>>
>> My apologies for being rude.
>>
>> What would you suggest, Maciej?
>
> I would suggest:
>
> a) Point out mistakes courteously.

Done.

> b) Preferably do so in the appropriate public forum where others can see
> them (I don't see any mail from you on this topic in public-webapps).

Sorry, it was public-html, not webapi.

> c) Assume good faith on the part of the editor, even if you do not receive
> an immediate reply.
>

I'll do my best.

>> If Cameron McCormick ignores constructive criticism for three weeks,
>> what's to say he'll won't ignore it another three weeks and then
>> forget about it altogether?
>
> Because he has a track record of responding to feedback
>

These things often change and develop very quickly. Two weeks seems
like long enough. Should it be four?


>> I tried to elicit a response by providing test cases and through
>> constructive criticism.
>>
>> The longer that document stays up there in its current form, the
>> greater the chance that someone will come along and write a book or
>> blog about this and teach those who are less knowledgeable, and pretty
>> soon, it starts appearing as a 'bug' on webbugtrack and filed as a bug
>> against IE. It has happened before. I can see on the JScript blog
>> right now, a bug that is not a bug, filed against IE, and comments
>> from the JScript team about how they will "fix" it.
>
> This lacks all sense of proportion. No one expects a W3C Working Draft to be
> technically correct in all details,

I ask that the standards docs are based on tests and facts; examples
at the very least. I don't think its too much to ask. I don't agree
with the mentality you ascribe to: just add [x] to the document. It is
careless. It is harmful. And, I think it is arrogant.

In fact, browser vendors do implement stuff in working Drafts. For
example, look at the CSSOM disaster that Anne cooked up. I can find
bugs right now on connect.microsoft.com, regarding that spec and I can
observe changed behavior in IE8b1 that closely matches that spec,
deviating from MSIE 7. We have a Working Draft that got adopted
without ever becoming a Technical Recommendation.

> and browser vendors and authors of books
> in particular know to test things

LOL.

What book authors are you talking about?

> and not rely on specs, and to look at the
> maturity level of documents. I would hasten to add that the mistake they'd
> make based on this (that '0' in HTMLCollection might be false when it is in
> fact true) is an error that would have almost no effect on anyone in
> practice.
>
> While pointing out technical errors in specifications is extremely valuable,
> please do not assume that just because you found it, it must become the most
> important thing in the world for the editor.
>

The inference here is that I found something, then, I decided that it
would become the most important thing in the world of the editor.

The only way you could make such inferences is if you read my mind,
right? So, let's have an example of that. Why don't you tell me what
I'm thinking right now, Maciej?


>> # No Indexed Property
>
> [[IndexGetter]] is a spec fiction,

I think I agree with that, it exists in the spec; it is fiction.

> as is the notion of whether something
> "has" a property. What is observable is the effects of getting the property,
> hasOwnProperty, in, and attempts to delete or put the property. If you
> describe things in those terms it will be easier to know what you mean.
>

If you ask a specific question using that terminology, I'll try and
answer it. If I don't have an answer, I'll say "I don't know".

Or post up some examples. That would be great.

>>
>> For example:
>>
>> 
>> 
>> alert('id' in document.body.attributes)
>> 
>> 
>>
>> alerts "false" in FF3 and Saf2 (but 'true' in Saf3).
>
> It probably doesn't matter which behavior is chosen on this, since it is
> such an unlikey thing to do, but better to choose one. And better for such
> things to be consistent if possible.
>

An example would show that IE doesn't support getters.

Creating a bug for IE where a good cross-browser solution exists would
seem unethical.

The indexed items could be specified to be a property, which is more
consistent in implementations.

It could be left to an implementation detail.


>>
>>> I think Web IDL should provide a formalism to cater to this, because
>>> nearly
>>> all bindings with special dynamic properties work like this afaik. But I
>>> think it would have to involve a pseudo-method for the "hasOwnProperty"
>>> check (which "in" is based on).
>>>
>>
>> WRONG.
>>
>> The 'in' operator is based on the [[HasProperty]], not "hasOwnProperty"
>
> First of all, [[HasProperty]] is often implemented in terms of
> hasOwnProperty, since it cannot return true unless hasOwnProperty does for
> some element of the prototype chain. Second, how could this distinction
></pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10721.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080806&amp;o=newest&amp;f=1">2008-08-06</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Maciej+Stachowiak%22&amp;o=newest&amp;f=1">Maciej Stachowiak</a></span>
</div>
<blockquote><span class="msgFragment"><pre>


On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:


On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:


I think Garret has a valid point (despite his needlessly rude tone)  
that the
way we describe magical dynamic properties in a way that makes  
clear they

are also visible to the "in" operator and to
Object.prototype.hasOwnProperty. Are there any DOM bindings that  
have index

(or named) properties which are *not* visible in such a way?


You mean "ECMAScript binding implementation", right?

Using reflection on a C# class won't give you a property named "0" or
"myform", even though you can get them using myvariable[0] and
myvariable["myform"].
If I were to implement a binding in Python, I would do the same
(though « 0 in myvariable » and « "myform" in myvariable » would work
the same as in ECMAScript today; but dir(myvariable) wouldn't show "0"
or "myform")

If not, then the current [IndexGetter] definition is useless and we  
need

a better formalism.


...or rather the ECMAScript binding should define this particularity.

I think Web IDL should provide a formalism to cater to this,  
because nearly
all bindings with special dynamic properties work like this afaik.  
But I
think it would have to involve a pseudo-method for the  
"hasOwnProperty"

check (which "in" is based on).


hasOwnProperty is ECMAScript-specific.


The Web IDL includes specific requirements for how to map an interface  
specified in Web IDL to ECMAScript. So, indeed, that would be the part  
of the Web IDL spec that would be the best place to define this.


Regards,
Maciej


</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10720.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080806&amp;o=newest&amp;f=1">2008-08-06</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Maciej+Stachowiak%22&amp;o=newest&amp;f=1">Maciej Stachowiak</a></span>
</div>
<blockquote><span class="msgFragment"><pre>


On Aug 6, 2008, at 11:23 AM, Garrett Smith wrote:



My apologies for being rude.

What would you suggest, Maciej?


I would suggest:

a) Point out mistakes courteously.
b) Preferably do so in the appropriate public forum where others can  
see them (I don't see any mail from you on this topic in public- 
webapps).
c) Assume good faith on the part of the editor, even if you do not  
receive an immediate reply.



If Cameron McCormick ignores constructive criticism for three weeks,
what's to say he'll won't ignore it another three weeks and then
forget about it altogether?


Because he has a track record of responding to feedback


I tried to elicit a response by providing test cases and through
constructive criticism.

The longer that document stays up there in its current form, the
greater the chance that someone will come along and write a book or
blog about this and teach those who are less knowledgeable, and pretty
soon, it starts appearing as a 'bug' on webbugtrack and filed as a bug
against IE. It has happened before. I can see on the JScript blog
right now, a bug that is not a bug, filed against IE, and comments
from the JScript team about how they will "fix" it.


This lacks all sense of proportion. No one expects a W3C Working Draft  
to be technically correct in all details, and browser vendors and  
authors of books in particular know to test things and not rely on  
specs, and to look at the maturity level of documents. I would hasten  
to add that the mistake they'd make based on this (that '0' in  
HTMLCollection might be false when it is in fact true) is an error  
that would have almost no effect on anyone in practice.


While pointing out technical errors in specifications is extremely  
valuable, please do not assume that just because you found it, it must  
become the most important thing in the world for the editor.



(my name is Garrett BTW)


My apologies for the typo.





that the
way we describe magical dynamic properties in a way that makes  
clear they

are also visible to the "in" operator and to
Object.prototype.hasOwnProperty. Are there any DOM bindings that  
have index
(or named) properties which are *not* visible in such a way? If  
not, then

the current [IndexGetter] definition is useless and we need a better
formalism.


Did you miss the demo that I posted yesterday? The one Cameron
mentioned in his comment, (that you're replying to)? It shows that
implementations will provide access to items/elements that are not
properties on Form.







Also, for NamedNodeMap, it seems that IE and Opera add attributes as
properties to the object,




I think that Web IDL can't provide as much syntactic help for HTML
collections where the properties are real.  So HTML will probably  
have

to include a sentence such as:


I also don't understand what is meant to by calling some properties  
"real".
I don't think this is a meaningful distinction. The core of the  
point that
Garret raised (as far as I can tell) is that the properties are  
visible to
has/in checks as well as gettable, and I think this is true in all  
cases of

DOM objects with dynamic index/named properties.



That is not true. I posted results and explained in discussion of my
last example that in Firefox3, FORM has:

# [[IndexGetter]]
# No Indexed Property


[[IndexGetter]] is a spec fiction, as is the notion of whether  
something "has" a property. What is observable is the effects of  
getting the property, hasOwnProperty, in, and attempts to delete or  
put the property. If you describe things in those terms it will be  
easier to know what you mean.


It may be that we need two different ways to spec dynamically  
available properties if the difference matters for compatibility.



Additionally, the NamedNodeMap in FF3 and Safari3 will provide access
to properties that would have otherwise have to be got via
'getNamedItem()'

For example:



alert('id' in document.body.attributes)



alerts "false" in FF3 and Saf2 (but 'true' in Saf3).


It probably doesn't matter which behavior is chosen on this, since it  
is such an unlikey thing to do, but better to choose one. And better  
for such things to be consistent if possible.




In the ECMAScript language binding, for every node in the collection
there must exist a property on the collection object whose name is
the index of the node in the collection, and whose value is the  
node.




Sounds fine to me, but I would probably have chosen SHOULD over MUST.

With some wording about whether these extra properties take  
precedence

over other properties on the object due to the interface, etc.  Ian?




I disagree with that.

Testcases to determine what implementations do and what are the worst
problems to avoid would be the most useful at this point. For example,
a HTMLFORMElement with the name "length", and attribute "length" on
the form.


 


Please do make up some test cases. You can post these to the list.
Talk to Ian about where to upload them for referenc</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10711.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080806&amp;o=newest&amp;f=1">2008-08-06</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Wed, Aug 6, 2008 at 2:29 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Aug 6, 2008, at 12:27 AM, Cameron McCormack wrote:
>
>> Hi Garrett.
>>
>> Garrett Smith:
>>>

[snip]

>> Your tests do show that the HTML collections expose items through real
>> properties rather than "fake" ones returned through a custom [[Get]].
>> So yes that means that HTML 5 won't be able to use [IndexGetter] etc. to
>> accurately describe current browser behaviour.  That doesn't necessarily
>> mean that [IndexGetter] etc. will have to be changed, just that for the
>> purpose of documenting HTML collections they're insufficient.
>
> I think Garret has a valid point (despite his needlessly rude tone)

My apologies for being rude.

What would you suggest, Maciej?

If Cameron McCormick ignores constructive criticism for three weeks,
what's to say he'll won't ignore it another three weeks and then
forget about it altogether?

I tried to elicit a response by providing test cases and through
constructive criticism.

The longer that document stays up there in its current form, the
greater the chance that someone will come along and write a book or
blog about this and teach those who are less knowledgeable, and pretty
soon, it starts appearing as a 'bug' on webbugtrack and filed as a bug
against IE. It has happened before. I can see on the JScript blog
right now, a bug that is not a bug, filed against IE, and comments
from the JScript team about how they will "fix" it.

(my name is Garrett BTW)

> that the
> way we describe magical dynamic properties in a way that makes clear they
> are also visible to the "in" operator and to
> Object.prototype.hasOwnProperty. Are there any DOM bindings that have index
> (or named) properties which are *not* visible in such a way? If not, then
> the current [IndexGetter] definition is useless and we need a better
> formalism.

Did you miss the demo that I posted yesterday? The one Cameron
mentioned in his comment, (that you're replying to)? It shows that
implementations will provide access to items/elements that are not
properties on Form.

Also, for NamedNodeMap, it seems that IE and Opera add attributes as
properties to the object,

>
>> I think that Web IDL can't provide as much syntactic help for HTML
>> collections where the properties are real.  So HTML will probably have
>> to include a sentence such as:
>
> I also don't understand what is meant to by calling some properties "real".
> I don't think this is a meaningful distinction. The core of the point that
> Garret raised (as far as I can tell) is that the properties are visible to
> has/in checks as well as gettable, and I think this is true in all cases of
> DOM objects with dynamic index/named properties.
>

That is not true. I posted results and explained in discussion of my
last example that in Firefox3, FORM has:

# [[IndexGetter]]
# No Indexed Property

Additionally, the NamedNodeMap in FF3 and Safari3 will provide access
to properties that would have otherwise have to be got via
'getNamedItem()'

For example:



alert('id' in document.body.attributes)



alerts "false" in FF3 and Saf2 (but 'true' in Saf3).

>>  In the ECMAScript language binding, for every node in the collection
>>  there must exist a property on the collection object whose name is
>>  the index of the node in the collection, and whose value is the node.
>>

Sounds fine to me, but I would probably have chosen SHOULD over MUST.

>> With some wording about whether these extra properties take precedence
>> over other properties on the object due to the interface, etc.  Ian?
>

I disagree with that.

Testcases to determine what implementations do and what are the worst
problems to avoid would be the most useful at this point. For example,
a HTMLFORMElement with the name "length", and attribute "length" on
the form.


  


Please do make up some test cases. You can post these to the list.
Talk to Ian about where to upload them for reference.

There is a testcase on connect.microsoft.com. I don't have time to
look it up now, (site is kind of hard to use and slow) but was filed
by "PPKPPK" about the "attributes array" (deja vu).

> I think Web IDL should provide a formalism to cater to this, because nearly
> all bindings with special dynamic properties work like this afaik. But I
> think it would have to involve a pseudo-method for the "hasOwnProperty"
> check (which "in" is based on).
>

WRONG.

The 'in' operator is based on the [[HasProperty]], not "hasOwnProperty"


Garrett

>
> Regards,
> Maciej
>
>

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10710.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080806&amp;o=newest&amp;f=1">2008-08-06</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Thomas+Broyer%22&amp;o=newest&amp;f=1">Thomas Broyer</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
>
> I think Garret has a valid point (despite his needlessly rude tone) that the
> way we describe magical dynamic properties in a way that makes clear they
> are also visible to the "in" operator and to
> Object.prototype.hasOwnProperty. Are there any DOM bindings that have index
> (or named) properties which are *not* visible in such a way?

You mean "ECMAScript binding implementation", right?

Using reflection on a C# class won't give you a property named "0" or
"myform", even though you can get them using myvariable[0] and
myvariable["myform"].
If I were to implement a binding in Python, I would do the same
(though « 0 in myvariable » and « "myform" in myvariable » would work
the same as in ECMAScript today; but dir(myvariable) wouldn't show "0"
or "myform")

> If not, then the current [IndexGetter] definition is useless and we need
> a better formalism.

...or rather the ECMAScript binding should define this particularity.

> I think Web IDL should provide a formalism to cater to this, because nearly
> all bindings with special dynamic properties work like this afaik. But I
> think it would have to involve a pseudo-method for the "hasOwnProperty"
> check (which "in" is based on).

hasOwnProperty is ECMAScript-specific.

-- 
Thomas Broyer

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10708.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080806&amp;o=newest&amp;f=1">2008-08-06</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Maciej+Stachowiak%22&amp;o=newest&amp;f=1">Maciej Stachowiak</a></span>
</div>
<blockquote><span class="msgFragment"><pre>


On Aug 6, 2008, at 12:27 AM, Cameron McCormack wrote:


Hi Garrett.

Garrett Smith:

In EcmaScript, the property access operators seem to look like a
"getter" to Cameron. What they really do is provide access to
properties added to the collection, or, in one case (on one
implementation), this seems implemented as a "getter". A "getter"  
is a

method that gets the value of a property of that name.


I’m sorry I haven’t had a chance to reply yet, I’ve been quite busy  
with

other things and haven’t had a chance to work on Web IDL for the last
few weeks.  (Actually I had a half written reply to your earlier mail
drafted, but I hadn’t got to finishing it yet.)

Your tests do show that the HTML collections expose items through real
properties rather than “fake” ones returned through a custom [[Get]].
So yes that means that HTML 5 won’t be able to use [IndexGetter]  
etc. to
accurately describe current browser behaviour.  That doesn’t  
necessarily
mean that [IndexGetter] etc. will have to be changed, just that for  
the

purpose of documenting HTML collections they’re insufficient.


I think Garret has a valid point (despite his needlessly rude tone)  
that the way we describe magical dynamic properties in a way that  
makes clear they are also visible to the "in" operator and to  
Object.prototype.hasOwnProperty. Are there any DOM bindings that have  
index (or named) properties which are *not* visible in such a way? If  
not, then the current [IndexGetter] definition is useless and we need  
a better formalism.



I think that Web IDL can’t provide as much syntactic help for HTML
collections where the properties are real.  So HTML will probably have
to include a sentence such as:


I also don't understand what is meant to by calling some properties  
"real". I don't think this is a meaningful distinction. The core of  
the point that Garret raised (as far as I can tell) is that the  
properties are visible to has/in checks as well as gettable, and I  
think this is true in all cases of DOM objects with dynamic index/ 
named properties.



 In the ECMAScript language binding, for every node in the collection
 there must exist a property on the collection object whose name is
 the index of the node in the collection, and whose value is the node.

With some wording about whether these extra properties take precedence
over other properties on the object due to the interface, etc.  Ian?


I think Web IDL should provide a formalism to cater to this, because  
nearly all bindings with special dynamic properties work like this  
afaik. But I think it would have to involve a pseudo-method for the  
"hasOwnProperty" check (which "in" is based on).



Regards,
Maciej


</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10706.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080806&amp;o=newest&amp;f=1">2008-08-06</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Cameron+McCormack%22&amp;o=newest&amp;f=1">Cameron McCormack</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
Hi Garrett.

Garrett Smith:
> In EcmaScript, the property access operators seem to look like a
> "getter" to Cameron. What they really do is provide access to
> properties added to the collection, or, in one case (on one
> implementation), this seems implemented as a "getter". A "getter" is a
> method that gets the value of a property of that name.

I’m sorry I haven’t had a chance to reply yet, I’ve been quite busy with
other things and haven’t had a chance to work on Web IDL for the last
few weeks.  (Actually I had a half written reply to your earlier mail
drafted, but I hadn’t got to finishing it yet.)

Your tests do show that the HTML collections expose items through real
properties rather than “fake” ones returned through a custom [[Get]].
So yes that means that HTML 5 won’t be able to use [IndexGetter] etc. to
accurately describe current browser behaviour.  That doesn’t necessarily
mean that [IndexGetter] etc. will have to be changed, just that for the
purpose of documenting HTML collections they’re insufficient.

I think that Web IDL can’t provide as much syntactic help for HTML
collections where the properties are real.  So HTML will probably have
to include a sentence such as:

  In the ECMAScript language binding, for every node in the collection
  there must exist a property on the collection object whose name is
  the index of the node in the collection, and whose value is the node.

With some wording about whether these extra properties take precedence
over other properties on the object due to the interface, etc.  Ian?

> Cameron McCormick is learning JavaScript and in the process, trying to
> write a specification. That is dangerous. What is worse is that he is
> displaying complete arrogance by refusing to discuss his obvious
> mistakes based on what he and Simon imagine browsers are doing and
> what they want browsers to do. That, I pointed out, and in a fairly
> cordial manner here:
> http://lists.w3.org/Archives/Public/public-html/2008Jul/0169.html

I wouldn’t say that I know every detail of ECMA-262 off by heart, so in
that regard I’d agree that I’m learning.

And please don’t take my non-reply as arrogance.  Other things in my
life have just taken precedence the last few weeks. :-)

> But unfortunately Cameron decided to make neither change nor
> acknowledgment of this mistake of his (I will probably not have time
> or energy to get around to discussing his other mistakes, which are
> probably more serious and potentially harmful).

I have certainly tried to write Web IDL with the aim of it being useful
for other specs (like HTML 5) to document actual behaviour, where that’s
interoperable, and to that end I do test implementations.  Now in this
particular instance, I didn’t test whether the properties were real ones
or not, so thanks for that test that shows they are.

> That part of the specification was based on either misunderstanding,
> poor observation, or imagination. It has been documented vaguely,
> making references to EcmaScript [[Get]], but is apparently supposed to
> be used in other languages. Since the item() method is always
> available, it is really unnecessary and can only serve to create real
> problems by requiring the changing of Stable code.

ECMAScript 3rd ed and Java are the only language bindings included in
Web IDL, but I try to make the extended attributes generic enough to be
useful for other languages.

> Here is Cameron demonstrates his failed attempt to understand what the
> browser is doing:
> 
> http://www.w3.org/TR/DOM-Bindings/#IndexGetter
> | If the [IndexGetter]  extended attribute appears on an
> | operation with a single unsigned long argument, it indicates
> | that an object that implements the interface  can be indexed
> | with an unsigned long,
> 
> Apparently it would mean something like:
> 
> // "operation"
> childNodes[ 0 ];
> 
> I clearly nicely pointed out Cameron's misunderstanding to him, on
> this list;
>
> With the methods item() and namedItem() and getNamedItem(), the
> bindings in EcmaScript can provide property access to the property.
> There is no [[IndexGetter]].

As [IndexGetter] is written at the moment, no, but as you’ve shown,
the numeric properties do exist.  And, assuming the wording is fixed up
to say that those real properties do exist on the object, is there still
a problem with using that in an example?

> >  (i.e. '0'
> > in document.forms would be False, and document.forms["0"] wouldn't be
> > equivalent to document.forms[0])
> >
> 
> Why do you say this?
> 
> In EcmaScript, document.forms[0] is equivalent to document.forms['0'].
> I'm not sure what you're thinking.
> 
> Property access calls ToString on the property name. What would be
> "shared" with Python and Ruby?

I think Simon’s saying that something similar, i.e. indexing an object,
could be implemented in Python and Ruby.  I’m not really a Python or
Ruby programmer, but I have seen some documentation on how Python can do
that sort of thing:

  http://docs.pytho</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10705.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080805&amp;o=newest&amp;f=1">2008-08-05</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Tue, Aug 5, 2008 at 4:02 PM, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
>> On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
>>>
>>> Actually, there is:
>>> http://www.w3.org/TR/html5/dom.html#htmlcollection
>>> and I believe the "elements" property of HTMLFormElement is actually
>>> an HTMLFormControlsCollection:
>>> http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
>>>
>>
>> First off, the IndexGetter behavior on the HTMLCollection[1] is the
>> authors imagination.
>
> Aren't "document.forms[0]" and "document.forms.myform" working?
>

Can you be more specific and direct in your reply? It isn't clear what
your point is.

>> The following example shows that indexed Properties exist on
>> NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
>> There is no [[ IndexGetter ]] as Cameron likes to make pretend.
>
> This is an "implementation detail" of the ECMAScript binding.
>

In EcmaScript, the property access operators seem to look like a
"getter" to Cameron. What they really do is provide access to
properties added to the collection, or, in one case (on one
implementation), this seems implemented as a "getter". A "getter" is a
method that gets the value of a property of that name.

Cameron McCormick is learning JavaScript and in the process, trying to
write a specification. That is dangerous. What is worse is that he is
displaying complete arrogance by refusing to discuss his obvious
mistakes based on what he and Simon imagine browsers are doing and
what they want browsers to do. That, I pointed out, and in a fairly
cordial manner here:
http://lists.w3.org/Archives/Public/public-html/2008Jul/0169.html

But unfortunately Cameron decided to make neither change nor
acknowledgment of this mistake of his (I will probably not have time
or energy to get around to discussing his other mistakes, which are
probably more serious and potentially harmful).

> In C#, these would obviously be mapped to indexers ("public
> HTMLElement this[int index] { get { ... } }" and "public object
> this[String name] { get { ... } }"), and there is no equivalent in
> Java.

What you are calling obvious is not clear to me.

What is clear is that there is a new specification that includes
something about indexed properties on collection objects. My example
made clear that that there is no "getter" for properties, except for
Form in Mozilla, and that is deprecated behavior from Netscape. A much
better alternative exists in browsers today. That behavior is the
properties added to a collection (ES bindings in browsers).

That part of the specification was based on either misunderstanding,
poor observation, or imagination. It has been documented vaguely,
making references to EcmaScript [[Get]], but is apparently supposed to
be used in other languages. Since the item() method is always
available, it is really unnecessary and can only serve to create real
problems by requiring the changing of Stable code.

Here is Cameron demonstrates his failed attempt to understand what the
browser is doing:

http://www.w3.org/TR/DOM-Bindings/#IndexGetter
| If the [IndexGetter]  extended attribute appears on an
| operation with a single unsigned long argument, it indicates
| that an object that implements the interface  can be indexed
| with an unsigned long,

Apparently it would mean something like:

// "operation"
childNodes[ 0 ];

I clearly nicely pointed out Cameron's misunderstanding to him, on this list;

With the methods item() and namedItem() and getNamedItem(), the
bindings in EcmaScript can provide property access to the property.
There is no [[IndexGetter]].

> I guess that in Python and Ruby, which share their "dynamic" nature
> with ECMAScript, these wouldn't be true properties as well

As well? As well as what? And what sort of 'guess'? This sounds like
the type of vague guessing that went into Cameron's wrote up.

>  (i.e. '0'
> in document.forms would be False, and document.forms["0"] wouldn't be
> equivalent to document.forms[0])
>

Why do you say this?

In EcmaScript, document.forms[0] is equivalent to document.forms['0'].
I'm not sure what you're thinking.

Property access calls ToString on the property name. What would be
"shared" with Python and Ruby?

This thread took a turn from the problems in WF 2.0, and the official
documentation of the misconceptions that are so common in a good
number of web devs. I'd like to get back to that next.


>
> --
> Thomas Broyer
>

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10702.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080805&amp;o=newest&amp;f=1">2008-08-05</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Thomas+Broyer%22&amp;o=newest&amp;f=1">Thomas Broyer</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
> On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
>>
>> Actually, there is:
>> http://www.w3.org/TR/html5/dom.html#htmlcollection
>> and I believe the "elements" property of HTMLFormElement is actually
>> an HTMLFormControlsCollection:
>> http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
>>
>
> First off, the IndexGetter behavior on the HTMLCollection[1] is the
> authors imagination.

Aren't "document.forms[0]" and "document.forms.myform" working?

> The following example shows that indexed Properties exist on
> NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
> There is no [[ IndexGetter ]] as Cameron likes to make pretend.

This is an "implementation detail" of the ECMAScript binding.

In C#, these would obviously be mapped to indexers ("public
HTMLElement this[int index] { get { ... } }" and "public object
this[String name] { get { ... } }"), and there is no equivalent in
Java.
I guess that in Python and Ruby, which share their "dynamic" nature
with ECMAScript, these wouldn't be true properties as well (i.e. '0'
in document.forms would be False, and document.forms["0"] wouldn't be
equivalent to document.forms[0])


-- 
Thomas Broyer

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10684.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080804&amp;o=newest&amp;f=1">2008-08-04</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 30, 2008 at 8:33 AM, Garrett Smith wrote:
>>
>> (3) There is no specification for a special [[Get]] for the "elements"
>> HTMLCollection as a shortcut to "namedItem", either (though this would not
>> seem to be a problem,
>
> Actually, there is:
> http://www.w3.org/TR/html5/dom.html#htmlcollection
> and I believe the "elements" property of HTMLFormElement is actually
> an HTMLFormControlsCollection:
> http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
>

First off, the IndexGetter behavior on the HTMLCollection[1] is the
authors imagination. It is a shame to see such misinformation has made
it so far.

The following example shows that indexed Properties exist on
NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
There is no [[ IndexGetter ]] as Cameron likes to make pretend.

==



Additional Properties on NamedNodeMap, HTMLCollection, NodeList
mailto:[EMAIL PROTECTED]"/>








var s = document.getElementById('s');
document.write([
  "NamedNodeMap: '0'in document.body.attributes : "
  + ('0'in document.body.attributes),
  "HTMLCollection '0'in document.body.childNodes : "
  + ('0'in document.body.childNodes),
  "HTMLOptionsCollection '0'in s.options : "
  + ('0'in s.options),
  "NodeList: '0'in document.getElementsByTagName('*') : "
  + ('0'in document.getElementsByTagName('*')),
  "'id'in document.body.attributes : "
  + ('id'in document.body.attributes)
].join('\n'));




This test is informative. It is not pass/fail. There is no public standard.



==

Even if the author wrote 0 tests, simple observations should show him
just how wrong he is. I wrote about this twice on public-webapi list,
addressing Cameron McCormick with direct questions. Both messages died
with 0 replies. The second one I wrote to the public-webapi list:-

| It can be demonstrated that all of: NamedNodeMap, NodeList, and
| HTMLCollection are implemented in the top 4 browsers with extra
| numeric properties being added.

| 
http://html5.googlecode.com/svn/trunk/incoming/garrett-smith/noIndexGetter.html

| StyleSheetList, and CSSRuleList also have this behavior. I can't
| find an object that implements indexed properties the way you
| have documented them.

| Although the HTML DOM spec defines a 'length' property for
| NamedNodeMap, yet provides no way to access items by index. This
| seems to be a strange design decision, though not the most harmful.
| Ideally, such decisions would be tested out before writing a lengthy
| document. Firefox, Opera, Safari, and IE all allow access by ordinal
| index, via property access, but not by the way you have described in
| your document.

My example demonstrates that there is no [[ IndexGetter ]] on
NamedNodeMap, et c. Ignoring valid criticism serves no useful purpose.
This was documented in IDL, of all the places.

>> and all implementations have supported this behavior for quite a long time).
>
> Note that all implementations also supports the same behavior on
> HTMLFormElement and HTMLDocument.
>

That is not true about document. There no indexed properties, no [[
IndexGetter ]], and no [[ NameGetter ]] and no named property. There
may be either a specialized [[ IndexGetter ]] or an indexed property
on a Form Element, and the [[ IndexedGetter ]] exists only in Firefox,
on the HTMLFormElement. I cannot understand decision to specify [[
IndexGetter ]] as "standard" for all objects with indexed properties
when it has been demonstrated to exist only on HTMLFormElement and
only in one browser:

Firefox.

==



  Document
  
li {
  display: none;
}
  



Document Has

  Named Property
  No Named Property
   [[ NameGetter ]]
  Indexed Property
  [[IndexGetter]]
  No Indexed Property


Form Has

  Named Property
  No Named Property
  [[ NameGetter ]]
  Indexed Property
  [[IndexGetter]]
  No Indexed Property



 



var ids = [];
if('test' in document) ids.push('nameProperty');
else {
 ids.push('noNameProperty');
 if(document.test) ids.push("nameGetter");
}
if('0'in document) ids.push('indexProperty');
else {
  ids.push('noIndexProperty');
  if(document[0]) ids.push('indexGetter');
}

var f = document.forms[0];
if('t'in f) ids.push('fnameProperty');
else {
 ids.push('fnoNameProperty');
 if(f.t) ids.push("fnameGetter");
}if('0'in f) ids.push('findexProperty');
else {
 ids.push('fnoIndexProperty');
 if(f[0]) ids.push('findexGetter');
}

try{
for(var i = 0; i < ids.length; i++)
 document.getElementById(ids[i]).style.display = "block";
 } catch(x) { alert(ids[i]); }



==
Safari3, Opera9, IE8

Document Has
  No Named Property
  No Indexed Property
Form Has
  Named Property
  Indexed Property

Firefox3:
Document Has
* No Named Property
* No Indexed Property</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10672.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080804&amp;o=newest&amp;f=1">2008-08-04</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Thomas+Broyer%22&amp;o=newest&amp;f=1">Thomas Broyer</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Wed, Jul 30, 2008 at 8:33 AM, Garrett Smith wrote:
>
> (3) There is no specification for a special [[Get]] for the "elements"
> HTMLCollection as a shortcut to "namedItem", either (though this would not
> seem to be a problem,

Actually, there is:
http://www.w3.org/TR/html5/dom.html#htmlcollection
and I believe the "elements" property of HTMLFormElement is actually
an HTMLFormControlsCollection:
http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection

> and all implementations have supported this behavior for quite a long time).

Note that all implementations also supports the same behavior on
HTMLFormElement and HTMLDocument.

Otherwise, FWIW, I'm OK with what you're saying about the use of
with(...){...} (useless and generally considered bad practice) and
calling a collection "array".

-- 
Thomas Broyer

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10666.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080804&amp;o=newest&amp;f=1">2008-08-04</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
I'm a little surprised at the lack of response here, so I'm replying
to myself here, just to keep this issue active.

I did a little more research and found that the misconception is more
common that I thought: DOM objects that have indexed properties are
often mistaken for arrays. This is the "misconception" that I found
documented in HTML5.

The following documents discuss DOM Collections using the term "Array":
 http://www.quirksmode.org/dom/w3c_core.html#t60
 http://www.quirksmode.org/dom/tests/attributesArray.html
 http://www.quirksmode.org/dom/tests/stylesheets.html
 http://ajaxian.com/archives/preloading-images-with-jquery#javascript-1
 http://jennifermadden.com/javascript/arraySimple.html
 http://httpunit.sourceforge.net/doc/javascript-support.html

Ian had politely asked me to post this information to the list.

Calling an HTMLCollection an array will mislead developers who don't
know the difference. It might also lead a reader to believe that the
author of the HTML specification deliberately used the word 'array'
and that "elements" is an array (not an HTMLCollection).

It seems that the only benefit in calling an HTMLCollection an array
is that 'array' is shorter to type.

Typing "HTMLCollection" is longer than typing "array" but it is misleading.

But that still leaves the other two issues. The first is the worst, I
think, because it relies on deprecated behavior and isn't very good
practice.

Garrett

On Tue, Jul 29, 2008 at 11:33 PM, Garrett Smith <[EMAIL PROTECTED]> wrote:
> I took a brief look at the WF 2.0 document yesterday and found some
> serious misconceptions and examples of "programming by coincidence."
> These reflect very poorly on html5.
>
> The errors can be found on the link:
> http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
>
> Doc Bugs:
> 1) Treating a a form element as an HTMLCollection.
> 2) The use of - with - to augment the scope chain is not necessary.
> 3) Calling the "elements" HTMLCollection an "array"
>
> (1) The definition of HTMLFormElement does not have a specialized [[Get]]
> for element names (nor should there be, as this is known to be
> problematic). The example in the documetation depends on such behavior.
>
> (2) - with - augments the scope chain with the object. This is completely
> unnecessary here and will create problems if, for example, there is an
> element named "watch". It is a bad practice and I see this influence in the
> popular libraries.
>
> (3) There is no specification for a special [[Get]] for the "elements"
> HTMLCollection as a shortcut to "namedItem", either (though this would not
> seem to be a problem, and all implementations have supported this behavior
> for quite a long time). I did notice that the elements collection is
> mistakenly called an 'array'. This is a serious documentation mistake of
> the worst kind: The spreading of misinformation. It will continue influence
> the muddy knowledge that is so common among most developers who tend want
> to call "push" et c directly on that NodeList object (see the
> "dojo.NodeList" for details). The elements Collection should be called an
> HTMLCollection and this should be changed immediately.
>
> // WRONG
> document.forms[0].qty,
>
> The "elements" property is what the example should use:-
>
> // RIGHT.
> document.forms[0].elements.namedItem('qty');
> document.forms[0].elements.qty; // Access via custom get
>
> This avoids ambiguity when having a form that has an element named "name",
> for example. It becomes ambiguous as to whether the "form.name" refers to
> the element or the form's "name" attribute. Problems could also arise with
> "action", "length", "toString", "elements".
>
> -
> // (GS) Don't augment scope chain here.
> with (document.forms[0]) {
>
> // (GS) Don't treat a form as a collection.
> // Use the 'elements' colletion.
>  if (qty.validity.valueMissing) {
>// the quantity control is required but not filled in
>  } else if (qty.validity.typeMismatch) {
>// the quantity control is filled in, but it is not a number
>  }
> }
>
> And further down:-
>
> // (GS) Don't treat a form as a collection.
> // Use the 'elements' colletion.
> var myControl = document.forms[0].addr;
>
> if (myControl.value == '[EMAIL PROTECTED]') {
>  myControl.setCustomValidity('You must enter your real address.');
> }
> -
> Fixed:
>
> var f = document.forms[0],
>qv = f.elements.namedItem('qty').validity;
>
>  if (qv.valueMissing) {
>// Value required but not filled in.
>  } else if (qv.typeMismatch) {
>// Value filled in, but it is not a number.
>  }
> }
>
> var addErrInvalidMsg = 'You must enter your real address.';
> var addr = document.forms[0].elements.namedItem('addr');
> if (addr.value === '[EMAIL PROTECTED]') {
>  addr.setCustomValidity(addErrInvalidMsg);
> }
>

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10601.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080730&amp;o=newest&amp;f=1">2008-07-30</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Garrett+Smith%22&amp;o=newest&amp;f=1">Garrett Smith</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
On Wed, Jul 30, 2008 at 1:00 AM, Kristof Zelechovski
<[EMAIL PROTECTED]> wrote:
> Form attribute names should take precedence over form control names.  There
> is no ambiguity.
> Both mechanisms belong to Netscape DOM and are deprecated.
> Form property names should take precedence over both.  I do not see much
> value in removing support for legacy code altogether; it looks a bit
> totalitarian to me.

 "Removing support"? Did you try to say that I was asking for an
implementation change, and that you thought that such change was
"totalitarian". Your reaction to whatever I wrote seems quite a bit
off.

> I agree,

With what?

> however, that examples provided should use
> modern wording, whatever that means.

Apparently, even you don't know what you mean.

The examples in any standards doc should not use Implementation
Specific Extensions, even if such code appears to work in 4 browsers.

Garrett

> Chris
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
> Sent: Wednesday, July 30, 2008 8:34 AM
> To: [EMAIL PROTECTED]
> Subject: [whatwg] HTML 5 : Misconceptions Documented
>
> I took a brief look at the WF 2.0 document yesterday and found some
> serious misconceptions and examples of "programming by coincidence."
> These reflect very poorly on html5.
>
> The errors can be found on the link:
> http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
>
> Doc Bugs:
> 1) Treating a a form element as an HTMLCollection.
> 2) The use of - with - to augment the scope chain is not necessary.
> 3) Calling the "elements" HTMLCollection an "array"
>
> (1) The definition of HTMLFormElement does not have a specialized [[Get]]
> for element names (nor should there be, as this is known to be
> problematic). The example in the documetation depends on such behavior.
>
> (2) - with - augments the scope chain with the object. This is completely
> unnecessary here and will create problems if, for example, there is an
> element named "watch". It is a bad practice and I see this influence in the
> popular libraries.
>
> (3) There is no specification for a special [[Get]] for the "elements"
> HTMLCollection as a shortcut to "namedItem", either (though this would not
> seem to be a problem, and all implementations have supported this behavior
> for quite a long time). I did notice that the elements collection is
> mistakenly called an 'array'. This is a serious documentation mistake of
> the worst kind: The spreading of misinformation. It will continue influence
> the muddy knowledge that is so common among most developers who tend want
> to call "push" et c directly on that NodeList object (see the
> "dojo.NodeList" for details). The elements Collection should be called an
> HTMLCollection and this should be changed immediately.
>
> // WRONG
> document.forms[0].qty,
>
> The "elements" property is what the example should use:-
>
> // RIGHT.
> document.forms[0].elements.namedItem('qty');
> document.forms[0].elements.qty; // Access via custom get
>
> This avoids ambiguity when having a form that has an element named "name",
> for example. It becomes ambiguous as to whether the "form.name" refers to
> the element or the form's "name" attribute. Problems could also arise with
> "action", "length", "toString", "elements".
>
> -
> // (GS) Don't augment scope chain here.
> with (document.forms[0]) {
>
> // (GS) Don't treat a form as a collection.
> // Use the 'elements' colletion.
>  if (qty.validity.valueMissing) {
>// the quantity control is required but not filled in
>  } else if (qty.validity.typeMismatch) {
>// the quantity control is filled in, but it is not a number
>  }
> }
>
> And further down:-
>
> // (GS) Don't treat a form as a collection.
> // Use the 'elements' colletion.
> var myControl = document.forms[0].addr;
>
> if (myControl.value == '[EMAIL PROTECTED]') {
>  myControl.setCustomValidity('You must enter your real address.');
> }
> -
> Fixed:
>
> var f = document.forms[0],
>qv = f.elements.namedItem('qty').validity;
>
>  if (qv.valueMissing) {
>// Value required but not filled in.
>  } else if (qv.typeMismatch) {
>// Value filled in, but it is not a number.
>  }
> }
>
> var addErrInvalidMsg = 'You must enter your real address.';
> var addr = document.forms[0].elements.namedItem('addr');
> if (addr.value === '[EMAIL PROTECTED]') {
>  addr.setCustomValidity(addErrInvalidMsg);
> }
>
>

</pre></span>
</blockquote><br>

<h3><span class=subject><a href="/whatwg@lists.whatwg.org/msg10583.html">Re: [whatwg] HTML 5 : Misconceptions Documented</a></span></h3>
<div class="darkgray font13">
<span class="sender pipe">
<span class=date><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=date:20080730&amp;o=newest&amp;f=1">2008-07-30</a></span></span>
<span class="sender pipe">
<span class=thead><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject:%22%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest&amp;f=1">Thread</a></span></span>
<span class=name><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=from:%22Kristof+Zelechovski%22&amp;o=newest&amp;f=1">Kristof Zelechovski</a></span>
</div>
<blockquote><span class="msgFragment"><pre>
Form attribute names should take precedence over form control names.  There
is no ambiguity.  Both mechanisms belong to Netscape DOM and are deprecated.
Form property names should take precedence over both.  I do not see much
value in removing support for legacy code altogether; it looks a bit
totalitarian to me.  I agree, however, that examples provided should use
modern wording, whatever that means.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, July 30, 2008 8:34 AM
To: [EMAIL PROTECTED]
Subject: [whatwg] HTML 5 : Misconceptions Documented

I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of "programming by coincidence."
These reflect very poorly on html5.

The errors can be found on the link:
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default

Doc Bugs:
1) Treating a a form element as an HTMLCollection.
2) The use of - with - to augment the scope chain is not necessary.
3) Calling the "elements" HTMLCollection an "array"

(1) The definition of HTMLFormElement does not have a specialized [[Get]]
for element names (nor should there be, as this is known to be
problematic). The example in the documetation depends on such behavior.

(2) - with - augments the scope chain with the object. This is completely
unnecessary here and will create problems if, for example, there is an
element named "watch". It is a bad practice and I see this influence in the
popular libraries.

(3) There is no specification for a special [[Get]] for the "elements"
HTMLCollection as a shortcut to "namedItem", either (though this would not
seem to be a problem, and all implementations have supported this behavior
for quite a long time). I did notice that the elements collection is
mistakenly called an 'array'. This is a serious documentation mistake of
the worst kind: The spreading of misinformation. It will continue influence
the muddy knowledge that is so common among most developers who tend want
to call "push" et c directly on that NodeList object (see the
"dojo.NodeList" for details). The elements Collection should be called an
HTMLCollection and this should be changed immediately.

// WRONG
document.forms[0].qty,

The "elements" property is what the example should use:-

// RIGHT.
document.forms[0].elements.namedItem('qty');
document.forms[0].elements.qty; // Access via custom get

This avoids ambiguity when having a form that has an element named "name",
for example. It becomes ambiguous as to whether the "form.name" refers to
the element or the form's "name" attribute. Problems could also arise with
"action", "length", "toString", "elements".

-
// (GS) Don't augment scope chain here.
with (document.forms[0]) {

// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
  if (qty.validity.valueMissing) {
// the quantity control is required but not filled in
  } else if (qty.validity.typeMismatch) {
// the quantity control is filled in, but it is not a number
  }
}

And further down:-

// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
var myControl = document.forms[0].addr;

if (myControl.value == '[EMAIL PROTECTED]') {
  myControl.setCustomValidity('You must enter your real address.');
}
-
Fixed:

var f = document.forms[0],
qv = f.elements.namedItem('qty').validity;

  if (qv.valueMissing) {
// Value required but not filled in.
  } else if (qv.typeMismatch) {
// Value filled in, but it is not a number.
  }
}

var addErrInvalidMsg = 'You must enter your real address.';
var addr = document.forms[0].elements.namedItem('addr');
if (addr.value === '[EMAIL PROTECTED]') {
  addr.setCustomValidity(addErrInvalidMsg);
}


</pre></span>
</blockquote><br>
    <h2></h2>
  </div>
  <div class="aside" role="complementary">
    <div class="logo">
      <a href="/"><img src="/logo.png" width=247 height=88 alt="The Mail Archive"></a>
    </div>
    <h2>48 matches</h2>
    <br>
    
<ul><li><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject%3A%22Re%5C%3A+%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;a=1&amp;o=newest&amp;f=1">Advanced search</a></li></ul>
<form class="overflow" action="/search" method="get">
<input type="hidden" name="l" value="whatwg@lists.whatwg.org">
<label class="hidden" for="q">Search the list</label>
<input class="submittext" type="text" id="q" name="q" placeholder="Search whatwg" value="subject:&quot;Re\: \[whatwg\] HTML 5 \: Misconceptions Documented&quot;">
<input class="submitbutton" id="submit" type="image" src="/submit.png" alt="Submit">
</form>

    
    <div class="nav margintop" id="nav" role="navigation">
      <h2 class="hidden">
                               Site Navigation
      </h2>
      <ul class="icons font16">
        <li class="icons-home"><a href="/">The Mail Archive home</a></li>
        <li class="icons-list">
          <a href="/whatwg@lists.whatwg.org" title="c" id="c">whatwg - all messages</a></li>
        <li class="icons-about">
          <a href="/whatwg@lists.whatwg.org/info.html">whatwg  - about the list</a></li>
        <li class="icons-expand"><a href="/search?l=whatwg%40lists.whatwg.org&amp;q=subject%3A%22Re%5C%3A+%5C%5Bwhatwg%5C%5D+HTML+5+%5C%3A+Misconceptions+Documented%22&amp;o=newest" title="e" id="e">Expand</a></li>
      </ul>
    </div>

    <div class="listlogo margintopdouble">
      <h2 class="hidden">
  				Mail list logo
      </h2>
      
    </div>
  </div>
  <div class="footer" role="contentinfo">
    <h2 class="hidden">
	        	      Footer information
    </h2>
    <ul>
      <li><a href="/">The Mail Archive home</a></li>
      <li><a href="/faq.html#newlist">Add your mailing list</a></li>
      <li><a href="/faq.html">FAQ</a></li>
      <li><a href="/faq.html#support">Support</a></li>
      <li><a href="/faq.html#privacy">Privacy</a></li>
    </ul>
  </div>
<script language="javascript" type="text/javascript">
document.onkeydown = NavigateThrough;
function NavigateThrough (event)
{
  if (!document.getElementById) return;
  if (window.event) event = window.event;
  if (event.target.tagName == 'INPUT') return;
  if (event.ctrlKey || event.metaKey) return;
  var link = null;
  switch (event.keyCode ? event.keyCode : event.which ? event.which : null) {
    case 69:
      link = document.getElementById ('e');
      break;
    }
  if (link && link.href) document.location = link.href;
}
</script>
</body>
</html>