[whatwg] HTML 5 : Misconceptions Documented

[Maciej Stachowiak]

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:
>
> <body id='test'>
> <script>
> alert('id' in document.body.attributes)
> </script>
> </body>
>
> 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.
>
> <form length="10">
>  <input name="length">
> </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"

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 possibly make a difference in this case? If the property  
is an own property, then there is no operational difference between  
[[HasProperty]] and hasOwnProperty. Thus, your all-caps "WRONG" seems  
a little over the top.

Regards,
Maciej