Skip to main content

Bug Tracker

Side navigation

#4630 closed enhancement (wontfix)

Opened May 06, 2009 06:06PM UTC

Closed February 17, 2011 08:12PM UTC

Add radioClass method

Reported by: brandon Owned by: brandon
Priority: low Milestone: 1.next
Component: attributes Version: 1.3.2
Keywords: needsreview Cc:
Blocked by: Blocking:
Description

radioClass method (inspired by Ext Core) adds a class to one element and removes it from its siblings. Attached is a patch to include radioClass into jQuery. This creates a dependency of the selectors module to the attributes module which didn't exist before. I didn't use the .siblings() method so as not to create another dependency on traversing.

Attachments (1)
  • radioClass.diff (1.8 KB) - added by brandon May 06, 2009 06:06PM UTC.

    radioClass method

Change History (14)

Changed May 06, 2009 06:38PM UTC by bganicky comment:1

Definitely good addition. I need this too often not to appreciate such a method.

+1

Changed May 06, 2009 06:54PM UTC by memiux comment:2

Yeap, I agree too

Changed May 07, 2009 03:02AM UTC by scrufus comment:3

+1

I would use this a lot.

Changed May 07, 2009 08:28PM UTC by paul.irish comment:4

Would these two then be equivalent?

#!js
$(foo).radioClass('on');
$(foo).addClass('on').siblings().removeClass('on');

Even though Ext may go with radioClass, it doesn't specifically target radio's which can appear misleading; siblingClass() would be more logical to me.

But on the whole, it doesn't seem to be enough of an improvement to deserve it's own syntactic sugar. This would also be the only attribute manipulation method that assumes a specific DOM relationship. A bit odd to me.

-1

Changed May 07, 2009 08:36PM UTC by ajpiano comment:5

not so sure this needs to be in core (though it seem some people like it). the name is certainly misleading, and i think that if something like this is going to go in, it way as well work natively to apply this behaviour on checkboxes, which at present wouldn't really be manipulated by this enhancement.

Changed May 07, 2009 08:49PM UTC by bbonifield comment:6

I'm in agreement with paul.irish in both the naming and usefulness. The method would only be useful when dealing with exclusive classes in sibling relationships.

If you wanted to add something like this, I'd would say it is more valuable to have some flexibility.

Assuming you had

#!js
<div id="parent">
  <h3>heading</h3>
  <ul>
    <li class="active">1</li>
    <li>2</li>
  </ul>
  <h3>heading</h3>
  <ul>
    <li>1</li>
    <li>2</li>
  </ul>
  <h3>heading</h3>
  <ul>
    <li>1</li>
    <li>2</li>
  </ul>
</div>

Something like...

#!js
$("#parent ul:last li:first").exclusiveClass('active', $("#parent"));

Where the second argument would be the scope that you should maintain exclusiveness within (perhaps making it so that the default scope is within the direct parent).

-1

Changed May 07, 2009 09:18PM UTC by cowboy comment:7

I agree with paul_irish completely.

Changed May 07, 2009 11:10PM UTC by redsquare comment:8

I agree with my chums from #jquery.

I'd rather see these type of extension functions go into an 'optional' lib which would be available to download alongside the core. Lets keep the core lean and mean.

Changed May 09, 2009 10:30PM UTC by eduardo comment:9

It's definitely useful.

+1

Changed June 13, 2010 02:43AM UTC by dmethvin comment:10

component: unfiledattributes

Changed October 22, 2010 06:21PM UTC by rwaldron comment:11

milestone: → 1.5
priority: majorlow
status: newopen

Needs review/attention

Changed January 12, 2011 02:02AM UTC by dmethvin comment:12

keywords: → needsreview
milestone: 1.51.next

Changed February 17, 2011 08:07PM UTC by doublerebel comment:13

To have the same behavior as the Ext method, radioClass must also take an array of classes, as in my little plugin here:

http://code.doublerebel.com/jQuery/jquery.radioclass.js

Interestingly, this ticket was filed (and various radioclass blog posts were written) about the same time I created that. I think radioClass would definitely see use.

Changed February 17, 2011 08:12PM UTC by rwaldron comment:14

resolution: → wontfix
status: openclosed

Without a public repo, unit tests or docs, it's hard to support something that already seems easily accomplished with existing core methods - as noted by paul.irish

-1