Add .hoverClass() and .focusClass()

550 views
Skip to first unread message

Scott González

unread,
Dec 18, 2008, 4:23:57 PM12/18/08
to jQuery UI Development
With the new CSS framework, there will be the need to add hover and focus classes to several elements.  In many cases, toggling the class will be the only logic for hovering or focusing an element.  This will require code like the following:

$(el).hover(
    function() {
        $(this).addClass('ui-state-hover');
    },
    function() {
        $(this).removeClass('ui-state-hover');
    }
);

Rather than duplicating this code over and over, I'd like to propose adding .hoverClass() and .focusClass() methods.

The above code would be replaced with:

$(el).hoverClass('.ui-state-hover');

Similarly, there would be:

$(el).focusClass('ui-state-focus');

Here is the accompanying ticket: http://ui.jquery.com/bugs/ticket/3673

Richard D. Worth

unread,
Dec 18, 2008, 5:01:10 PM12/18/08
to jquery...@googlegroups.com
+1

Scott and I discussed this already somewhat and I was concerned about possible naming conflicts. google 'jquery focusClass' and nothing. google 'jquery hoverClass' and you find one plugin that is this same implementation, and a 2yr old ticket in jQuery Trac suggesting the addition, marked worksforme. So the likelihood of colliding with someone (a plugin, or jQuery itself someday) AND having the result be unexpected seems quite low.

- Richard
(No detected libraries)

Jörn Zaefferer

unread,
Dec 18, 2008, 6:28:41 PM12/18/08
to jquery...@googlegroups.com
Seems useful to me!

Jörn

Eduardo Lundgren

unread,
Dec 18, 2008, 6:30:44 PM12/18/08
to jquery...@googlegroups.com
+1
--
Eduardo Lundgren
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.

Scott González

unread,
Dec 19, 2008, 10:57:02 AM12/19/08
to jQuery UI Development
Because this will bind events, we'll need a way to remove the event handlers.  Anyone have ideas?

We could add an additional method:
.unbindHoverClass()
.removeHoverClass()

We could apply a namespace to the handlers 'ui-hover' and 'ui-focus' and then tell users to unbind them on their own:
.unbind('.ui-hover .ui-focus')
* this would make it difficult to remove a single class when there are multiple classes:
$(el).hoverClass('foo bar').unbind('.ui-hover').hoverClass('bar')
vs.
$(el).hoverClass('foo bar').removeHoverClass('foo');


Thoughts?


On Thu, Dec 18, 2008 at 4:23 PM, Scott González <scott.g...@gmail.com> wrote:

Richard D. Worth

unread,
Dec 19, 2008, 11:43:55 AM12/19/08
to jquery...@googlegroups.com
I like unbindHoverClass() remove is too suggested of have add-ed.

- Richard

Brandon Aaron

unread,
Dec 19, 2008, 11:47:02 AM12/19/08
to jquery...@googlegroups.com
This is the code I use to toggle a class on hover:

$(el)
    .bind('mouseenter mouseleave', function(event) { 
        $(this)[ (event.type == 'mouseenter' ? 'add' : 'remove') + 'Class') ]('ui-state-hover');
    });

If you know that the hover class won't be applied before actually hovering you can even just get away with using toggleClass but it is a fragile solution.

$(el)
    .bind('mouseenter mouseleave', function(event) {
        $(this).toggleClass('ui-state-hover');
    });

I've considered making a helper like hoverClass on several projects but in practice I usually need to do more than just toggle the class. I guess what I'm saying is ... I don't know that I'd go through the trouble of making a documented helper method for this. If you are using this very logic in a lot of places, I'd just keep it private to the library.

However, if you do put this in the API, I'd make it take an extra function or two that can apply additional logic instead of having to do more bindings. I'd recommend keeping the unbind process simple and use the unbind syntax with a namespace to remove it.

$(el)
    .hoverClass('test')
    .unbind('.ui-hover')
    .hoverClass('test', bothFn)
    .unbind('.ui-hover')
    .hoverClass('test', overFn, outFn);


Maybe name it hoverWithClass?

--
Brandon Aaron

Scott González

unread,
Apr 1, 2009, 7:58:34 PM4/1/09
to jQuery UI Development
I just talked to Richard about a new idea for how to handle this:

Add methods to $.widget.prototype to add the hover and focus class functionality.  The use would look like:

this._hoverable(element);
this._focusable(element);

Then the widget factory can handle clearing the classes when the plugin is disabled and unbinding the events on destroy.

Thoughts?

Richard D. Worth

unread,
Apr 1, 2009, 8:33:45 PM4/1/09
to jquery...@googlegroups.com
For an example of about how much code we're talking about saving for each plugin, see

http://dev.jqueryui.com/changeset/2430

- Richard

2009/4/1 Scott González <scott.g...@gmail.com>

Paul Bakaus

unread,
Apr 2, 2009, 1:04:20 AM4/2/09
to jquery...@googlegroups.com

Eduardo Lundgren

unread,
Apr 2, 2009, 1:06:33 AM4/2/09
to jquery...@googlegroups.com
Sounds good for me too.

+1

Scott Jehl

unread,
Apr 2, 2009, 7:51:58 AM4/2/09
to jquery...@googlegroups.com
+1

Scott Jehl

unread,
Apr 2, 2009, 8:42:46 AM4/2/09
to jquery...@googlegroups.com
Should we make one for active state on mousedown/up too? Not sure...

Richard D. Worth

unread,
Apr 2, 2009, 8:48:14 AM4/2/09
to jquery...@googlegroups.com
Scott G and I discussed activate state a bit. I don't think it applies as well, since you wouldn't remove active state on disable. Consider for example

<select multiple="multiple" disabled="disabled">
<option selected="selected">option 1</option>
<option>option 2</option>
<option selected="selected">option 3</option>
</select>

These stay selected even when disabled.

- Richard

Scott González

unread,
Apr 2, 2009, 9:20:06 AM4/2/09
to jquery...@googlegroups.com
On Thu, Apr 2, 2009 at 8:42 AM, Scott Jehl <sc...@scottjehl.com> wrote:
Should we make one for active state on mousedown/up too? Not sure...

As Richard said, I don't think it applies as well.  Especially since in most cases you'll need to bind some functionality on mousedown/up anyway if that activates something, so you're not really saving any code.

I am wondering though if we can roll _focusable and _hoverable into one method.  Do we ever have cases where something reacts to only one?

Paul Bakaus

unread,
Apr 2, 2009, 11:45:42 AM4/2/09
to jquery...@googlegroups.com


2009/4/2 Scott González <scott.g...@gmail.com>

Hovering a jQuery UI widget should *never* focus it.
 



Richard D. Worth

unread,
Apr 2, 2009, 11:49:42 AM4/2/09
to jquery...@googlegroups.com
On Thu, Apr 2, 2009 at 11:45 AM, Paul Bakaus <paul....@googlemail.com> wrote:


2009/4/2 Scott González <scott.g...@gmail.com>

On Thu, Apr 2, 2009 at 8:42 AM, Scott Jehl <sc...@scottjehl.com> wrote:
Should we make one for active state on mousedown/up too? Not sure...

As Richard said, I don't think it applies as well.  Especially since in most cases you'll need to bind some functionality on mousedown/up anyway if that activates something, so you're not really saving any code.

I am wondering though if we can roll _focusable and _hoverable into one method.  Do we ever have cases where something reacts to only one?

Hovering a jQuery UI widget should *never* focus it.

The question is whether there's ever a widget element that is focusable but not also hoverable, or hoverable but not also focusable.

- Richard

Paul Bakaus

unread,
Apr 2, 2009, 11:58:02 AM4/2/09
to jquery...@googlegroups.com

ah - it can definitely be hoverable but not focusable I think (not sure about the other way around). I don't have a concrete example right now, but I would keep them seperated, do the change for all widgets, and then see if it works (or the other way around, and if you're stuck, divide them again).
 


- Richard



Reply all
Reply to author
Forward
0 new messages