New jQuery announced!
in [JavaScript]
|
From: Matt Kruse on 14 Dec 2009 12:02 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 14 Dec 2009 12:15 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 14 Dec 2009 13:04 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 14 Dec 2009 15:26 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 15 Dec 2009 11:03
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 |