From: Matt Kruse on
On Dec 14, 10:36 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> I took five minutes to put together a demonstration, which touches
> upon most of the issues discussed in this thread.
> http://www.cinsoft.net/jquerysucks.html

The attr('height') argument is obvious. I objected to that in the
jQuery-dev thread also. I think it is an absurd addition to the code.
Your example page illustrates that nicely.

> But the last one should be obvious.  One of the images is a
> map:-
> <img id="testimage" src="images/cinsoft.gif" height="32" width="32"
> ismap alt="">
> I tried to query it in two ways (one right, one wrong).

Interesting. I'm not sure that anyone would ever actually do this, but
it does illustrate a potential problem.

> Don't bring up documentation or community again as the documentation
> is invariably wrong (hardly surprising) and the community, right up to
> the leader, is clueless.  Just admit that it was (and is) a terrible
> mistake to trust jQuery.

It has its limitations, the API choices are unwise, and some of the
code inside is definitely "oh look an obscyre failing test case lets
apply some blogged-about browser-specific hack to fix it rather than
really understanding the root cause and correct logical solution."
I'll admit that, certainly. Always have.

Matt Kruse
From: David Mark on
On Dec 14, 11:49 am, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Dec 14, 7:55 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > You are very confused.  I never claimed it was a get/setAttribute
> > wrappers at all.  
>
> I may have misunderstood your constant criticisms to the effect of
> "jQuery can't even handle attributes correctly!"

You have. I was referring to the _use_ of get/set/removeAttribute
inside jQuery. I've repeated numerous times that they'd be better off
without those methods, _except_ when it comes to the queries, which
should _not_ take DOM defaults into account. I never looked past attr
before, but it appears the attribute-based queries are similarly
botched.

>
> > Nobody knows exactly what his requirements are.  Including him, of
> > course.
>
> I pointed this out in the jQuery-dev thread. Hopefully he takes this
> seriously, since it can only help improve the attr() method, or at
> least clarify what it is intended to do. I suspect the result will be
> new test cases derived from the clarified documentation, and possibly
> improved code to handle those cases.

Yeah, you were really rolling there (with one minor misconception)
until Resig confused you again. ;) I laughed when I saw Resig trying
to correlate the test results for _my_ two wrappers with the results
for his. I'll put up a jQuery set when I get a chance, but I'll have
to guess at what the thing is supposed to do. Likely will put 1.3 and
1.4 on the same page to compare and contrast. I can tell you that at
least a half dozen attributes will throw exception on calling
removeAttr and at least another dozen more will fail silently. And -
this is the point - it can all be traced to the same misunderstanding,
which has already been explained to them (more than once). They are
never going to figure it out by observing test cases (those just
produce more confused patches).

>
> > If that is what the design calls for, which is what the - prop -
> > wrapper does.  I covered _both_ bases with _two_ wrappers.  The jQuery
> > thing tries to cram them both into one, which is impossible.  Get it?
>
> Clearly, it is possible. It just doesn't behave the way you think it
> should.

It doesn't behave the way anyone (sane) thinks it should. BTW, what
do you think this thing returns for XML documents?

>
> What if the method were documented as "retrieve the property value
> from an element if it exists (with exceptions x, y, z), otherwise fall
> back to retrieving the attribute value if possible."?  Maybe you think
> that functionality is stupid, but oh well.

Of course it is stupid and that description is not accurate. Does it
return a string (attribute) or a number (property) for tabindex?
Well, it depends on the browser, mode, jQuery version, etc. It even
changes based on the element type.

>
> > My "attribute wrappers" were never marketed as magic tools, nor do
> > they deal only in attributes.  The idea is that they prove how futile
> > it is for most scripts to try to read/write/remove attributes.  And,
> > of course, jQuery does those things, unnecessarily and inaccurately.
>
> It would be more accurate to say that for some cases, it is futile. In
> many other cases, it's simple and works just fine cross-browser.

Odd that mine, which were thrown together over a weekend and barely
touched since, have no such problems. And who maintains the matrix of
working features per browser, jQuery version, etc.?

>
> > No, it shows I am not about to let Resig steal my code.  I _gave_ him
> > the fix for broken attributes two years ago.  
>
> It's always an ego thing for you. Unfortunate.

It has nothing to do with me. Various incarnations of this idiotic
and obviously broken script are all over the Web (largely thanks to
parroting by people like you). That's not going to be good for
anyone. Except me perhaps as I've been recently fielding queries
about jQuery abatement. I figured IE8 would be the point where most
people figured it out it was poison. :)

>
> > He apparently couldn't
> > understand it.  I thought you did at one point.  Are you drunk or
> > what?
>
> Likely.
>

That's what I figured. Don't waste my time. :(
From: David Mark on
On Dec 14, 12:02 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Dec 14, 10:36 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > I took five minutes to put together a demonstration, which touches
> > upon most of the issues discussed in this thread.
> >http://www.cinsoft.net/jquerysucks.html
>
> The attr('height') argument is obvious. I objected to that in the
> jQuery-dev thread also. I think it is an absurd addition to the code.
> Your example page illustrates that nicely.

Thank you, but I could have sworn you were swinging back the other way
on that one. ;)

>
> > But the last one should be obvious.  One of the images is a
> > map:-
> > <img id="testimage" src="images/cinsoft.gif" height="32" width="32"
> > ismap alt="">
> > I tried to query it in two ways (one right, one wrong).
>
> Interesting. I'm not sure that anyone would ever actually do this, but
> it does illustrate a potential problem.

Always with the same preface. It's not the only attribute that will
fail. You should be able to recite most of the others. Then there
are the ones that fail in stranger ways (e.g. class, href, etc.). As
for href (and the like), _those_ they try to treat like attributes
(returning unresolved paths). Of course, their attempts don't work
consistently at all. I am sure as I already solved this problem (some
code needs resolved paths, some needs unresolved paths, so they both
need to be available).

>
> > Don't bring up documentation or community again as the documentation
> > is invariably wrong (hardly surprising) and the community, right up to
> > the leader, is clueless.  Just admit that it was (and is) a terrible
> > mistake to trust jQuery.
>
> It has its limitations, the API choices are unwise, and some of the
> code inside is definitely "oh look an obscyre failing test case lets
> apply some blogged-about browser-specific hack to fix it rather than
> really understanding the root cause and correct logical solution."

That's the story of all of the "major" libraries. They are dumping
grounds for misconceptions, guarded by bitchy neophytes who think they
are browser scripting Gods. I saw how Resig referred to your
questioning of his obviously idiotic design and code as "drama".
That's the mindset and it has no place in programming. :)

> I'll admit that, certainly. Always have.

You change your tune daily. It's tiresome.
From: David Mark on
On Dec 14, 12:02 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:

[...]

>
> Interesting. I'm not sure that anyone would ever actually do this, but
> it does illustrate a potential problem.
>

Second try at a successful (and very basic) test failed as well. Just
wanted to know which link in the document had the tabindex specified.
Various IE versions and modes think there are two of them (1 != 2).

See, these are trivial to do with XPath or QSA. How many of jQuery's
"supported" browsers lack both? IE6/7 I presume and those are the
browsers least likely to work with jQuery (that's why they never stop
bitching about them and threatening to drop support). Of course, if
they did drop those two (as if they ever had them), what possible
justification would there be for jQuery's crumbling monolith? The
active community? ;)
From: Matt Kruse on
On Dec 14, 2:26 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> Second try at a successful (and very basic) test failed as well.  Just
> wanted to know which link in the document had the tabindex specified.
> Various IE versions and modes think there are two of them (1 != 2).

Hmmm...

Using "My Library" source here:
http://www.cinsoft.net/mylib-build.asp?version=1.0&helptopic=setattribute&dom=on&setattribute=on&action=Build

Sample html:
<table cellspacing="5" id="x" onlyonce="yes"><tr><td>Data</td></tr></
table>

Using IE6 and "My Library":
API.getAttribute(document.getElementById('x'),'onlyonce') => null
API.getAttribute(document.getElementById('x'),'cellspacing') => null

Using jQuery:
$('#x').attr('onlyonce') => "yes"
$('#x').attr('cellspacing') => 5

Seems like jQuery gives me the right answers, and "My Library" fails.

Matt Kruse