Skip to main content

Bug Tracker

Side navigation

#12793 closed feature (wontfix)

Opened October 26, 2012 06:19PM UTC

Closed October 26, 2012 06:26PM UTC

Last modified October 26, 2012 08:50PM UTC

.fadeToggle(boolean) and .slideToggle(boolean)

Reported by: david71rj Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.8.2
Keywords: Cc:
Blocked by: Blocking:


.fadeToggle(boolean, ...)
.slideToggle(boolean, ...)
to work similar to
.toggleClass(string, boolean)

Currently it is possible with a workaround.

  // Somelines method
  if(theBoolean) $el.fadeIn('slow');
  else $el.fadeOut('slow');

  // Workaround method
  jQuery(el)[theBoolean ? 'fadeIn' : 'fadeOut']('slow');

I think that it is acceptable, once that both methods not accept a boolean in args.

  jQuery.fn.fadeToggle = function(
    optional mixed duration,
    optional string easing,
    optional function callback,
    optional boolean showOrHide
  ) {
    /* ... */
Attachments (0)
Change History (7)

Changed October 26, 2012 06:26PM UTC by rwaldron comment:1

resolution: → wontfix
status: newclosed

Good for a monkey patch, but core is going the way of less complexity

Changed October 26, 2012 06:35PM UTC by david71rj comment:2

Hum... I guess that doesn't is a complexity, but a facility. If I need use a workaround to do it (with Core features), so Core is not suficient. Someone can post a third opinion (to tie), please? :)

Seems only that it is *incompatible* with jQuery source method to .fadeToggle(). (the bad part).


Changed October 26, 2012 06:53PM UTC by rwaldron comment:3

_comment0: Was this a feature or a bug fix? It was filed as a feature. 1351277668992278

Was this a feature or a bug fix? It was filed as a feature. If there is a bug, please identify and we'll re-open

Changed October 26, 2012 07:36PM UTC by david71rj comment:4

Well, currently it doesn't defined. For me is a improvement/feature. But I think it is need to Core, and the implementation is very easy. Don't will break jQuery too.

Changed October 26, 2012 07:46PM UTC by rwaldron comment:5

Sorry, this isn't compelling enough to change the core library. Anytime a new method signature overload is introduced, it inevitably introduces bugs in existing code and requires maintenance.

Changed October 26, 2012 08:23PM UTC by david71rj comment:6

A good reason to the jQuery Test Suite exists, not? :P

Well... I think that it probably will slowdown jQuery execution, really, with my tests, it'll slow between 0% to 3% ( in 6 million executions.

But on real, I think that you need to consider that jQuery animate in fade and slide by Core currently, and too have showOrHide arg in other methods (but with "static animation").

Well, I'll not to insist very much, only I think that need be part of Core (because of 1+1 sum above). But the jQuery Team need see the best to framework, and not to specifically *my problem* (hum, not is really a problem).

In .fadeToggle() page you can see an user told about this same feature request.

Changed October 26, 2012 08:50PM UTC by dmethvin comment:7

This is digressing into a meta-discussion about API design.

It's not just about performance or whether it is technically possible to implement with a few lines of code inside jQuery core. It's about the benefit versus the complexity and size of code/documentation, the odds of breaking something, and the user's learning curve. If we (or JavaScript) provide a simple way to compose two things, that is often better than adding code and documentation to pre-compose them via complex signatures--even if it is slightly longer.

Complex APIs are difficult to document, hard to remember, and often have conflicting or non-intuitive results. For an example, see the 33 different options for $.ajax(), the 3 completely different semantics for $().toggle() or the 9 different signatures for $(). Try to figure out whether $(elem).load(x) will load content via AJAX or set an onload handler without knowing the data type of x. Go see what happened when we made .outerWidth() a setter in 1.8.

jQuery was meant to be easily extended by users so they can use it in a way that works for them. We should not be creating a complex API that reflects the union of all thoughts about how to use jQuery in all situations.