John Resig has a new idea
beegee
Some sort of "get goobs to test my javascript" thing. I'm not sure I
would ever use such a thing but perhaps others would find it useful.
Anyway, he's already getting slashdotted but mostly over the term
"crowdsourcing" http://tech.slashdot.org/article.pl?sid=09/03/24/2134236&from=rss.
I thought perhaps clj readers might have a different take or at least
explain to me why this is not a vague muddle.
Bob
David Mark
> http://www.infoq.com/news/2009/03/test-swarm
>
> Some sort of "get goobs to test my javascript" thing. I'm not sure I
It is just about testing jQuery.
"In the jQuery project we try to support the current version of all
major browsers, the last released version, and the upcoming nightlies/
betas (we balance this a little bit with how rapidly users upgrade
browsers - Safari and Opera users upgrade very quickly)."
This is an admission that jQuery is not a cross-browser script (not
news.)
"At the time of this post that includes 12 browsers.
* Internet Explorer 6, 7, 8. (Not including 8 in 7 mode.)
* Firefox 2, 3, Nightly.
* Safari 3.2, 4.
* Opera 9.6, 10.
* Chrome 1, 2."
Not including 8 in "7 mode?" Firefox 1.x is right out?! Safari 2?
Opera 8? And this is with the new jQuery version?
You have to wonder how many *configurations* of these browsers are
tested. IE alone has more configurations than there are hours in a
lifetime.
If you know what you are doing, unit testing is a series of
confirmations, occasionally leading to a revelation about an obscure
quirk or incompatibility.
If you do *not* know what you are doing, unit testing is a crystal
ball directing mystical incantations. In other words, anything goes,
no matter how inexplicable, so long as the unit tests appear to work
in the targeted environments.
It should be clear which path will lead to success in untested (or
unknown) browsers and configurations.
There are two ways to improve. Learn how to write proper cross-
browser code or try to enlist millions of helpers to run your unit
tests every day until the end of time. I'm not shocked that John
Resig is now embarking on the latter course.
[snip]
Matt Kruse
> There are two ways to improve. Learn how to write proper cross-
> browser code or try to enlist millions of helpers to run your unit
> tests every day until the end of time.
False dichotomy.
I think that a distributed, "crowd-sourced" testing engine is a good
thing. Rather than manual testing in a limited subset of browser
configurations, opening up the testing to a wide range of users,
configurations, locales, etc will reveal problems that may not
otherwise have been noticed. This would be a good thing. Perhaps it
will even trigger enough red flags that the code will be seen as more
fragile than it is currently believed to be. Perhaps after failing in
different configurations of "supported" browsers, the jQuery team will
improve the code to work correctly on all of them, and solve problems
in a more general way.
I don't see how this can be a bad thing, unless they use failing test
cases as a way to identify browser configurations that will be added
to the "not supported" list.
Matt Kruse
David Mark
> On Mar 25, 12:30 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > There are two ways to improve. Learn how to write proper cross-
> > browser code or try to enlist millions of helpers to run your unit
> > tests every day until the end of time.
>
> False dichotomy.
>
> I think that a distributed, "crowd-sourced" testing engine is a good
> thing. Rather than manual testing in a limited subset of browser
> configurations, opening up the testing to a wide range of users,
> configurations, locales, etc will reveal problems that may not
> otherwise have been noticed. This would be a good thing.
In the case of jQuery, I am sure it will reveal lots of problems that
never should have made it to outside testers. Much in the same way
that the jQuery user forum reveals problems that never should have
made it into production.
Perhaps it
> will even trigger enough red flags that the code will be seen as more
> fragile than it is currently believed to be. Perhaps after failing in
> different configurations of "supported" browsers, the jQuery team will
> improve the code to work correctly on all of them, and solve problems
> in a more general way.
Why don't they do that in the first place? As you know, as a whole,
that project and its various subsidiaries are in a state of flux.
There are various factions fighting for and against browser sniffing.
Those against seem to favor ill-advised object inferences. Then there
are the "overloading" hacks that make wild assumptions about host
objects. Quite an imposition (and folly IMO) to ask the world to step
in for testing at this point. And yes, the switchboards will be
overloaded, just as in the forums. Who will sift through all of the
false reports, misinterpreted results, bad suggestions, etc.? And why
doesn't John Resig just admit jQuery is a bad design and start over?
That would be the practical thing.
Along those lines, look at the features in jQuery that attract Web
developers. CSS selector queries and animations top the list.
Realize that the days of using huge blobs of complicated Javascript to
accomplish such things are numbered, so there is no good reason to
start over on jQuery at all.
>
> I don't see how this can be a bad thing, unless they use failing test
> cases as a way to identify browser configurations that will be added
> to the "not supported" list.
Yes, why would that change? Widespread empirical observations will
confirm that jQuery has been an incompatible mess all along. Will
this finally convince the authors to pack it in or will they just add
more "edge cases."
And that list is pretty long as it is. Hard to believe that anybody
uses jQuery on the Web. Also, there must be at least two lists now
(the latest version is basically a do-over.) Anyone keeping track of
what breaks in the browser sniffing version(s) which are still spread
all over the Internet (most site owners don't keep up on John Resig's
progressive enlightenment.)
Richard Cornford
It comes as no surprise to here that its authors are perceiving issues
in the testing of JQurey. The very short intervals between releases of
bugfixing minor versions of JQuery 1.3 shows that the testing that was
in place for its creation has not proved up to the task of facilitating
the smooth release of a new version.
On that page John Resig is quoted as writing "The end result is that we
need to run 10 separate test suites in 12 separate browsers before and
after every single commit to jQuery core", and following that with
"Cross-Browser JavaScript testing does not scale". But there is an
aspect of failing to join up the dots in that.
A reasonable question is; what is it about JQuery that means that
everything needs re-testing every time anything is changed. And the
answer to that question is that JQuery has an architecture that is
highly interdependent, so when you change anything the odds are high
that the change has ramifications all over the place. It is not that
cross-browser testing does not scale, more that the testing needs of
interdependent systems scales (pretty much) exponentially with their
complexity.
Given an exponentially expanding testing problem accompanying the growth
of any highly interdependent system there are 3 response:-
1. Cap the size.
2. Expand the testing facilities to keep up.
3. Re-design to reduce/remove the interdependence.
Some combination of the three is indicated, but number 2 has the
drawback of potentially being restrictively expensive (in one sense or
another). The cheapest approach to 2 has to be to get a very large (and
presumably ever growing) pool of volunteers to do the work on their own
time and for free. But it still isn't a cost free alternative as it has
to be accompanied by an administrative effort to sort and manage the
results. And if the testing requirement grows exponentially, (and if the
volunteers keep rolling in,) even if the administrative burned is no
that great to start with, it is going to grow, eventually (and
predictably) to the point where it replaces testing as being the
perceived issue in the ongoing development process (at least if/while
the solution to the testing 'problem' is seen to lie only in option 2).
If you doubt the need for an administrative effort to accompany
distributed testing, or the significance of that effort, it may be
illuminating to see how reports of bugs are being handled now. Consider
the following thread from the jQuery Development mailing list/google
group, the discussion ended over a week ago, which seems long enough for
anyone who could have added to the debate to do so:-
<URL:
http://groups.google.com/group/jquery-dev/browse_frm/thread/80ff60037e954521 >
|-------------------------------------------------------------
| From: Danny
| Date: Tue, 17 Mar 2009 00:35:08 -0700 (PDT)
| Subject: Odd error in IE 7 with $.each
|
| $.each(document.styleSheets... fails with the error:
| Line: 692
| Character: 11
| Code: 0
| Error Message: Invalid procedure call or argument
|
| The simplest page with the error is:
|
|
| <script type="text/javascript"
| src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.js"
| ></script>
| <script>
| $.each (document.styleSheets, function(){});
| </script>
|
| (making the markup valid and adding a DOCTYPE don't help).
|
| A regular for loop works fine.
|
| It seems the problem is the object[++i] at the end of the loop;
| instead of returning undefined it throws the error.
|
|
| Danny
|
|-------------------------------------------------------------
| From: John Resig
| Date: Tue, 17 Mar 2009 09:29:26 -0400
| Subject: Re: [jquery-dev] Odd error in IE 7 with $.each
|
| Would you be open to filing a bug on this? Thanks.
|
| What a stupid behavior on the part of IE.
|
|
| --John
|-------------------------------------------------------------
| From: Robert Katic
| Date: Tue, 17 Mar 2009 09:44:56 -0700 (PDT)
| Subject: Re: Odd error in IE 7 with $.each
|
| I am wondering if it would be necessary to check if
| (i in object) too, in future (with i < length). I hope not :).
|
|-------------------------------------------------------------
| From: Danny
| Date: Tue, 17 Mar 2009 14:15:10 -0700 (PDT)
| Subject: Re: Odd error in IE 7 with $.each
|
|
| Ticket created: http://dev.jquery.com/ticket/4366
|
| I'm not sure that this needs to be fixed, as opposed to documented,
| as was done with $.isFunction. It's obviously not a commonly used
| case. It would have saved me hours of head-beating if I had known
| that I had to write an old-fashioned for-loop or use $.each
| ($.makeArray (document.styleSheets)...; it's not hard.
|
| And John:
| "What a stupid behavior" and "part of IE" is redundant.
|
| Actually, it's understandable why this happens (not forgivable;
| Microsoft should have fixed it): for COM collections like
| styleSheets, the collection[i] notation is just syntactic
| sugar for collection.item(i), a function call. It's not
| unreasonable for a function call to throw an error for
| incorrect arguments. Microsoft lives in a .NET world, where
| arrays are arrays. This dynamic expando thing is beyond
| their little brains.
|
| Danny
|-------------------------------------------------------------
The bug report boiled down to the observation that when a 'collection'
(host) object that was empty was processed through JQuery's - each -
method an error was thrown. Seems simple enough, but apparently
following the misdirection in the original report (the suggestion that
the problem was with the - object[++i] - expression), no actual bug was
perceived in JQuery, but rather IE got the blame. Thus as of today the
'ticket' has only the following comment:-
<URL: http://dev.jquery.com/ticket/4366 >
| Changed 5 days ago by dmethvin
| jQuery-dev related thread:
|
|
http://groups.google.com/group/jquery-dev/browse_frm/thread/80ff60037e954521#
|
| I tend to agree that this may be something to document rather
| than fix, since it should be relatively rare.
However, there is a bug in JQuery's - each - method, right there on line
692 where IE said it was. So here is the code, re-wrapped for Usenet
posting:-
| each: function( object, callback, args ) {
| var name, i = 0, length = object.length;
| if ( args ) {
| if ( length === undefined ) {
| for ( name in object )
| if ( callback.apply( object[ name ], args ) === false )
| break;
| } else
| for ( ; i < length; )
| if ( callback.apply( object[ i++ ], args ) === false )
| break;
| // A special, fast, case for the most common use of each
| } else {
| if ( length === undefined ) {
| for ( name in object )
| if (callback.call(object[name], name, object[name]) === false)
| break;
| } else
| for ( //line 692 starts here
| var value = object[0];
| i < length && callback.call( value, i, value ) !== false;
| value = object[++i]
| ){} //line 692 ends here
| }
| return object;
| },
I have split line 692 up across 5 lines as it is one of those - for -
statements where all the work gets done in control structure and the
body of the loop is empty. Some people think that doing that sort of
thing is 'elegant', I think it makes for obscure code that is hard to
debug (an opinion justified here by the fact that the bug has gone
unnoticed, by its author(s), the participants and observers of the above
thread, and has been there at least since JQuery 1.2.1 (the oldest
version I have on this box) while the - each - method has been
re-written around it).
Execution gets to that statement if the - args - parameter does not have
trueness and the - object.length - value is not the undefined value. In
the code that provokes the error the - args - parameter is undefined and
the - object.length - value is numeric zero.
"Danny" though the - object[++i] - expression at the end of - for -
control construct produced the error, but it could not have as it was
never executed. It was never executed because - length - had been
assigned the zero value from the styleSheets object's - length -
property and so the - i < length - expression is false the first time
it is evaluated (- i - is zero and - length - is zero).
Instead the error is thrown by the evaluation of - var value =
object[0] -, and is a completely predictable error as if -
object.length - is zero we can pretty much expect any 'array-like'
object not to have a '0' property. Under these circumstances the - value
= object[0] - expressions should never have been being evaluated in the
first place. This is just a basic programming error and a pretty obvious
bug in JQuery. (though not nearly as visible as it is obvious, or as it
should have been).
So here a bug has been reported, and in enough detail to reproduce it at
will, and yet no more has been achieved than the production of a little
superfluous hot air.
The administration need comes from the fact that if you ask armatures to
do your testing for you they will report bugs where there are none, and
bug where there are bugs but miss-attribute them, and bugs precisely
where there are bugs. The work is in sorting those things from each
other, and apparently it takes more than a superficial glance at the
code to decide the question.
Usually when I point these things out on Usenet that gets noticed by
someone and they get fixed in pretty short order, but that is a fix to
JQuery's - each - method, as employed extensively by pretty much all of
the rest of JQuery, the plug-ins built on top of it, and ever site suing
it. So time to run through all those unit tests again (plus add the
extra test that verifies that empty host 'collections' are handled
properly in future).
Richard.
Richard Cornford
<snip>
> The administration need comes from the fact that if you ask armatures
That should have been "amateurs"
Richard.
RobG
[...]
> Along those lines, look at the features in jQuery that attract Web
> developers. CSS selector queries and animations top the list.
Given that selectors will be supported by a host API in the near
future (some browsers are already implementing them), I can't see that
query-based selectors will go away anytime soon. And since the API
returns static collections, they will require yet more script to
optimise peroformance and handle modifications to the collections they
return (and probably locking-in developers to some DOM update API of
their chosen framework or library), which leads to your next comment.
> Realize that the days of using huge blobs of complicated Javascript to
> accomplish such things are numbered,
Unfortunately I think you are wrong there (though how I wish you were
right). Apple's Mobile Me is dependent on SproutCore, an increadibly
bloated heap of junk (it is so bloated, the site uses browser sniffing
to re-direct iPhone users to a message that says, more or less, "use
the native apps on your iPhone"[1]). I recently used a web
application based on SharePoint that used a 1MB page - 926kB of that
was in 15 script files (one of which was jQuery) for a simple form.
It wouldn't run on Firefox as it required ActiveX support for some
reason I didn't work out.
Regardless of how "cross browser" jQuery tries to be, its inclusion by
MS with products like SharePoint means that it will be used in
environments that will only tolerate IE. An amusing (though
disheartening) paradox.
1. I find this particularly insulting. It says either that I am so
dumb that I don't realise I can use Mail on my iPhone, or Apple is
making excuses for the performance of Mobile Me on an iPhone (likely
it runs very poorly, if at all)
--
Rob
David Mark
wrote:
> |-------------------------------------------------------------
> | From: Danny
> | Date: Tue, 17 Mar 2009 00:35:08 -0700 (PDT)
> | Subject: Odd error in IE 7 with $.each
> |
> | $.each(document.styleSheets... fails with the error:
> | Line: 692
> | Character: 11
> | Code: 0
> | Error Message: Invalid procedure call or argument
> |
> | The simplest page with the error is:
> |
> |
> | <script type="text/javascript"
> | src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.js"
> | ></script>
> | <script>
> | $.each (document.styleSheets, function(){});
> | </script>
"Danny" is right. You couldn't get a simpler test case.
> |
> | (making the markup valid and adding a DOCTYPE don't help).
> |
> | A regular for loop works fine.
Now there's a clue.
> |
> | It seems the problem is the object[++i] at the end of the loop;
> | instead of returning undefined it throws the error.
> |
> |
> | Danny
> |
> |-------------------------------------------------------------
> | From: John Resig
> | Date: Tue, 17 Mar 2009 09:29:26 -0400
> | Subject: Re: [jquery-dev] Odd error in IE 7 with $.each
> |
> | Would you be open to filing a bug on this? Thanks.
That's obviously at the top of John's macros.
> |
> | What a stupid behavior on the part of IE.
> |
He loves to blame everything on IE.
> |
> | --John
> |-------------------------------------------------------------
> | From: Robert Katic
> | Date: Tue, 17 Mar 2009 09:44:56 -0700 (PDT)
> | Subject: Re: Odd error in IE 7 with $.each
> |
> | I am wondering if it would be necessary to check if
> | (i in object) too, in future (with i < length). I hope not :).
I wonder if any of these people have a debugger for IE.
> |
> |-------------------------------------------------------------
> | From: Danny
> | Date: Tue, 17 Mar 2009 14:15:10 -0700 (PDT)
> | Subject: Re: Odd error in IE 7 with $.each
> |
> |
> | Ticket created:http://dev.jquery.com/ticket/4366
There's progress.
> |
> | I'm not sure that this needs to be fixed, as opposed to documented,
> | as was done with $.isFunction. It's obviously not a commonly used
> | case. It would have saved me hours of head-beating if I had known
> | that I had to write an old-fashioned for-loop or use $.each
> | ($.makeArray (document.styleSheets)...; it's not hard.
> |
> | And John:
> | "What a stupid behavior" and "part of IE" is redundant.
> |
> | Actually, it's understandable why this happens (not forgivable;
> | Microsoft should have fixed it): for COM collections like
> | styleSheets, the collection[i] notation is just syntactic
> | sugar for collection.item(i), a function call. It's not
> | unreasonable for a function call to throw an error for
> | incorrect arguments. Microsoft lives in a .NET world, where
> | arrays are arrays. This dynamic expando thing is beyond
> | their little brains.
This is just a mishmash of random technical terms and MS bashing.
> |
> | Danny
> |-------------------------------------------------------------
>
> The bug report boiled down to the observation that when a 'collection'
> (host) object that was empty was processed through JQuery's - each -
> method an error was thrown. Seems simple enough, but apparently
> following the misdirection in the original report (the suggestion that
> the problem was with the - object[++i] - expression), no actual bug was
> perceived in JQuery, but rather IE got the blame. Thus as of today the
> 'ticket' has only the following comment:-
>
> <URL:http://dev.jquery.com/ticket/4366>
> | Changed 5 days ago by dmethvin
> | jQuery-dev related thread:
> |
> |http://groups.google.com/group/jquery-dev/browse_frm/thread/80ff60037...
> |
> | I tend to agree that this may be something to document rather
> | than fix, since it should be relatively rare.
Agree based on what?
>
> However, there is a bug in JQuery's - each - method, right there on line
> 692 where IE said it was. So here is the code, re-wrapped for Usenet
> posting:-
What a shock.
>
> | each: function( object, callback, args ) {
> | var name, i = 0, length = object.length;
> | if ( args ) {
> | if ( length === undefined ) {
> | for ( name in object )
> | if ( callback.apply( object[ name ], args ) === false )
> | break;
> | } else
> | for ( ; i < length; )
> | if ( callback.apply( object[ i++ ], args ) === false )
> | break;
> | // A special, fast, case for the most common use of each
> | } else {
> | if ( length === undefined ) {
> | for ( name in object )
> | if (callback.call(object[name], name, object[name]) === false)
> | break;
> | } else
> | for ( //line 692 starts here
> | var value = object[0];
> | i < length && callback.call( value, i, value ) !== false;
> | value = object[++i]
> | ){} //line 692 ends here
Jesus wept.
> | }
> | return object;
> | },
>
> I have split line 692 up across 5 lines as it is one of those - for -
> statements where all the work gets done in control structure and the
> body of the loop is empty. Some people think that doing that sort of
> thing is 'elegant', I think it makes for obscure code that is hard to
> debug (an opinion justified here by the fact that the bug has gone
I agree. That stinks.
> unnoticed, by its author(s), the participants and observers of the above
> thread, and has been there at least since JQuery 1.2.1 (the oldest
> version I have on this box) while the - each - method has been
> re-written around it).
And this is perhaps the most used function in the entire script.
You'd think that somebody would have scrutinized the logic at some
point. Feedback finally exposed the loophole (line number and all)
and they *still* couldn't figure it out. So now they want more
feedback. I say why bother.
>
> Execution gets to that statement if the - args - parameter does not have
> trueness and the - object.length - value is not the undefined value. In
> the code that provokes the error the - args - parameter is undefined and
> the - object.length - value is numeric zero.
>
> "Danny" though the - object[++i] - expression at the end of - for -
> control construct produced the error, but it could not have as it was
> never executed. It was never executed because - length - had been
> assigned the zero value from the styleSheets object's - length -
> property and so the - i < length - expression is false the first time
> it is evaluated (- i - is zero and - length - is zero).
>
> Instead the error is thrown by the evaluation of - var value =
> object[0] -, and is a completely predictable error as if -
> object.length - is zero we can pretty much expect any 'array-like'
> object not to have a '0' property. Under these circumstances the - value
> = object[0] - expressions should never have been being evaluated in the
> first place. This is just a basic programming error and a pretty obvious
> bug in JQuery. (though not nearly as visible as it is obvious, or as it
> should have been).
>
> So here a bug has been reported, and in enough detail to reproduce it at
> will, and yet no more has been achieved than the production of a little
> superfluous hot air.
And a ticket!
>
> The administration need comes from the fact that if you ask armatures to
> do your testing for you they will report bugs where there are none, and
> bug where there are bugs but miss-attribute them, and bugs precisely
> where there are bugs. The work is in sorting those things from each
> other, and apparently it takes more than a superficial glance at the
> code to decide the question.
>
> Usually when I point these things out on Usenet that gets noticed by
> someone and they get fixed in pretty short order, but that is a fix to
> JQuery's - each - method, as employed extensively by pretty much all of
> the rest of JQuery, the plug-ins built on top of it, and ever site suing
> it. So time to run through all those unit tests again (plus add the
> extra test that verifies that empty host 'collections' are handled
> properly in future).
That's the thing with unit tests. They tend to mirror problems that
are already known to the developers (or at least within their
imaginations.)
Additionally, there are now two distinct flavors of jQuery to test (or
perhaps they have cut the tether to the thousands of sites using the
browser sniffing version(s).)
David Mark
> On Mar 26, 6:37 am, David Mark <dmark.cins...@gmail.com> wrote:
> [...]
>
> > Along those lines, look at the features in jQuery that attract Web
> > developers. CSS selector queries and animations top the list.
>
> Given that selectors will be supported by a host API in the near
> future (some browsers are already implementing them), I can't see that
> query-based selectors will go away anytime soon. And since the API
What I meant was that the introduction of the new API spells the end
for things like jQuery. That's why Resig wrote a wrapper around it
and called it "Sizzle." An appropriate name BTW (no steak.)
> returns static collections, they will require yet more script to
> optimise peroformance and handle modifications to the collections they
Yes, that is unfortunate, but no worse than what you get with the
libraries (some say it returns static nodelists as a concession to
library users.)
> return (and probably locking-in developers to some DOM update API of
> their chosen framework or library), which leads to your next comment.
>
> > Realize that the days of using huge blobs of complicated Javascript to
> > accomplish such things are numbered,
>
> Unfortunately I think you are wrong there (though how I wish you were
> right). Apple's Mobile Me is dependent on SproutCore, an increadibly
Oops, I meant for competent developers.
> bloated heap of junk (it is so bloated, the site uses browser sniffing
We've been over SproutCore. It makes jQuery look like a masterpiece.
> to re-direct iPhone users to a message that says, more or less, "use
> the native apps on your iPhone"[1]). I recently used a web
In other words, "our Web developers are completely incompetent."
> application based on SharePoint that used a 1MB page - 926kB of that
> was in 15 script files (one of which was jQuery) for a simple form.
> It wouldn't run on Firefox as it required ActiveX support for some
> reason I didn't work out.
Web developers seem to have forgotten about bandwidth (everyone is on
high-speed now, right?) It guess it doesn't register that if
developer A needs 1000KB to accomplish what takes developer B 100KB,
developer A won't be around very long.
>
> Regardless of how "cross browser" jQuery tries to be, its inclusion by
> MS with products like SharePoint means that it will be used in
> environments that will only tolerate IE. An amusing (though
> disheartening) paradox.
MS just latched onto the name. They have to know it is drivel and
they don't care.
>
> 1. I find this particularly insulting. It says either that I am so
> dumb that I don't realise I can use Mail on my iPhone, or Apple is
> making excuses for the performance of Mobile Me on an iPhone (likely
> it runs very poorly, if at all)
Odd that Apple can't design a decent application for their own phone.
I recently worked on an iPhone app and found it very capable (of
course, I didn't use jQuery or any other 50KB capsule of wasted time.)
[snip]
Danny
the object[0] will throw the error, but if the collection is not
empty, at some point ++i will equal length and object[++i] will throw.
When I found this bug, there were 3 stylesheets, so the $.each loop
worked fine for all three, then threw an error at the end.
The problem is the same in both cases: IE throws an error if the index
into a collection is larger than the size of the collection. The bug,
however, is IE's, not jQuery's. In Javascript, a too-large index
should return undefined, not throw an error. Try it: [1][1]
===undefined is true, even in IE. IE's JScript pretends that its
collections are Javascript arrays, but they are not. Thus the problem
with $.each.
Danny
David Mark
> Actually, this analysis is largely wrong. If the collection is empty,
Now there's hubris.
> the object[0] will throw the error, but if the collection is not
That much is apparent at this point.
> empty, at some point ++i will equal length and object[++i] will throw.
> When I found this bug, there were 3 stylesheets, so the $.each loop
> worked fine for all three, then threw an error at the end.
> The problem is the same in both cases: IE throws an error if the index
> into a collection is larger than the size of the collection. The bug,
> however, is IE's, not jQuery's. In Javascript, a too-large index
The "bug" is not IE's. It is jQuery's. Why not stop arguing and
rewrite the line? Then tell Resig to fire up the unit tests again.
Make sure you test all of the various jQuery versions, plug-ins,
widgets and combinations thereof. Good luck with that!
> should return undefined, not throw an error. Try it: [1][1]
> ===undefined is true, even in IE.
So?
> IE's JScript pretends that its
> collections are Javascript arrays, but they are not. Thus the problem with $.each.
I recognize the words, but that statement makes no sense.
>
> Danny
>
Please don't top-post and get a last name.
[snip]
Matt Kruse
> Actually, this analysis is largely wrong. If the collection is empty,
> the object[0] will throw the error, but if the collection is not
> empty, at some point ++i will equal length and object[++i] will throw.
Richard's analysis is just premature, in your case. There are
potential errors on both ends of the loop.
> The problem is the same in both cases: IE throws an error if the index
> into a collection is larger than the size of the collection. The bug,
> however, is IE's, not jQuery's. In Javascript, a too-large index
> should return undefined, not throw an error. Try it: [1][1]
> ===undefined is true, even in IE. IE's JScript pretends that its
> collections are Javascript arrays, but they are not. Thus the problem
> with $.each.
The core assumption is wrong: That if an object has a 'length'
property, and it returns 0, that inspecting object[0] is safe. This is
obviously a false assumption in a major browser that's been around for
many years.
Since the goal of libraries like jQuery are to normalize browser
behavior and shield developers from browser implementation details,
doesn't that indeed make it jQuery's problem?
Since browsers are free to implement features with host objects that
"look" like normal js objects/arrays, but do not behave just like
them, then it's jQuery's responsibility to either detect the
difference and behave appropriately or clearly document that the
method in question cannot be used to process host objects. Since most
developers probably have no clue about which things are host objects
in IE, for example, it would be better for jQuery to normalize
behavior and not break when the user passes it something it doesn't
like.
Matt Kruse
Richard Cornford
> Actually, this analysis is largely wrong. If the collection is
> empty, the object[0] will throw the error,
So in what sense is asserting that the - value = object[0] - expression
will throw an error wrong? Your test-case has no style sheets and so
the - document.styleSheets - collection will be empty in its case.
> but if the collection is not empty, at some point ++i will
> equal length and object[++i] will throw.
I didn't say it wouldn't, just that in the test code posted that
expression would not be evaluated and so it could not be responsible for
the error observed when running the test-case.
> When I found this bug, there were 3 stylesheets, so the
> $.each loop worked fine for all three, then threw an error
> at the end.
So the test-case you created failed to demonstrate the issue you were
attempting to report? And there I was being pleasantly surprised that
for once someone had managed to create a concise, reproducible
demonstration of their issue.
> The problem is the same in both cases: IE throws an error if
> the index into a collection is larger than the size of the
> collection. The bug, however, is IE's, not jQuery's. In
> Javascript, a too-large index should return undefined, not
> throw an error.
That is just for native objects. Host objects are allowed to implement
their [[Put]] methods in any way they want, including such that
exceptions are thrown on assignment. Thus when you are dealing with a
host object (or don't know what type of object you are dealing with) the
only sensible approach is to assume the worst, which includes not
accessing the 'array index' members of array-like objects outside of the
range with the upper limit (x.length - 1).
In reality the most restrictive standard imposing a constraint on
behaviour here is the W3C DOM spec (and ECMAScript bindings) for the
StyleSheetList interface and its - item - method, and if taken literally
that document requires that reading of an 'out of bounds' index should
result in the - null - value (with no exceptions thrown). That position
is arguable (hinges on the interpretation of "integer index" in
context), but if accepted IE is not conforming with that specification,
but then no other browsers do either so it becomes a little hypocritical
to point the finger at IE alone. (There is no binding of IDL null to any
ECMAScript primitive in the W3C specs, but if you expect -
getElementById - to return null for a non-existing ID value, rather than
the undefined value, then you also have to expect - item - to return
null)
> Try it: [1][1] ===undefined is true, even in IE.
An array is a native object.
> IE's JScript pretends that its
> collections are Javascript arrays, but they are not.
No it doesn't, not by a long way.
Strictly the 'collections' are independent of JScript (not owned by
JScript), else VBScript could never be used for DOM interactions in IE
(and it certainly can be).
> Thus the problem
> with $.each.
The problem with $.each is that its logic is seriously flawed. That may
be exacerbated by using it with host objects, but even with native
arrays it makes no sense to write a - for - loop that is not constrained
in its access to the array by the length property of the array. It is
not as if:-
for( i = 0; i < length; ++i ){
value = object[i];
if(callback.call( value, i, value ) === false){
break;
}
}
- is that difficult to write.
Richard.
Richard Cornford
> Danny wrote:
<snip>
>> The problem is the same in both cases: IE throws an error if
>> the index into a collection is larger than the size of the
>> collection. The bug, however, is IE's, not jQuery's. In
>> Javascript, a too-large index should return undefined, not
>> throw an error.
>
> That is just for native objects. Host objects are allowed to implement
> their [[Put]] methods in any way they want, including such that
> exceptions are thrown on assignment.
In context that should refer to the host object's [[Get]] methods, and
reading rather than assignment, but those methods also may be
implemented at the host implementer's discretion, and so also may throw
exceptions.
Incidentally, IE browsers do not claim (per -
document.implementation.hasFeature -) to implement the W3C StyleSheets
module so while it could be argued that they do not conform to it that
failure to conform still could not be categorised as a bug.
Richard.
Garrett Smith
> On Mar 25, 9:16 pm, Danny <d.wac...@prodigy.net> wrote:
>> Actually, this analysis is largely wrong. If the collection is empty,
>
> Now there's hubris.
>
>> the object[0] will throw the error, but if the collection is not
>
> That much is apparent at this point.
>
[[GET]] returns true for numbers (some numbers). Probably a broken
[[HasProperty]] is at fault (see below).
>> empty, at some point ++i will equal length and object[++i] will throw.
>> When I found this bug, there were 3 stylesheets, so the $.each loop
>> worked fine for all three, then threw an error at the end.
>> The problem is the same in both cases: IE throws an error if the index
>> into a collection is larger than the size of the collection. The bug,
>> however, is IE's, not jQuery's. In Javascript, a too-large index
>
> The "bug" is not IE's. It is jQuery's. Why not stop arguing and
> rewrite the line? Then tell Resig to fire up the unit tests again.
> Make sure you test all of the various jQuery versions, plug-ins,
> widgets and combinations thereof. Good luck with that!
>
>> should return undefined, not throw an error. Try it: [1][1]
>> ===undefined is true, even in IE.
>
> So?
>
It is not really expected behavior that getting a property would throw
an error.
What is more surprising:-
javascript:alert('9011' in document.styleSheets)
javascript:alert('-1' in document.styleSheets)
javascript:alert( '009.1' in document.styleSheets)
javascript:alert( (Number.MAX_VALUE) in document.styleSheets)
javascript:alert( -Number.MAX_VALUE in document.styleSheets )
true.
javascript:alert( (Number.MIN_VALUE) in document.styleSheets)
false.
javascript:alert( 1e-6 in document.styleSheets)
true.
javascript:alert( 1e-7 in document.styleSheets)
false.
I can't quite make sense of it, much less think of a reason why IE's
behavior would be useful.
If we try the typeof operator on it:-
javascript:alert( typeof document.styleSheets[911] )
"unknown"
At this point I pretty much expected that. Type conversion of "unknown"
objects results in error. ToBoolean is the most common source of such
problems, but they may occur with ToString also. Example:-
For example:-
javascript:alert( typeof new ActiveXObject("Msxml2.XMLHTTP").open )
unknown
javascript:alert( new ActiveXObject("Msxml2.XMLHTTP").open )
- Error Thrown -
Looking at [[Get]] could not provide any conclusive answers. Object
document.styleSheets is a Host object which may have a special [[Get]].
Given that the |in| operator returns true for number-strings, there
seems to be a problem with [[HasProperty]] with this particular object.
The implementation's [[HasProperty]] code might be used for step 1 of
[[Get]]:-
|8.6.2.1 [[Get]](P)
|
| When the [[Get]] method of O is called with property name P,
| the following steps are taken:
|
| 1. If O doesn't have a property with name P, go to step 4.
The phrase "have a property" could be implemented by the same code that
performs [[HasProperty]].
If somehow step 1 returns true, we get to step 2. After that, the
program would be in a state where error would be expected. I do not know
if this is what happens.
IE should not throw error on type converting the "unknown" objects
because it causes programs to fail. Sometimes, as is the case with this
one, the bug may stay hidden and not surface immediately. It is very
natural to write:-
if(obj.prop) {
}
I would like IE to change.
Garrett
Jorge
wrote:
>
> (...) it makes no sense to write a - for - loop that is not constrained
> in its access to the array by the length property of the array. It is
> not as if:-
>
> value = object[i];
> if (callback.call( value, i, value ) === false) {
> break;
> }
> }
>
> - is that difficult to write.
OMG, that's ^^^^ so ordinary, it isn't "ninja-ish" (cool) enough...
LOL.
Cornford +1, Resig -1 (Danny -1).
--
Jorge.
David Mark
It's definitely not useful and the above results seem nonsensical.
>
> If we try the typeof operator on it:-
> javascript:alert( typeof document.styleSheets[911] )
> "unknown"
Of course. That means that for whatever reasons, style sheets are
implemented as ActiveX objects (unknown probably refers to iUnknown.)
http://msdn.microsoft.com/en-us/library/ms680509(VS.85).aspx
>
> At this point I pretty much expected that. Type conversion of "unknown"
> objects results in error. ToBoolean is the most common source of such
> problems, but they may occur with ToString also. Example:-
The bindings between IE and its ActiveX host objects are a mystery.
The only thing I know for sure is that the typeof operator identifies
their properties as "unknown" and you definitely can't type convert
them without exception.
That's the anthem for the century so far.
Jorge
> (..)
> I would like IE to change.
>
I'd rather prefer it to disappear. Forever. Gone. Resting by Netscape
Navigator's side. What a wonderful world it would be.
--
Jorge.
Jorge
♬ gone ♪ forever ♩ gone ♫ foreeever ♬ aaaah-oooh ♫
--
Jorge.
Richard Cornford
> On Mar 26, 3:46 am, Richard Cornford wrote:
<snip>
>> for ( i = 0; i < length; ++i ) {
>> value = object[i];
>> if (callback.call( value, i, value ) === false) {
>> break;
>> }
>> }
>>
>> - is that difficult to write.
>
> OMG, that's ^^^^ so ordinary, it isn't "ninja-ish" (cool) enough...
> LOL.
For some reason relative 'coolness' does not even feature in the list of
things to be considered that I employ while designing/writing computer
code.
Richard.
David Mark
Resig is a Ninja in the Inspector Clouseau mold. He could trip over
his own shadow.
I suppose "Secrets of the Javascript Klutz" wouldn't have sold as well.
Garrett Smith
[...]
> Given that the |in| operator returns true for number-strings, there
> seems to be a problem with [[HasProperty]] with this particular object.
>
> The implementation's [[HasProperty]] code might be used for step 1 of
> [[Get]]:-
>
> |8.6.2.1 [[Get]](P)
> |
> | When the [[Get]] method of O is called with property name P,
> | the following steps are taken:
> |
> | 1. If O doesn't have a property with name P, go to step 4.
>
> The phrase "have a property" could be implemented by the same code that
> performs [[HasProperty]].
>
> If somehow step 1 returns true, we get to step 2. After that, the
> program would be in a state where error would be expected. I do not know
> if this is what happens.
And IE might appear to be identifying a property in that object itself,
not on the [[Prototype]].
javascript:alert(({}).hasOwnProperty.call(document.styleSheets, '911'))
true.
For a styleSheets collection, IE identifies an own property of (n of
numberset) as present, just by being present in that set of numbers.
Given that, it seems more likely that the [[Get]] is failing at step 1
because of this reason. Then again, it may be something else.
[...]
Garrett
Garrett Smith
> Danny wrote:
>> Actually, this analysis is largely wrong. If the collection is
>> empty, the object[0] will throw the error,
>
> So in what sense is asserting that the - value = object[0] - expression
> will throw an error wrong? Your test-case has no style sheets and so the
> - document.styleSheets - collection will be empty in its case.
>
Yep. And object.item(0) will throw the error, too.
[...]
>
> That is just for native objects. Host objects are allowed to implement
> their [[Put]] methods in any way they want, including such that
> exceptions are thrown on assignment. Thus when you are dealing with a
> host object (or don't know what type of object you are dealing with) the
> only sensible approach is to assume the worst, which includes not
> accessing the 'array index' members of array-like objects outside of the
> range with the upper limit (x.length - 1).
The error is not caused by using property access [] operator (to get the
out-of-index property).
The error occurs with IE trying to get the out of index property. The
error occurs whether by property access, by calling the item method, or
by calling the collection directly (which IE allows).
The item() method in IE and does not return null when called on various
collections (but not all collections) in IE.
Some examples of out-of-bounds item returning null are
node.all.item(99999) and styleSheet.media.item(99999). Both correctly
return null in IE.
The w3c does not define a standard "collection" interface with an item
method. IE documents its item method as being something that operates on
"various collections". This is fine. What is not fine is IE's design and
testing.
>
> In reality the most restrictive standard imposing a constraint on
> behaviour here is the W3C DOM spec (and ECMAScript bindings) for the
> StyleSheetList interface and its - item - method, and if taken literally
> that document requires that reading of an 'out of bounds' index should
> result in the - null - value (with no exceptions thrown). That position
> is arguable (hinges on the interpretation of "integer index" in
> context), but if accepted IE is not conforming with that specification,
> but then no other browsers do either so it becomes a little hypocritical
> to point the finger at IE alone. (There is no binding of IDL null to any
> ECMAScript primitive in the W3C specs, but if you expect -
> getElementById - to return null for a non-existing ID value, rather than
> the undefined value, then you also have to expect - item - to return null)
>
I am not sure you mean by "no other browsers conform to the specification".
javascript: alert(document.styleSheets.item(999999))
"null" in Safari, Firefox, Opera.
These browsers do not return undefined for an 'out of bounds' index.
However, the item() method in IE throws the same error when the index is
out of range:-
javascript: alert( document.styleSheets.item(999999) )
The w3c HTML DOM mentions the use of property accessors for
HTMLCollection. However, DOM Level 2 Style makes no mention of property
accessors behavior is not standardized for a StyleSheetList.
The w3c did not define a generalized "collection" interface. Such design
would seem to avoid w3c specification shotgun surgery.
Garrett
Garrett Smith
> Richard Cornford wrote:
>> Danny wrote:
>
> The item() method in IE and does not return null when called on various
> collections (but not all collections) in IE.
>
Correction:
The item() method in throws an error when called on various collections
(but not all collections) with an 'out of bounds' index in IE.
Garrett
Richard Cornford
> Richard Cornford wrote:
>> Danny wrote:
>>> Actually, this analysis is largely wrong. If the collection
>>> is empty, the object[0] will throw the error,
>>
>> So in what sense is asserting that the - value = object[0] -
>> expression will throw an error wrong? Your test-case has
>> no style sheets and so the - document.styleSheets -
>> collection will be empty in its case.
>
> Yep. And object.item(0) will throw the error, too.
Only to be expected as the W3C spec requires - object.item(0) - and -
object[0] - to be "equivalent" when - 0 - is an "integer index".
<snip>
> The error is not caused by using property access [] operator
> (to get the out-of-index property).
It is.
> The error occurs with IE trying to get the out of index
> property.
And that is not what a property accessor does when used as the right
hand side of an assignment expression?
> The error occurs whether by property access, by calling the
> item method,
The two are specified as being equivalent for some property
names/arguments, so no real surprise there.
> or by calling the collection directly (which IE allows).
And no published standard forbids.
> The item() method in IE and does not return null when called
> on various collections (but not all collections) in IE.
>
> Some examples of out-of-bounds item returning null are
> node.all.item(99999) and styleSheet.media.item(99999). Both
> correctly return null in IE.
>
> The w3c does not define a standard "collection" interface with
> an item method. IE documents its item method as being something
> that operates on "various collections". This is fine. What is
> not fine is IE's design and testing.
Not really. IE had - item - methods on its collections long before there
were W3C DOM standards. That makes it difficult to assert that anything
they do is wrong, except where it disagrees with Microsoft's own
documentation of what they are supposed to do. If blame is to be
attributed here at all then a reasonable target for that blame might be
the W3C for attempting to formalise a pre-existing interface in a way
that was incompatible with the existing/established behaviour of that
interface. That is a mistake the W3C had made many times by now, and is
going to repeat in the future.
>> In reality the most restrictive standard imposing a constraint on
>> behaviour here is the W3C DOM spec (and ECMAScript bindings) for
>> the StyleSheetList interface and its - item - method, and if
>> taken literally that document requires that reading of an 'out
>> of bounds' index should result in the - null - value (with no
>> exceptions thrown). That position is arguable (hinges on the
>> interpretation of "integer index" in context), but if accepted
>> IE is not conforming with that specification, but then no other
>> browsers do either so it becomes a little hypocritical to point
>> the finger at IE alone. (There is no binding of IDL null to any
>> ECMAScript primitive in the W3C specs, but if you expect -
>> getElementById - to return null for a non-existing ID value,
>> rather than the undefined value, then you also have to expect
>> - item - to return null)
>
> I am not sure you mean by "no other browsers conform to the
> specification".
I mean that the W3C specs require - object.item(n) - and - object[n] -
to be "equivalent" when "dereferencing" whenever - n - is an "integer
index", (For the StyleSheetList interface in this case, but all the
other 'collection' interfaces as well) so if - object.item(4) - returns
null then - object{4] - should evaluate to null, but mostly it doesn't
(and the result is the undefined value instead).
It would be possible to argue about the nature of "integer index" in
that context, for example asserting that a number is only an "index" if
it indexes something in the collection; that there is no such thing as
an 'out of bounds index' because an 'out of bounds number' is not an
"index" (it does not "index" anything (anything that exists)). I don't
recall anyone trying that line but I can see how it could be argued.
However, that promptly lets IE off the hook for throwing exceptions
with - object[0] - as then - 0 - has stopped qualifying as an "index"
and the behaviour of - object[0] -, where - object - is an empty
collection, becomes unspecified (and so as with other host object,
exception throwing is allowed).
> javascript: alert(document.styleSheets.item(999999))
> "null" in Safari, Firefox, Opera.
Which is irrelevant in context.
> These browsers do not return undefined for an 'out of bounds'
> index.
But they fail to be "equivalent" with -
alert(document.styleSheets[999999]) -.
> However, the item() method in IE throws the same error when
> the index is out of range:-
> javascript: alert( document.styleSheets.item(999999) )
Now that is "equivalent", just not what the W3C spec asks for (assuming
a particular interpretation of "integer index"). IE doesn't claim to
support the W3C StyleSheets module so its 'equivalence' between bracket
notation and - item - method calls is a bit of a bonus.
> The w3c HTML DOM mentions the use of property accessors for
> HTMLCollection. However, DOM Level 2 Style makes no mention of
> property accessors behavior is not standardized for a
> StyleSheetList.
Except in the ECMAScript bindings:-
<URL:
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/ecma-script-binding.html >
- where it says:-
<URL:
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/ecma-script-binding.html >
| Object StyleSheetList
|
| ...
|
| The StyleSheetList object has the following methods:
| item(index)
| This method returns a StyleSheet object.
| The index parameter is of type Number.
| Note: This object can also be dereferenced using square
| bracket notation (e.g. obj[1]). Dereferencing with an
| integer index is equivalent to invoking the item method
| with that index.
(Observe the 'Note', and that all other ECMAScript biddings for - item -
and - nameditem - methods in the W3C DOM specs have similar notes.)
> The w3c did not define a generalized "collection" interface.
> Such design would seem to avoid w3c specification shotgun surgery.
Is that supposed to mean something?
Richard.
dhtml
wrote:
> Garrett Smith wrote:
> > Richard Cornford wrote:
> >> Danny wrote:
> >>> Actually, this analysis is largely wrong. If the collection
> >>> is empty, the object[0] will throw the error,
>
> >> So in what sense is asserting that the - value = object[0] -
> >> expression will throw an error wrong? Your test-case has
> >> no style sheets and so the - document.styleSheets -
> >> collection will be empty in its case.
>
> > Yep. And object.item(0) will throw the error, too.
>
> Only to be expected as the W3C spec requires - object.item(0) - and -
> object[0] - to be "equivalent" when - 0 - is an "integer index".
>
It is not to be expected that item(0) would throw an error. In this
case, it should return null. Even by MSDN documentation, which
states:-
| Returns an object or a collection of objects if successful, or null
otherwise.
> <snip>
>
> > The error is not caused by using property access [] operator
> > (to get the out-of-index property).
>
> It is.
The same error occurs with calling item(0) (at least in IE6) and so
clearly the cause of the problem is beyond the use of the operator
[].
It is the implementation of getting the object that is at fault.
>
> > The error occurs with IE trying to get the out of index
> > property.
>
> And that is not what a property accessor does when used as the right
> hand side of an assignment expression?
>
Sure, if the standard [[Get]] is used, that will happen. It is even
fairly reasoable to assume that something will be returned (if even
undefined).
With a host object, there may or may not be a call to the standard
[[Get]]. If there is a special [[Get]], then anything could happen.
> > The error occurs whether by property access, by calling the
> > item method,
>
> The two are specified as being equivalent for some property
> names/arguments, so no real surprise there.
>
And the item method is specified as having a very clear behavior:-
| Return Value
|
| StyleSheet
|
| The style sheet at the index position in the StyleSheetList, or
null
| if that is not a valid index.
[...]
>
> > The w3c does not define a standard "collection" interface with
> > an item method. IE documents its item method as being something
> > that operates on "various collections". This is fine. What is
> > not fine is IE's design and testing.
>
> Not really. IE had - item - methods on its collections long before there
> were W3C DOM standards. That makes it difficult to assert that anything
> they do is wrong, except where it disagrees with Microsoft's own
> documentation of what they are supposed to do. If blame is to be
That is the problem. Well, part of the problem. The item method
doesn't do in IE what MSDN says it does. Instead, it throws an error
(sometimes). It does not check the type of the first argument.
Instead, it tries to convert it to a number. Look:-
javascript: alert(document.body.childNodes.item( "XXX").nodeName );
javascript: alert(document.body.childNodes.item(""))
- returns the first element in the document. In IE6, anyway.
It doesn't do what w3c says it does either. It doesn't even seem to b
callable, as:-
typeof childNodes.item
- is "string" in IE.
Feature tests would not identify "item" as something that can be
called. Given the bugs we've seen, that might be a good thing.
> attributed here at all then a reasonable target for that blame might be
> the W3C for attempting to formalise a pre-existing interface in a way
> that was incompatible with the existing/established behaviour of that
> interface. That is a mistake the W3C had made many times by now, and is
> going to repeat in the future.
>
Yes, that is happening in HTML 5. The BODY "onhashchange", null having
a string equivalent of "" sometimes and "null" other times (same with
undefined), c:\fakepath\, or any of the recent statements and advice
by I. Hickson, such as providing advice on how to prevent a script
from blocking the browser HTML rendering:-
| Put the scripts first [before styleSheets].
- or:-
| Browsers are already allowed to not block on [script and link].
Even after being told repeatedly that he is wrong (by Boris and
Jonas), e.g. Boris: "We'll block until all external stylesheets in the
currently-selected style set have finished loading. Alternate
stylesheets do not block script execution."
Even after numerous testcases, he never admits he was wrong, but then
goes on to say things like:-
| The best way forward is really to just
| design your scripts such that they don't depend on the style sheets
(you
| have no guarantee that the user will get the CSS anyway), and then
to just
| rely on the browser vendors to make the right decisions about when
to
| fetch each file.
And concludes that the solution to the problem (the problem is FOUC,
but he snips that) is to create an element for dialogs (red herring).
My opinion of Ian used to be a lot higher. Now I see him as
unreasonable and biased.
I don't want devote so much energy to repeatedly point out the same
mistakes.
>
>
> >> In reality the most restrictive standard imposing a constraint on
> >> behaviour here is the W3C DOM spec (and ECMAScript bindings) for
> >> the StyleSheetList interface and its - item - method, and if
> >> taken literally that document requires that reading of an 'out
> >> of bounds' index should result in the - null - value (with no
> >> exceptions thrown). That position is arguable (hinges on the
> >> interpretation of "integer index" in context), but if accepted
> >> IE is not conforming with that specification, but then no other
> >> browsers do either so it becomes a little hypocritical to point
> >> the finger at IE alone. (There is no binding of IDL null to any
> >> ECMAScript primitive in the W3C specs, but if you expect -
> >> getElementById - to return null for a non-existing ID value,
> >> rather than the undefined value, then you also have to expect
> >> - item - to return null)
>
> > I am not sure you mean by "no other browsers conform to the
> > specification".
>
> I mean that the W3C specs require - object.item(n) - and - object[n] -
> to be "equivalent" when "dereferencing" whenever - n - is an "integer
> index", (For the StyleSheetList interface in this case, but all the
> other 'collection' interfaces as well) so if - object.item(4) - returns
> null then - object{4] - should evaluate to null, but mostly it doesn't
> (and the result is the undefined value instead).
>
Yes, that is right. So the implementation of property access could be
expected to return null, because that is what is specified for item,
however implementations return undefined.
> It would be possible to argue about the nature of "integer index" in
> that context, for example asserting that a number is only an "index" if
> it indexes something in the collection; that there is no such thing as
> an 'out of bounds index' because an 'out of bounds number' is not an
> "index" (it does not "index" anything (anything that exists)). I don't
> recall anyone trying that line but I can see how it could be argued.
> However, that promptly lets IE off the hook for throwing exceptions
> with - object[0] - as then - 0 - has stopped qualifying as an "index"
> and the behaviour of - object[0] -, where - object - is an empty
> collection, becomes unspecified (and so as with other host object,
> exception throwing is allowed).
>
I think the intent of the specification is clear enough about the item
method with:-
| Returns:
| The style sheet at the index position in the StyleSheetList,
| or null if that is not a valid index.
> > javascript: alert(document.styleSheets.item(999999))
> > "null" in Safari, Firefox, Opera.
>
> Which is irrelevant in context.
>
It shows that other implementation follows the specification of
returning null for the item method when parameter |index| is out of
bounds (e.g. outside the range of valid child stylesheet indices is 0
to length-1 inclusive).
> > These browsers do not return undefined for an 'out of bounds'
> > index.
>
> But they fail to be "equivalent" with -
> alert(document.styleSheets[999999]) -.
>
> > However, the item() method in IE throws the same error when
> > the index is out of range:-
> > javascript: alert( document.styleSheets.item(999999) )
>
> Now that is "equivalent", just not what the W3C spec asks for (assuming
> a particular interpretation of "integer index"). IE doesn't claim to
Square bracket notation is noted to be equivalent to item, not the
other way around. The item method is specified.
[...]
> (Observe the 'Note', and that all other ECMAScript biddings for - item -
> and - nameditem - methods in the W3C DOM specs have similar notes.)
>
> > The w3c did not define a generalized "collection" interface.
> > Such design would seem to avoid w3c specification shotgun surgery.
>
> Is that supposed to mean something?
That same note is used to describe various dom collections. If they
end up having to change that note in one place, they have to change it
everywhere. That is shotgun surgery.
Garrett
Richard Cornford
>On Mar 27, 3:12 pm, Richard Cornford wrote:
>> Garrett Smith wrote:
>>> Richard Cornford wrote:
>>>> Danny wrote:
>>>>> Actually, this analysis is largely wrong. If the collection
>>>>> is empty, the object[0] will throw the error,
>>
>>>> So in what sense is asserting that the - value = object[0] -
>>>> expression will throw an error wrong? Your test-case has
>>>> no style sheets and so the - document.styleSheets -
>>>> collection will be empty in its case.
>>
>> > Yep. And object.item(0) will throw the error, too.
>>
>> Only to be expected as the W3C spec requires - object.item(0) -
>> and - object[0] - to be "equivalent" when - 0 - is an "integer
>> index".
>>
>
> It is not to be expected that item(0) would throw an error.
As we have already established beyond and reasonable doubt that - value
= object[0] - causes an exception to be thrown when - object - is an
empty styleSheets collection, and having observed the (conditional)
'equivalence' between property accessors and calls to the collection's -
item - method, - object.item(0) - throwing the same exception is
entirely "to be expected".
> In this case, it should return null. Even by MSDN documentation,
> which states:-
>| Returns an object or a collection of objects if successful,
>| or null otherwise.
Right, so Microsoft have a bug (in their code or their documentation),
but that is hardly unexpected.
>> <snip>
>>
>>> The error is not caused by using property access [] operator
>>> (to get the out-of-index property).
>>
>> It is.
>
> The same error occurs with calling item(0) (at least in IE6)
> and so clearly the cause of the problem is beyond the use of
> the operator [].
All you are saying there is that there is more than one means of
provoking this particular exception. But we started with concrete code
that used one particular means to cause he exception to be thrown, and
in that code the property accessor did cause the exception to be thrown.
> It is the implementation of getting the object that is at fault.
You still have to cause the getting to be attempted before it can fail.
>>> The error occurs with IE trying to get the out of index
>>> property.
>>
>> And that is not what a property accessor does when used as
>> the right hand side of an assignment expression?
>>
>
> Sure, if the standard [[Get]] is used, that will happen.
The internal GetValue function will call an object's [[Get]] method
regardless of whether it is the native one or a host-provided
alternative.
> It is even fairly reasoable to assume that something will
> be returned (if even undefined).
>
> With a host object, there may or may not be a call to the
> standard [[Get]]. If there is a special [[Get]], then
> anything could happen.
Somewhere in this thread someone has already pointed out that
host-provided [[Get]] methods are at liberty to throw exceptions.
Callling the object's [[Get]] method is "what a property accessor does
when used as the right hand side of an assignment expression". The
property accessor use causes the [[Get]] method to be called, and in
this case the [[Get][ method throws the exception.
>>> The error occurs whether by property access, by calling the
>>> item method,
>>
>> The two are specified as being equivalent for some property
>> names/arguments, so no real surprise there.
>>
>
> And the item method is specified as having a very clear behavior:-
>| Return Value
>|
>| StyleSheet
>|
>| The style sheet at the index position in the StyleSheetList,
>| or null if that is not a valid index.
Yes, but a property accessor is only specified as being equivalent if
the property name is an "integer index", so the behaviour of property
accesses where the property name is not an "integer index" is not
specified. Thus the throwing of exceptions is allowed with the use of
some property accessors (as only ECMA 262 apples in those case), and it
becomes important to determine what an "integer index" means.
>>> The w3c does not define a standard "collection" interface with
>>> an item method. IE documents its item method as being something
>>> that operates on "various collections". This is fine. What is
>>> not fine is IE's design and testing.
>>
>> Not really. IE had - item - methods on its collections long before
>> there were W3C DOM standards. That makes it difficult to assert
>> that anything they do is wrong, except where it disagrees with
>> Microsoft's own documentation of what they are supposed to do.
>> If blame is to be
>
> That is the problem.
It is _a_ problem, or rather it is a potential problem (as it really
isn't that difficult to work with styleSheets collections in a way that
does not provoke any issues, suggesting that practical issue here was
introduced by something outside of IE and the W3C standards).
> Well, part of the problem. The item method
> doesn't do in IE what MSDN says it does.
Apparently not, and that is a bug (which Microsoft will probably fix if
it is brought to their attention, though they may just fix the
documentation).
> Instead, it throws an error (sometimes). It does not check the
> type of the first argument. Instead, it tries to convert it to a
> number. Look:-
>
> javascript: alert(document.body.childNodes.item( "XXX").nodeName );
> javascript: alert(document.body.childNodes.item(""))
>
> - returns the first element in the document. In IE6, anyway.
Type-converting arguments is a very javascript-like thing to be doing. I
don't think anyone would reasonable complain about that, as it should be
the responsibility of the javascript programmer to ensure they are
passing the right types of values into function/method calls (that is
one of disciplines that goes with using a loosely type language).
> It doesn't do what w3c says it does either.
Which is only a bug if Microsoft claimed to support the DOM
interface/module.
> It doesn't even seem to b
> callable, as:-
>
> typeof childNodes.item
>
> - is "string" in IE.
Mad as that may be it has been there since IE4 to my certain knowledge,
and has gone sufficiently unnoticed over that time as to suggest it
isn't really an issue.
> Feature tests would not identify "item" as something that can
> be called.
No feature test has ever been devised that will accurately determine the
capability of host method.
> Given the bugs we've seen, that might be a good thing.
>
>> attributed here at all then a reasonable target for that blame
>> might be the W3C for attempting to formalise a pre-existing
>> interface in a way that was incompatible with the
>> existing/established behaviour of that interface. That is a mistake
>> the W3C had made many times by now, and is going to repeat in the
>> future.
>>
>
> Yes, that is happening in HTML 5. The BODY "onhashchange", null
> having a string equivalent of "" sometimes and "null" other times
> (same with undefined), c:\fakepath\, or any of the recent
> statements and advice by I. Hickson, such as providing advice on
> how to prevent a script from blocking the browser HTML rendering:-
<snip>
> My opinion of Ian used to be a lot higher. Now I see him as
> unreasonable and biased.
<snip>
The people responsible for HTML 5 seem to have some extremely personal
and odd ideas about what web browser should do. The also seem to be
largely self-selected, where it would seem reasonable for the W3C to
include representatives of wider perspectives in their working groups.
But given the W3C's record on botching DOM specs even if they tried that
they would probably still fail to achieve anything useful.
<snip>
>>> I am not sure you mean by "no other browsers conform to the
>>> specification".
>>
>> I mean that the W3C specs require - object.item(n) - and -
>> object[n] - to be "equivalent" when "dereferencing" whenever -
>> n - is an "integer index", (For the StyleSheetList interface in
>> this case, but all the other 'collection' interfaces as well) so
>> if - object.item(4) - returns null then - object{4] - should
>> evaluate to null, but mostly it doesn't (and the result is the
>> undefined value instead).
>>
>
> Yes, that is right. So the implementation of property access could
> be expected to return null, because that is what is specified for
> item,
If, and whenever, the property name qualified as an "integer index".
> however implementations return undefined.
Yes, or throw exceptions.
>> It would be possible to argue about the nature of "integer index"
>> in that context, for example asserting that a number is only an
>> "index" if it indexes something in the collection; that there is
>> no such thing as an 'out of bounds index' because an 'out of
>> bounds number' is not an "index" (it does not "index" anything
>> (anything that exists)). I don't recall anyone trying that line
>> but I can see how it could be argued. However, that promptly
>> lets IE off the hook for throwing exceptions with - object[0]
>> - as then - 0 - has stopped qualifying as an "index" and the
>> behaviour of - object[0] -, where - object - is an empty
>> collection, becomes unspecified (and so as with other host object,
>> exception throwing is allowed).
>>
>
> I think the intent of the specification is clear enough about the
> item method with:-
>| Returns:
>| The style sheet at the index position in the StyleSheetList,
>| or null if that is not a valid index.
Yes, but property accessors are only supposed to be equivalent to -
item - calls _if_ the property name is an "integer index". And the
specification for - item - does (and could not) throw any light on what
being an "integer index" means.
>>> javascript: alert(document.styleSheets.item(999999))
>>> "null" in Safari, Firefox, Opera.
>>
>> Which is irrelevant in context.
>
> It shows that other implementation follows the specification
> of returning null for the item method when parameter |index|
> is out of bounds (e.g. outside the range of valid child
> stylesheet indices is 0 to length-1 inclusive).
Did anyone say they didn't? But what this thread has been dealing with
is property accessor use, which is a far less well-specified area.
>>> These browsers do not return undefined for an 'out of bounds'
>>> index.
>>
>> But they fail to be "equivalent" with -
>> alert(document.styleSheets[999999]) -.
>>
>>> However, the item() method in IE throws the same error when
>>> the index is out of range:-
>>> javascript: alert( document.styleSheets.item(999999) )
>>
>> Now that is "equivalent", just not what the W3C spec asks for
>> (assuming a particular interpretation of "integer index").
>> IE doesn't claim to
>
> Square bracket notation is noted to be equivalent to item,
> not the other way around.
Equivalence is not normally considered to be asymmetrical, sequential or
directional.
When they are specified as being equivalent they should be (totally
equivalent, including returning null), the problem is that they are not
required to be equivalent under all circumstances. You have to pin down
the boundaries of those circumstances before any failure to be
equivalent can be judged in terms of its relevance to DOM conformance.
> The item method is specified.
Giving a specification for a sub-set of property accessor use, where the
size/scope of that subset hinges on the interoperation of "integer
index".
>[...]
>
>> (Observe the 'Note', and that all other ECMAScript biddings
>> for - item - and - nameditem - methods in the W3C DOM specs
>> have similar notes.)
>>
>>> The w3c did not define a generalized "collection" interface.
>>> Such design would seem to avoid w3c specification shotgun
>>> surgery.
>>
>> Is that supposed to mean something?
>
> That same note is used to describe various dom collections.
Pretty much word-for word.
> If they end up having to change that note in one place, they have
> to change it everywhere.
Or provide a single unambiguous definition of what they mean by "integer
index" in those contexts.
> That is shotgun surgery.
Is it? That is not a term that I have noticed used in British English so
I will have to take your word for it.
Richard.
Richard Cornford
> dhtml wrote:
<snip>
>> In this case, it should return null. Even by MSDN documentation,
>> which states:-
>>| Returns an object or a collection of objects if successful,
>>| or null otherwise.
>
> Right, so Microsoft have a bug (in their code or their
> documentation), but that is hardly unexpected.
Looking at the MSDN documentation on - styleSheets - for myself turned
up this in relation to the - item - method:-
<URL: http://msdn.microsoft.com/en-us/library/ms536461(VS.85).aspx >
| Remarks
| Windows Internet Explorer 7 and later. If given a string
| that is not a numeric index, this method throws an error
| if no id property with that string value is found.
- which states that an error will be thrown under some circumstances.
Clearly the text that says the method returns an object or null is not
intended to be exhaustive.
Richard.
David Mark
wrote:
> Richard Cornford wrote:
> > dhtml wrote:
> <snip>
> >> In this case, it should return null. Even by MSDN documentation,
> >> which states:-
> >>| Returns an object or a collection of objects if successful,
> >>| or null otherwise.
>
> > Right, so Microsoft have a bug (in their code or their
> > documentation), but that is hardly unexpected.
>
> Looking at the MSDN documentation on - styleSheets - for myself turned
> up this in relation to the - item - method:-
>
> <URL:http://msdn.microsoft.com/en-us/library/ms536461(VS.85).aspx>
>
> | Remarks
> | Windows Internet Explorer 7 and later. If given a string
> | that is not a numeric index, this method throws an error
> | if no id property with that string value is found.
So, as with other ActiveX properties that throw exceptions on [[Get]],
this is not a bug. Probably gone largely unnoticed as it would take
some stupendously foolish code to use an out-of-range index with a
host object.
Of course, jQuery's - each - method was probably not designed to trip
over the rock with the "bug" under it, but the bizarre body-less - for
- loop was opaque enough to shield the defect from recent scrutiny by
its authors. They thought they saw a bug and that's likely where it
would have stood.
Now that this has been clarified here, it will be interesting to see
how many months it takes to get fixed in jQuery. I think it was
around 6 to fix the typeof xyz = 'array' in another bowel-level
function (toArray I think.) Another 6 after that to get rid of the
browser sniffing (sort of.) Of course, it will take an infinite
amount of time to fix the overloading nonsense.
The list of "supported browsers" (at least one configuration of each
anyway), keeps getting shorter (and the code keeps getting longer.)
Now Resig wants a million monkeys to send bug reports every time a
change is submitted. These are not the strategies of a man confident
in his abilities.
I've heard that jQuery "just works" from Web developers. Like most
mechanically recited marketing mumbo-jumbo, it is zippy but
inaccurate. From the looks of it, jQuery "doesn't work, has never
worked or even come close to working, might appear to work in some
cases for some browsers, contains lots of bugs, is subject to change
at any time, is not recommended for use, but can always be improved."
That should be followed by a disclaimer that the author has a terrible
track record with regard to Javascript, browser scripting and
programming in general And, of course, bugs submitted to the support
forum have little chance of being fixed (or even being understood.) I
think that's fair (but I guess it won't fit on a T-shirt.)
Garrett Smith
> dhtml wrote:
>> On Mar 27, 3:12 pm, Richard Cornford wrote:
>>> Garrett Smith wrote:
>>>> Richard Cornford wrote:
>>>>> Danny wrote:
[...]
>
> As we have already established beyond and reasonable doubt that - value
> = object[0] - causes an exception to be thrown when - object - is an
> empty styleSheets collection, and having observed the (conditional)
> 'equivalence' between property accessors and calls to the collection's -
> item - method, - object.item(0) - throwing the same exception is
> entirely "to be expected".
>
>> In this case, it should return null. Even by MSDN documentation,
>> which states:-
>> | Returns an object or a collection of objects if successful,
>> | or null otherwise.
>
> Right, so Microsoft have a bug (in their code or their documentation),
> but that is hardly unexpected.
>
Not uncommon. I try to hold the software vendor to the expectation that
their documentation of their software be correct, even if it is often
incorrect. So, I sort of "expect" that, even though I know it is often
not that case.
[...]
>
>>>> The error occurs whether by property access, by calling the
>>>> item method,
>>>
>>> The two are specified as being equivalent for some property
>>> names/arguments, so no real surprise there.
>>>
>>
>> And the item method is specified as having a very clear behavior:-
>> | Return Value
>> |
>> | StyleSheet
>> |
>> | The style sheet at the index position in the StyleSheetList,
>> | or null if that is not a valid index.
>
> Yes, but a property accessor is only specified as being equivalent if
> the property name is an "integer index", so the behaviour of property
> accesses where the property name is not an "integer index" is not
> specified. Thus the throwing of exceptions is allowed with the use of
> some property accessors (as only ECMA 262 apples in those case), and it
> becomes important to determine what an "integer index" means.
>
The parameter name is |index|. When they say "integer index", they
probably should have instead used just |index|. Integer could be
replaced with "dom unsigned long". That is, an unsigned integer type
that has values in the range [0, 4294967295].
This index would be provided as a string for property access. If a
string is not used, the value is converted to a string value (the
property access operator requires that). For example, styleSheets[1]
converts to styleSheets["1"], styleSheets[NaN] converts to
styleSheets["NaN"].
IE identifies identifies floating point numbers as "integers", too (see
below). But then Gecko and AppleWebKit do too, but only when using the
item method. This may be to copy IE to support poorly coded sites (guess).
>>>> The w3c does not define a standard "collection" interface with
>>>> an item method. IE documents its item method as being something
>>>> that operates on "various collections". This is fine. What is
>>>> not fine is IE's design and testing.
>>>
>>> Not really. IE had - item - methods on its collections long before
>>> there were W3C DOM standards. That makes it difficult to assert
>>> that anything they do is wrong, except where it disagrees with
>>> Microsoft's own documentation of what they are supposed to do.
>>> If blame is to be
>>
>> That is the problem.
>
> It is _a_ problem, or rather it is a potential problem (as it really
> isn't that difficult to work with styleSheets collections in a way that
> does not provoke any issues, suggesting that practical issue here was
> introduced by something outside of IE and the W3C standards).
>
The out-of-bounds problem does not normally occur. I found the behavior
of IE's item method more interesting than the fact of a logical mistake
in jQuery.
IE's item method is designed to work on a "map" type collection, a
"list" type collection, or one of IE's Map/List hybrid collections. It
returns a node, a collection, null, or throws an error.
We can test this method on a childNodes collection (a hybrid collection
in IE). The results show that the documentation is wrong and that the
behavior is unstable.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en" >
<head>
<title>childNodes.item() test</title>
</head>
<body>
<pre id="a">
<script type="text/javascript">
var childNodes = document.body.childNodes;
try{
document.write('childNodes.item(0): ');
document.writeln( childNodes.item(0));
document.write('childNodes.item("a"): ');
document.writeln( childNodes.item("a") );
document.write('childNodes.item("xxx"): ');
document.writeln(childNodes.item("xxx") );
document.write('childNodes.item("0.2"): ');
document.writeln(childNodes.item("0.2"));
document.write('childNodes.item(1): ');
document.writeln(childNodes.item(1));
document.write('childNodes.item(999): ');
document.writeln(childNodes.item(999));
} catch(ex) {
document.writeln(ex.name + ": " + ex.message);
}
</script>
</pre>
</body>
</html>
(Only the first and last calls to childNodes.item are per w3c standard.)
Results:
IE6:
childNodes.item(0): [object]
childNodes.item("a"): [object]
childNodes.item("xxx"): [object]
childNodes.item("0.2"): [object]
childNodes.item(1): TypeError: Invalid procedure call or argument
Safari 4.0 (528.16), Firefox 3.0.7, Google Chrome:
childNodes.item(0): [object Text]
childNodes.item("a"): [object Text]
childNodes.item("xxx"): [object Text]
childNodes.item("0.2"): [object Text]
childNodes.item(1): [object HTMLPreElement]
Opera 9.6:
childNodes.item(0): [object Text]
childNodes.item("a"): [object HTMLPreElement]
childNodes.item("xxx"): null
childNodes.item("0.2"): null
childNodes.item(1): [object HTMLPreElement
>> Well, part of the problem. The item method
>> doesn't do in IE what MSDN says it does.
>
> Apparently not, and that is a bug (which Microsoft will probably fix if
> it is brought to their attention, though they may just fix the
> documentation).
>
>> Instead, it throws an error (sometimes). It does not check the
>> type of the first argument. Instead, it tries to convert it to a
>> number. Look:-
>>
>> javascript: alert(document.body.childNodes.item( "XXX").nodeName );
>> javascript: alert(document.body.childNodes.item(""))
>>
>> - returns the first element in the document. In IE6, anyway.
>
> Type-converting arguments is a very javascript-like thing to be doing. I
> don't think anyone would reasonable complain about that, as it should be
> the responsibility of the javascript programmer to ensure they are
> passing the right types of values into function/method calls (that is
> one of disciplines that goes with using a loosely type language).
>
Type converting arguments may be javascript-like, but type converting
"XXX" is totally not javascript-like.
Taking that result of said conversion and applying it to get an item out
of a list is absurd.
What is worse is that Gecko mimics that behavior (sort of). Gecko
returns the first Node, however, not the first element. Since Gecko
recognizes text nodes, it returns the first text node. AppleWebKit
mimics this behavior also. Opera takes a more sane option of returning
null.
Now we have MSIE going and trying to change that behavior with:-
| Windows Internet Explorer 7 and later. If given a string that is not a
| numeric index, this method throws an error if no id property with that
| string value is found.
[...]
>
>> It doesn't even seem to b
>> callable, as:-
>>
>> typeof childNodes.item
>>
>> - is "string" in IE.
>
> Mad as that may be it has been there since IE4 to my certain knowledge,
> and has gone sufficiently unnoticed over that time as to suggest it
> isn't really an issue.
>
>> Feature tests would not identify "item" as something that can
>> be called.
>
> No feature test has ever been devised that will accurately determine the
> capability of host method.
>
Thomas and David's "isHostMethod" (which I do not use) would return
false in that case.
>>>
>>
>> I think the intent of the specification is clear enough about the
>> item method with:-
>> | Returns:
>> | The style sheet at the index position in the StyleSheetList,
>> | or null if that is not a valid index.
>
> Yes, but property accessors are only supposed to be equivalent to - item
> - calls _if_ the property name is an "integer index". And the
> specification for - item - does (and could not) throw any light on what
> being an "integer index" means.
>
Property access would have to convert the expression to a string value,
so childNodes[0] would be interpreted to childNodes["0"].
>>
>> Square bracket notation is noted to be equivalent to item,
>> not the other way around.
>
> Equivalence is not normally considered to be asymmetrical, sequential or
> directional.
>
> When they are specified as being equivalent they should be (totally
> equivalent, including returning null), the problem is that they are not
> required to be equivalent under all circumstances. You have to pin down
> the boundaries of those circumstances before any failure to be
> equivalent can be judged in terms of its relevance to DOM conformance.
>
I suppose null and undefined are equivalent in some way, too (null ==
undefined).
[...]
>
>> If they end up having to change that note in one place, they have
>> to change it everywhere.
>
> Or provide a single unambiguous definition of what they mean by "integer
> index" in those contexts.
>
>> That is shotgun surgery.
>
> Is it? That is not a term that I have noticed used in British English so
> I will have to take your word for it.
>
http://en.wikipedia.org/wiki/Shotgun_surgery
| Shotgun surgery is an antipattern in software development and occurs
| where a developer adds features to an application codebase which span
| a multiplicity of implementors or implementations in a single change.
| This is common practice in many programming scenarios as a great
| amount of programming effort is usually expended on adding new
| features to increase the value of programming assets. As a consequence
| these new features may require adding code in several places
| simultaneously where the code itself looks very similar, and may only
| have slight variations.
The side effect is that the next specification will replace DOM 2
entirely. It will probably use IndexGetter, which states that objects
have numbered properties.
Garrett
David Mark
> Richard Cornford wrote:
> > dhtml wrote:
> >> On Mar 27, 3:12 pm, Richard Cornford wrote:
> >>> Garrett Smith wrote:
> >>>> Richard Cornford wrote:
> >>>>> Danny wrote:
>
> [...]
>
>
>
> > As we have already established beyond and reasonable doubt that - value
> > = object[0] - causes an exception to be thrown when - object - is an
> > empty styleSheets collection, and having observed the (conditional)
> > 'equivalence' between property accessors and calls to the collection's -
> > item - method, - object.item(0) - throwing the same exception is
> > entirely "to be expected".
>
> >> In this case, it should return null. Even by MSDN documentation,
> >> which states:-
> >> | Returns an object or a collection of objects if successful,
> >> | or null otherwise.
>
> > Right, so Microsoft have a bug (in their code or their documentation),
> > but that is hardly unexpected.
>
> Not uncommon. I try to hold the software vendor to the expectation that
> their documentation of their software be correct, even if it is often
> incorrect. So, I sort of "expect" that, even though I know it is often
> not that case.
Richard noted in a later post that according to other MS
documentation, the behavior is unexpected.
No.
Explicitly allowed.
It is true enough that this is the first documented case in ten years
of a host method that fails the isHostMethod test. Likely never came
up as nobody would test this method. Though perfectly allowed for
host objects, I think the "string" result should be reported to MS as
a bug.
I wouldn't throw the baby out with the bath water though. Using the -
in - operator alone fails in far more places as it tells you nothing
about the property. You have to have a central function anyway as you
never know how the rules will change from one year to the next.
Granted, it had been a decade of mind-numbing monotony on that front
until this find. The fix for isHostMethod is simple: document this
one known deviation.
[snip]
Garrett Smith
Other documentation specifically about styleSheets collection.
>> Results:
>> IE6:
>> childNodes.item(0): [object]
>> childNodes.item("a"): [object]
>> childNodes.item("xxx"): [object]
>> childNodes.item("0.2"): [object]
>> childNodes.item(1): TypeError: Invalid procedure call or argument
>
> Explicitly allowed.
>
What is? The error isn't. Not even by MS documentation.
[...]
>>> No feature test has ever been devised that will accurately determine the
>>> capability of host method.
>> Thomas and David's "isHostMethod" (which I do not use) would return
>> false in that case.
>
> It is true enough that this is the first documented case in ten years
> of a host method that fails the isHostMethod test. Likely never came
> up as nobody would test this method. Though perfectly allowed for
> host objects, I think the "string" result should be reported to MS as
> a bug.
>
It has been discussed here and on microsoft.public.scripting.jscript.
> I wouldn't throw the baby out with the bath water though. Using the -
> in - operator alone fails in far more places as it tells you nothing
> about the property. You have to have a central function anyway as you
> never know how the rules will change from one year to the next.
> Granted, it had been a decade of mind-numbing monotony on that front
> until this find. The fix for isHostMethod is simple: document this
> one known deviation.
>
Changes to such a centralized method would require retesting everything
(the entire library and anything else that depends on it). There may be
places where |in| is not suitable, but there are plenty of places where
it is sufficient. If there is a place where it is not sufficient, such
as index in styleSheetList, then that can be replaced by something more
sensible, such as a check to index < styleSheetList.length.
Such design strategies are not just something I "have to have", they are
something I try to avoid.
I found this about a year ago. A related observation was posted much
earlier here:-
http://groups.google.com/group/microsoft.public.scripting.jscript/browse_thread/thread/a2e1e8260830df53/b800def9feb3318f?lnk=gst&q=typeof+item+string+#b800def9feb3318f
Garrett
David Mark
Yes, which clarified that the styleSheets collection documentation did
not contradict the behavior after all (behavior that is explicitly
allowed for host objects in any browser.)
>
> >> Results:
> >> IE6:
> >> childNodes.item(0): [object]
> >> childNodes.item("a"): [object]
> >> childNodes.item("xxx"): [object]
> >> childNodes.item("0.2"): [object]
> >> childNodes.item(1): TypeError: Invalid procedure call or argument
>
> > Explicitly allowed.
>
> What is? The error isn't. Not even by MS documentation.
Microsoft doesn't say it is not allowed.
>
> [...]
>
> >>> No feature test has ever been devised that will accurately determine the
> >>> capability of host method.
> >> Thomas and David's "isHostMethod" (which I do not use) would return
> >> false in that case.
>
> > It is true enough that this is the first documented case in ten years
> > of a host method that fails the isHostMethod test. Likely never came
> > up as nobody would test this method. Though perfectly allowed for
> > host objects, I think the "string" result should be reported to MS as
> > a bug.
>
> It has been discussed here and on microsoft.public.scripting.jscript.
Yes, but did anyone think to tell MS. They don't read their own
groups either.
>
> > I wouldn't throw the baby out with the bath water though. Using the -
> > in - operator alone fails in far more places as it tells you nothing
> > about the property. You have to have a central function anyway as you
> > never know how the rules will change from one year to the next.
> > Granted, it had been a decade of mind-numbing monotony on that front
> > until this find. The fix for isHostMethod is simple: document this
> > one known deviation.
>
> Changes to such a centralized method would require retesting everything
> (the entire library and anything else that depends on it). There may be
Of course. Care must be taken. Good thing this function hasn't
change since its inception and survives this latest "find" (as Richard
pointed out, the anomaly has been known since IE4.)
> places where |in| is not suitable, but there are plenty of places where
> it is sufficient. If there is a place where it is not sufficient, such
> as index in styleSheetList, then that can be replaced by something more
> sensible, such as a check to index < styleSheetList.length.
I don't see where - in - alone is every going to tell you anything
about a property (other than it exists.) The typeof operator can give
clues about host objects' intentions. IE's "unknown" type means
"don't tread on me." Knowing that could have saved trouble in 1999
with Mac IE and navigator.mimeTypes (the first time I tripped over an
unknown type) as it could today with the style sheets collection. As
you demonstrated, the - in - operator alone could not have saved any
grief as its results just don't shed any light. Another example is
the "undefined" document.all, which is clearly waving off usage.
Would you really try to call that because it is - in - the document
object? I know we talked about a few others recently.
>
> Such design strategies are not just something I "have to have", they are
> something I try to avoid.
I wouldn't. Though the pattern has been largely unchanged since IE4,
specific properties have changed type from one version to another.
For instance, things that did not blow up in IE6 turned into "unknown"
types in IE7. If I had to predict one operation that will never blow
up in any future version of IE, it would be typeof.
[snip]
Matt Kruse
> I've heard that jQuery "just works" from Web developers.
> From the looks of it, jQuery "doesn't work, has never
> worked or even come close to working
It has always worked for everything I've used it for. That pretty much
proves your statement wrong.
> might appear to work in some
> cases for some browsers
I would say it does work for almost all cases (certainly common ones)
in almost all of the browsers typically used on the Internet. I think
it's unfair to imply that it fails with common cases in many browsers.
The truth is, most jQuery developers will never encounter a problem
with it. For a small percentage of people using incompatible browsers,
or for people who are doing things outside the normal operations that
most developers use it for, they may encounter real problems. There's
no denying that.
Your characterization of it always sounds like negative propaganda.
Since you have legitimate criticisms of the code and the design,
continually exaggerating your point only makes people roll their eyes.
> contains lots of bugs
Have you ever written software? (That is a rhetorical question).
I think all the software I've ever written has had bugs. Certainly the
stuff that is a collaborative effort.
Saying it contains lots of bugs is like saying it "contains lots of
numbers."
Matt Kruse
David Mark
> On Mar 27, 11:31 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > I've heard that jQuery "just works" from Web developers.
> > [...]
> > From the looks of it, jQuery "doesn't work, has never
> > worked or even come close to working
>
> It has always worked for everything I've used it for. That pretty much
> proves your statement wrong.
Hardly. It depends on your definition of "worked." Which version(s)
are you referring to? If you have deployed the browser sniffing
version(s), you had better revisit those sites with IE8. You do
understand that the UA string dictated how *attributes* were handled.
Those will be some mysterious bugs to track down. And as you know,
that is one of many problems.
>
> > might appear to work in some
> > cases for some browsers
>
> I would say it does work for almost all cases (certainly common ones)
> in almost all of the browsers typically used on the Internet. I think
I would say that is a ridiculous statement when applied to any version
of jQuery.
> it's unfair to imply that it fails with common cases in many browsers.
You can't get much more common than querying an attribute.
>
> The truth is, most jQuery developers will never encounter a problem
> with it.
Hard to quantify that, but I estimate you are wrong. Regardless, all
non-jQuery developers will avoid problems with it.
> For a small percentage of people using incompatible browsers,
That's a long list.
> or for people who are doing things outside the normal operations that
> most developers use it for, they may encounter real problems. There's
> no denying that.
Outside the normal operations of what?
>
> Your characterization of it always sounds like negative propaganda.
It is hardly a characterization. Your reaction sounds like a reboot.
> Since you have legitimate criticisms of the code and the design,
> continually exaggerating your point only makes people roll their eyes.
I'm not exaggerating.
>
> > contains lots of bugs
>
> Have you ever written software? (That is a rhetorical question).
> I think all the software I've ever written has had bugs.
If it used jQuery, it definitely had bugs. It comes with them (lots
of them.) No, we're not starting this discussion over.
> Certainly the
> stuff that is a collaborative effort.
I don't follow that.
> Saying it contains lots of bugs is like saying it "contains lots of
> numbers."
In some other language. Again, I think the record speaks for itself
on jQuery's bugs, past and present and indicates a pretty bleak future
in that regard. Those interested in more details should search the
archive (this one or jQuery's.)
David Mark
> On Mar 28, 6:38 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > On Mar 27, 11:31 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > I've heard that jQuery "just works" from Web developers.
> > > [...]
> > > From the looks of it, jQuery "doesn't work, has never
> > > worked or even come close to working
>
> > It has always worked for everything I've used it for. That pretty much
> > proves your statement wrong.
>
> Hardly. It depends on your definition of "worked." Which version(s)
> are you referring to? If you have deployed the browser sniffing
> version(s), you had better revisit those sites with IE8. You do
> understand that the UA string dictated how *attributes* were handled.
> Those will be some mysterious bugs to track down. And as you know,
> that is one of many problems.
>
>
>
> > > might appear to work in some
> > > cases for some browsers
>
> > I would say it does work for almost all cases (certainly common ones)
> > in almost all of the browsers typically used on the Internet. I think
>
> I would say that is a ridiculous statement when applied to any version
> of jQuery.
>
> > it's unfair to imply that it fails with common cases in many browsers.
>
> You can't get much more common than querying an attribute.
And, of course, I am referring to attributes the jQuery way (the attr
method.) In at least the previous version of jQuery (which is
currently all over the Web), it is used throughout the code and even
calls itself:
if ( msie && notxml && name == "style" )
return jQuery.attr( elem.style, "cssText", value );
It isn't just for elements either. :)
if ( set )
// convert the value to a string (all browsers do this but IE) see
#1070
elem.setAttribute( name, "" + value );
if ( msie && special && notxml )
return elem.getAttribute( name, 2 );
ISTM that get/setAttribute is virtually never needed and is ill-
advised due to IE's longstanding broken design. So now IE is only
partially broken (attributes work more or less as expected in IE8
mode) and thousands of Websites are still running this function on a
constant basis. One of many examples, most pointed out to John Resig
over a year back.
[snip]
David Mark
And not to beat a (soon to be) dead horse, but out of curiosity I
looked at the attr method in 1.3.2. Looking at the two side by side
makes it clear that upgrading will be a major pain for many sites. It
isn't that the new attr method has changed significantly, just enough
to cause obscure compatibility problems with prior versions.
It is hard to think of a more critical function and even harder to
imagine such an inept implementation. It's primary purpose is to get
and set attributes, purportedly for HTML and XML elements alike.
Problem #1 is that it doesn't always do that. Sometimes it gets and
sets DOM properties. This is the test from 1.3.2, but is roughly the
same as in 1.2.5 (at first glance.)
// If applicable, access the attribute via the DOM 0 way
if ( name in elem && notxml && !special ) {
So if this is true, the attr method will not use the get/setAttribute
methods at all, it will get/set DOM properties.
Here is name:
// Try to normalize/fix the name
name = notxml && jQuery.props[ name ] || name;
Unfortunately, this is assigned before the above test and jQuery.props
is a "black list" of attributes to convert into property names. Even
worse, the list is incomplete and varies slightly from 1.2x to 1.3x.
So depending on the attribute, the test for name in elem can be
affected by:
1. Element type
2. Browser
3. jQuery version
What is special?
var special = /href|src|style/.test( name );
This is the same (and incomplete) in both versions.
So under some strange and shifting circumstances, jQuery will get and
set properties, rather than attributes.
Evidently values passed for sets are not required to be strings as
that wouldn't fly for the many properties that are not strings.
That means that in the circumstances where it falls through to this:
if ( set )
// convert the value to a string (all browsers do this but IE) see
#1070
elem.setAttribute( name, "" + value );
We may have the wrong name and/or the wrong value. And IE < 8
(including IE8 in legacy modes) should never get here (setAttribute is
broken as designed.)
Getting will certainly be problematic as well. Passing "rowspan" for
a TD will return a string or null in FF, a number or null in IE7 and a
string or null in IE8. Same for "colspan."
Oops, that's in jQuery 1.2x. In 1.3x, the "rowspan" case changes
slightly to return numbers (never null) for every browser, but
"colspan" is the same (will probably catch up in a later version.)
Don't even bother with event handler attributes as they have similarly
inconsistent results across browsers and circumstances.
I think the only thing clear about this muddle is that this is a very
bad way to query attributes. The code and everything built on top of
it is tangling up attributes and properties in a way that serves
absolutely no benefit and is very likely to lead to obscure bugs and
misunderstandings (just look at Resig's own comments.)
Those have got to be some really lousy unit tests. Perfectly apt for
such a lousy piece of software. It's not just the bugs and the
seemingly unending apathy, but nobody needed an attribute wrapper in
the first place (certainly not one like this.)
David Mark
[snip]
>
> Those have got to be some really lousy unit tests.
[snip]
Documentation too. From the 1.3 explanation of the attr method:
"Access a property on the first matched element. This method makes it
easy to retrieve a property value from the first matched element. If
the element does not have an attribute with such a name, undefined is
returned. Attributes include title, alt, src, href, width, style,
etc."
That's not what it does (not even in general terms.) It does mirror
the misconception that attributes and properties are the same thing.
And what is the expected return value (other than undefined?)
How to set a property in Javascript:
el.className = 'myclass';
How to set the same property in jQuery:
$(el).attr('class', 'myclass');
The latter is less clear, less concise, far slower, completely
inefficient and the behavior is undocumented (until yesterday.)
How about this one:
el.rowSpan = 3;
Now, in ten pages or less, explain what this one does:
$(el).attr('rowspan', 3);
Bonus questions:
$(el).attr('onclick', 'alert("test")');
$(el).attr('disabled', true);
So next time somebody tells you to learn jQuery as it makes Javascript
much simpler and smooths out the differences between browsers, give
them this test. Even in a hypothetical environment with one browser
and one configuration, these are complicated issues in jQuery (that
nobody seems to grasp, not even its authors.)
On the opposite end of the spectrum, setting properties of DOM nodes
couldn't be simpler in Javascript. You do, of course, need to know
that "class" cannot be a property name so "className" is used instead
(same for "for" and "htmlFor.") Additionally, DOM property names use
camel-case. That's about it as most apps don't need to deal with
attributes directly.
You clearly do not need John Resig's ridiculous attr method to shield
you from this. On the contrary, his abstraction is not only confused
but incomplete (not to mention a moving target.)
So tally up the simple, concise, elegant, well-supported and well-
documented arguments and you get 0. Doesn't save time either. Look
at all of the sites using jQuery 1.2x (and realize that many of them
deployed jQuery *after* these problems came to light.) What do they
do now? Upgrade? What if something breaks? See the previous few
posts for a partial road map (for one of the issues.) Gives me
headaches just *thinking* about it and I have never deployed jQuery
anywhere.
Can anyone (sane) recommend for the uninitiated to adopt jQuery 1.3x?
Perhaps there is a sentiment that Resig finally got it right this
time, but we know that is not true either (and the design isn't worth
getting "right" anyway.) Anyone who has recommended it in the past
should admit at this point that it was foolish advice.
Garrett Smith
They do document a certain behavior:-
| Return Value
|
| Returns an object or a collection of objects if successful,
| otherwise null.
>> [...]
>>
>>>>> No feature test has ever been devised that will accurately determine the
>>>>> capability of host method.
>>>> Thomas and David's "isHostMethod" (which I do not use) would return
>>>> false in that case.
>>> It is true enough that this is the first documented case in ten years
>>> of a host method that fails the isHostMethod test. Likely never came
>>> up as nobody would test this method. Though perfectly allowed for
>>> host objects, I think the "string" result should be reported to MS as
>>> a bug.
>> It has been discussed here and on microsoft.public.scripting.jscript.
>
> Yes, but did anyone think to tell MS. They don't read their own
> groups either.
>
A bug should be filed on connect.microsoft.com.
>
> I don't see where - in - alone is every going to tell you anything
> about a property (other than it exists.) The typeof operator can give
> clues about host objects' intentions. IE's "unknown" type means
> "don't tread on me." Knowing that could have saved trouble in 1999
> with Mac IE and navigator.mimeTypes (the first time I tripped over an
> unknown type) as it could today with the style sheets collection. As
> you demonstrated, the - in - operator alone could not have saved any
> grief as its results just don't shed any light. Another example is
Yes, interesting case here.
> the "undefined" document.all, which is clearly waving off usage.
> Would you really try to call that because it is - in - the document
> object? I know we talked about a few others recently.
>
document.all belongs in the "don't do that" category.
David Mark
A bit vague. My basic point is that host objects are allowed to throw
exceptions and it isn't clear from Microsoft's documentation whether
this childNodes exception is intentional or not.
>
>
>
> >> [...]
>
> >>>>> No feature test has ever been devised that will accurately determine the
> >>>>> capability of host method.
> >>>> Thomas and David's "isHostMethod" (which I do not use) would return
> >>>> false in that case.
> >>> It is true enough that this is the first documented case in ten years
> >>> of a host method that fails the isHostMethod test. Likely never came
> >>> up as nobody would test this method. Though perfectly allowed for
> >>> host objects, I think the "string" result should be reported to MS as
> >>> a bug.
> >> It has been discussed here and on microsoft.public.scripting.jscript.
>
> > Yes, but did anyone think to tell MS. They don't read their own
> > groups either.
>
> A bug should be filed on connect.microsoft.com.
I agree on the item method "string" result.
>
>
>
> > I don't see where - in - alone is every going to tell you anything
> > about a property (other than it exists.) The typeof operator can give
> > clues about host objects' intentions. IE's "unknown" type means
> > "don't tread on me." Knowing that could have saved trouble in 1999
> > with Mac IE and navigator.mimeTypes (the first time I tripped over an
> > unknown type) as it could today with the style sheets collection. As
> > you demonstrated, the - in - operator alone could not have saved any
> > grief as its results just don't shed any light. Another example is
>
> Yes, interesting case here.
>
> > the "undefined" document.all, which is clearly waving off usage.
> > Would you really try to call that because it is - in - the document
> > object? I know we talked about a few others recently.
>
> document.all belongs in the "don't do that" category.
Certainly not the most practical example. Same for testing the item
method. Both show that nothing is infallible when it comes to host
objects.
kangax
[...]
> A bug should be filed on connect.microsoft.com.
Their bug tracker is broken. I couldn't submit a bug (which was crashing
the entire browser) when RC1 came out - there would be an error on a
page once I logged in and tried viewing any ticket or creating a new
one. I could still view tickets when logged out but not able to comment,
rate, etc.
Other people I know had the same problems.
[...]
--
kangax
Garrett Smith
ECMA says that childNodes.item() should result in getting the item
property off childNodes and calling its [[Call]] property. What the
[[Call]] property does when called is up to the implementation.
In this case, it the implementation is MSIE and Microsoft provides
documentation, cited above. I think it is clear that if |item| is
unsuccessful, that null should be returned.
What IE does and what MSDN says IE will do are not the same.
javascript: alert(document.childNodes.item(99999))
- will trigger the error, while:-
javascript: alert(document.childNodes[99999])
- results in undefined.
Remarks on the general "item" page state:-
http://msdn.microsoft.com/en-us/library/ms536460(VS.85).aspx
| Internet Explorer 8 and later. In IE8 mode, the iSubindex parameter
| is not used. For more information, see Defining Document
| Compatibility.
|
| The item method cannot retrieve input type=image elements from a
| form. To access all elements contained in a form, use the children
| collection.
The documentation for childNodes.item is different:-
http://msdn.microsoft.com/en-us/library/ms536609(VS.85).aspx
| Syntax
|
| oItem = object.item(vIndex)
|
| Parameters
|
| vIndex Required. An Integer that specifies the zero-based index
| of the item to get.
IE has similiar collection-like behavior on the callable childNodes or
children collections.
What childNodes.item does is different than what should happen in any
the two applicable pieces of documentation (the general one or the one
specifically for "childNodes").
The design of this API would seem to be that the item method for a
childNodes collection would "override" the general item method.
However, the more specific childNodes item is documented as different
number of parameters. There is no mention of typechecking on the first
parameter. It says nothing about the general item method.
Is the general item method will be used if more than one parameter is
supplied to childNodes.item? MSDN does not say. We could try to draw an
inference by looking at the implementation and by looking at other
implementations.
The Remarks on the styleSheets item page states:-
http://msdn.microsoft.com/en-us/library/ms536461(VS.85).aspx
| Windows Internet Explorer 7 and later. If given a string that is
| not a numeric index, this method throws an error if no id property
| with that string value is found.
If there is a general collection-type of object that |item| can be used
on, the various implementations violate LSP (aside from the little fact
that it *doesn't work* like the documentation states).
Microsoft's |item| method suffers from poor design and testing. The
childNodes example I posted earlier in this thread (not even close to
complete) showed that the implementation is inconsistent with MSDN
documentation.
The design of overriding a general item method with specific item
methods where the specific methods are documented to have different
number of parameters and different behavior (throwing errors) blatantly
violates LSP.
The w3c decision to half-adopt/half-change such a poorly designed, error
prone, and inconsistent item method, that already had existing pages
depending on it, and try to standardize was of very poor judgement.
It would not be that hard to recognize the problems and come up with an
alternative method name.
>
>>
>>
>>> I don't see where - in - alone is every going to tell you anything
>>> about a property (other than it exists.) The typeof operator can give
>>> clues about host objects' intentions. IE's "unknown" type means
>>> "don't tread on me." Knowing that could have saved trouble in 1999
>>> with Mac IE and navigator.mimeTypes (the first time I tripped over an
>>> unknown type) as it could today with the style sheets collection. As
>>> you demonstrated, the - in - operator alone could not have saved any
>>> grief as its results just don't shed any light. Another example is
>> Yes, interesting case here.
>>
>>> the "undefined" document.all, which is clearly waving off usage.
>>> Would you really try to call that because it is - in - the document
>>> object? I know we talked about a few others recently.
>> document.all belongs in the "don't do that" category.
>
> Certainly not the most practical example. Same for testing the item
> method. Both show that nothing is infallible when it comes to host
> objects.
Might be a good idea to avoid general purpose solutions that involve
host objects.
It would be nice if host objects would have more predictable behavior.
If the w3c decides to recognize the problems with half-assed adopting
broken garbage that browser vendors implemented... Ah wishful thinking.
Garrett
Garrett Smith
ECMA says that childNodes.item() should result in getting the item
javascript: alert(document.childNodes.item(99999))
javascript: alert(document.childNodes[99999])
- results in undefined.
| Windows Internet Explorer 7 and later. If given a string that is
| not a numeric index, this method throws an error if no id property
| with that string value is found.
If there is a general collection-type of object that |item| can be used
on, the various implementations violate LSP (aside from the little fact
that it *doesn't work* like the documentation states).
Microsoft's |item| method suffers from poor design and testing. The
childNodes example I posted earlier in this thread (not even close to
complete) showed that the implementation is inconsistent with MSDN
documentation.
The design of overriding a general item method with specific item
methods where the specific methods are documented to have different
number of parameters and different behavior (throwing errors) blatantly
violates LSP.
The w3c decision to half-adopt/half-change such a poorly designed, error
prone, and inconsistent item method, that already had existing pages
depending on it, and try to standardize was of very poor judgement.
It would not be that hard to recognize the problems and come up with an
alternative method name.
>
>>
>>
>>> I don't see where - in - alone is every going to tell you anything
>>> about a property (other than it exists.) The typeof operator can give
>>> clues about host objects' intentions. IE's "unknown" type means
>>> "don't tread on me." Knowing that could have saved trouble in 1999
>>> with Mac IE and navigator.mimeTypes (the first time I tripped over an
>>> unknown type) as it could today with the style sheets collection. As
>>> you demonstrated, the - in - operator alone could not have saved any
>>> grief as its results just don't shed any light. Another example is
>> Yes, interesting case here.
>>
>>> the "undefined" document.all, which is clearly waving off usage.
>>> Would you really try to call that because it is - in - the document
>>> object? I know we talked about a few others recently.
>> document.all belongs in the "don't do that" category.
>
> Certainly not the most practical example. Same for testing the item
> method. Both show that nothing is infallible when it comes to host
> objects.
Might be a good idea to avoid general purpose solutions that involve