I haven't looked over the menu branch yet. I've got a note about merging this change into the menu branch, but I'm not sure when we want to pull menu into master.
I wanted it to be as flexible as possible. If the user really wants to specify a different element to position against, they can, but they'd have to intentionally do it. This probably allows for some crazy kind of complex autocomplete UI that somebody will think of one day :-P
I don't see the point of defining each possible corner combination if they're all the same. Lines 239-243 are completely redundant. I don't care enough to get involved with this project, but you can change line 235 to start with ".ui-corner-tl, .ui-corner-top, .ui-corner-left, .ui-corner-all{"... and the next 3 lines similarly. This change alone will only free a little less than 1kB from redundancy, but the mentality shift might be appreciated, given that jQuery UI publishes a minified version.
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?
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...