New labs plugin: ui.selectmenu

[Scott Jehl]

Hi all,
Over at Filament, we've worked out a new UI plugin and I just
committed it into labs.

It's called selectmenu, you can check it out here:
http://jquery-ui.googlecode.com/svn/branches/labs/selectmenu/index.html

The component is designed to replace the functionality of a native
form select element, allowing for enhanced skinning and behavior. You
call it on a select element, like this:
$('select').selectmenu();

The original select element will remain in the page (whether visible
or hidden), and the new selectmenu component will control it. This of
course allows for easy form submission as if this plugin was never
there.

We've got a great deal of functionality already in place, such as:

- keyboard accessibility (arrowing, selecting when both open and closed)
- ARIA support - (tested on NVDA - seems to work well)
- different menu types (popup vs. dropdown)
- widget factory driven (incomplete, but it's a start)
- full theming support
- form label association (click label to focus)
- formatting of options: ability to split option text into better
formatted elements in the UI component. This feature could really use
some feedback, especially on the technical implementation side.

We've filled out the wiki page with more info and ideas:
https://jqueryui.pbworks.com/Selectmenu

We'd appreciate any feedback on the functionality and especially the
code, which we realize can be improved to be in line with our coding
practices.

Also, we'll be posting a lab article on our site about this plugin in
the near future.

Thanks for checking it out. Hopefully this plugin can be reworked and
shuffled into an upcoming release!

-Scott

[Paul Bakaus]

Very cool, nice job!

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

[Wichert Akkerman]

Hi Scott,

On 6/11/09 7:46 PM, Scott Jehl wrote:
> Hi all,
> Over at Filament, we've worked out a new UI plugin and I just
> committed it into labs.
>
> It's called selectmenu, you can check it out here:
> http://jquery-ui.googlecode.com/svn/branches/labs/selectmenu/index.html
>
> The component is designed to replace the functionality of a native
> form select element, allowing for enhanced skinning and behavior. You
> call it on a select element, like this:
> $('select').selectmenu();
>
> The original select element will remain in the page (whether visible
> or hidden), and the new selectmenu component will control it. This of
> course allows for easy form submission as if this plugin was never
> there.

very nice! I was wondering why you use a bunch of spans, instead of an
ul and li elements? Using a list feels more natural (and semantically
correct).

Wichert.

--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

[Scott Jehl]

Hi Wichert
The markup is ul/li currently. Perhaps you firebugged into one of the
formatted option items (which do contain a few spans in the demo page).
See the planning wiki for details on that feature.

The generated markup is listed on the wiki as well.

Thanks!

[Jörn Zaefferer]

Nice work!

I've posted a comment on the wiki page with specifics.

Jörn

[alexander farkas]

Hi,

this is indeed a really nice work.

For Aria-Support:
1. The button (anchor-Element) has no role. I´m not sure wether we
should use combobox/button with has-popup or simply list (but all
these roles should also use aria-expanded=true/false, this last thing
you have to test with FF 3.5b4)
2. the menu-element should have the role list-box instead (with
attribute aria-multiselectable=true/false)

For the technical implementation:
I see a lot of similarities with the normal menu-widget. I think it
should be designed as an addon for this widget. This can also be a
proof of concept for the extensibility of the widget-menu and can push
the development of it further.

BTW:
Who is currently working on the menu-widget? I would like to help out,
there.

regards
alex

[Todd Parker]

We'll take a look at the aria attributes -- thanks for the input.

Although there is some overlap with the simple menu, I think the
approach we're taking is to centralize a lot of the menu code for
positioning and collision detection (positionTo), z-index fix
(stackFix) and shadows (shadow)as separate utilities so these can be
used across plugins but the menu itself will be a fairly rich widget
that might be overkill as for something like this. It would also mean
that every plugin that had any sort of menu (autocomplete, comboxbox,
selectmenu, etc.) would be part of menu or need that as a dependency
and I think we're trying to make these work standaone of we can.

We'd love your help with the menu. There is some code already in /labs/
menu/ that you could start looking at and the wiki page is fairly
complete. Fell free to jump right in and start working on this. Paul
Bakaus did work on an early menu plugin and the one on labs was
written my Maggie Wachs so they will probably be good resources for
you.

BTW - we're trying to keep feedback on widgets on the wiki pages so
add any future comments on the wiki. Maybe even re-post you aria
feedback there for reference. Thanks!

_t

On Jun 12, 8:33 am, alexander farkas <a.farkas...@googlemail.com>
wrote:

[Scott Jehl]

Hey Alexander,
I'll take a look at your ARIA suggestions, thanks for the feedback!

I agree with Todd about keeping this plugin independent of menu. I
think one distinction could be that this is meant to be a form
element, whereas the menu widget is probably meant more for
navigation.I'm not sure, but it seems that the behavior and ARIA could
change depending on that context as well.

The majority of the code weight of this plugin involves tying all of
the interaction back to the original select, and I see that as being
pretty difficult to port to the menu plugin without actually building
it right into the same code base. It would also be a shame to require
the overhead of the menu plugin if all you want is a select menu. As
it is, this plugin is pretty light-weight, and will probably get
lighter with a little cleanup.


As for helping out on the menu plugin, that would be greatly
appreciated!
Paul's version is in the dev branch and I'm sure there's quite a lot
of good code in there already, though I'm not sure how updated it is
for the new framework and design recommendations.

Consider the version of menu in the labs branch to be a presentational
and behavioral recommendation from the design/interaction team, and
the wiki page describes a much fuller feature-set that should be
followed for development.

thanks
-Scott

[alexander farkas]

Hi,

thx for your advices. I have looked yesterday into the menu-codes. I
think I will work on the menu-plugin by paul. It seems to be very well
designed. This means I have to make it themeroller compatible and add
the other features from the fg.menu and the wiki (Aria, keyboard and
so on). Due to the fact, that the positionTo helper is in an early
stage, i would still use the old position-method, included in the menu-
branch and switch to the new helper-method as soon as possible.

About the closeOthers/CloseOnDocumentClick implementations in menu-
and similiar widgets.
I think this kind of behavioral pattern and its implementation needs
to be more clear. In fact in real application-widgets: a widget doesn
´t close because you activate another widget of the same type or
because you click somewhere else. It closes itself, because the user
moves the focus away from the widget.

The implementation is far simpler, than seen in fg.menu, ui.selectmenu
or paul´s ui.menu. It simply looks like this:

var self = this;
this.element
.bind('focusin', function(){
clearTimeout(self.killTimer);
})
.bind('focusout', function(){
self.killTimer = setTimeout(self.close, 1);
});

(This code needs Jörn´s focusin/focusout cross-browser implementation)

[Scott Jehl]

That sounds cleaner than the current way I have the closing logic
working. The only concern I have with that is, with both menu and
selectmenu, the menu button and menu don't share a common wrapper (due
to appending the menu at the end of the body for ie z-index). This
means focus moves between those separate elements while the user is
using a single selectmenu.
I guess to handle this, you'd need to maybe create a custom event for
a blur on the widget as a whole..?



On Jun 14, 2009, at 9:36 AM, "alexander farkas" <a.far...@googlemail.com

[alexander farkas]

If your widget uses two elements, it could look like this:

var self = this;
this.button.add(this.menu)

.bind('focusin', function(){
clearTimeout(self.killTimer);
})
.bind('focusout', function(){
self.killTimer = setTimeout(self.close, 1);
});

On 14 Jun., 16:41, Scott Jehl <sc...@scottjehl.com> wrote:
> That sounds cleaner than the current way I have the closing logic  
> working. The only concern I have with that is, with both menu and  
> selectmenu, the menu button and menu don't share a common wrapper (due  
> to appending the menu at the end of the body for ie z-index). This  
> means focus moves between those separate elements while the user is  
> using a single selectmenu.
> I guess to handle this, you'd need to maybe create a custom event for  
> a blur on the widget as a whole..?
>

> On Jun 14, 2009, at 9:36 AM, "alexander farkas" <a.farkas...@googlemail.com

[malk0]

Great job, i think we perhaps should re-use this for jquery-ui-buttons
(i mean make call to selectmenu for button menu)
What do you think about scott?

[Scott González]

I don't think the button plugin should have any knowledge of the selectmenu.  If you want to have a button which opens a menu on click, that should either be built into the menu plugin or you should create a button that opens a menu in a click event handler.  Also, the selectmenu plugin serves a specific function: replacing native selects.  I don't see why you would want to use it in any other context.  If you want an actual menu, you should use the menu plugin.

[Scott González]

Hey Alex, I think your suggestion about auto-closing widgets when they lose focus instead of clicking somewhere else on the document makes sense.  Can you start a new thread specifically about this?  The focusin/focusout events could be brought into jQuery UI to make this possible.

[Paul Bakaus]

On Sun, Jun 14, 2009 at 10:36 PM, alexander farkas <a.farkas.pm@googlemail.com> wrote:

Hi,

thx for your advices. I have looked yesterday into the menu-codes. I
think I will work on the menu-plugin by paul. It seems to be very well
designed.

Hey Alex,

didn't look at my current code again, but on a quick note, here's two things

to consider when starting over:

- right now, I'm using the positionAround() method call of the old positionTo

prototype in the menu code, so you have to get rid of that to make it work

again I guess (since Gavin is working on refactoring positionTo)

- I left I think with the problem of how to add/remove nodes to a menu. I *might*

  have implemented something already, but I'm not sure.

Anyway, please ping me anytime if you have questions about the current or

future implementation, and I'll try to answer them as good as possible.

Cheers,

Paul

 

This means I have to make it themeroller compatible and add
the other features from the fg.menu and the wiki (Aria, keyboard and
so on). Due to the fact, that the positionTo helper is in an early
stage, i would still use the old position-method, included in the menu-
branch and switch to the new helper-method as soon as possible.

About the closeOthers/CloseOnDocumentClick implementations in menu-
and similiar widgets.
I think this kind of behavioral pattern and its implementation needs
to be more clear. In fact in real application-widgets: a widget doesn
´t close because you activate another widget of the same type or
because you click somewhere else. It closes itself, because the user
moves the focus away from the widget.

The implementation is far simpler, than seen in fg.menu, ui.selectmenu
or paul´s ui.menu. It simply looks like this:

var self = this;
this.element
       .bind('focusin', function(){
               clearTimeout(self.killTimer);
       })
       .bind('focusout', function(){
               self.killTimer = setTimeout(self.close, 1);
       });

(This code needs Jörn´s focusin/focusout cross-browser implementation)