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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Oct 14 10:48:29 PDT 2007


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





------- Comment #20 from Richard at litotes.demon.co.uk  2007-10-14 10:48 PDT -------
> Please, ladies & gentlemen, let's try to remain courteous in these
> discussions.
> 
> 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.

By which you mean compatibility with IE, because, as I have mentioned,
historically many browsers had collections that could be called and would
report 'function' when tested with - typeof -, so the status quo is already
computable with all of those.

A pragmatic acceptance of the real world would tend to indicate that
compatibility with IE has a lot to be said for it.

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

The relevant specs nether require that a 'collection' (taken as shorthand for
NodeList, HTMLCollection, NamedNodeMap etc and anything outside DOM such as
window.frames) be callable, nor do they preclude the possibility (at least in
ECMAScript/javascript contexts (and Java itself is the limiting factor in the
Java context, not the DOM bindings)).

These 'collections' are all host objects so ECMA 262 allows them to report
anything they like from a - typeof - operation. Though historically almost no
host objects have stepped outside of the limited set of - typeof - responses
defined in ECMA 262 (the only notable exceptions being methods of ActiveX
objects which often report 'unknown'). 

> 2) Do the relevant specs forbid this behavior?

Nothing described in this bug report is forbidden by any pertinent
specification.

> We're somewhat
> hesitant to outright violate specs, even in cases where there
> might be some effect on compatibility.

That is not an issue here. All of:-

1. Callable collections that report 'object' with typeof.
2. Non-callable collections that report 'object' with typeof
3. Callable collections that report 'function' with typoeof
4. Non-callable collections that report 'function' with typeof

- are allowed by the pertinent specifications. Though 1 and 4 are of
questionable rationality. 4 would be absolutely stupid, but it is still worth
noting that when the team creating Mac IE looked at what the Windows IE team
had done even they perceived option 1 as wrong and chose option 3 in its place.

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

Microsoft's own documentation is littered with JScript examples which call
collections, to the exclusion of using property accessors for the task.
Virtually anyone coming into browser scripting via IE only scripting and
Microsoft documentation will have been exposed to these bad examples.

The result will be that if you don't allow collections to be called probably
about 50% of the sites that are "best viewed with IE" will be non-functional
with Safari. The situation will be worse with "IE only" intranets and it may
extend to .NET components.

So the question of whether the collections should be callable comes down to; do
you care about that? And the pragmatic answer is probably 'yes'.

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

That last is not clear. If you are aiming for 'like for like' compatibility
with Windows IE then the implications go well beyond the 'collections'. On
Windows IE all of (or at least most of) the DOM methods also report "object"
from - typeof -, as do other callable objects such as - alert -, - setTimeout -
and - attachEvent -. And perversely the - item - method of 'collections'
reports "string" from - typeof -, of all things (at least up to version 6. I
have not checked to see if that insanity was carried through to version 7 yet).
All of that is allowed, but it certainly is not a good idea and should not be
reproduced lightly.

The issue here is not one of compatibility but rather one of expectations. From
the first description: "Javascript's type of an NodeList is "function", where
"object" is expected." But why is that expected when there is no standard that
asserts that anything specific should be expected? Anyone who had any
experience stretching back a couple of versions with Opera, or included
Konqueror or Mac IE would have no such expectation as it would have been
disappointed years ago.

It is an expectation that comes from looking at a couple of recent browsers and
assuming that what they do should be definitive (despite the evidence that even
recent browsers are a long way from being consistent).

The problem with pandering to such uniformed expectations is that while you can
give in to the expectations of the first individual who presents them the next
individual's expectations stand a very good chance of being different, and
sooner or later there will be expectations that are incompatible with earlier
ones.

Indeed the situation here stems from people having uniformed and incompatible
expectations. The W3C DOM specifications gives a solid justification for an
expected outcome from:-

document.images.item(1);

The ECMAScript bindings, by asserting that the bracket notation is to be mapped
to the - item - method, justifies the same expected outcome for:-

document.image[1];

While there is nothing in the world to suggest that:-

document.images(1);

- should do anything but throw an exception, beyond Microsoft's documentation
and the fact that it does not throw an exception in most actual web browsers
but instead produces the same outcome as the previous two.

The only way out of that is to totally give in to creating a like-for-like
imitation of one (and only one) of the browsers that are producing these
expectations, and so in your case reproducing all of the features of IE,
regardless of how perverse and irrational they may be (That would not be
exclusive; there is no reason for not providing things that do not feature in
IE at all in addition, and handling them in any why seen as desirable).

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

Just remember that you will have to generate a list of all of the
object/function properties available in Safari and then test Windows IE to see
precisely what it does return from - typeof - for its equivalents. Otherwise
the problem is not solved, only moved a little more out of sight.


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



More information about the webkit-unassigned mailing list