why not re-use open attribute instead of expandable?

[stevefaulkner]

No description provided.

[bkardell]

So then I imagine it would be like: If a panel doesn't include the open attribute at all it isn't expandable/collapsable? Visually speaking the panel contents would be available, same as open, but it would not include controls. If this is the suggestion, I'm open to changing it.

[LJWatson]

Whichever solution we use, the attribute itself would need to be present to indicate the panel's ability to expand/collapse (or open/close) wouldn't it?

[LJWatson]

So with open="true" the panel would be in an open state and capable of being closed. With open="false" the reverse would be the case. Without open present at all, the panel would not be capable of being opened or closed.

[bkardell]

@LJWatson that's correct - the reason I initially used "expansion-state" as the attribute is because I was trying to deal with this funkiness in the mental model... Conceptually a panel itself is opened or closed, there's really no third option. That is, you can view its contents or you can't. With summary/defaults the default is that it isn't open... However, with panel we do have a kind of "third state" in that the default is just that there's no control, it's just an (open) group with a title and some panels allow you to toggle that and provide a button for doing so. In other words, since open is a boolean attribute (I'm checking implementations but correct me if I am wrong) it is simply present or not which doesn't seem to leave an answer for "I'm just a panel". What you propose above seems like a contextual change to the meaning of open and would mean that it is suddenly not just a boolean attribute.

[ZoeBijl]

Seems this is fixed, can we close it?

[bkardell]

I've left it open because I have to rework the prollyfills/examples to
reflect this if we are going this way - is it updated within the spec
already? I haven't looked.

On Fri, Nov 20, 2015 at 2:23 AM, Michiel Bijl [email protected]
wrote:

Seems this is fixed, can we close it?

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

Brian Kardell :: @briankardell :: hitchjs.com