Prev: Acheter ACEON pilule enligne
Next: keyboard commands?
From: Thomas 'PointedEars' Lahn on 23 May 2010 18:31
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
From: David Mark on 23 May 2010 18:59
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?
From: David Mark on 23 May 2010 19:18
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. :)
From: David Mark on 24 May 2010 14:32
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/prototype/detecting-event-support-without-browser-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.lang.javascript/browse_thread/thread/b9812e0878c7c67c/6641a9bce1e18d7d?#6641a9bce1e18d7d

Later discussed here:-

http://groups.google.com/group/comp.lang.javascript/msg/d216c4b1c2b3c7ec

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/2009/11/testing-for-browser-event-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/how-jquery-1-4-fixed-rest-of-live-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". ;)
First  |  Prev  | 
Pages: 1 2
Prev: Acheter ACEON pilule enligne
Next: keyboard commands?