The value option doesn't make sense to me. The menu is built from a select, so the selects value is used, thats it.

Worked for autocomplete, too; no one ever requested a value option...

Autocomplete has a width option, which applies to the suggestion list. Should that be renamed to menuWidth for consistency?

Is handleWidth really something you need to configure via JS?

I don't get what the icons option does (by looking at the spec). An array doesn't have named properties, as that supposed to be an object? What does it do?

The format option is could be remodelled after the source/parse design for Autocomplete (http://wiki.jqueryui.com/Autocomplete). Let the user provide a callback for either the whole dataset or each row, and display the return value. Might be worth considering to make that asynchronous: Provide the data in the first argument, and a callback in the second. Let the user call that callback with the formatted data; that allows an ajax request to enhance the data to display, which would work best in combination with getting the full dataset as the first argument - you wouldn't want a request for each row. The plugin could still check the return value of the callback, if it isn't undefined, assume a synchrnous operation and use the return value, instead of waiting for the response-callback.

I have a feeling that people (like me) might also want to include images in the Selectmenu (and Autocomplete, fwiw) without creating CSS classes. Perhaps it would be easier to have the image/icon be part of the data that is transformed by the widget? Either an img or cssClass type of thing?

How can i use to replace two dynamic selects?

Is there a way to dynamically modify the options in the original SELECT and have the widget reflect those changes? Or should I call destroy and recreate the 'selectmenu'?

Sam, you need to delete and the recreate the widget.

Apart from that, I notified Filament of some issues with this plugin on the original blog post. I thought I should write a link to it from here, for further reference.

http://www.filamentgroup.com/lab/jquery_ui_selectmenu_an_aria_accessible_plugin_for_styling_a_html_select/#commentNumber26

The normal UI option setter syntax ...("option","foo","bar"); should work. If it does not currently (I haven't had a chance to test), then I am sure it will before it is released.

The custom icon implementation needs some work.

Currently the icons are not dynamically sizable. CSS background-image will not scale an image to the height/width of the container, at least until CSS3, so the icon image files have to be an arbitrary static size.

If they were instead <img> elements, they would be scalable.

Could each option element use an optional custom attribute, like "icon-path" or something similar, and build the icon from that?

Font families seem to be different in closed and opened states (the widget itself and the menu that pops up).

Line height for a popup with custom images also seems to be different on the select and the menu.

Menu selected item isn't aligned vertically with the widget in popup with optgroups demo.

The format callback certainly doesn't match the one in the spec...not that it ought to. Format should be (and is) a callback, not a hash of find and replaces. The _formatText method ought to pass the text and the actual OPTION element to the format callback, instead of just the text. This allows for much more versatility in formatting the list items.

There is also a bug in type-ahead that eats up ctrl+keypresses. Surprised no one ran into this, as it breaks ctrl-r!

There is no reason that maxHeight shouldn't be compatible with dropdown style, in my estimation. I was using maxHeight on a selectmenu, but it was getting jittery over the window edge. When i took out the if (style=="popup") in the mouseup that uses the timeout to delay for the safemouseup, the maxHeight works fine in both styles.

What's the hold up with this? This seems like a much more fundamental, and core widget than something like autocomplete (which I can build myself) and shadow (which I won't even use because the slow-down isn't worth the minor visual flair). Yet, it's rated as very low priority?!

I'm sure everyone here that has used jquery ui in a project has run into the situation where 90% of your widgets are looking nice and consistent. You can replace all your buttons and text inputs, with equivalent markup and jquery ui styles (ui-state-default). We don't need to do anything special for text inputs to achieve a similar look (background + border are sufficient here). The things you can't really style in a satisfying way without javascript are select menus and radio/checkbox buttons. The normal HTML widgets (as well as file uploads and fieldsets) are too wonky in their styling.

Not only is this way too low priority (IMHO), unlike some of the other proposals on here, this one is nearly complete. It's also a plugin that I would hate to write myself, without nice community to help support it . Transparently replacing HTML select widgets better be done properly, and when some random use case comes up where it's broken it's great to have lots of eyes on it to fix it. If your fancy select widget is broken in ie 7 and you can't change a parameter in the back end of your web app because of it, your users have a right to be PO'd.

The optgroup labels do not work with spaces.
I've solved this problem with the fix below:
- use the label only to display and reduce the label to an id without spaces for all other statements
... maybe this could be improbed to remove all special characters that are not allowed as css-class-name

===================================================================
--- ui.selectmenu.js 2009-12-15 16:35:05 UTC (rev 5596)
+++ ui.selectmenu.js 2009-12-15 17:17:52 UTC (rev 5597)
@@ -122,7 +122,8 @@
text: self._formatText(jQuery(this).text()),
selected: $(this).attr('selected'),
classes: $(this).attr('class'),
- parentOptGroup: $(this).parent('optgroup').attr('label')
+ parentOptGroup: $(this).parent('optgroup').attr('label').replace(/\s/g, ""),
+ parentOptGroupLabel: $(this).parent('optgroup').attr('label')
});
});

@@ -165,7 +166,7 @@
this.list.find('li.' + optGroupName + ':last ul').append(thisLi);
}
else{
- $('<li class="'+self.widgetBaseClass+'-group '+optGroupName+'"><span class="'+self.widgetBaseClass+'-group-label">'+selectOptionData[i].parentOptGroup+'</span><ul></ul></li>')
+ $('<li class="'+self.widgetBaseClass+'-group
+'+optGroupName+'"><span
+class="'+self.widgetBaseClass+'-group-label">'+selectOptionData[i].pare
+ntOptGroupLabel+'</span><ul></ul></li>')
.appendTo(this.list)
.find('ul')
.append(thisLi);

Is there a possibility to select an entry in the selectmenu by the option-value (<option value="123">label</option>) of the original select element and not by the index?
$('#mycombo').selectmenu('value', elemlIndex);
It would be nice to have such a method!

I feel that the format function should be passed the option element in addition to (or perhaps even in place of) the text. Let me explain a use case for this: I am creating a select menu to select the brand of a product. For each brand I also want to show the logo in the select menu. The non-javascript markup looks like this:

<select>
<option style="background: url(/contentstore/123d1231.jpeg) no-repeat left" value="1">Adidas</option>
<option style="background: url(/contentstore/2341a112.jpeg) no-repeat left" value="1">Nike</option>
</select>

Firefox the logo will show the logo correctly in the select menu. Other browsers ignore the style on the <option> element. When using selectmenu on this markup I want to extract the background image URL in my format function and use that to create a <img> element. This is only possible if the format method gets the <option> element as parameter as well.

The current implementation does not match the spec form this page: the value property in ui hash passed to events does not specify the value of the selected option, but the index of the selected option.

I am not sure if there is a need for a new ui hash data type; perhaps it would be simpler to just include the original <option> element? That already has the value and any other data that you might want.

The plugin does not behave correctly in environments where Array.prototype is augmented. There's a patch here: http://dev.jqueryui.com/ticket/5034

If you click on the menu to open it it is immediately closes again. This is different from a standard <select> which stays open until it looses focus. The only way to keep it open appears to be hold down your mousebutton and move the mouse down until you hover over an item, then move the mouse outside of the menu and release the button.

The behaviour for a large list of options is suboptimal at the moment. The entire list can be (much) larger than the current page height, in which case the page is stretched to make room for the entire list, which adds a lot of empty space to the page. Selecting items at the end of the list is very awkward since there is no scroll option, and the menu often closes before you found the item you are looking for.

I found it useful in event handlers to know the index if the selected option and the option element itself. I did this using a simple change:

@@ -339,8 +339,11 @@ $.widget("ui.selectmenu", {
this._prevChar[0] = C;
},
_uiHash: function(){
+ var index = this.value();
return {
- value: this.value()
+ index: index,
+ option: $("option", this.element).get(index),
+ value: this.element[0].value
};
},
open: function(event){