Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > YUI--doomed?

Reply
Thread Tools

YUI--doomed?

 
 
David Mark
Guest
Posts: n/a
 
      05-22-2010
http://github.com/yui/yui3/commit/a3...424c16d#diff-0

1076 1076
1077 1077 hasMethod: function(method) {
1078 1078 var node = this._node;
1079 - return !!(node && method in node && node[method].apply);
1079 + return !!(node && method in node &&
1080 + (typeof node[method] === 'function' ||
1081 + String(node[method]).indexOf('function') ===
1)); // IE reports as object, prepends space

Passing a host object method to the String constructor. Are they
completely insane? One thing is for sure, they don't read this group
(or peruse my site).

http://www.cinsoft.net/host.html

" kangax added a note to a3b173f build/node/node-base-debug.js:L1081

May 14, 2010

String-converting host objects is known to blow up in IE, so this is not
a very good idea. Function decompilation is another thing that's best
avoided."

Good man.

" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081

May 15, 2010

Its not pretty, but it works in IE6 and isn't blowing up any test cases."

It most assuredly does _not_ work in IE6 (or any version of IE for that
matter). This is what happens when you program by observation. He's
looking for a failure case, instead of understanding the abstraction
which says: host objects can do whatever the hell they want. It's been
well-established (for about ten years) that typeof is the only safe way
to detect their methods. It's been written up here a thousand times.
Who on the planet that writes JS for a living hasn't heard of isHostMethod?

"Let me know if you have a failure case."

There it is. Show me where it fails. That's what the Dojo people say
over and over. If a lack of a failure case is your only justification
for your logic, then you don't understand cross-browser scripting at
all. Do these people ever think about what will happen tomorrow? The
whole point of things like YUI and Dojo is that they are supposedly
needed due to the ever-changing browsers, yet their authors will commit
anything that appears to work in _today's_ browsers (well, the four or
five they profess to "care" about). They don't seem to understand that
tomorrow's browsers may change. What sort of logic is that? And it's
not like they don't have an avalanche of broken browsers behind them to
serve as reminders. All I can figure is that they are all suffering
from mass hysteria and the developers who lean on them have just gotten
used to the endless failures. You sure don't have to show them where it
fails.

"Better yet, suggest a cleaner hasMethod test."

Why bother? I know what will come of it. I suggested a cleaner Dojo.
Lots of similar blithering ensued and it never got used.

"This undocumented method will likely be marked deprecated in a future
release."

Great.

" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

5 days ago

Based on the change, you seem to have realized that host objects aren't
functions and don't have an apply method. Most realized that 5 years ago
or more. Where have you been?"

They've been working on YUI of course. Just gettin' stuff done in the
Real World (where host methods work like native functions and IE never
throws exception on type conversions).

"Converting host property object to string and parsing the string to see
what it looks like doesn't really provide indication for the capability
of that property.

when node is a form:
hasMethod("item")

And yes, string conversion of host object is known to blow up in IE,
even [[Get]] can cause unknown error. The in operator may provide
misleading results with catchall. For most consistent results, use typeof."

As hopefully any novice knows by now.

" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081

5 days ago

Thanks for the feedback."

I find that open source contributors usually go out of their way to be
polite. It's often all they've got. And it gives them an excuse to
dismiss criticism as rude by comparison (they want to get back to having
fun again).

"If you're assertion is true ("For most consistent results, use typeof")
then you have nothing to worry about as IE should never reach the OR
condition that converts to string."

Oh brother. If? And, once again, today's observations alone are enough
to go by (until tomorrow of course). Don't attempt to understand
anything, just watch the browsers and adjust to suit. Of course, in
this case, the observations are demonstrably faulty _today_ (as well as
ten years ago). And this is a "major" library with tons of widgets
stacked on top of it, published by a behemoth enterprise (Yahoo!)

"Unfortunately, that is consistently wrong, as typeof on a host object
in IE is "object"."

That's not "wrong". What is wrong is the design of the "soon to be
deprecated" function. Welcome to 2001, er 2010.

"As mentioned, this undocumented method will be likely be deprecated."

So no need to fix it or learn anything from its failings.

"However, I would love to be enlightened by those in the "know", so
please submit a use-case that makes YUI::Node:hasMethod blow up."

Show me where it fails. Show me where it fails. Show me where it
fails. Ugh. Even if it doesn't fail today, it may well fail tomorrow.
See all of those broken "degraded" browsers behind you? Best to
finally learn what you are doing.

And note the snide attempt at irony. That's typical. The more ignorant
they are, the quicker they resort to baiting. IIRC, Resig launched into
similar snipes almost instantly when I first reviewed his garbage (and
slowly but surely implemented most of the ideas I fed him).

" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

5 days ago

The typeof operator takes an operand and results in string; it is not
consistently wrong. typeof on a host object in IE is not consistently
"object". Try the example I provided in my last message. Again:
when node is a form:
hasMethod("item")

A program expecting MSIE to consistently result "object" for methods
will fail if the type is something other than object. The typeof
operator returns implementation dependent string for host object in ES3.

But carry on as you like."

And you know they will.

" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081

5 days ago

Thanks Garrett."



"The example you provide is exactly why this method is currently
undocumented, and why it will likely be deprecated."

That's three times now.

"Short of try/catching a call to the method, I haven't found a reliable
way to determine whether the object is a function or not in all cases."

OMG. I can repeat myself too.

http://www.cinsoft.net/host.html

i - s - H - o - s - t - M - e - t - h - o - d. There you go.

"Unfortunately, in my testing, no native dom node reports anything as
typeof "function", so all checks fall to the String coercion."

http://www.cinsoft.net/host.html

i - s - H - o - s - t - M - e - t - h - o - d. There you go.

"The only assumptions made here are that calling the String constructor
on native dom properties/methods is safe."

Native dom properties/methods? Regardless, that's not a safe assumption.

http://www.cinsoft.net/host.html

i - s - H - o - s - t - M - e - t - h - o - d. There you go.

"I've heard anecdotally that this may "blow up" in some cases, however
none of these case have surfaced with this implementation. A testcase to
the contrary would be helpful."

Show me where it fails. Show me where it fails...

"Rather than commenting on checkins, a better way to contribute would be
to help solve this problem."

And commenting on check-ins is not a way to help solve the problem?

"While I'm not convinced Node::hasMethod belongs in the library,
Y.Lang.isFunction could benefit with some help here."

Well, make up your mind. Do you want more comments or not?

" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

5 days ago

Anything where typeof results in "unknown".
Here:
typeof document.createElement("xml").onreadystatechange; // "unknown"
document.createElement("xml").onreadystatechange; // boom!"

Yes, that's a classic.

"The ES3 specification states that for host object, the result of typeof
is implementation-dependent. Notable changes are seen between Opera
versions and IE. Moreover, string conversion of host objects, as stated,
is not required by ES3 and that can blow up, too."

That's an abstraction put forth by the specification. Understand that
and you will understand why "isFunction" has no place in a JS program
and "hasMethod" won't work for any arbitrary property you throw at it.
There has to be a contract between the caller and the function, which
should be documented. Here it is:-

http://www.cinsoft.net/mylib-doc.asp#ishostmethod

"Using the value of string converting a host object to determine program
decisions is ridiculous. No standard requires string conversion of host
object. The result is nonstandard, proprietary, undocumented. You should
not be doing that."

Exactly. Understand that and you never have to test this in another
browser again. I haven't since around 2001. And not one explosion since.

"For example, in IE, I can see the string value of alert, which is a
host method, has "function" in it.
javascript: alert( String( alert ) )

My suggestion for helping out with isFunction is to refactor anything
that uses it to not do that, to deprecate isFunction, and to remove it.
It is broken by design."

I suspect you are spitting in the wind. That's almost exactly what I
told the Dojo people about isFunction and isArray. They still exist to
this day and are called by about a thousand different functions. New
functions are constantly added that must discriminate between host
objects, arrays and Object objects (a trifecta!) It's almost as if they
go out of their way to run straight into the walls imposed by the
language. I wonder if anyone working on these "standard" libraries that
support so many shiny widgets (which unsurprisingly break down, even in
the handful of "current" browsers they ostensibly support) knows the
first thing about any of this. I couldn't vouch for them. Not a one.

"/**
* Determines whether or not the provided object is a function.
* Note: Internet Explorer thinks certain functions are objects:
*/

The comment further indicates that the author believes that getAttribute
is a function in IE. There is no reason for believing that to be true
and in fact it is false."

I remember Resig blogged about it being called without a call operator
at one point. Of course, he was wrong and blaming his failure to
understand on voodoo.

"Y.Lang.isFunction does not and can not, in the general sense, fulfill
what is promised in its preceding code comment."

Of course not. It should not be allowed to accept host objects of any
sort (not even methods). And if it can't accept host objects, what do
you need it for? Okay, the odd native object that is callable in some
browsers but not others (e.g. RegExp). So disallow passing those
objects as well. Once you understand that, you don't design
"overloaded" functions that must discriminate between regular
expressions and functions. End of story.

typeof xyz == 'function'; // What else do you need?

"It fails due to the reasons that been discussed over the years on
c.l.js and touched upon here. It boils down to typeof having different
results with host object and the [[Class]] property being
implementation-dependent for host object. It fails for other reasons
where a built-in may have also a [[Call]] property, or be somehow
callable without having a [[Call]] property (as spidermonkey RegExp)."

Right. Though I don't know about any Spidermonkey object that is
callable but does not implement [[Call]] internally. How do you figure
that? Regardless, this is all well beyond what the YUI authors can (or
need to) digest.

"The function is a failed attempt because the author demonstrates
misleading information about the a callable object being a function. An
object that is callable is not necessarily a function. Failing to make
that distinction in a code comment, and, moreover, providing a false
statement with getAttribute, shows that the author does not know that
the function is not clear on what can be expected of it.

As such, use of that function should be avoided."

As should the author.

"More details of "isFunction" functions, typeof, and host methods have
been discussed over the years on c.l.js."

" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081 "

I can't say as I'm optimistic. I really don't want to read it, but...

"4 days ago

The "boom" in your test is a "not supported" JS error due to
node[method] access on a field of type "unknown", not String conversion."

Here we go. Any type conversion will do it. Try it!

"Treating "unknown" as "undefined" resolves this issue and puts the
hasMethod result inline with other vendor implementations for the
xmlNode.hasMethod('onreadystatechange') test case."

Not even close.

"As I mentioned, while not sold on the Node::hasMethod, we are
interested in beefing up support for Lang::isFunction."

Did you not read the previous comments? It doesn't need "beefing up"
but slaughtering.

"This discussion would be more appropriate on YUI Forums or within our
ticket system."

I suspect it would be just as productive in those venues.

" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

4 days ago

You wrote: "Treating "unknown" as "undefined" resolves this issue and
puts the hasMethod result inline with other vendor implementations "

That is completely wrong and false. The unknown type represents ActiveX
object.

Didn't you just publish a chapter in book? And you're on the YUI team....

Unbelievable."

Indeed. What book would that be? And being on the YUI team is not
exactly a badge of honor. More of a scarlet letter (Y).

" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081 "

I know I don't want to continue, but it's like watching a train wreck...

"4 days ago

Thanks Garrett."



"Calling Node::hasMethod against your xml test case is now "false", as
expected."

Oh God. Expected by whom?

"Please file a bug for any failing case you have with this
implementation. Calling it "wrong" doesn't get any closer to a resolution."

Show me where it fails; show me where if fails; show me, show me, show
me... Arrgh!! Not even an attempt at understanding. None of the
previous registered at all? It's like what one of the Dojo team members
told me: I'm not too good with abstractions. How can you write software
if you aren't "too good" with abstractions? Well, badly of course (and
Dojo is certainly bad).

" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

4 days ago

Quote: "Calling Node::hasMethod against your xml test case is now
"false", as expected."

No, and for example, a true result for:-
typeof hostObject.property === "unknown"

- is not an indication that the property is undefined; quite the
contrary. In IE, some host objects are implemented as ActiveX objects.
When an ActiveX object is supplied to typeof operator, the result is
"unknown"."

When a _property_ of an ActiveX object... We went over this.

"And so the example typeof hostObject.property === "unknown" would be
indicative that the property is an ActiveX object."

Yes, it is a specific type of ActiveX object that is only found in
JScript implementations as a _property_ of other types of ActiveX
objects (which do not have "unknown" types themselves).

"This matches behavior documented in MS-ES3, for SafeArray."

That's the one.

"MSDN links are broken, but a copy of MS-ES3 may be found on the FAQ:
http://jibbering.com/faq/#resources"

That was four days ago. The line seems to have gone dead. Hopefully
YUI will follow suit. As it is full of UA sniffing, I'm sure it will.
It's not like it is setting the world at present.

If that all sounds harsh, realize that I have to deal with these things
constantly. I don't mind as I get paid dearly for it. But I feel for
the clients. YUI, Dojo, etc. projects shouldn't require a high-end JS
consultant on permanent standby. Aren't they supposed to make things
_easier_, saving tine and money? I know for sure it doesn't pan out
(except for me). These things are gold. If I were selfish, I wouldn't
say a word, would I? Think about that before whining about my criticism(s).
 
Reply With Quote
 
 
 
 
Michael Haufe (\TNO\)
Guest
Posts: n/a
 
      05-23-2010
On May 22, 5:11*pm, David Mark <(E-Mail Removed)> wrote:
> [...]


I'm curious to why you bother. The subjects of your criticism don't
understand the language in theory yet are trying to put it into
practice and also show no willingness to improve on that situation.
Why not just let them collapse in upon themselves if that is what they
are destined to do anyway as you've claimed?
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      05-23-2010
Michael Haufe ("TNO") wrote:
> On May 22, 5:11 pm, David Mark <(E-Mail Removed)> wrote:
>> [...]

>
> I'm curious to why you bother.


Why does anyone bother to do anything? At least I am trying to bring
about positive change. And it has worked well (if sporadically) over
the years. Somebody from YUI will see this and you can bet they will
get the message eventually. In the interim, I predict there will be a
lot of hissing and moaning on IRC, the term "troll" will be bandied
about (ironic for IRC dwellers who live below the newsgroups) and
perhaps a new article will be posted to StackOverflow (or the like); not
to address the issues, but to question my motivations.

But notice how jQuery finally removed the UA sniffing, despite Resig's
obvious misunderstandings about it. Remember his reaction when I first
told him he was screwing up (and about ten years behind the times).
This was in 2007. It finally sunk in (about a year later). The
attribute issues were discussed in that same thread, but they are still
chewing on those. In 2010. Just for the record, the issues in
question date back to 1999 (and were never a secret). Granted, I didn't
publish a GP solution (with appropriate feature testing) until 2007.
Same for other feature testing tidbits that eventually showed up in
jQuery, Prototype and countless other small projects. The larger
dinosaurs (e.g. Dojo, YUI) are slower to move. Their brains are too far
removed from their tails.

http://www.cinsoft.net/host.html

Like tossing a boulder into the ocean, eventually the waves break on
every shore.

> The subjects of your criticism don't
> understand the language in theory yet are trying to put it into
> practice and also show no willingness to improve on that situation.


Yes, so one of my motivations is to *warn* developers to steer clear of
projects like that. You don't think there is a *huge* problem with
naive developers being taken in by projects like this? I do as I see it
every day. They end up buying books, T-shirts, attending fanboy
conferences and never seem to realize that they've been had. It sucks a
fortune out of the economy (a portion of which ends up in my pocket
eventually, so I can hardly be criticized for speaking up about the
problem). In short, if you are developing with YUI, Dojo, etc. and
don't have a clue what goes on in inside it, you best have someone like
me on site (or on a short leash). Because when things break, the only
recourse is to upgrade/downgrade pieces (or all) of the canned software
and/or ask the authors of the software (as seen in the OP) what they
think. And as we've seen endlessly, the developers don't know anything.
On the contrary, reading their source is like reading a coloring
book for me. A very bad, ugly coloring book with gaudy color, drawing
outside the lines, etc.

> Why not just let them collapse in upon themselves if that is what they
> are destined to do anyway as you've claimed?


So I should just clam up and let them take everyone else with them.
Apathy is just not my thing. And the "collapse" won't be complete as
there will always be dead-enders slaving away at these things. Dojo
never even bubbled, so there's nothing to collapse, yet that doesn't
deter its authors (who are hopelessly deluded and blind to their own
failings).

Whet is happening should be obvious. iPhones/iPads are a prime example
of how Joe Consumer is starting to rely less and less on Joe Web
Developer. Who wants to deal with flaky scripts in a browser when you
can buy shiny applications from Apple's store? The Web will not be the
application platform of the future; that much is clear at this point.
Such proprietary platforms are to the Web as the Web was to the old
bulletin board systems.

The incompetents have thrown the game away by concentrating on follies
like CSS selector queries (five years down the drain), bloated OO
architecture that bastardizes the language, crappy grid widgets, etc.
It's all been a huge waste. The Web will never be Windows. And Dojo,
YUI, etc. will never be Visual Basic.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      05-23-2010
David Mark wrote:
[...]

>
> That was four days ago. The line seems to have gone dead. Hopefully
> YUI will follow suit. As it is full of UA sniffing, I'm sure it will.
> It's not like it is setting the world at present.
>


That was supposed to read "setting the world ablaze". They do make lots
of videos of themselves talking about it though. What a colossal waste.
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      05-23-2010
David Mark wrote:

> But notice how jQuery finally removed the UA sniffing, despite Resig's
> obvious misunderstandings about it. Remember his reaction when I first
> told him he was screwing up (and about ten years behind the times).
> This was in 2007. It finally sunk in (about a year later).


This is not the first time you claim your ideas influenced design changes in
other libraries, particularly jQuery, directly, so I should point this
fallacy out to you: Post hoc non est propter hoc.¹

While it is true that you have told him, there is no obvious cause-and-
effect relationship between your postings and the later change. In fact,
since Resig is known to despise you, it is more likely that the message sunk
in through other channels, if at all.

You should keep that in mind when you observe further such changes.


PointedEars
___________
¹ <http://en.wikipedia.org/wiki/Post_hoc_ergo_propter_hoc>
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      05-23-2010
Thomas 'PointedEars' Lahn wrote:
> David Mark wrote:
>
>> But notice how jQuery finally removed the UA sniffing, despite Resig's
>> obvious misunderstandings about it. Remember his reaction when I first
>> told him he was screwing up (and about ten years behind the times).
>> This was in 2007. It finally sunk in (about a year later).

>
> This is not the first time you claim your ideas influenced design changes in
> other libraries, particularly jQuery, directly, so I should point this
> fallacy out to you: Post hoc non est propter hoc.¹


My Latin is rusty, but you should know that most libraries are using
isEventSupported these days (as well as other constructs of mine). In
the case of isEventSupported, the cite is typically to Kangax' blog,
which links back to me. Same for CSS detection, which usually cites
Peter's blog, which links back to me. Fair enough?

Then there the umpteen different bug fixes that were spelled out here,
then carried over there by Matt Kruse (who also seems to "despise" me).
Those are well-documented. In fact, several required more than one
round trip, leading to long threads going on simultaneously (here and in
the jQuery developer forum). The selected option bug is the most recent
example. The ActiveX XHR exceptions are another.

>
> While it is true that you have told him, there is no obvious cause-and-
> effect relationship between your postings and the later change.


Which change are you talking about? Regardless, telling him means he
heard it from me (first). Can't change that. Do you think he erased
his memory? Whether others chimed in later is irrelevant. The UA
sniffing would seem to top the list. What a revelation he had a full
year later. And what a bizarre coincidence that he used a virtually
identical script injection test (as seen in My Library). Same for the
bit that injects a DIV, checks its padding, etc. Almost verbatim, even
the set to null at the end (which I had long since deemed unnecessary)
was carried over. And recall that he and Matt Kruse were falling all
over themselves to get me to post my code (fall of 2007). I did and
then a year later (jQuery 1.3 IIRC), pieces of it started showing up in
jQuery. Call me paranoid.

> In fact,
> since Resig is known to despise you, it is more likely that the message sunk
> in through other channels, if at all.


Resig would do well not to despise me as I'm personally responsible for
cleaning up a number of his messes. And he should really listen more as
he keeps putting his foot in his mouth in public. I just read where he
is claiming that you can be "standards-based" in "all browsers" if you
use the HTML5 doctype. And apparently, he's been slinging that nonsense
since 2008. Can I help it if he routinely makes a buffoon out of
himself? All I can do is try to mitigate the damage he does.

>
> You should keep that in mind when you observe further such changes.


No I shouldn't. Who cares?
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      05-23-2010
Thomas 'PointedEars' Lahn wrote:
> In fact,
> since Resig is known to despise you, it is more likely that the message sunk
> in through other channels, if at all.
>


And, of course, he very recently copped my attributes code and put it in
his repository. So the idea that his "despising" me would prevent him
from lifting my stuff is a laughable fallacy in its own right. Think
about that.

Furthermore, the whines that erupted when I forced him to remove it all
painted *me* as the bad guy. Go figure.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      05-24-2010
David Mark wrote:
> Thomas 'PointedEars' Lahn wrote:
>> In fact,
>> since Resig is known to despise you, it is more likely that the message sunk
>> in through other channels, if at all.
>>

>
> And, of course, he very recently copped my attributes code and put it in
> his repository. So the idea that his "despising" me would prevent him
> from lifting my stuff is a laughable fallacy in its own right. Think
> about that.
>
> Furthermore, the whines that erupted when I forced him to remove it all
> painted *me* as the bad guy. Go figure.


And to alleviate any doubt about my "claims".

From jQuery 1.4:-

// Technique from Juriy Zaytsev
//
http://thinkweb2.com/projects/protot...wser-sniffing/
var eventSupported = function( eventName ) {
var el = document.createElement("div");
eventName = "on" + eventName;

var isSupported = (eventName in el);
if ( !isSupported ) {
el.setAttribute(eventName, "return;");
isSupported = typeof el[eventName] === "function";
}
el = null;

return isSupported;
};

And when and where was this technique invented? Hopefully you already
know as it was done here.

As for when, not sure why (in my Host primer) I linked to this
particular message in the fairly lengthy thread where this was first
proposed, but here it is:-

http://groups.google.com/group/comp....41a9bce1e18d7d

Later discussed here:-

http://groups.google.com/group/comp....16c4b1c2b3c7ec

And then blogged about by Kangax. Think Resig even knew where the idea
originally came from? Well, he did if he read the blog post carefully
as I'm rightly credited. It's incontrovertibly my invention.

Googling "isEventSupported" today comes up with roughly 2000 hits. I'm
pretty sure Prototype is one of them. YUI too, IIRC. I've seen it in
other "major" (as well as minor) libraries as well. And here is a
regurgitation of Kangax' post on the subject:-

http://blog.strictly-software.com/20...t-support.html

And resting exactly above that code in jQuery 1.4 is this "inject and
detect" device that I first published in 2007 (and it sure as hell
wasn't being used by anybody at that time, at least not in public).
Sort of a double feature.

jQuery(function(){
var div = document.createElement("div");
div.style.width = div.style.paddingLeft = "1px";

document.body.appendChild( div );
jQuery.boxModel = jQuery.support.boxModel = div.offsetWidth === 2;
document.body.removeChild( div ).style.display = 'none';
div = null;
});

Note the superfluous set to null at the end.

And here's one of many similar examples from My Library:-

var divOuter = createElement('div');
var divInner = createElement('div');

offsetIncludesBorder = (function() {
setStyles(divOuter, {position:'absolute', visibility:'hidden',
left:'0', top:'0', padding:'0', border:'solid 1px'});
setStyles(divInner, {position:'absolute', left:'0', top:'0', margin:'0'});
divOuter.appendChild(divInner);
body.appendChild(divOuter);
b = divInner.offsetLeft == 1;
body.removeChild(divOuter);
divOuter.removeChild(divInner);
return b;
})();

divInner = divOuter = null;

Of course, in this case, the set to null is not superfluous. But other
examples in My Library featured such unneeded code at one time. And
I've published numerous other examples of similar patterns that featured
the fairly well-known superfluous null set (since deemed unnecessary).

Then there's this obvious (and uncredited) imitation:-

script.type = "text/javascript";
try {
script.appendChild( document.createTextNode( "window." + id + "=1;" ) );
} catch(e){}

root.insertBefore( script, root.firstChild );

// Make sure that the execution of code works by injecting a script
// tag with appendChild/createTextNode
// (IE doesn't support this, fails, and uses .text instead)
if ( window[ id ] ) {
jQuery.support.scriptEval = true;
delete window[ id ];
}

He actually tries to delete a property of a host object (window). As
noted, IE never gets to that line (at least not to this date), so it
"works" by coincidence. Can't show him where that fails today, can you?
Maybe tomorrow...

My slightly longer (and more competent) version can be seen in My
Library or side by side with this one at:-

http://www.cinsoft.net/host.html

And I should give credit to Randy Webb for inspiring mine. As a matter
of fact, he and Richard are largely responsible for schooling me on the
basics of feature testing. Without their input, My Library would not
have been possible. Just as without my input (and influence), jQuery
would not be able to "work" without UA sniffing or when ActiveX is
disabled (an fairly notorious example not recounted in this post) and
neither would "Live" have been "fixed":-

http://www.neeraj.name/2010/01/14/ho...e-methods.html

So, unless you are blind, stupid (or Matt Kruse), I suspect this will
put the matter to rest once and for all. I didn't even go into all of
the bug fixes. Kruse likes to take sole credit for those; but of
course, as seen with the selected option bug, left to his own devices,
he's hardly capable of fixing (or even diagnosing) anything. I think it
took about six months or repetition before he realized what I meant by
"jQuery will blow up in IE with ActiveX disabled".
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments