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-...@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.
