Add .hoverClass() and .focusClass()

[Scott González]

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]

+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]

Seems useful to me!

Jörn

[Eduardo Lundgren]

+1

--
Eduardo Lundgren
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.

[Scott González]

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]

I like unbindHoverClass() remove is too suggested of have add-ed.

- Richard

[Brandon Aaron]

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]

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]

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]

+1

--
Paul Bakaus
UI Architect
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus

[Eduardo Lundgren]

Sounds good for me too.

+1

[Scott Jehl]

+1

[Scott Jehl]

Should we make one for active state on mousedown/up too? Not sure...

[Richard D. Worth]

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]

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]

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

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

[Richard D. Worth]

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]

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