I think in the case of the css method, the overhead and filesize of checking for helper values trumps the usefulness of that implementation. Particularly, using the css method implies you are setting css properties.

Such as css('display', 'block'), other developers using/viewing my code and myself will easily know what the heck i'm doing here.

I agree with Dan... Not sure if the overhead here is worth the "benefit" of allowing complete 100% interoperability between the options objects that one can pass to .css() and .animate()

Thanks for the replies guys. Concerning overhead, you would know better than I - I understand how elusive these things are when you're looking at a black box (as I am).

I will just note that, in reply to Dan concerning readability of the code, in my own project I have situations like this:

--snip--
'element.init':{height:100},
'element.collapsed':{height:'hide'},
'element.expanded':{height:'show'}
--snip--

That is to say, the element is given an original height (or width or top or whatever) when it is initialised (using the state "init"), and then is shown or hidden by referring to the states "expanded" and "collapsed" respectively. I feel what I'm doing is more understandable written thus, as opposed to, say,

--snip--
'element.init':{},
'element.collapsed':{height:0},
'element.expanded':{height:100}
--snip--

which can be passed natively to css() - moreover the latter implementation doesn't allow me to have any elements with ''element.init:{height:'auto'}''. So, I've written it the former way and written tests in the collapse() and expand() functions for 'hide' and 'show'.

As you've implied, of course, this situation is somewhat unique. As you may be able to infer I'm animating a lot of elements, for each of whom the 'init', 'collapsed' and 'expanded' CSS is different (fontSizes, paddings, margins, lefts, bottoms, transforms, opacities etc. also come into play). As jQuery becomes more popular I wonder if this kind of writing isn't going to be more prominent. Consider applications like Facebook and iGoogle which, no doubt, do expanding, collapsing, dragging, etc. with as little redundancy across elements as possible.

But ultimately I don't know enough about the implementation of css() and animate() to do any kind of cost/benefit analysis, so ultimately it's up to the jQuery team.

Thanks again for the input Dan and AJ :)

In case it wasn't clear, the reason I need to pass these states to css() is because after an element is initialised it has a default state, collapsed or expanded or whatever, which is determined dynamically. If this default state is collapsed then the result is that the element shows on screen and then slides up, as opposed to being originally invisible.

Perhaps there's a more elegant way of coding this using the existing jQuery system.

Might make a cool plugin, eh?

This does sound like a better job for a plugin. We do extend the values with .animate() for example, but there is a W3C spec regarding CSS values. I don't think we want to be doing too many magical things there.