Responsive popovers to inline content?

[scottaohara]

At one point in time we had been talking about how one might want to have content rendered as a popover at larger viewport sizes, but not at smaller viewports. E.g., a website navigation which has sub-navigation popovers, but at small screen those sub-navigations, when toggled open, are rendered inline.

From what I can tell, there isn't really a way to do this without someone needing to specifically remove the popover attribute(s) and re-implement the content as a custom disclosure widget.

The point of this issue is to close the loop on this topic - is this a feature we would want to create/support for popover, or is the solution to manually remove the popoveriness of an element if it's not meant to be a popover in x scenario?

[kizu]

I want to mention a reverse case: when we can have inline content that is present on a larger viewport, but might need to be a popover/toggletip on a smaller one. Example: side-notes, where we might want to display them in a sidebar alongside their context, but transform them into toggletips when there is not enough space.

I can imagine other cases, where based on various media (or even container?) properties we would want to either display an element always, or make it a popover/tooltip/toggletip. So, as an author, I would really want to have something that allows this built in, compared to implementing this behavior from scratch.

[scottaohara]

at least from the way i've been thinking about this, the reverse seems a bit 'easier' to handle because one can set a [popover] element to be display: block and the biggest hurdle then is to undo all the default UA styles for [popover] so that it can be rendered inline.

Maybe invokertarget and similar CSS overwriting could be the answer for my use case - where it's two distinct buttons to toggle the sometimes popover content. but right now, without invokertarget, the only way one can toggle content without it being a popover is to custom create a button aria-expanded=... triggering element.

a very basic example of making popover content appear for viewports larger than 600px, but rendered as a popover below that viewport size

https://codepen.io/scottohara/pen/KKbrpoV

[bkardell]

I know we discussed this as well because I definitely brought examples of where wanted this and where we fell down on this with controls like <details>. I still want this.

[css-meeting-bot]

The Open UI Community Group just discussed Responsive popovers to inline content?, and agreed to the following:

• RESOLVED: this use case typically requires Javascript and/or explicitly overriding the display property. Action item: add author guidance to the spec for this use case.

The full IRC log of that discussion

<hdv> scotto_: I wanted to remind myself how would popover work with responsive design
<hdv> scotto_: what if elements are rendered as popovers on larger screens but differently on small screens, eg same buttons would do different things
<masonf> q+
<gregwhitworth> q?
<hdv> scotto_: I could make a popover inline content by undoing UA styles… works if I want to go from inline content to make something popover but can't do the reverse
<hdv> scotto_: so is this something I should hack together with script?
<gregwhitworth> q+
<hdv> scotto_: or would invokertarget potentially solve this?
<lukew> q+
<hdv> scotto_: I don't know how to do make popover responsive in the way I mentioned
<gregwhitworth> ack masonf
<kizu> q+
<gregwhitworth> q-
<hdv> masonf: the only two ways I know is what you just said: override styles in a media query or JavaScript to toggle popover attribute
<gregwhitworth> ack lukew
<brecht_dr> q+
<hdv> lukew: one thing that may or may not be a solution to this… is related to the discussion of a popover to be open by default? could that be a solution here? especially if controlleable via CSS?
<hdv> scotto_: no because it would still be in the top layer
<hdv> masonf: there was a proposal for a default-open attribute
<hdv> lukew: agree it would be nice not to have to duplicate markup
<gregwhitworth> ack kizu
<hdv> masonf: I don't think you have to duplicate markup… you just need some JS to add or remove an attribute
<hdv> kizu: just looked at the issue… eg you can add display:block and it would display even when not open. If display:static it would go out of the top layer?
<gregwhitworth> q+
<scotto_> q+
<hdv> kizu: or another way would be to have multiple elements and in media queries set one to display block and the other to none
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: I agree with kizu . I played around with this a few times… to have them show as regular content. I think this is a very special use cases. Sometimes you might not need to use a popover this kind of behaviour
<hdv> brecht_dr: the way kizu described would work
<hdv> gregwhitworth: what I'm struggling with… it felt like there was a desire to try and resolve this declaritively… I don't know how that's viable, it would lead to accessibility problems
<hdv> gregwhitworth: you could solve the rendering aspect of it, but you still have the ARIA references
<hdv> gregwhitworth: default open is initially open for what? because of a container query?
<sarah_h_> q+
<hdv> gregwhitworth: worry you would get a circular loop
<hdv> gregwhitworth: I think there isn't a declarative answer to this, outside of us solving HTML templating
<hdv> gregwhitworth: (don't think we should now)
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack sarah_h_
<hdv> sarah_h_: I agree with Greg… I don't think it's a bad thing for this to require JS. The difference between these is a behavioural difference… so seems like it makes sense for this to be a JavaScript problem
<hdv> sarah_h_: probably isn't always based on screen size either
<gregwhitworth> q?
<gregwhitworth> ack scotto_
<hdv> scotto_: I'm fine with all of this. I love people telling me do you actually need this
<masonf> Proposed resolution: this use case typically requires Javascript.
<hdv> scotto_: makes sense to me for this to just require people to do it via script
<hdv> scotto_: maybe we need author guidance?
<hdv> gregwhitworth: makes sense to me
<bkardell_> q+
<gregwhitworth> ack bkardell_
<hdv> bkardell_: can we make the resolution that someone is going to come up with the author guidance
<masonf> Proposed resolution: this use case typically requires Javascript. Action item: add author guidance to the spec for this use case.
<hdv> bkardell_: I'm not sure if I wrapped my head around the issue
<hdv> bkardell_: I would like it to be easy and declarative to show content… that much we should be able to do I feel?
<hdv> gregwhitworth: I think the only truly declarative way I can think of is something that uses HTML template, basically conditionals (which JS offers today)
<hdv> bkardell_: I don't really understand… you can use display and take it out of the top layer?
<hdv> bkardell_: one of the use cases would also be print
<hdv> gregwhitworth: we could define magic that could do this… but then we'd also need to remove the accessibility info, eg the connection between invoker target and popover
<masonf> Proposed resolution: this use case typically requires Javascript and/or explicitly overriding the display property. Action item: add author guidance to the spec for this use case.
<hdv> bkardell_: I'm fine with the proposed resolution
<lukew> +1
<scotto_> +1
<bkardell_> +1
<hdv> +1
<brecht_dr> +1
<sarah_h_> +1
<masonf> RESOLVED: this use case typically requires Javascript and/or explicitly overriding the display property. Action item: add author guidance to the spec for this use case.

[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.