> 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 .attr(any_jQuery_method) change, it meant
that certain attribute names behave very differently than others; even
when those magic names are documented it would no doubt surprise many
users. It doesn't seem that burdensome to make the person call .height
() if they really want the current height, rather than the css height
property or the html height attribute. That's the great thing
about .height(), it can mean whatever we want it to mean because it
doesn't carry the history and implied meanings of .css("height")
or .attr("height").
As a counterpoint to that statement, I'll point out that in IE many
values return "auto" when queried by .css(), while other browsers
return the real measurements. The end result of that is many people
who test lightly on IE will write code that ends up doing parseInt
("auto", 10) and getting NaN. Then they try passing that back into
jQuery and complain when it throws an error trying to set the value to
"NaNpx".
Here's one example of many: http://dev.jquery.com/ticket/4915
So I see the problem we're trying to fix here, I'm just not sure if
the proposed solution is the right fix.
--
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.
