Enhancement Request: make css() parse 'hide' and 'show'

[alex.moon@…]

Hey everybody.

I'm working on a site at the moment where I'm storing certain states for animated elements as JS objects which are passed to css() and animate(). Obviously a lot of properties can be passed to both, and the ones that can't can be caught and either translated or applied before the call to css() or animate().

jQuery's great power is its intuitive versatility, and it is comforting that css() and animate() will silently ignore any properties they can't handle, but it seems to me that situations similar to mine wouldn't be that uncommon. Hence, it would make sense (to me at least) to rewrite css() such that it applies these properties.

So: css('height','hide') would be functionally equivalent to css('display','none') css('opacity','show') would be functionally equivalent to css('display','') (or perhaps something more like:

  //pseudocode
  if(css('display')=='none') { css('display','block') }
  else { css('display','') }

)

I realise the existing functionality might be entirely deliberate - I request this enhancement only because I've run into nothing so far which it would break.

Thanks all.

[danheberden]

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.

[ajpiano]

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

[alex.moon@…]

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 :)

[anonymous]

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.

[danheberden]

Might make a cool plugin, eh?

[dmethvin]

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.