[openable] Should openable be disallowed on certain elements?

[lukewarlow]

Openable is intentionally allowed on a wide variety of elements, however, it's possible that some should be disallowed.

Namely dialog or details come to mind as candidates for disallowing openable.

[sorvell]

• include <details> since openable would apply to the element itself and not its content.
• exclude <dialog> since it is basically already openable. Is there anything good openable could do on it?
• exclude popover elements? Again, Is there anything good openable could do on it?
• exclude probably all metadata content

[css-meeting-bot]

The Open UI Community Group just discussed [openable] Should openable be disallowed on certain elements?.

The full IRC log of that discussion

<keithamus> Zakim, please open the queue
<Zakim> ok, keithamus, the speaker queue is open
<keithamus> scribe+
<keithamus> lwarlow: Like popover, openable works everywhere. On html it works right?
<keithamus> masonf8: theoretically everywhere.
<keithamus> lwarlow: every html-namespaced element
<keithamus> lwarlow: should the same be true of openable?
<scott> q+
<masonf8> q+
<keithamus> lwarlow: Should it be blocked on certain elements? Should it work on details? Dialog?
<masonf8> ack scott
<keithamus> scott: I think we should follow what popover did, if we didn't it would raise a red flag on revising popover. It doesn't make any sense.
<keithamus> scott: putting it on details, for instance, is probably more about setting author expectations. If openable on details - I wouldnt expect it to control everything but the summary element, I'd expect it to include the summary.
<sorvell> q+
<lwarlow> q+
<keithamus> scott: likewise if it had popover, there's a conflict - we need to decide which one wins out, we'd need to specify that.
<keithamus> scott: is it whichever attribute comes first? Or one always wins
<keithamus> scott: again for dialog I could see someone putting it on there, and instead of .show() they use this. Some desire for non-modal non-popover dialogs. it should not break out - supposed to be in the container
<keithamus> scott: I think its a good list for what doesn't make sense but we can have a solution for those.
<keithamus> masonf: I think I agree with scott - standards wise it'll have to be global, you'll have to say what happens in the weird cases. The two weird cases seem to be dialog and popover. One thing scott said is order - order can't matter. One will need to win, I don't have opinions on whihc.
<masonf> ack mason
<masonf> ack lwarlow
<keithamus> sorvell: meta point: this question cannot be answered without understanding how these things would or would not compose. We need to understand what behaviour would occur then decide what is bad
<masonf> +1 to sorvell
<scott> q+
<keithamus> lwarlow: if you have popover & openable on an element, it'd be display:none. Then you'd have to call a JS api, which would do the thing; `.showPopover()` will show as popover, `.expandOpenable()` would open as openable.
<sorvell> q+
<keithamus> lwarlow: three situations where we need to decide: if it's open as openable, and you call showPopover, should we throw? no-op? or upgrade it to popover?
<masonf> We currently throw if you do showModal(); showPopover();
<keithamus> likewise if you call showPopover and open as openable should that do anything? Or throw?
<keithamus> lwarlow: if you have openable, popover on the same element, and you have it declaratively open, then what?
<masonf> q+
<keithamus> lwarlow: maybe the answer is obvious, maybe it should be not openable?
<keithamus> lwarlow: we'll talk a bit more about that on one of the other issues.
<keithamus> lwarlow: I agree though we don't need to exclude it from anything, maybe from SVG but that's a can of worms I'm not touching...
<masonf> ack sorvell
<keithamus> sorvell: is the reason we need a distinction between popover & openable because we dont have easy access to whether it should be in the top layer or not?
<keithamus> sorvell: we just want the thing to open, whether its in the flow or not in the flow. Do we need a whole feature to work out the css for this? Seems unfortunate.
<masonf> I vote to close that can of worms.
<keithamus> lwarlow: there are differences which warrant it as a separate API; one is open on find. Don't want popovers doing that.
<keithamus> lwarlow: Potentially differences in focus management (another issue to discuss that)
<keithamus> lwarlow: findability, embedded in page - it's not a popover, it doesn't pop over stuff - it's part of the inpage flow of elements
<keithamus> lwarlow: findability - we could come up with a way that popovers are searchable but it's not something we want necessarily
<keithamus> q+
<masonf> ack scott
<keithamus> scott: I could see someone wanting to declare both popover/openable on the same thing - larger screens openable, smaller screens popover.
<keithamus> scott: Maybe you just want an accordion on a small screen?
<keithamus> scott: declaring both attributes, with two buttons, one with commandfor as openable and the other as commandfor popover - you can render for 2 different displays
<sorvell> In flow or out of flow is otherwise controlled via `position`. That doesn't feel really distinctive to me...
<lwarlow> +1 to that use case
<keithamus> scott: but maybe sorvell's question is a good one - maybe we can just do this with CSS
<masonf> ack masonf
<sorvell> q+
<keithamus> masonf: I do agree with lwarlow's comments on openable vs popover - they feel very similar but they're different in both how they present and what you put in them.
<keithamus> masonf: I think you should be able to put both, we have a precedent with dialog popover now; if you do showModal then showPopover it'll throw, and vice-versa. You're already open in another mode
<keithamus> masonf: the fact we required the command attribute to always be present is nice in this case because you have to supply the way you want this to open
<keithamus> masonf: it would be nice if initiallyopen worked for both popover and openable, with some way to disambiguate for the presence of both - maybe a value for which one wins
<keithamus> masonf: you can have both and in most cases it just works
<masonf> ack keith
<masonf> keithamus: would it work with CSS UA stylesheet. If you have popover openable, the stylesheet says :not(popover-open) {display:none}. You'd have to add more and it'll get touch.
<masonf> s/touch/tough
<masonf> lwarlow: you have :not(:popover-open) and that's display:none.
<keithamus> masonf: the dialog/popover cases are quite finicky, I have cls open for this, so it's fixable - though not trivial.
<keithamus> masonf: you could have dialog popover openable, and need to figure out how all three of these work
<masonf> ack sorvell
<keithamus> sorvell: whether or not something would be openable vs popover would be a responsive UI case which could be driven via CSS. Having said that the different functionality of findable - I don't have a good response for
<keithamus> sorvell: a comparison would be nice to see

[mfreed7]

I'm tentatively removing Agenda+ - feel free to put it back if you'd like to discuss this again.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.