Line 688... I saw it because I was trying to use .live() and this check shot that to pieces... If the link doesn't pass this check it's assumed to not be a Highslide link, even if the link has the "highslide" class applied.
isHsAnchor : function (a) { return (a.onclick && a.onclick.toString().replace(/\s/g, ' ').match(/hs.(htmlE|e)xpand/)); } It's a bad idea, imho. The writers of the library assumed that every link could have it's own custom display parameters as part of the onclick handler... something like <a onclick="return hs.expand(this, { /* options */ };" ...> The problem is that the options should still be stored in an external JS to be semantic, and if you try to do a full page of images (a gallery or contents table in a store) with Highslide handlers on each image, it's an incredible amount of code fluff. Rob Rick Waldron wrote: > I've searched the source... maybe I missed it, but I cant find your > example... > > http://highslide.com/highslide/highslide-full.js > > > Rick > > On Tue, Dec 15, 2009 at 5:03 PM, Robert E. Rothermel III > <thirden...@gmail.com <mailto:thirden...@gmail.com>> wrote: > > The only time that I can think of where one would want to use > .attr('onclick', function() { /.../ }); is Highslide... it > actually runs a regex on each A tag to see if the string > "hs.expand" is in the onclick attribute. > > > Rick Waldron wrote: >> I've been reading this thread right along and I apologize for >> being the late one to the party, and I wasn't going to bother, >> because its not at the core of the discussion, but I'm still >> perplexed. >> >> Why would you want to use: >> >> .attr('onclick', function() { /../ }); >> >> When exists: >> >> .click(function() { /../ }) >> .bind('click', function() { /../ }) >> .live('click', function() { /../ }) >> >> ..... >> >> Or, this? What practical application does this have? Where a dev >> would set the height of an element with the height of the same >> element. >> >> $o.attr('height',$o.attr('height')) >> >> ...I understand that in the context of test cases, round-trip >> value getting/setting ensures that methods are reliable, but in >> the real world? >> >> >> Perhaps my understanding of javascript beyond jquery is the >> reason, but I've never, not even once, had an issue with attr() >> doing what *I intended* it to do - like I said, it could be >> because I'm not expecting it to do anything particularly zany, >> like setting a value with the same value from the same source. >> >> Also, for a method that you're so quick to call "broken", I >> decided to do a reality check of code that is expected to *always >> and only work with jQuery*... I dug through jQuery UI 1.7.2 and i >> found something not-too-shocking: only 1 occurrence of >> "getAttribute" (in datepicker... line 6166), 1 occurrence of >> setAttributeNS() (in $.ui.* ) and 1 occurrence of >> removeAttributeNS() (in $.ui.*). 47 occurrences of .attr() (a >> mix of string and object argument syntaxes) and 12 .removeAttr()'s >> >> jQuery UI is more then expected to work browser independently, >> its implied by its use. >> >> >> Furthermore, after looking at that site you referenced several >> times (that i will not copy/paste here), I second a move to 100% >> ban all references, along with the newsgroup you cited. I realize >> you feel as though ignoring certain sources might leave you in >> the dark, but my advice would be to try and steer clear of bad >> information. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Dec 15, 2009 at 3:22 PM, Matt <m...@thekrusefamily.com >> <mailto:m...@thekrusefamily.com>> wrote: >> >> On Dec 15, 11:32 am, John Resig <jere...@gmail.com >> <mailto:jere...@gmail.com>> wrote: >> > > I think this is a great approach, and I hope it goes >> somewhere. How >> > > exactly can I help with it? >> > Categorizing the "types" would be a great start. Types that >> should >> > "just work", Types that should return booleans, types that we >> > obviously don't care about (attributes of isindex, for >> example), and >> > attributes that we provide better alternatives for (Using >> .click() >> > instead of .attr("onclick", fn), for example). >> >> I will take a look at this. I may come to different >> conclusions than >> you, but I will propose something. Having a dump of all the >> attributes >> and documenting what to expect from each would be fantastic. >> >> > > Because height() tries to do so much magic, it ends up >> that this: >> > > $o.attr('height',$o.attr('height')); >> > I was 100% serious about a ban concerning everything from >> CLJ. Please, >> > original ideas/concerns/bug reports/test cases only. >> >> Seems petty to me. There is a good test case there that >> illustrates >> the problem. I'm not going to reproduce it to shelter jQuery >> from CLJ. >> >> Nevertheless, since attr() calls height() for both getter and >> setter, >> the real problem is that >> $o.height( $o.height() ) >> is not reliable in some cases. So perhaps the issue is there, >> instead >> of with attr(). >> >> > On the whole though, I'd recommend to just stop reading the >> group as >> > who knows what they will try to pull next. >> >> I've never been a fan of head-in-the-sand. I can find the >> pearls of >> wisdom in the posts there without taking anything personally. And >> there is a lot of good, robust, deep stuff posted there that >> you won't >> find in blog posts or discussions here. To each his own. >> >> Matt Kruse >> >> -- >> >> You received this message because you are subscribed to the >> Google Groups "jQuery Development" group. >> To post to this group, send email to >> jquery-dev@googlegroups.com <mailto:jquery-dev@googlegroups.com>. >> To unsubscribe from this group, send email to >> jquery-dev+unsubscr...@googlegroups.com >> <mailto:jquery-dev%2bunsubscr...@googlegroups.com>. >> For more options, visit this group at >> http://groups.google.com/group/jquery-dev?hl=en. >> >> >> >> -- >> >> You received this message because you are subscribed to the >> Google Groups "jQuery Development" group. >> To post to this group, send email to jquery-dev@googlegroups.com >> <mailto:jquery-dev@googlegroups.com>. >> To unsubscribe from this group, send email to >> jquery-dev+unsubscr...@googlegroups.com >> <mailto:jquery-dev+unsubscr...@googlegroups.com>. >> For more options, visit this group at >> http://groups.google.com/group/jquery-dev?hl=en. > > -- > > You received this message because you are subscribed to the Google > Groups "jQuery Development" group. > To post to this group, send email to jquery-dev@googlegroups.com > <mailto:jquery-dev@googlegroups.com>. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com > <mailto:jquery-dev%2bunsubscr...@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en. > > > -- > > You received this message because you are subscribed to the Google > Groups "jQuery Development" group. > To post to this group, send email to jquery-...@googlegroups.com. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.