Hi Jörn,

As I understand this panel (i.e. new accordion) has almost no relation to panel (content grouping) widget which concept is described at pbworks, and that's a confusing thing to know. You see, I think that essentially accordion could be composed out of panels (as in ist-ui-panel with 'accordion' option), but not vice versa. What's your opinion?

And another thing: is there any sense from the point of accessability to hide accordion icons? If all accordion panels are collapsed how one should know that this control accepts clicks and could be opened?

Any chance we can get 1.8.2 released to include this soon?

Excellent work guys, this bug had me for a while!

I fixed it on my fork, and sent a pull request.

.apply(self should be .apply(this, as mentioned here: https://forum.jquery.com/topic/sortable-21-4-2010

Viewable on https://view.jqueryui.com/master/tests/visual/theme.html

Of to a good start. We need to inline the dialog. And various variations of all widgets: Accordion without icons, vertical slider, various additional datepicker controls...

COMMAND/COMMAND_LEFT/WINDOWS is the command (meta) key on Apple keyboards and the Windows key on Windows keyboards. COMMAND_RIGHT/MENU is the command key on the right side of Apple keyboards and the (context) menu key on the right side of Windows keyboards.

Whats COMMAND and variants and MENU supposed to be?

Noticed that after pushing it...

Sounds good!

@Jorn: That's interesting, but it shouldn't change our implementation, right? Caus now we support people using html that wouldn't otherwise work in IE6 because we'll add the missing for=id attribute. It only means if they want it to work in IE6 without JavaScript, they'll need the attribute in the html.

Actually IE6 always requires the for-attribut.

Ok, turns out .closest( "label" ) was useful in the case that the checkbox is inside the label. Otherwise we search the document. Fixed up in 93c3e89

Good point. Fixed in 93c3e89

iirc, a label only requires the "for" attribute when the input is outside the label. should the checkbox's parent be checked first to see if it's the label?

We can't really assume anything about the proximity of the checkbox and its label, though in many common scenarios they won't be too far away from one another. But they might be in different cells in a table, each wrapped in their own div or span or one on its own and the other wrapped in some sibling element. What we know is the user asked us to turn the input[type=checkbox] into a jQuery UI checkbox, so that element will stay where it is and be wrapped in the necessary generated div and the label moved from wherever it might be into the same.

I'm not sure how .closest() would help us here since it wouldn't find the nearest label, .closest() walks up the parent tree starting with the current element. So that would only work if the checkbox were inside the label (which is sometimes done but not a rule). But we can't do .closest("fieldset") nor .closest("form") to find some common container since we don't know for sure that the the checkbox is in either. We know it's in its document and we know the label is in the same document and the for of one matches the id of the other.

Just a (weak) example on my part (sorry). Another brain-fart: -- it's that kind of day -- is .siblings() would be too restrictive of course.

The real point being: the label is surely proximate to the control, especially a checkbox control. Going-up to the .ownerDocument and then filtering for a label's attribute is grossly inefficient in terms of finding a label that is likely proximate, no?

I see jQuery uses .closest() internally so maybe that would be a better route here?

Steven: Why would you have multiple tabs that with labels that point to the same checkbox?

Thinking: .siblings() is probably fine here. The danger exposed here is, say, a tab interface with the same control on more than one panel. .siblings() protects from that.

Cool, thanks. I'll update my Button Lite widget accordingly, putting it into a custom namespace instead of the ui-namespace.