AccordionPane

[bitpshr]

Enhancement

Add an AccordionPanel component

[rishson]

So we need to list out the initial features.

Things to consider:

• Can multiple sections be open at the same time, or only 1 section at a time?
• Does the accordion's height stay constant, irrespective of the open section(s) content, or does it resize?
• Can you disable sections?

For the initial implementation, my suggestion would be:

1 section open at once
height stays constant - (overflow sections if needed)
no disabled sections.

[rishson]

Also, I'd like to standardise on naming things that may have been called 'panel' in the past.
I've been using semantic ui for too long, but i've got used to the brevity of their widget naming, so we could have:

accordion
tab
sideBar
split

Thoughts?

[msssk]

I am also a fan of names being as long and descriptive as necessary, but no more. I think the "panel" suffix is often unnecessary.

For now, we should try to agree on the accordion name, and my vote goes to "accordion".

The overall naming scheme might be best tracked in a separate issue, but some quick thoughts:

• tab: we probably want both tabs (or tabContainer?) and tab, yes?
• split: this is a little lacking in descriptiveness for me... the "panel" suffix might actually be warranted

[rishson]

tab is a contentious one. I've always viewed tab as both the tabStrip and the tabContents (for want of better names.
tabPane and splitPane?
(I just dislike 'panel' as its too retro).

[rishson]

Which would give us:

• tabPane
• splitPane
• slidePane
• accordion
  ?

[bitpshr]

While I don't really care what suffix we use (e.g. "Pane" vs. "Panel" vs. anything else), I do think that every container component should use the same suffix. I think having one component that doesn't use it, like "Accordion", is confusing. This suffix sort of serves as an indicator that a component is a container-style component in my mind.

[rishson]

@bitpshr I've started to wonder if we need to consider all the widgets where the primary function is layout, such as :

• menu
• header
• footer

To me, it seems clunky to have pane suffixes to these widgets. If the list was something like:

• tabPane
• splitPane
• slidePane
• accordion
• menu
• header
• footer

then I think its ok to drop the suffix at times. [shrug_emoji]

[bitpshr]

@rishson sounds good to me.

[msssk]

Some questions on what we want from an accordion pane:

• Should it accept arbitrary children? Or only TitlePanes?
• Should it have an exclusive option to enforce only a single pane open at a time?

[bitpshr]

I don't think an AccordionPane should accept arbitrary children. If another widget is needed next to the internal TitlePanes, the widget should just be a sibling to the AccordionPane within a wrapping div.

I like the idea of an exclusive option.

[sebilasse]

Just wanted to mention that my Semantic UI dojo2 Integration also contains Accordion, posted a WIP preview here : dojo/widget-core#559

[eheasley]

We are very near completion on this as a result of working on related tasks, so we will go ahead and get this taken care of for beta 4.