jQuery crashes again
in [JavaScript]
|
Prev: FAQ Topic - How do I generate a random integer from 1 to n? (2010-04-03)
Next: active (x)html newsgroup?
From: David Mark on 6 Apr 2010 21:26 Hans-Georg Michna wrote: > On Tue, 6 Apr 2010 06:34:16 -0700 (PDT), Richard Cornford wrote: > >> The public API of a framework/ >> library/object/etc. could be thought of as a contract; you agree to >> use it as advertised (documented) and in return its creator's/ >> maintainers undertake to keep it working as advertised. > > This hinges on the functions actually being documented in > detail. So let's look at jQuery's .attr(...) method's > documentation: > > ----- Begin ----- > .attr( attributeName ) Returns: String LOL. ,,,or undefined or null or boolean or whatever (assuming it still looks basically like it always did). Same for Dojo's. And nobody can define what the functions do either. I know that sounds insane for "major" industry software that is largely built on queries. I didn't tell them to botch it them all to hell, tie them to shifty browser sniffing and then dump QSA on top. > > Description: Get the value of an attribute for the first element > in the set of matched elements. LOL. > > attr( attributeName ) attributeName The name of the attribute to > get. > ----- End ----- > > That's it. No mention what the function does when the attribute > exists, but has an empty string value, what it does when the > attribute does not exist, what it does when the attribute has > been modified with JavaScript earlier, etc. More like what it does if the attribute has been modified by either the jQuery attr method (a good possibility) or the user (another good possibility). I don't think the authors know. :( > > The docs continue in that minimalistic style, for example, the > .attr(attributeName, value) doc does not say what happens when > value is undefined or an empty string. Anything from a property set that makes sense to one that does not make sense to an exception (as we've seen in numerous cases). > > One reason I now try to avoid jQuery is that I cannot read up on > what exactly it does. You could write a master's thesis on all of the variables that impact the query results between browsers, configurations, library versions, etc. And the sad thing is that it shouldn't take more than a page to describe them all. http://www.cinsoft.net/attributes.html > > This also generally shows that good documentation is essential > for good software. > No question there and jQuery has never had it and isn't likely to get it any time soon as its authors don't know what they are writing about. For example. what are the height/width methods described as? If it is less than ten pages, it's wrong. The stupid things are just that unpredictable. :( http://www.cinsoft.net/size.html
From: David Mark on 6 Apr 2010 22:24 David Mark wrote: > Matt Kruse wrote: >> On Apr 5, 5:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>> So, isn't it about time you started using My Library instead? >> No. The poorly-documented API kind of sucks. >> >> Despite its flaws and limitations, I recently used the "sortable" >> project of jQuery UI and found it very easy to create an interface to >> reorganize content by dragging and dropping things around. All the >> options I wanted were there, and it was relatively painless to create >> in a small amount of time. When you have that kind of high-level >> functionality ready to deliver, documented, tested, and with examples, >> let me know. >> >> Or I also did this: >> $('tr.task').live('hover', function() { $ >> (this).toggleClass('hover'); }); >> >> Again, despite its limitations, this was a very easy way to add :hover >> support to some table rows in IE6. Does ML make it that easy? >> > > Forgot to translate this for you (though I don't know why I am > bothering). You really don't need a toggleClass and I would consider it > ill-advised as you should add only on entering and remove on leaving. > The jQuery example is ambiguous about that, so prone to get out of sync. > > Off the top of my head:- > I suppose I really shouldn't write such things off the top of my head. Didn't quite nail the exact behavior now that I look at the original again. To match behavior that (I think) the OP's tries to implement, I'd need something more like these two one-liners:- var addOrRemoveHoverClass = function(el, b) { E(el)[b ? 'addClass' : 'removeClass']('hover'); }; Q('tr.task').onRoll(function(e) { addOrRemoveHoverClass(this, true); }, function(e) { addOrRemoveHoverClass(this); }); Granted, that will attach listeners to each task row, which is hardly ideal. However, Resig's scheme is even worse as it will have to run *queries* in response to mouseover/out/enter/leave events. Just goes to show how queries and other syntactic sugar can get in the way of writing efficient applications. This would take a half dozen lines of API code to accomplish with delegation. I'll leave that as an exercise. Shouldn't be too hard as you can inspect the rollover code on the Build Test page. That leads straight to a private function that demonstrates how it is done (rolloverListenerWithParentCheck). And if you look very carefully, you will see there is a missing footnote on the builder (Rollover module needs the DOM module to do elements with descendants). That's a definite oversight (and a fairly rare sort of caveat), but then when a quarter of the Object Reference is still missing (for at least one more day), it's not a top priority. And whatever sort of ill-advised scheme is intended, I would advise trying a CSS-only solution first. Of course, the idea of falling back (with a conditional comment) to something like "Live" for IE6's "benefit" is pretty ludicrous (for one, IE6 is terribly slow with queries). I have to wonder what the OP was trying to accomplish with this.
From: David Mark on 6 Apr 2010 22:34 David Mark wrote: > David Mark wrote: >> Matt Kruse wrote: >>> On Apr 5, 5:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>> So, isn't it about time you started using My Library instead? >>> No. The poorly-documented API kind of sucks. >>> >>> Despite its flaws and limitations, I recently used the "sortable" >>> project of jQuery UI and found it very easy to create an interface to >>> reorganize content by dragging and dropping things around. All the >>> options I wanted were there, and it was relatively painless to create >>> in a small amount of time. When you have that kind of high-level >>> functionality ready to deliver, documented, tested, and with examples, >>> let me know. >>> >>> Or I also did this: >>> $('tr.task').live('hover', function() { $ >>> (this).toggleClass('hover'); }); >>> >>> Again, despite its limitations, this was a very easy way to add :hover >>> support to some table rows in IE6. Does ML make it that easy? >>> >> Forgot to translate this for you (though I don't know why I am >> bothering). You really don't need a toggleClass and I would consider it >> ill-advised as you should add only on entering and remove on leaving. >> The jQuery example is ambiguous about that, so prone to get out of sync. >> >> Off the top of my head:- >> > > I suppose I really shouldn't write such things off the top of my head. > Didn't quite nail the exact behavior now that I look at the original again. > > To match behavior that (I think) the OP's tries to implement, I'd need > something more like these two one-liners:- > > var addOrRemoveHoverClass = function(el, b) { > E(el)[b ? 'addClass' : 'removeClass']('hover'); > }; > > Q('tr.task').onRoll(function(e) { > addOrRemoveHoverClass(this, true); > }, function(e) { > addOrRemoveHoverClass(this); > }); > > Granted, that will attach listeners to each task row, which is hardly > ideal. However, Resig's scheme is even worse as it will have to run > *queries* in response to mouseover/out/enter/leave events. Just goes to > show how queries and other syntactic sugar can get in the way of writing > efficient applications. > > This would take a half dozen lines of API code to accomplish with > delegation. I'll leave that as an exercise. Shouldn't be too hard as > you can inspect the rollover code on the Build Test page. That leads > straight to a private function that demonstrates how it is done > (rolloverListenerWithParentCheck). And if you look very carefully, you > will see there is a missing footnote on the builder (Rollover module > needs the DOM module to do elements with descendants). That's a > definite oversight (and a fairly rare sort of caveat), but then when a > quarter of the Object Reference is still missing (for at least one more > day), it's not a top priority. > Nevertheless it is now documented. Been a fairly productive day in that area. :)
From: David Mark on 6 Apr 2010 22:41 David Mark wrote: > David Mark wrote: >> Matt Kruse wrote: >>> On Apr 5, 5:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>> So, isn't it about time you started using My Library instead? >>> No. The poorly-documented API kind of sucks. >>> >>> Despite its flaws and limitations, I recently used the "sortable" >>> project of jQuery UI and found it very easy to create an interface to >>> reorganize content by dragging and dropping things around. All the >>> options I wanted were there, and it was relatively painless to create >>> in a small amount of time. When you have that kind of high-level >>> functionality ready to deliver, documented, tested, and with examples, >>> let me know. >>> >>> Or I also did this: >>> $('tr.task').live('hover', function() { $ >>> (this).toggleClass('hover'); }); >>> >>> Again, despite its limitations, this was a very easy way to add :hover >>> support to some table rows in IE6. Does ML make it that easy? >>> >> Forgot to translate this for you (though I don't know why I am >> bothering). You really don't need a toggleClass and I would consider it >> ill-advised as you should add only on entering and remove on leaving. >> The jQuery example is ambiguous about that, so prone to get out of sync. >> >> Off the top of my head:- >> > > I suppose I really shouldn't write such things off the top of my head. > Didn't quite nail the exact behavior now that I look at the original again. > > To match behavior that (I think) the OP's tries to implement, I'd need > something more like these two one-liners:- > > var addOrRemoveHoverClass = function(el, b) { > E(el)[b ? 'addClass' : 'removeClass']('hover'); > }; > > Q('tr.task').onRoll(function(e) { > addOrRemoveHoverClass(this, true); > }, function(e) { > addOrRemoveHoverClass(this); > }); > Could also be written in one line. And, as with the above, it doesn't need the event object (e). This is a case where a one-liner is more efficient. Q('tr.task').onRoll(function() { E(this).addClass('hover'); }, function() { E(this).removeClass('hover'); }); Starting to convert it to use the API makes it better still:- Q('tr.task').onRoll(function() { API.addClass(this, 'hover'); }, function() { API.removeClass(this, 'hover'); }); But, as mentioned, a pure API solution would be best as it could use delegation.
From: Matt Kruse on 6 Apr 2010 22:49
On Apr 6, 9:24 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > I suppose I really shouldn't write such things off the top of my head. > Didn't quite nail the exact behavior now that I look at the original again. I didn't think it was very difficult. > To match behavior that (I think) the OP's tries to implement, I'd need > something more like these two one-liners:- > var addOrRemoveHoverClass = function(el, b) { > E(el)[b ? 'addClass' : 'removeClass']('hover'); > > }; Pretty basic, yes. And basically what is already in jQuery. > Q('tr.task').onRoll(function(e) { > addOrRemoveHoverClass(this, true);}, function(e) { > addOrRemoveHoverClass(this); > }); > Granted, that will attach listeners to each task row, which is hardly > ideal. Indeed, not only not ideal, but impractical and a bad idea. What does "onRoll" mean? Seems like a very bad name. How do I know if I need Q() or E()? Seems like the single $() convention is better, as both return elements to take action on. I'm not sure why you wouldn't just do this: Q('tr.task').onRoll(function(e) { E(this).addClass('hover');}, function(e) { E(this).removeClass('hover'); }); and avoid the extra function. And that basically mirrors jQuery's hover() method, right? But in spite of all that, the one-liner I posted actually uses event delegation, which is the preferred method (especially since in this example content will be added via ajax). You can't just ignore that when writing a comparable solution using ML, can you? > However, Resig's scheme is even worse as it will have to run > *queries* in response to mouseover/out/enter/leave events. Does it? When? > This would take a half dozen lines of API code to accomplish with > delegation. I'll leave that as an exercise. Well, it's a trivial one-liner in jQuery and runs quite well. Why would I switch to ML, which would require me to write a number of lines of code and which doesn't even have an example of the functionality? Seems like a step backwards, at least in the API. > Shouldn't be too hard as > you can inspect the rollover code on the Build Test page. That leads > straight to a private function that demonstrates how it is done > (rolloverListenerWithParentCheck). And if you look very carefully, you > will see there is a missing footnote on the builder (Rollover module > needs the DOM module to do elements with descendants). That's a > definite oversight (and a fairly rare sort of caveat), but then when a > quarter of the Object Reference is still missing (for at least one more > day), it's not a top priority. At this point, I throw up my hands and say "it's not worth it. ML is clearly not mature. I'm not going to spend hours trying to figure all that out." > And whatever sort of ill-advised scheme is intended, I would advise > trying a CSS-only solution first. Not applicable for IE 6/7. > Of course, the idea of falling back > (with a conditional comment) to something like "Live" for IE6's > "benefit" is pretty ludicrous (for one, IE6 is terribly slow with > queries). I have to wonder what the OP was trying to accomplish with this. Simple highlighting of rows on hover. In this case, the # of rows are limited, so swapping a class is fine. With more rows, I would certainly switch to altering the backgroundColor directly. Matt Kruse |