> 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 the page).
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 -
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).
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 values on selects
or making sure that rowSpan and colSpan will always return a value on
TDs even if one isn't set).
> I'm not sure that a good way to define requirements is to ask whether
> or not anyone would do it that way, and whether they had a good enough
> reason to do so. When attr() retrieves property/attribute values in
> almost all other cases, and the user can easily map the results to the
> source, then introducing new behavior with height() etc only adds
> confusion. You cannot explain simply what value will be returned,
> because the height() logic is convoluted. And it considers margins and
> padding, etc, which is _not_ the same as the height of the element
> itself.
>
> Here is my argument: Users can already get the computed height using
> height(). There is no compelling reason to return the computed height
> when doing attr('height'). In fact, making this change _removes_
> functionality, and forces the user to manually code property/attribute
> access if they want to retrieve the value in the source.
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.
Getting the current, "computed", value is much more useful and
practical to everyday users. height attributes are simply a bit of
legacy left over from ancient documents (as is bgcolor and inline
onTYPE event handlers). 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.
> On a related note, you said that the inserted method-calling
> functionality was too broad. What attributes do you plan to map to
> methods - just height and width? Or more?
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).
--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.
