Velocity Reviews - jQuery Attribute Summit--Latest Coverage

Good evening. Tonight jQuery looks at one of the major problems on the
Web today - that old vexed question of what is going on with attr. Is
there still time to confront it, let alone solve it, or is it too
late? What are the figures, what are the facts, what do people mean
when they talk about attr? :)

http://groups.google.com/group/jquer...ef5e91bd714033

Starts out promising enough:-

"I think attr() needs some long-over-due re-thinking. It's definitely
very broken as-is, doesn't do what the documentation says it does, and
is a constant (justified) source of criticism of the jQuery library."

But it was too early to tell. :)

The first response I would expect would be a definition of the
method's purpose and the expected results (or at least a recitation
from the incorrect documentation).

But not from the author of jQuery:-

"Do you have any specific examples?"
....

"Do you have any specific examples?"
....

"Do you have any specific examples?"

....

"Specific filed bugs and test cases would certainly accelerate the
process."

Actually, patching without understanding results in patchwork quilts
that (sort of) work in the last browser versions tested. Then things
change (e.g. IE8 comes out) and nobody knows the ramifications:-

"This is core functionality, and filing/patching bugs on specific
problems with individual attributes wouldn't be very helpful."

But Resig had a tray full of Kool-aid for the delegates.

"It's only a backwards step if you're attempting to use .attr() as a
glorified way to set DOM 0 events - which is not really something that
jQuery is designed for nor does it encourage."

So, it's a glorified way to set properties some times, attributes
another and CSS in still other cases. And setting certain properties
(they are only aware of the one reported example of DOM0 events) in
certain browsers (they only test FF) throws exceptions. Does that
about cover it?

"At least looking at the current test suite results I'm not really
seeing any major systemic issues. Of the 9 currently failing tests in
Firefox 3.5 8 of them are cases where the suite is expecting a null
value when an attribute doesn't exist"

9 times. In FF3.5 (of course).

They are using tests for my wrapper functions to test their (slightly
different) designs (which have never been formalized). If they don't
know what they are testing for, how can any set of tests help them?

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

Spot on!

"We should also figure out which attributes merit support."

Oh brother did this just take an ominous turn. And are we talking
about attributes or properties? Clearing that up should have been the
first item on the agenda.

"Supporting every known (and unknown) HTML attribute will certainly
bloat the code
base and provide negligible benefit"

Bullshit. That's like a calculator missing a few number keys.

"Additionally I don't think we should necessarily be trying to
replicate the underlying DOM-specified behavior in all browsers.

What does that mean?

"jQuery has already made the inherent push to remove the user from the
bizarreness of the DOM, no reason to not continue that now. "

An inherent push? Regardless, all they've done is confuse the hell
out of DOM manipulation. It's not surprising as they clearly don't
understand it at all. ;)

"I've removed the .attr(fn) getter functionality as a sign of good
faith."

Okay, fair enough. Everyone re-download please (and put out a recall
on blog posts featuring this subject).

http://www.mrspeaker.net/2009/11/26/...ry-trick-attr/

Like that one.

"To start I've created a page that's a rough dump of the contents in
the HTML 4 spec:"

That is quite a dump. What was wrong with the original? And why was
it not consulted years ago?

http://docs.jquery.com/How_Attributes_Work

No, I'm sure I liked the w3c version better. ;)

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

He just keeps setting me up. :) I'll resist that one (it's
Christmas).

"The only place I use attr extensively is when I want the href value
of a link for further manipulation to unobtrusively convert non-JS
functionality to JS functionality, most commonly when the href is for
a document fragment"

But that would be an _attribute_ value. And what if you want the
resolved URI held by the property? They are basically crossing wires
at random in an attempt to produce... something. Nobody seems to know
what that something is.

"Obviously I could go down to getAttribute, but I've never had a
problem using it like this."

Obviously. Unless you pass some of the other umpteen URI-related
attribute names

that return _property_ values. It's determined by a "white list" of
"special" attribute names, which is updated at a glacial pace (or not
at all) as observations are reported. It's a hard way to go
considering the specs have been sitting there for a decade.

"I use .attr() to get the href attribute value, too."

And use it to get _property_ values for others. :)

"Because height() tries to do so much magic, it ends up that this:

$o.attr('height',$o.attr('height'));

actually gives wrong results. IMO, attr() should be reflexive in that
calling attr() to set a property with a value retrieved from attr()
should always maintain the same value. I just really think the whole
idea of calling methods when getting/setting attributes is bad. What
is the real basis for it?"

That's what I want to know.

"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)."

Nothing ever "just works" in jQuery. And that word "better" is a
troubling indicator. Do they understand it's roughly a one-line fix
to make - onclick - work cross-browser. Currently it throws an
exception in FF, so I guess - click - is better from where they
sit. ;)

"After we tackle the attributes we should look at the most common
properties (like innerHTML, innerText, textContent, etc.) and at least
be able to tell users what to use instead or make sure that they're
supported by .attr() directly."

What if attributes tackle them? And what does the rest of that mean
anyway? What to use instead of the innerHTML property? Sure as hell
not anythng in jQuery as it can't even read attributes straight.

"I was 100% serious about a ban concerning everything from CLJ.
Please,
original ideas/concerns/bug reports/test cases only."

If they can't see the bugs, the bugs can't see them. :)

"var a = $(foo).attr(A);
$(foo).attr(A, a);
equals( a, $(foo).attr(A), "Attributes did a round-trip and are still
equal." );"

Yes, that's original. Funny they never thought of this before?

"On the whole though, I'd recommend to just stop reading the group as
who knows what they will try to pull next."

Yes, it could be dangerous. Minds could be snapped.

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

Why do we need a new interpretation of attribute values? Or do they
want property values? Hard to say at this point, three years after
the initial "design" work.

"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"

How is it that grown men are afraid of a technical newsgroup anyway
(even to glance at it?) I guess shattered illusions can be painful.

"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()."

Obviously. And it further illustrates the confusion caused by
intertwining methods with attributes (properties?)

"Doing a Google Code Search yields lots of interesting edge cases that
we'll want to figure out"

No doubt most of the hits are in their own bug tracker. And I doubt
if any of them are "edge cases" (a typical excuse for monumental
gaffes).

"Huh. Unfortunately we really don't want to deal with their bullshit,
especially if they're threatening to sue us."

It's an interesting legal question. Can a newsgroup sue somebody?

"As we're looking to transfer ownership of the code base over to the
Software Freedom Conservancy we can't take code from tainted sources
-"

The who?

"and if you're unwilling to take responsibility for your code then we
really won't be able to accept code submissions from you."

We're _jQuery_ brand managers...

"Thankfully we can still use your help in figuring out a good
situation for the attributes to be in. Looking forward to your input."

Thank God for that. :)

"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"

Uh oh.

"jQuery UI is more then expected to work browser independently, its
implied by its use."

What?

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

Yes, it is good to steer clear of bad information. So how did they
find themselves in this pile-up?

"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()."

Thank you! And that's just the beginning. :)

"So we could disable it on XML documents - but regardless, that is
definitely th exception."

Coulda, woulda, shoulda... Meanwhile, for three years...

"Naturally, they aren't the case - the second is far superior. Setting
a DOM 0 expando property is simply so substitute for binding events
via jQuery."

Oh, IBTD. :)

And there's the "better" attitude again. These are two completely
different things.

"Adding that there is no (for now) symmetry between attr
("height", ...) and attr("height") I am afraid, that I will not be the
only confused one.."

The best most jQuery users could hope for would be slightly more
confused than Resig (who seems completely lost).

"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 for
`.css('color')`? How about other properties, such as 'border-width'
or 'offset'? (*wanders off to a different browser tab to try for
himself*) "

Yeah, me three. What sort of perverse design paradigm is this?

"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 overt aliasing/magic."

Yes, especially for those attempting to write CSS selector query
engines. ;)

"The way how jQuery does mixing properties with attributes is a very
clever thing."

No, it isn't. The typical jQuery user shouldn't need to be conscious
of attributes at all. That's why the name (attr) was mistake #1. The
fact that it actually retrieves property values (in most cases) makes
it even more confusing and all but guarantees they will never
understand what they are doing.

http://groups.google.com/group/jquer...582786ca2195c2

Yes, during all of this babbling, yet another "edge case" appears. No
answer, of course.

"jQuery returns the value-property on form-elements, instead of the
value-attribute. This is a really good thing, because a) a lot of
novice developers don´t know about the difference and are expecting
this behavior b) more advanced developers know the difference, but
want in general to know the value-property of a form element"

And where is this documented? And why is this method called "attr" if
it is expected to return _property_ values?

"With other words the developer gets what he/she wants/expects here."

Then why would they expect _attribute_ values for href?

"If you change your API to this behavior you will
a) break existing code
a) do unexpected things
b) you don´t have a jQuery-method, wich returns the height-/width-
attribute anymore"

Yes, now we see the futility inherent in the system.

"I think, you did a great job mixing properties and attributes"

Think again.

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

Superior? They are two different things. Depending on the context,
you might need one, both or neither.

"2) The returned result from .height() (not .attr('height'), since
that's been temporarily disabled) was somehow different from the
expected value."

It's on that page he ignored. :) If it fails an identity test...

"For the moment ignore XML documents, I think it probably makes sense
to disable attrFn on XML documents."

Ignore XML documents? Where's the accompanying blog post/apology/
recall?

"Just to clarify: .attr("height") no longer exists"

So what is the result of that call now? The undefined value?

"We don't provide a way to get at the original height, or color, or
left offset of an element via .css() and somehow people still manage"

,.,to shoot themselves in the foot time and again. And what is the
"original height"? The attribute value? That doesn't make much sense
either as it can be changed.

"I'm not sure why this should be any different. Additionally it's not
clear that .height() would be returning a different value than the one
that was originally embedded in the page (at least until it's further
manipulated - at which point the current value is the expected result
anyway). "

Oh God. This is worse than I thought. ;(

http://www.cinsoft.net/jquerysucks.html

"Much of this comes back to the intention of .attr() - I think
that .attr() should work more like .css()."

I think it should work more like .bind(). :)

"Giving you the current, computed, attribute value - and should
actively try to route around unexpected values"

Computed attribute value? And how do you determine which values are
"unexpected".

"Actually, the compelling reason is that the specified attribute
height will quickly lose sync with the actual height of the element.

<iframe height="100".../>

$("iframe").height( 1 ).attr("height")
// 100... but it's height isn't 100 any more."

That is compelling. Mismatched method calls, mismatched (and
misinterpreted) results.

"Getting the current, "computed", value is much more useful and
practical to everyday users."

For those contexts that have entered Resig's realm of understanding I
guess.

"height attributes are simply a bit of legacy left over from ancient
documents (as is bgcolor and inline onTYPE event handlers)."

That's bullshit (in every possible sense). It's like saying that
clientHeight is better than offsetHeight. And JFTR, the height
attribute is not a "legacy bit".

"If we cut the crufty legacy code we can build APIs that are much more
cohesive and match the intentions and expectations of the user
better."

Maybe, if they had the _slightest_ clue how to proceed...

"Initially it mapped to anything in jQuery.fn. Now it just maps to
some of the common getter/setters in jQuery: val, css, html, text,
data, width, height, and offset (and the events)."

Yes, three of those are attributes and this also accepts "innerHTML"
as an attribute name (the interface is clearly designed to accept
attribute rather than property names). How is this simplifying
anything?

"An alternative that might work here - and one that would go together
with a mapping of the available attributes - is to simply deprecate
the use of certain attributes (height, width, bgcolor, onTYPE, etc.
come to mind off hand). It's pretty easy to do if we just point people
towards the alternatives that we already provide."

Sure, "deprecate" the height and width attributes, DOM0, etc. It
would be a neat trick if a JS library ("major" or not) could pull that
off.

"Then we can focus all of our energy on just making the remaining set
of attributes work identically (and expectedly) across all platforms."

Attributes? But I thought properties were "better" (in some cases).
Those already work as expected across "all platforms". They do not
work identically, but stepping on the differences does nothing useful
(e.g. changing tabindex of -1 to 0 because most browsers report 0) and
in fact obscures significant details about the host environment. The
goal should not be to make every DOM property report the same thing in
every browser. :)

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

That's too bad as "John and company" surely know ****-all about what
it does (or what it's supposed to do).

"It returns the attribute values of DOM elements."

That's what the docs say. Of course...

"Regardless of what the original html source says, once it's parsed
into a DOM it's a living structure with values that change."

Yes, and the attributes change right along with the DOM properties (in
most cases). Obviously they have _nothing_ to do with CSS.

"I tend to think of the HTML as the "original" values of DOM
attributes, but subject to change"

That's incisive. :)

"jQuery operates on the DOM and as such, it should return computed
values as a matter of course."

More confusion. Attributes are very much a part of the DOM.

"This conflation of DOM and source is probably something that does
come up a lot for beginners and may be part of the learning curve for
jQuery."

Yes it does, but jQuery provides no clear distinction between the two.

"With that being said, I can see it also being useful to be able to
get at the original attribute values specified in the source."

Yes, particularly for this script. ;)

"I don't have any ideas about this and honestly, I've never had a
specific need to do it. But perhaps a plugin geared towards this
would be better. $.htmlattr ?"

No good. The script itself needs this logic internally. Users
shouldn't need to be bothered with attributes at all in most cases.

The last word from Resig:-

"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"

There's a good fellow.

"We can re-explore the issue once we have a better grasp of how all
the existing attributes behave."

This is what I'm talking about. Why do Web developers want to wait
indefinitely for this guy to learn basic DOM scripting? In the
meantime, they can only deploy distilled confusion.

In the end, what did "we" accomplish?

"I've left in the functionality that was there but severely limited it
- you can only use it from an object and only if you pass in 'true' as
the second argument, like so:
.attr({ height: 10, html: "..." }, true)"

Not innerHTML, but "html".

More importantly though, the functionality is now exposed as a quick-
setter for newly-created DOM elements, like so (which is, ultimately,
the result I was trying to achieve with the .attr()
changes anyway):
$("<div>", { height: 10, html: "...", id: "test", click: fn })"

Not onclick, but "click" (the former throws an exception in some
browsers).

"Note that the above doesn't take a context, thus it only works on the
current document (which is fine, since we wouldn't want to use the
method setters on non-HTML documents anyway), and it looks for an
argument that matches isPlainObject(). Also note that it doesn't work
with selectors or more-complicated HTML strings - only for standalone
element creation (<div>, <div/>, and <div></div> - for example)."

I suppose that's as clear as anything said so far on the subject. And
I see they renamed "isObjectLiteral". :)

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

They punt on a lot of browser scripting "edge cases" (like frames and
XML). How do you score that way?

Closing thoughts from dubjadubja:-

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

Well, until we meet again and the case is solv-ed...