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.
> 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'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!
> 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 <wich...@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
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!
On Jun 12, 2009, at 3:47 AM, Wichert Akkerman <wich...@wiggy.net> wrote:
>> 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 <wich...@wiggy.net> It is simple to make things.
> http://www.wiggy.net/ It is hard to make things
> simple.
On Fri, Jun 12, 2009 at 12:40 PM, Scott Jehl<sc...@scottjehl.com> wrote:
> 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!
> On Jun 12, 2009, at 3:47 AM, Wichert Akkerman <wich...@wiggy.net> wrote:
>> 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.
>>> 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 <wich...@wiggy.net> It is simple to make things.
>> http://www.wiggy.net/ It is hard to make things
>> simple.
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.
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:
> 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.
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
On Jun 12, 2009, at 9:23 AM | Jun 12, 2009, Todd Parker wrote:
> 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:
>> 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.
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:
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
> 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:
> 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
> > 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. 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:
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.
On Sun, Jun 14, 2009 at 6:47 PM, malk0 <malk0.php...@gmail.com> wrote:
> 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?
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.
On Sun, Jun 14, 2009 at 9:36 AM, alexander farkas <a.farkas.pm@
> 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:
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.
> 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:
|
