Collapse with parent assumes .panel

[alexrussell]

The collapse plugin, when used with data-parent="{selector}", appears to assume that you are using panels (presumably because of the original accordion use-case). Line 49 of the plugin has a specific reliance on .panel in the code, but is there any reason for this? I have code that has a similar close-all-others-within-a-container mechanism, but has very little need of using panels. Is this something that can/should be changed (now that #15241 is merged, reducing the emphasis on accordions using panels) or is there a good reason for the reliance on panels?

[barryvdh]

Just facing the same issue, so 👍 for decoupling from styling.

[alexrussell]

Glad it wasn't just me. I did wonder if I was just missing something. I changed .panel to * in my local JS file and it does appear to work without issue.

[cvrebert]

X-Ref: #8892, 201088c

[bassjobsen]

Instead of changing the selector to > * i suggest to change it to > .panel, > .collapsible-item. Their is no need to define any style rules for .collapsible-item here, but it can be used for that purpose too.

Or alternatively make it an option with > .panel as default. The data-..... for this option should be set on the parent element.

[alexrussell]

If I'm honest, I don't really see the gain in introducing more markup (in this case the collapsible-item classname) than is required, but at the same time there's not much harm that I can see.

In my specific case, it luckily works pretty much like panels, but just without the panel markup, and thus works with the JS that exists, after changing .panel to *. I have something like this: ul > (li > .title[data-toggle=collapse] + ul.collapse > li*)*, so the collapse trigger is the .title, with the collapsible element being the second-level uls. So yes, I could of course just stick .collapsible-item on those uls but I don't feel that there's much need to.

[cvrebert]

@fat I believe we decided to punt this to v4, correct?

[mdo]

Yeah this will change in v4.