On Dec 17, 11:41 am, John Resig <jere...@gmail.com> 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 values on selects
> or making sure that rowSpan and colSpan will always return a value on
> TDs even if one isn't set).
Careful... that opens a can of worms.
If I have html like:
<textarea rows="5" style="height:500px;"></textarea>
Then what should .attr('rows') return? The computed value is surely
not 5, but you can't get a computed value. Toss out that attribute?
Same would go for any attribute that can be over-ridden by css:
<table><tr><td bgcolor="red" style="background-color:blue;">test</
table>
attr('bgcolor') => ???
<input size="5" style="width:500px;">
attr('size') => ???
So do you make a list of presentation attributes and not support them
also? (there are quite a few)
> 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.
The attribute still is! The computed height is not. With a method
named attr(), I would expect the former, not the latter.
> Getting the current, "computed", value is much more useful and
> practical to everyday users.
Only if it is logical and predictable. People calling attr() are
programmers, not casual computer users. 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.
> > 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).
Hmmm... $('<object data="..."/>').attr('data') => ???
You may run into a number of cases that may need "special handling",
at which point you have to have really good documentation about the
intent of the method and what to expect. And as you go forward, you'll
probably find more "oops, I didn't think of that" situations where
this logic causes problems.
Matt Kruse
--
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.
