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
