Re: [w3ctag/design-reviews] The Popup API (Issue #743)

+1 to @nt1m's response. As to this part:

> I think for popover you also need a JS call (`showPopover`) in order to push to the top layer, which works out great I think, but yeah I would definitely be concerned if just using the `popover` attribute added it to the top layer.

You're exactly right that there's an explicit action (either `.showPopover()` or user-click on an invoking element), which means there's a well defined point at which the Popover is added to the top layer.

From the [discussion](https://github.com/w3ctag/meetings/blob/gh-pages/2022/telcons/10-31-minutes.md#the-popup-api---leaverou-atanassov-1):
> Though I'm not quite sure why that is specific to the CSS syntax, if authors use the popup attribute all over the place, won't the UA still need to override this somehow?

I don't understand this question. This is basically what the Popover API *does*. The behaviors include managing the top layer, and allowing 1) proper ordering of things in the top layer, and 2) being able to kick them out when needed.

> If you have multiple.. if you have ads and other 3p content in the page, isn't there going to be an arms race to see who can get on the top layer first and obliterate the other top layer..
> z-index: 9999 problem all over again. Not sure using an attribute is going to fix that
> Yeah, I don't buy the argument that the popup api avoids the z-index problem. The whole notion of top-layer feels underspecified and undefined

Can you be more specific about this concern? This is essentially what the Popover API *does*, in combination with the (pre-existing) [top-layer](https://fullscreen.spec.whatwg.org/#top-layer) concept. Since it's a stacking layer in the document, 3p content is [constrained to the iframe it's in](https://open-ui.org/components/popup.research.explainer#exceeding-the-frame-bounds). The z-index: 999 problem is precisely what is avoided by having **only one** top layer, and having [well-specified behaviors](https://github.com/whatwg/html/pull/8221/files) around adding and removing from that top layer.

On the "top layer feels underspecified and undefined", can you be more specific? Top layer is [defined right here](https://fullscreen.spec.whatwg.org/#top-layer), as:
> The [top layer](https://fullscreen.spec.whatwg.org/#top-layer) is an [ordered set](https://infra.spec.whatwg.org/#ordered-set) of elements, rendered in the order they appear in the set. The last element in the set is rendered last, and thus appears on top.

If there's something missing from this spec, let's clarify it!

> Dan: If we close, we should emphasize the a11y concerns and make sure they are addressed. Are we ok to close?

We're taking a11y *very seriously*, and we're committed to making Popover accessible by default. We've pulled out some pieces of the API (e.g. [`popover=hint`](https://github.com/openui/open-ui/issues/526#issuecomment-1219845155)) precisely because we don't yet know how to make them accessible. 

> Can we say we're okay with the attribute thing and say we have other concerns?

It sounds like generally, the feedback is:
 1. You'd like more documentation or explanation of the top layer concept. If you let me know what's [missing](https://fullscreen.spec.whatwg.org/#top-layer), I'm happy to work on that.
 2. You'd still like a "CSS way" to add things to the top layer. Are you ok if, in the future when that's been defined, we use it to "explain" how Popover works today?
 3. You'd like to make sure we're taking a11y seriously. I promise we are, but let me know if there are specific concerns, and I'll make sure we address them.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/743#issuecomment-1317536382
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/743/1317536382@github.com>