[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-19 Thread DBJDBJ
Oh, how true my daddy was: "Son (he said) always make the manual first and then give it to the customers. And then son, wait for the dust to settle. And then my son, then start making, whatever is that thing, you are selling my son" ... --DBJ On Dec 18, 8:30 pm, John Resig wrote: > > What about

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-18 Thread John Resig
> What about (i)frames? In that case just use the jQuery inside the (i)frame. I'm fine punting on that as well. Optimized for the very-most-common case. --John -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send e

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-18 Thread Roman Neuhauser
# jere...@gmail.com / 2009-12-18 12:52:08 -0500: > I read through the thread again last evening, and mulled it over last > night, and I now agree that there is just too much room for confusion Thanks for the consideration! IMO (and from my experience) .attr is needlessly magic and inconsistent (e

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-18 Thread Dave Methvin
> The results of calling an API > should be very predictable, not open to interpretation and having 10 > different outcomes depending on what you pass in, forcing a user to > consult a big table to see what they can expect to get back for each > input parameter. IMO. That was my concern with the .

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-18 Thread John Resig
I read through the thread again last evening, and mulled it over last night, and I now agree that there is just too much room for confusion (at least at this point) especially since .attr() has always behaved in a particular manner. We can re-explore the issue once we have a better grasp of how all

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-18 Thread Marco Rogers
At the risk of jumping into a conversation that's a little beyond me, I'd like to throw in 2 cents as a long time jquery user. I can follow the arguments being made by those who think attr is broken. But I agree with John and company that the attr function does what it's supposed to do. It retur

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread Matt
On Dec 17, 2:26 pm, Leeoniya wrote: > attr('width') would get the computed > width but attr('width', '5') sets the width attribute? there's too > much room for ambiguity in my opinion. Just to clarify, in the case of width the width() method would get called in both cases. So $o.attr('width')

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread Leeoniya
i agree with matt on this 100%. an attr() method should return the attribute's value, always. there are way too many common cases when interpretation would make this method unreliable and unusable. making something that has so much functionality overlap with css() is not good at all, especially wh

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread Matt
On Dec 17, 11:41 am, John Resig wrote: > Much of this comes back to the intention of .attr() - I think that > .attr() should work more like .css(). Giving you the current, > computed, attribute value - and should actively try to route around > unexpected values (such as .value returning useless va

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread John Resig
> Actually, the compelling reason is that the specified attribute height > will quickly lose sync with the actual height of the element. > > > > $("iframe").height( 1 ).attr("height") > // 100... but it's height isn't 100 any more. > > Getting the current, "computed", value is much more useful and

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread John Resig
> Like Karl said, I have had cases where I want to compare the current > height of an element with what was specified. I've also had cases > where height="x" were hard-coded in the html and I wanted to access > the value (without having control over the html to use css, just > injecting script into

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread Matt
On Dec 17, 10:29 am, John Resig wrote: > I would be much more convinced if there were examples where: > 1) People were legitimately using inline-specified height/width and in > a way that was different from specifying the value in pixels and in > way that was superior to using CSS. > 2) The return

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread John Resig
Just to clarify: .attr("height") no longer exists. --John On Thu, Dec 17, 2009 at 11:47 AM, Karl Swedberg wrote: > I'm curious about what the rationale was for having .attr('height') return > the same thing as .css('height'). Was it just in case people use the wrong > method? > I could see the

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread Karl Swedberg
I'm curious about what the rationale was for having .attr('height') return the same thing as .css('height'). Was it just in case people use the wrong method? I could see the usefulness of having .attr('height') return the actual attribute value in cases where, for example, I needed to see wh

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread John Resig
I would be much more convinced if there were examples where: 1) People were legitimately using inline-specified height/width and in a way that was different from specifying the value in pixels and in way that was superior to using CSS. 2) The returned result from .height() (not .attr('height'), sin

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread alexander farkas
The way how jQuery does mixing properties with attributes is a very clever thing. One simple API for multiple different things is a very nice thing, but has its constraints. An example: jQuery returns the value-property on form-elements, instead of the value-attribute. This is a really good thing

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread Már Örlygsson
> Never ever, would I have guessed that .attr('height') would report a > value on elements that don't have an explicit height `attr`ibute. Somehow I have the feeling that it would be useful for developers to be able to access plain old element attributes - in a cross-browser way - without any over

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-17 Thread Már Örlygsson
> I am afraid, that I will not be the only confused one... I, for one, am very much confused. Never ever, would I have guessed that .attr('height') would report a value on elements that don't have an explicit height `attr`ibute. Should I now expect $(element).attr('color') to work as an alias fo

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-16 Thread Robert Katić
I have to correct my correcting: Both .attr({"height": "180"}) and .attr("height", "180") will call .height(). Still there still is big discrepancy between .attr({ click: function(){/*..*/} }) and .attr("click", function(){/ *..*/}) Adding that there is no (for now) symmetry between attr("height"

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-16 Thread Robert Katić
> > If we have > > >  $(xml).find("foo").attr("height", "180cm") > > > then you would expect calling elem.setAttribute() and not .height(), I > > hope. > > If so, there is a bug in jQuery.attr()... > > So we could disable it on XML documents - but regardless, that is > definitely th exception. I h

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-16 Thread John Resig
> I would note some problems (2): > > If we have > >  $(xml).find("foo").attr("height", "180cm") > > then you would expect calling elem.setAttribute() and not .height(), I > hope. > If so, there is a bug in jQuery.attr()... So we could disable it on XML documents - but regardless, that is definite

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-16 Thread Robert Katić
I would note some problems (2): If we have $(xml).find("foo").attr("height", "180cm") then you would expect calling elem.setAttribute() and not .height(), I hope. If so, there is a bug in jQuery.attr()... Other think to take in consideration is that $("div").attr("click", function(){ /*..*

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-16 Thread Rick Waldron
So... that example still doesn't use: *.attr('onclick', function() { /.../ }); * * * But I see where you're coming/going with this (as far as purpose, not syntax). It simply adds more credence to my point, as it's getting/testing a value, not setting. * * Rick * * On Wed, Dec 16, 2009 at 12:5

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-16 Thread Robert E. Rothermel III
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

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-16 Thread John Resig
I think these lines, for example: isHsAnchor : function (a) { return (a.onclick && a.onclick.toString().replace(/\s/g, ' ').match(/hs.(htmlE|e)xpand/)); }, That is some awful, awful, code. Considering that this code in no way uses jQuery I don't see how making the changes would cause any

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-16 Thread Rick Waldron
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> wrote: > The only time that I

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-16 Thread Robert E. Rothermel III
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 apolog

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread Rick Waldron
John, that last resource you posted is great, kangax is the man. Rick On Tue, Dec 15, 2009 at 4:40 PM, John Resig wrote: > > 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

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread Rick Waldron
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()

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread John Resig
> 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. Excellent, appreciate your help! Doing a Google Code Search yields lots of interesting edg

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread Matt
On Dec 15, 11:32 am, John Resig 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

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread Matt
On Dec 15, 11:21 am, John Resig wrote: > Hmm, I don't remember the bug off-hand but here's the reproduction: > Failing:http://ejohn.org/files/bugs/selected/ > Passing:http://ejohn.org/files/bugs/selected/fixed.html Ah, I see. The description in the source is misleading. Note that this only happe

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread John Resig
> 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

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread John Resig
> 1) I cannot find the rationale for this. Or even where this "bug" is > discussed. Can anyone point me to it? I am curious. > >        // Safari mis-reports the default selected property of a hidden > option >        // Accessing the parent's selectedIndex property fixes it >        if ( name == "

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread Matt
On Dec 15, 10:24 am, Diego Perini wrote: > it is not only "href" that has problems, seems all attributes having > an URI string as value have to be read in the way you described. > Some of them are: action, cite, codebase, data, href, longdesc, > lowsrc, src, usemap. The root cause, if I'm not mi

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread Matt
On Dec 14, 12:31 am, John Resig wrote: > For example, documenting that disabled/selected/etc. are expected to > return boolean values. Documenting the expected value returned from > zIndex. Documenting what happens with relative URL resolution across > browsers. > THEN we can go back and fill in t

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-15 Thread Diego Perini
Karl, it is not only "href" that has problems, seems all attributes having an URI string as value have to be read in the way you described. Some of them are: action, cite, codebase, data, href, longdesc, lowsrc, src, usemap. In IE6/7 elements have a predefined number of attributes (minimum 80, va

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-14 Thread Karl Swedberg
I use .attr() to get the href attribute value, too. If you use .getAttribute(), IE6 and IE7 require a second argument to really, truly get the attribute: somelink.getAttribute('href', 2) --Karl Karl Swedberg www.englishrules.com www.learningjquery.com On Dec 14, 2009, at 10:0

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-14 Thread Scott Sauyet
On Dec 13, 11:27 pm, Matt wrote: I'm not going to jump into these murky waters, but I want to follow up on this bit: > As it is now, I always recommend that attr() be avoided in code, and > if someone uses it in code I am looking at, I tell them to remove it. > It's too fragile and the logic tha

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-14 Thread Robert Katić
> I disagree. Being able to set all the (useful) properties of a DOM > element via a single object structure can be very useful - and I see > no reason not to overload the existing .attr() behavior if it already > covers most of the functionality well and if there are no conflicts. I > especially t

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-13 Thread John Resig
> Well, I have to admit that I am not too happy in which direction attr > () is going. > Adding to much magic is not simplifying the API to me. > If we (John) wont an method that can do everything (including > bindings!), than I would prefer it as an separate method ("set()" ?) > leaving rest of AP

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-13 Thread John Resig
> I will take a look at this when I get a chance. I'm not going to copy > his code, but if there are any similarities then he can sue me. > > I think one of the core problems is understanding what attr() is > intended to do. Clearly it is not just a get/setAttribute wrapper. > Clearly it is not jus

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-13 Thread Robert Katić
> I think one of the core problems is understanding what attr() is > intended to do. Clearly it is not just a get/setAttribute wrapper. > Clearly it is not just meant to access the properties of elements. It > is a mixture of several different ways to access "attributes" of an > element, and it app

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-13 Thread Matt
On Dec 13, 6:06 pm, John Resig wrote: > Just got word from Paul Irish that David Mark is refusing to provide > an open license for his attribute test suite - in fact he's > threatening legal action against me and the Software Freedom > Conservancy if we should "cop[y] one word or the tiniest aspec

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-13 Thread John Resig
Just got word from Paul Irish that David Mark is refusing to provide an open license for his attribute test suite - in fact he's threatening legal action against me and the Software Freedom Conservancy if we should "cop[y] one word or the tiniest aspect of the design". Naturally, that branch with t

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-11 Thread John Resig
> For example: > > > $('#x').attr('readonly') === true > > This is a boolean property of the element, not its attribute value. > The name attr() implies that it deals with attributes. But the code > actually gets/sets properties as the first line of business. I would > expect to get back the strin

[jquery-dev] Re: attr() is still very broken in 1.4a1

2009-12-11 Thread Matt
On Dec 11, 11:10 am, John Resig wrote: > > 1) It still confuses properties and attributes, which is its biggest > > problem. Behavior is unpredictable. This is bad. > Do you have any specific examples? For example: $('#x').attr('readonly') === true This is a boolean property of the element, no