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
> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On Dec 15, 11:32 am, John Resig <[email protected]
>> <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>.
>> To unsubscribe from this group, send email to
>> [email protected]
>> <mailto:jquery-dev%[email protected]>.
>> 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 [email protected]
>> <mailto:[email protected]>.
>> To unsubscribe from this group, send email to
>> [email protected]
>> <mailto:[email protected]>.
>> 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 [email protected]
> <mailto:[email protected]>.
> To unsubscribe from this group, send email to
> [email protected]
> <mailto:jquery-dev%[email protected]>.
> 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 [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
