> 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 just meant to access the properties of elements. It
> is a mixture of several different ways to access "attributes" of an
> element, and it apparently tries to pick the best approach and give
> the user what they want. Calling height() instead of accessing
> a .height property or doing getAttribute('height') may give some users
> what they expect, but is it predictable? What if I really do want the
> 'height' property, and not the current computed value? How will I know
> which I am going to get?
>
> If my current markup has an 'xxx' attribute and jQuery successfully
> gets the attribute value, but then later adds a xxx() method and
> returns that value instead, upgrading jQuery will break my code. But
> how could I have known that this would happen? Knowing what attr()
> will do has become entirely unpredictable, and even writing test cases
> becomes difficult because it's not clear what the method is _supposed_
> to do.
>
> 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 that it is intending to code is not
> well documented, so we can't depend on it. Luckily, it's easily coded
> around. Unfortunately, many plugins and examples use it quite a bit.
>
> Since this single method is such a consistent base of attack on
> jQuery's quality and robustness, and because it is used so often in
> code, I think it would be a good idea to clarify what attr() is really
> intended to do and put it into words. As it is now, I'm not sure
> anyone can really concisely describe it.I think this sounds like a good idea - while I'm (naturally) not as pessimistic as you as to the state of attr() I think that a better understanding of its true goals (in the form of documentation, fed back into a test suite) would be admirable. 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 the test suite as appropriate. We should also figure out which attributes merit support. Supporting every known (and unknown) HTML attribute will certainly bloat the code base and provide negligible benefit. Additionally I don't think we should necessarily be trying to replicate the underlying DOM-specified behavior in all browsers. jQuery has already made the inherent push to remove the user from the bizarreness of the DOM, no reason to not continue that now. I've removed the .attr(fn) getter functionality as a sign of good faith. I would like to explore this further and still think it deserves a lot of merit but I agree that we should asses the full implications first. http://github.com/jquery/jquery/commit/b4b30cc6837dc5480f3d1a3da0cb9fe12dfc9b72 To start I've created a page that's a rough dump of the contents in the HTML 4 spec: http://www.w3.org/TR/html4/index/attributes.html Into the following page: http://docs.jquery.com/How_Attributes_Work The next step will be to categorize the attributes and figure out how, or if, they should be supported. I plan on taking a stab at this tomorrow. --John -- 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.
