Disabled Resizable Styling

[Scott González]

When you disable a resizable element, the ui-state-disabled class gets added to the resizable element, which defaults to an opacity of 0.35.  Resizable probably shouldn't use the .ui-state-disabled class because the element isn't actually disabled and it's not at all unlikely that a resizable element will contain nested widgets which may be enabled while the resizable is disabled.

[Todd Parker]

+1

Todd Parker
to...@filamentgroup.com

On Jul 30, 2009, at 9:25 AM, Scott González <scott.g...@gmail.com>
wrote:

[Scott Jehl]

+1
If I remember right, I've seen this problem in other areas too, like
draggable and sortable. Might be worth looking into.
I'm pretty sure this class should only be used on widgets that are
disabled, but not interactions.

Somewhat related:
I think I've also seen a case where disabling an interaction plugin
added a aria-disabled=true attribute to the element. I'm not sure
that's a good idea considering several behaviors could be applied to
one element (draggable, resizable) and aria-disabled didn't seem to be
descriptive enough of the particular behavior that was disabled (in
this case, there wasn't an explicit aria role being assigned, since it
was just an interaction, not a widget). Thoughts?

[Scott González]

On Thu, Jul 30, 2009 at 9:47 AM, Scott Jehl <sc...@scottjehl.com> wrote:

+1
If I remember right, I've seen this problem in other areas too, like
draggable and sortable. Might be worth looking into.
I'm pretty sure this class should only be used on widgets that are
disabled, but not interactions.

Maybe $.ui.mouse should override the disable/enable methods to handle this for us automatically.
 

Somewhat related:
I think I've also seen a case where disabling an interaction plugin
added a aria-disabled=true attribute to the element. I'm not sure
that's a good idea considering several behaviors could be applied to
one element (draggable, resizable) and aria-disabled didn't seem to be
descriptive enough of the particular behavior that was disabled (in
this case, there wasn't an explicit aria role being assigned, since it
was just an interaction, not a widget). Thoughts?

Let's bring this up on free-aria since it's a problem lots of people will run into with ARIA.

[Scott González]

After thinking about this some more, I'm thinking the base disabled handling (in _setData) should only add the plugin-specific disabled class.  Then all widgets would add the ui-state-disabled class and set aria-disabled = true.

2009/7/30 Scott González <scott.g...@gmail.com>

[Kevin Dalman]

I agree with Scott in that the widget-factory should not be adding
classes in a way that is beyond the widget's control. At a minimum I'd
like to see this implemented in the next version because the current
functionality is causing problems for me.

But here is a more elaborate idea that I posted in the Wiki before
someone pointed me to this thread. Perhaps there is a kernel of an
idea in it...

There should be a way to control what ui-classes are 'auto-added' to
widgets - ideally a *global option* available to all widgets. Perhaps
the widget factory could have a set of 'state-class defaults',
something like...

uiDefaultClass: "ui-state-default"
uiEnabledClass: ""
uiDisabledClass: "ui-state-disabled"
uiHoverClass: "ui-state-hover"

When creating an instance of *any widget*, users could override OR
extend these defaults in the options...

$("#myElement").draggable({
uiDisabledClass: ""
, uiEnabledClass: "ui-state-highlight"
})

It would also be possible to change the options for all instances of
the widget on the page...

$.ui.draggble.defaults.uiDisabledClass = "";

Widget authors themselves could modify these defaults to suit the
widget's specific functionality, with the 'disabled' class being the
most obvious one to address. PERHAPS this could even be extended to
automate the handling of custom widget classes - ie, let the factory
take care of adding/removing state-specific classes.

defaults: {
uiDisabledClass: "ui-draggable-disabled"
}
- OR -
defaults: {
uiDisabledClass: "ui-state-disabled ui-draggable-disabled"
}

Such a solution would fix my problem and simultaneously extends the
factory's ability to customize 'state classes' to suit any type of
widget. I realize widgets can have a custom _setData() method, but it
could be advantageous for this to be built-in so that *every widget*
has the same abilities and option syntax.

This would maintain backward compatibility because the same classes
would be added *unless* the widget OR user specifically overrides the
factory defaults.

/Kevin

[Scott González]

Hey Kevin,

The widget factory is already smart enough to add widget-specific classes for generic states that it handles (currently only disabled).  The real problem here is just that the base widget shouldn't add the generic disabled class, because that behavior doesn't make sense for interactions.  Since the widget factory doesn't know anything about what the plugin will be used for, it can't really add any other classes at all, so I don't think it makes sense to add extra functionality like this.  We also don't want users to be able to change classes to whatever they want because it makes supporting the plugins much harder.

[Kevin Dalman]

Thanks for the feedback Scott,

If the generic classes will be removed from *all widgets*, that works
for me, but I'll clarify a few things anyway...

> The widget factory is already smart enough to add widget-specific classes
> for generic states that it handles (currently only disabled).

I didn't realize that. I noticed that the Draggable widget adds it
onLoad...

(this.options.disabled && this.element.addClass("ui-draggable-
disabled"))

...so assumed it used handled it at other times as well. My bad.

> The real problem
> here is just that the base widget shouldn't add the generic disabled
> class, because that behavior doesn't make sense for interactions.

This is clearly true for *some* widgets, like Draggable. But I assumed
the ui-state-disable state *is appropriate* for other widgets (?).
This is why I suggested *let the widget author decide*, and provide a
way to notify the factory of this choice. If en/disabled is the only
state handled by the factory, then a simple boolean option would
suffice, like addGenericClasses. This is consistent with the
addClasses option Draggable already has (which has no effect on any
disabled classes - tried that ;)

IF it is useful for 'some widgets' to have the generic class handled,
then it seems redundant to make the author add enable/disable handling
*only* to add/remove a generic class when the factory is already
handling classes for these events. So I was looking for a way to let
the factory do it all.

IF the widget *does* specify that generic class should be applied,
there could still be edge-case implementations where this is not
desireable. This is why I thought the same option should be exposed so
users could 'override' the widget default. I don't see this as a
support issue, but as a way to handle special needs *without support*.
But I understand about not allowing widget-specific classes to be
altered.

I'm clarifying this just in case there IS a need for 'some widgets' to
utilize the ui-state-disabled class, and any other generic class that
may be handled by the factory, now or in the future.

But if this is the consensus is to eliminate the ui-state-disabled
class completely, do you think this will be done in the next UI
version? It's causing a small issue for me, so my interest here is
selfish :)

/Kevin

[Scott González]

All widgets will keep the generic class. All interactions will lose
the generic class. It really is that simple.