New jQuery announced!
in [JavaScript]
|
From: David Mark on 12 Dec 2009 06:29 On Dec 11, 5:15 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Stefan Weiss wrote: > > On 11/12/09 08:35, Garrett Smith wrote: > >> Garrett Smith wrote: > >>> jQuery.attr has specific handling for many odd cases. What does attr > >>> have to do with: > > >>> | if ( name == "selected" && elem.parentNode ) > >>> | elem.parentNode.selectedIndex; > > >> Note that the statement inside the if test is entirely useless, as it is > >> not assigned to anything. > > > The two lines above the quoted part are: > > > // Safari mis-reports the default selected property of a hidden option > > // Accessing the parent's selectedIndex property fixes it > > > It would appear that this was intended as a bug workaround, and that > > reading the selectedIndex property is all that's required. Still, it's a > > strange thing to do, and could very well be optimized away by a minifier > > tool or by the JS engine itself. > > A workaround, but to what problem? Something in their head likely. > > <body onload ="alert(document.getElementById('c').selected)"> > <select id="x"> > <option id="a">a</option> > <option id="b">b</option> > <option id="c" style="visibility: hidden;" selected>c</option> > <option id="d">d</option> > </select> > > In Safari, the 'c' is selected, the alert is - true - and when the > select is expanded, the 'c' option is blacked out. > > Perhaps someone can demonstrate what the workaround actually fixes. Unlikely. But they won't take it out because somebody has fuzzy memories of a "problem" that they can't really explain. > > Anyway, attr is dealing with non-string value property. Certainly, except when it branches off into attributes (e.g. "special properties" href and src). It makes absolutely no sense and provides a far less consistent interface than the "buggy" DOM implementations. The indoctrinated neophytes don't see it because they don't know any better. One of their luminaries remarked recently that it "uses properties and always has" and couldn't understand why people are claiming it is broken. :)
From: David Mark on 12 Dec 2009 12:03 On Dec 11, 12:08 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Dec 11, 10:47 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > You must live in a bubble. > > No, I deal with JS and JS developers every day. > > There's no point in going over this again. You cannot relate to those > who face development situations and business cases different than > yours. Nice try (seriously) in your recent attempt to educate John Resig about his own attr/removeAttr methods. He's obviously confused about what those test results mean, so let me explain. The first two strictly deal with attributes. You made one mistake in your explanation to Resig in that manipulating most DOM properties by script will reflect back to the attributes. It's the DOM defaults and user input that must be filtered to gain a clear view of the document structure. The latter two do the exact same thing, but resolve the "raw" attributes to their DOM interpretations, still returning null for missing attributes (except for booleans, of course). For example, URI's are resolved, booleans return true/false, numeric attributes return numbers, etc. All four are attempts to produce a consistent interface for reading the DOM, filtering out DOM defaults. I recently modified the two wrappers slightly to filter out user input as well. I'll post as soon as I finish updating the tests (there are about 100 now). That's the view you need for a CSS selector query engine, WYSIWYG editor or like application. As you mentioned, it is _not_ a view that the typical Web app needs to see. The biggest unanswered question, which Resig seems unwilling to address, is what the hell is his attr method supposed to do? Who knows? Is it a view of the underlying document structure, does it include DOM defaults, user input, etc.? It clearly does nothing predictable or consistent in any browser. As an aside, notice that he only ever tests your suggestions in FF3.5. ;) He did mention that it is _not_ "designed" to read DOM properties. So now I am really confused. It's clearly not designed to read attributes either (except for "special" properties). Are file paths to be resolved or not? Are DOM defaults to be ignored, embraced or stepped on? His method does a little of each. What about user input? I get the idea that he doesn't comprehend the various layers at all. And yeah, spot on about the new jQuery method entanglement, which makes this thing even worse (hard to believe). I forgot they had methods called "height", "width", etc. So his "solution" to "onclick" throwing an exception (in FF!) is to use "click" instead as it will then call the jQuery click method, which does... God knows what. And somehow he thinks this "improves" his already muddled API. (!) The guy is clearly not qualified to write even the simplest DOM scripts. He doesn't understand the basic concepts. The attr and removeAttr methods and the years of confusion and twiddling that have followed, leading up to this latest pathetic denial, are all the proof you should need. But the typical code monkey will load up their app (which may well have straddled the land mines in the specific version of jQuery used) in IE8 and FF3.5, note that it appears to work (just don't disable ActiveX in IE!) and chafe that such "petty" criticism is unrealistic for such an obviously magical script (turned them into a programmer!) I'll post similar tests with the jQuery methods when I get a chance. I'll have to guess at what they are trying to do, but there are only so many possibilities. I know they are incapable of providing a consistent and symmetrical interface for anything though. Initial testing shows that removeAttr throws exceptions and fails silently for several attribute names. If the caller switches gears and passes property names instead, a few of the failures go away. but new ones take their place. As for licensing, which I see Resig is interested in, tell him he can license the whole test suite, wrappers, etc., but it won't be cheap. Hell, tell the "foundation" to pick up the bill. :) And if he copies one word or the tiniest aspect of the design, brutal legal action will follow. I'm tired of seeing my ideas show up in his "cutting edge" script years later.
From: David Mark on 12 Dec 2009 15:46 On Dec 12, 6:11 am, RobG <rg...(a)iinet.net.au> wrote: > On Dec 12, 7:26 am, "S.T." <a...(a)anon.com> wrote: > > > > > On 12/7/2009 8:59 AM, David Mark wrote: > > > > But it has the same old attr method. :( > > > > attr: function( elem, name, value ) { > > > > // don't set attributes on text and comment nodes > > > >... and on and on and on. > > > For all these massive bugs, future browser incompatibility issues, code > > breaking on every library update and inept coding that you claim litters > > jQuery -- I don't seem to see any effects of them. Ever. Nor do my > > users. Nor other developers I communicate with. > > > Weird, isn't it? > > > Guess I'm just really, really lucky. > > Or don't read the jQuery GG forum. A quick scan over the last two days > of posts turned up the following: > > Random problems with load()????? > <URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/cc155ee... > > > > Problem with Jquery Superfish in IE7 > <URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/422d435... > > > > IE 7-8 bug on menu loading when mouse is over the menu > <URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/87d5484... > > > > load() function and IE8 > <URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/a12e5d4... > On a positive note, posts to that list are dwindling. I guess people are tired of wrong (or no) answers. :) Quoting from that last one:- "I fat fingered the last one so... I have this piece of code $("#AP_PONum").live("change", function(){ ap_po = $("option:selected",this).val(); $("#content-box").load("webapps/finished_jewelry/PurReq/display/ dsp_addPurchaseRequest.cfm?poNum="+ap_po); }); which works like a champ in firefox. it's called from a drop down grabs the ColdFusion template and load it in a div called content-box. This does nothing in IE8, no error, no load, no love.. nothing any ideas on how to work around this?" They better test in more than IE8 and FF. :) Look at the three (!) queries in this one line. Two can be replaced with document.getElementById. The other one is sure to be a disaster as it uses ":selected". http://groups.google.com/group/comp.lang.javascript/msg/05416b9fc93b2092 And what is that other one doing? Looking for the selected option of a SELECT? jQuery makes it so easy... to shoot yourself in the foot, even when the target is right in front of your face. ;) Assuming there are no options with empty or missing values:- var el = document.getElementById('AP_PONum'); el.onchange = function() { ap_po = this.options[this.selectedIndex].value; ... }; In modern browsers, you can even get away with:- el.onchange = function() { ap_po = this.value; ... }; Something like that is much faster, easier to read and understand, not prone to bizarre inconsistencies, etc. For the macro-challenged, the keystroke count is reduced as well. The jQuery list's answer to this is (typically) no answer at all (literally). ;)
From: Garrett Smith on 12 Dec 2009 18:07 Andrew Poulos wrote: > On 12/12/2009 8:26 AM, S.T. wrote: >> On 12/7/2009 8:59 AM, David Mark wrote: >>> But it has the same old attr method. :( >>> >>> attr: function( elem, name, value ) { >>> >>> // don't set attributes on text and comment nodes >> > >>> ... and on and on and on. >> >> For all these massive bugs, future browser incompatibility issues, code >> breaking on every library update and inept coding that you claim litters >> jQuery -- I don't seem to see any effects of them. Ever. Nor do my >> users. Nor other developers I communicate with. >> >> Weird, isn't it? >> >> Guess I'm just really, really lucky. Probably. Bugs do not always manifest in the scenario. If they did, there would be value in unit testing. [...] > Yes, many developers are lucky. > Like all things in life, there is more than meets the eye. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Hans-Georg Michna on 13 Dec 2009 11:55
On Fri, 11 Dec 2009 06:03:46 -0800 (PST), Matt Kruse wrote: >I know what >problems I have with jQuery, and I code around them. Matt, it would be nice to have a list of these. Care to publish one? Hans-Georg |