New jQuery announced!
in [JavaScript]
|
From: David Mark on 14 Dec 2009 08:57 On Dec 13, 11:00 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Dec 12, 2:06 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > In conclusion, results for attribute-related queries would make decent > > seeds for random number generators. > > Can you come up with a real test-case that fails? > Now you are parroting Resig? You really don't get it either, do you?
From: David Mark on 14 Dec 2009 08:59 On Dec 14, 2:23 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > David Mark wrote: > > On Dec 13, 12:44 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >> On Dec 13, 11:55 am, Hans-Georg Michna <hans- > > >> georgNoEmailPle...(a)michna.com> wrote: > >>> On Wed, 9 Dec 2009 09:43:44 -0800 (PST), David Mark wrote: > >>>> ... I made an exception a couple of years back (Google "browser > > [sni[\ > > > Want to remove the click listener for each in turn? > > > var fn = function() { > > E(this).fadeOut().off('click', fn); > > }; > > > Q('.myclass').fadeIn().on('click', fn); > > [sni[ > > > For me, I can't see coding like this. But the interface is there (and > > works efficiently) for those who can. > > It is a pity that this style of programming has become so widely adopted. > > The design of making a query and performing an action is inherently > inefficient. Yes. > > A simple event library can go much further, with much fewer bugs, much > less code, much faster performance. Absolutely. > > Long menthod chains and complex expressions are harder to debug, then > again, one-letter functions like 'E' aren't very descriptive, either. Yes. I don't like the constructor names either. At the time, I was demonstrating an alternative to the less-descriptive "$". > > Aside: I do mean to get back to that getWindowSize post, I am sorry I > have many things going on right now. I have not forgotten that one. NP.
From: Matt Kruse on 14 Dec 2009 11:19 On Dec 14, 7:57 am, David Mark <dmark.cins...(a)gmail.com> wrote: > On Dec 13, 11:00 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > > On Dec 12, 2:06 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > In conclusion, results for attribute-related queries would make decent > > > seeds for random number generators. > > Can you come up with a real test-case that fails? > Now you are parroting Resig? You really don't get it either, do you? I'm trying to imagine a case where this actually matters. Digging into code and finding logic flaws that will pop up in real cases is one thing. Dreaming up edge cases that may in theory fail under obscure conditions for obscure input is another, and not necessarily useful. On Dec 12, 2:06 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > So, an element like this:- > <div></div> > ...will produce a test like this:- > return (" null ").indexOf( match ) > -1; > ...in some browsers and modes. So? I guess if you are trying to match elements where class=="null" this will cause problems? Or did I miss something? > elem[ name ] != null > That's everything but null or undefined. So property values that are > neither end up converting this to a string:- > elem[ name ] > ...which could end up as "true" or "function anonymous() { ... }" or > "[object CSSStyleDeclaration]" or whatever. Why would you be writing a query to match the 'onclick' attribute, or anything that might return a stringified function? Or a CSSStyleDeclaration? > Here's more madness:- > enabled: function(elem){ > return elem.disabled === false && elem.type !== "hidden"; > }, > Sure, hidden inputs are always disabled. We needed that smoothed > over. :) "enabled" is a poor word choice. The intent is different than what many might expect. > disabled: function(elem){ > return elem.disabled === true;}, > checked: function(elem){ > return elem.checked === true; > Wrong. That includes user input. Because it's supposed to, of course. If I want to get a reference to all checkboxes that are currently checked, I of course want to consider user input. > selected: function(elem){ > // Accessing this property makes selected-by-default > // options in Safari work properly > elem.parentNode.selectedIndex; > return elem.selected === true; > }, > LOL. There's _that_ again. I am curious as to the origins of this. > So how could you possibly trust any script from these people, let > alone something as convoluted and confused as jQuery? You seem very interested in pointing out every little potential logical flaw in the source code, without any consideration for whether the flaw will ever be practically applicable. Sure, it would be great to have 100% perfect code that considers every possible scenario ideally. But in reality, this isn't always possible (no software is perfect). Just because you dream up a potential case where the logic will fail does not invalidate its usefulness in all the realistic cases where it will work correctly. It makes no sense to throw out functionality that will work correctly for almost every case just because you find one case that is difficult or impossible to handle correctly - especially if no one actually needs that case in practice! Your tunnel vision prevents you from seeing the bigger picture, where this code is useful for many cases that work just fine. Matt Kruse
From: David Mark on 14 Dec 2009 11:36 On Dec 13, 11:00 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Dec 12, 2:06 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > In conclusion, results for attribute-related queries would make decent > > seeds for random number generators. > > Can you come up with a real test-case that fails? > Squawk! Show me an example (as if examples will help you understand the underlying logic). And what is a "real test-case" anyway? 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 There are three images. The middle one is forced to use the border- box model (a la IE quirks mode). All I want to do is get the height and then put it back the same as it was. In DOM terms:- img.height = img.height; In "concise" jQuery terms:- $(img).attr('height', $(img).attr('height')); I believe that would have worked in all (most?) previous jQuery versions, where the attr method remained a "glorified way to set properties" (with a few detours into attributes). It's pretty easy to visualize, but there is also a log. FF3.5 attr height #1 = 32 attr height #1 after put back = 32 attr height #2 = 32 attr height #2 after put back = 0 attr height #3 = 32 attr height #3 after put back = 32 IE8 (standards) attr height #1 = 32 attr height #1 after put back = 32 attr height #2 = 32 attr height #2 after put back = 0 attr height #3 = 0 attr height #3 after put back = 0 IE8 (compatibility) attr height #1 = 32 attr height #1 after put back = 32 attr height #2 = 72 attr height #2 after put back = 72 attr height #3 = 0 attr height #3 after put back = 0 IE8 (quirks) attr height #1 = 12 attr height #1 after put back = 0 attr height #2 = 52 attr height #2 after put back = 32 attr height #3 = 0 attr height #3 after put back = 0 Looks like random numbers to me. ;) I'll skip the middle (user input) tests as they will only confuse you further. 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). FF3.5 Image map (right way) : [object HTMLImageElement] Image map (wrong way) : undefined IE8 (standards) Image map (right way) : [object HTMLImageElement] Image map (wrong way) : undefined IE8 (compatibility) Image map (right way) : undefined Image map (wrong way) : [object] IE8 (quirks) Image map (right way) : undefined Image map (wrong way) : [object] Yeah, that's just the sort of inconsistency that "programmers" often need. :) Those were the first tests I tried. I'm sure you can come up with more. If you understand the code, attributes, properties, box models, etc., the results are fairly trivial to predict. But why bother when the author is clearly beyond help? 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. And understand that My Library is 100% box model _agnostic_ and handles attributes properly (more or less, the new wrappers are slightly improved). And, as we've seen, it has the toddler interface you so covet for your team. You've spent two years defending and fighting with jQuery, without any understanding of what is going on under the hood. You can't even upgrade from 1.3 as it will break your apps, so you are stuck with UA sniffing as well. Every time there is an inkling of understanding, you talk to Resig and he confuses you again. The code's logic (or lack thereof) remains constant throughout your endless waffling.
From: Matt Kruse on 14 Dec 2009 11:49
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!" > 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. > 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. 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. > 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. > 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. > He apparently couldn't > understand it. I thought you did at one point. Are you drunk or > what? Likely. Matt Kruse |