[whatwg] HTML 5 : Misconceptions Documented

Wed Aug 6 11:23:33 PDT 2008

On Wed, Aug 6, 2008 at 2:29 AM, Maciej Stachowiak <mjs at apple.com> 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:

<body id='test'>
<script>
alert('id' in document.body.attributes)
</script>
</body>

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.

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

Garrett

>
> Regards,
> Maciej
>
>