[Webkit-unassigned] [Bug 14547] typeof document.body.childNodes=="function" ("object" expected)

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=14547





------- Comment #18 from dhtmlkitchen at gmail.com  2007-10-13 22:50 PDT -------
(In reply to comment #17)
> Please, ladies & gentlemen, let's try to remain courteous in these discussions.
> 
Point taken. My post sounded sarcastic. Richard did correctly correct me on
Function.prototype.prototype point, clearing up confusion that I caused. 


> It's probably true that many of the issues noted by the test are not required
> by the relevant specs. However, we may have to implement some of those things
> for compatibility. The best thing to do with this bug report would be to split
> off a separate bug for each individual issue, rather than making this a master
> bug for dozens of DOM binding quirks. For each individual issue, it would be
> great to know:
> 
> 1) Do the relevant specs require this behavior? (Probably the answer is no in
> most cases, since the ECMAScript spec has pretty loose rules for host objects,
> and the DOM specs are not very detailed in specifying how JS bindings should
> work.)
> 
document.images is not a function, it is a NodeList instance.  

> 2) Do the relevant specs forbid this behavior? We're somewhat hesitant to
> outright violate specs, even in cases where there might be some effect on
> compatibility.
> 
ECMA and W3 do not forbid any custom behavior, AFAIK.

> 3) Is the behavior required for compatibility, or just a minor corner case?
> 

Minor case, AFAIK. most uses of nodelist/collection won't try to invoke them
with arguments. Please correct this if it is not right.

> In the case of the original function vs. object thing for NodeLists, it's clear
> that neither the ECMA-262 spec or the DOM spec require typeof to return
> "object". It's also clear that this is not forbidden - the ECMAScript spec
> allows host objects to return anything whatsoever from "typeof". And it's clear
> that returning "object" matters to web compatibility. Therefore we should give
> a typeof result of object. This may require objects to gain an isFunction()
> method in addition to implementsCall(), which can default to calling
> implementsCall() but which is overridable.
> 
I don't think it's a good idea to implement conflicting interfaces.

typeof it == "function" should mean that I can use the call method or any other
methods on Function.prototype. If it's a function, I expect it to be one,
completely.

Function.prototype.constructor is Function.

What is the constructor of such an object?

If typeof it == "function", I expect that. 

How do you resolve document.images.length?
1) function.length
2) collection length

Implementing Function for a Collection/NodeList conflicts with NodeList
interface.
Partially implementing Function makes for a confusing interface. 

It is not desirable to implement Function for document.images. Collection, not
Function.

Can this feature removed? Is it being heavily relied on? 


> I'm not sure what the answer is for the many other issues mentioned in this
> bug. They deserve separate bug reports and someone should do the analogous
> research.
> 


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.