bkardell / common-panel

An effort to define a new element with clear semantics and separation
14 stars 3 forks source link

why not re-use open attribute instead of expandable? #33

Open stevefaulkner opened 9 years ago

bkardell commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 8 years ago

Seems this is fixed, can we close it?

bkardell commented 8 years ago

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 notifications@github.com wrote:

Seems this is fixed, can we close it?

— Reply to this email directly or view it on GitHub https://github.com/bkardell/common-panel/issues/33#issuecomment-158308290 .

Brian Kardell :: @briankardell :: hitchjs.com