torgo
commented
2 years ago Hi @mfreed7 sorry we should have caught this earlier but can you provide answers to the security & privacy questionnaire? Thanks!
Closed mfreed7 closed 1 year ago
torgo
commented
2 years ago Hi @mfreed7 sorry we should have caught this earlier but can you provide answers to the security & privacy questionnaire? Thanks!
mfreed7
commented
2 years ago Hi @mfreed7 sorry we should have caught this earlier but can you provide answers to the security & privacy questionnaire? Thanks!
Sorry about that - I just edited the OP to include the questionnaire. While I was there, I also linked to the in-progress spec PR.
torgo
commented
2 years ago Hi @mfreed7 thanks for that! Do you have any additional info on feedback/support from additional stakeholders (implementers)? Some additional TAG feedback incoming from our session today.
LeaVerou
commented
2 years ago Hello there,
We reviewed this today in a breakout, and we are quite concerned with the amount of attributes and methods this is adding on every single element. We believe this would add a lot of additional complexity (e.g. what happens when <body> is a popup? Or when table elements are popups? Or when form elements are popups? Or replaced elements?) that is not actually required for addressing the use cases that popup is meant to address. Furthermore, this makes the API itself clunkier and more verbose, as now names need to be distinct from any other global name, not just names on the same element. It is also inconsistent with the rest of HTML, which typically defines new elements for things like that (e.g. we didn't add a dialog attribute to HTMLElement, we added a <dialog> element). We understand that this design enables some possibilities that having a separate element does not, but on balance, we don’t think the tradeoff is worth it.
We would prefer to see the popup functionality as one or more separate element(s). Any attributes specified on the popup trigger (popuptoggletarget) could be global attributes.
mfreed7
commented
2 years ago Thanks for the review!
So in OpenUI we discussed this alternative (a <popup> element) at length, over roughly a year and with 10+ meetings dedicated to this specific topic. What would your solution be to the accessibility and semantic issues with that approach? (Our eventual conclusion was that there wasn’t a good solution, and the attribute approach was therefore superior. It also happens to be more powerful.) Also recall that the TAG closed my design review for <popup> based on these concerns, which is when we went in the global attribute direction.
I think we’d agree that this adds several new attributes, but only one (popup) truly confers new behavior on any element. The other two (anchor and defaultopen) simply modify that behavior. There are certainly precedents for global attributes that modify the behavior of any element, e.g. contenteditable or tabindex or even the aria-* attributes, right? Can you help me understand why this is different?
As for limiting the list of elements, we could definitely do that. However, should we restrict that list just because we don’t have a specific use case in mind right now for <input popup> or even <table popup> or <body popup>? Web developers are amazingly creative people. Of course, if there is some sort of incompatibility or reason not to support the attribute on an element, a restriction would be in order. We had such a discussion about <dialog> on https://github.com/openui/open-ui/issues/520, and decided that even there it makes sense to allow the popup attribute. How would you go about deciding which elements deserve popup support and which don’t?
Thanks again for your review! Besides the attribute vs element issue, were there any other comments on the behaviors it confers?
Hi @mfreed7 thanks for that! Do you have any additional info on feedback/support from additional stakeholders (implementers)? Some additional TAG feedback incoming from our session today.
The Gecko folks have been involved in our OpenUI discussions of the feature, and have offered some great feedback which we’ve incorporated. I wouldn’t say we have official support just yet from other implementers though.
mfreed7
commented
1 year ago Just to add a bit more detail to the answer above, I've updated the explainer with a summary section detailing "why an attribute instead of an element":
https://open-ui.org/components/popup.research.explainer#why-a-content-attribute
Here is the summary paragraph of that section:
By having
popupbe a content attribute that purely confers behavior upon an existing element, the above problems are nicely resolved. Semantics are provided by elements, and behaviors are confered on those elements via attributes. This situation is exactly analogous tocontenteditableortabindex, which confer specific behaviors on any element. Imagine a Web in which those two attributes were instead elements:<contenteditable>and<tabindex index=0>. In that Web, many common patterns would either be very convoluted or simply not possible.
Hopefully this helps.
mfreed7
commented
1 year ago Thanks for the great F2F discussion just now. I think we better understand your concerns, which is helpful. I hope we were able to answer at least some of them in the meeting.
As mentioned, I wrote up a fairly detailed document that goes through a nearly-complete design for each of 3 approaches: <popup> element, CSS, and Javascript. (It also talks about an old version of the content attribute.) Note that this document is somewhat rough, as it was developed while OpenUI was discussing the best fix for the problems with the <popup> element approach. However, I think it's still fairly illustrative of what the API would look like in each case.
But in particular, I want to point out the CSS version in that doc, since that's what came up during the meeting. That section details what a CSS-based pop-up API would look like, and walks through the big issues. In my view at least, the CSS approach is the most fundamentally broken of the four approaches in that doc. But take a look and see what you think.
Quick side note: your questions are all great. They're ones that the OpenUI also asked, and it took us significant conversation and exploration to get where we are today, with the content attribute approach. I'm happy to walk you through how we came to that conclusion for any piece of the API, to double-check that we made the right decisions along the way.
At this point, we'll wait here and try to address any followup questions you have. If you feel it'd be useful to have another high-bandwidth F2F to discuss this, we're more than happy.
douglascross
commented
1 year ago I'm thrilled by where this is going, having had to write an advanced popup component myself.
Has consideration been given to all the various ways a popup would get aligned to an anchor and dynamically react to the available viewport space? (much the same way as a <select> element?
This is the first time I've found myself at the cutting edge of web standards, so this is exciting.
I will be holding off replacing my popup component with native elements (or attributes) such as <dialog> because it's not sufficient. This new [popup] shows real promise.
LeaVerou
commented
1 year ago Thank you for all the background @mfreed7 and the discussion on Monday. Here are some of my thoughts (not necessarily representing TAG consensus):
The CSS approach is broken because it's trying to do everything in CSS, which is clearly not appropriate for something like this which adds functionality. A good approach would be layered: some presentational concepts may need to be added to CSS, some structural ones to HTML, and JS APIs for what remains. It is also important to decouple the concepts that a popup brings, and expose them individually as much as possible, then <popup> just becomes a nice higher level package deal. Otherwise, authors end up abusing <popup> just because they e.g. need access to the top-layer. It sounded to me like some of the use cases mentioned may have even been in that group. One of the use cases mentioned in the call was "adding the popup attribute to a <tr> to highlight it". I may be mistaken, but I didn't think highlighting an element is (conceptually) a popup. The way I see it, conceptually a popup is to present ephemeral UI near another relevant control. Dropdowns, menus, tooltips, listboxes, toasts all fall under that category. There seems to be a fundamental difference between that and highlighting an element, but perhaps I have misunderstood the user needs this is trying to address. If so, it would be good to expand the explainer with these needs.
The layered approach seems to already be largely followed, e.g. with the anchor positioning proposal. It seems to me that top-layer-ness is also a concept that belongs to CSS. Then the UA stylesheet could make sure popups and dialogs enter the top layer via something like:
dialog[open],
popup[open] {
position: top-layer; /* or whatever */
}The typical HTML way for adding functionality around elements is to wrap them with other elements and encapsulate the functionality in these elements. This is how <dialog> works, this is how <details> works, sectioning elements, or even custom elements. tabindex and contenteditable assign traits to existing elements (making them focusable or editable), whereas popup seems much more clearly a container-type functionality. An element is a popup, popup-edness (😀) is central to what the element is for, whereas tabindex and contenteditable do not describe the element, do not set its identity, they are essentially metadata that set certain behaviors. Indeed, the vast majority of examples I see are <div popup>.
I'm not an a11y expert, so I'd love some clarification on why the semantics of "group that contains a table" are problematic and we instead need to make the table a popup. However, if a container with a single child is problematic for a11y, it sounds like this is something that affects other elements too. What is the role of a <dialog> or <details> that contains a single table? If these are problematic, do we need to introduce some kind of role "hoisting" up the DOM tree?
The current proposal introduces the concept of a minimum role to ensure a popup is never less meaningful than at least than a group. However, a <popup> element would address this quite naturally, by having a default ARIA role of group, unless a different type is specified (or explicitly a role). Sure, you say the concept of a minimum role would help with other things too, but at least it wouldn't be needed here. I'm also wondering if we need a new ARIA role for a popup that is not something else? It doesn't seem enough to describe it with just role=group, but again, I'm not an a11y expert, just thinking out loud.
Furthermore, making <popup> an element would help you do away with warts like these:
.show() and .hide())dialog.showModal() throws if there's a popup attributeIt also allows more room for future expansion, without adding popup* attributes to divs and other random elements. And it would free up the popup attribute to be used for something else, e.g. toggling a popup (I find names like popuptoggletarget and popuphidetarget pretty hard to read or understand).
mfreed7
commented
1 year ago Thanks for the comments! I'd really like to hear a consensus response that hopefully includes the discussion points raised in the F2F.
A good approach would be layered: some presentational concepts may need to be added to CSS, some structural ones to HTML, and JS APIs for what remains
I agree! I believe this is what we've done. The popup and popupshowtarget/etc. attributes in HTML, the :open and :closed pseudo classes in CSS, and showPopUp()/popupshow/etc in JS.
It seems to me that top-layer-ness is also a concept that belongs to CSS. Then the UA stylesheet could make sure popups and dialogs enter the top layer via something like: ...
I would recommend you please take a look at the alternatives document's CSS section. It contains exactly your position: top-layer CSS idea, and then walks through the rest of the design, and all of the problems that ensue. In particular this section about the behaviors. I don't want to re-hash all of those reasons here in this comment. As I said in the meeting, I completely see why this is a great first opinion about how this feature should work, but it just seems to really fall apart when you get into all of the details of the design.
tabindexandcontenteditableassign traits to existing elements (making them focusable or editable), whereas popup seems much more clearly a container-type functionality. An element is a popup, popup-edness (😀) is central to what the element is for, whereastabindexandcontenteditabledo not describe the element, do not set its identity, they are essentially metadata that set certain behaviors. Indeed, the vast majority of examples I see are<div popup>.
I think this is a core difference of opinion. The pop-up API very specifically provides presentational behaviors that can be applied to any element. The fact that something "pops up" is not central to what the element is for, at all. This is the same as the fact that whether something is "editable" does not change what the element is. An editable table cell is still a table cell, it just has a behavior that makes it editable. Here are some examples for pop-up:
<dialog popup> is a dialog and has pop-up behaviors. Note that the only difference between this and a "plain" modal dialog is the behavior, particularly light-dismiss.<div role=listbox popup> is a listbox that pops up over other content and light dismisses. That same listbox without popup is still a listbox, it just doesn't pop up.<input type=range popup> is a range slider that pops up over the top. An example is a video volume slider.<tr popup> is a table row which pops up to emphasize the row. That use case in particular is impossible via a <popup> element, due to table fixup rules.In all of these cases, the element defines what, semantically, the content is, while the popup attribute adds some nice behaviors to that element. This is 100% aligned with how tabindex or contenteditable work for all of these same examples. They add behavior to an existing element, but do not change the semantics of that element.
Also, one side note while I'm here: the API has been renamed to the "popover" API based on a naming conflict raised by the WHATWG.
LeaVerou
commented
1 year ago I'm starting to think the fundamental disconnect here is that parts of the popup/popover proposal (and even comments here) talk about top-layeredness as the main thing a popup brings and others talk about it as just one of many features a popup brings. Top-layeredness is absolutely a trait of another element and not an element "identity". However, a popup is not just an element on the top-layer, is it? It's also an element with light dismiss behaviors, that can be opened and closed through certain triggers, whose position may be anchored to another element, that comes with certain ARIA minimum roles, etc. The way I see it, there's a fundamental difference between e.g. a dropdown menu (popup) and a slider that "pops-up" over a video (which doesn't need any of these behaviors, just top-layer access). It is not great DX if developers that only need one popup behavior (e.g. top-layer or light-dismiss) need to pull in the entire "popup package" and disable features one by one (e.g. `popup="manual"). Ideally, all of these behaviors should be available separately, then popup itself can be more high level (e.g. even come with default UA styling), as it would only be used when an author needs multiple of these behaviors.
<dialog popup>is a dialog and has pop-up behaviors. Note that the only difference between this and a "plain" modal dialog is the behavior, particularly light-dismiss.
Case in point, I wonder if light dismiss should also be available separately. It seems a bit weird to make a dialog a popup just so it can have light dismiss.
<div role=listbox popup>is a listbox that pops up over other content and light dismisses. That same listbox withoutpopupis still a listbox, it just doesn't pop up.
Conceptually, a listbox inside a popup makes just as much sense to me, if not more than the listbox popping up by itself. With the listbox itself being the popup, once you need to include a tip about the options or a validation indicator or whatnot suddenly you have to change your markup completely.
<tr popup>is a table row which pops up to emphasize the row.
Do you have an example of this kind of use case? Is it only using popup for top-layer access or also other behaviors?
I would recommend you please take a look at the alternatives document's CSS section. It contains exactly your
position: top-layerCSS idea, and then walks through the rest of the design, and all of the problems that ensue.
I did read the document — that's where position: top-layer came from! That document is why I wrote that the problems with the CSS approach stem from trying to do everything in CSS. Here is a more detailed response to the points raised in that document:
A “dual class” top layer will need to be created, with
<dialog>and fullscreen always above “developer” top layer elements.
I think part of this problem is actually unrelated to the exact syntax you pick. Even if <popup> or <div popup> comes with magic that places it at the top-layer, once developers start (ab)using it to put things at the top-layer, the UA will need an even higher top-layer for its own stuff. It's basically the z-index: 99999 problem in a different form, where many different components all want to be "above everything else on the page". You've already identified this in other places, since there are more than 1 ways to place things at the top-layer, so how do dialogs, popovers, and fullscreen elements interact? What about different popups that are open at the same time? You already need to have a layering order.
In order to use CSS to control top layer access, there would no longer be a way to deny or remove an element from the top layer, for example when a modal dialog or fullscreen element needs to be shown.
See above.
That precludes using a popup on top of a dialog/fullscreen.
Why? Could you please explain this a bit more?
a CSS-based approach precludes any way for the UA to “force” elements out of the top layer.
Why not? The UA can override whatever CSS it needs to.
In this approach, light dismiss and one-at-a-time behavior cannot be built into a CSS property, and must be implemented in JavaScript.
Maybe I'm not following this argument, but it does not seem like a problem at all, just a good separation of concerns. CSS would totally not be appropriate to describe light dismiss behaviors, that's why I suggested that <popup> would be a nice convenient package of a bunch of CSS and JS APIs.
Unclear how to implement the popup declarative activation feature.
Again, this assumes that if top-layeredness is defined in CSS, everything must be done in CSS. position: top-layer (or whatever syntax) would just define appearance once the popup is shown, you'd still need an open attribute or an internal state to control whether it's shown. Declarative activation would be defined in terms of modifying that state with appropriate events, and has nothing to do with CSS.
If access to the top layer was controlled via CSS, there could not be a CSS selector to select items in the top layer.
Indeed, but that's like saying "I want a selector that targets display: grid elements, i.e. why would you want to do that?
nt1m
commented
1 year ago @mfreed7 I think in theory popover as an attribute could make sense, but in practice, the style adjustments triggered by top layer sort of limit the scope of the API, and what use cases are possible with it: https://fullscreen.spec.whatwg.org/#new-stacking-layer
is a range slider that pops up over the top. An example is a video volume slider.
It seems more likely that someone wanting to achieve such use case, will create a container element with the range input in it, to work around the style adjustments.
<tr popup>is a table row which pops up to emphasize the row.
How is that possible without the table row popping up in random places? the abspos adjustment makes this impossible.
mfreed7
commented
1 year ago We are taking a layered approach, so these questions you’re asking make sense. This is the approach @plinss suggested at https://github.com/w3ctag/design-reviews/issues/680#issuecomment-946019920, and we agreed with it. It’s also why anchor positioning is a separate feature from popover.
However, a popup is not just an element on the top-layer, is it? It's also an element with light dismiss behaviors, that can be opened and closed through certain triggers, whose position may be anchored to another element, that comes with certain ARIA minimum roles, etc.
Yes, definitely it’s more than just top layer or light dismiss, it's a package of interrelated behaviors. That additionally includes one-at-a-time / nested popovers, declarative triggering behaviors, and a11y tree effects like adding aria-expanded. All of the things needed to truly make a "popover" without breaking accessibility or requiring tons of Javascript. As mentioned, the positioning part of your comment is covered by the separate anchor positioning proposal.
Case in point, I wonder if light dismiss should also be available separately. It seems a bit weird to make a dialog a popup just so it can have light dismiss.
That’s an interesting thing to consider for future extensions, but I don’t know of a use case where they would be separated. All the use cases we found needed both. Certainly if a use case arises in the future for an isolated "light dismiss" feature, we could explain Popover in terms of that new feature.
Do you have an example of this kind of use case? Is it only using popup for top-layer access or also other behaviors?
@scottaohara referred to one in the telecon meeting we had last week. To me, the main point to reinforce is that the approach we’re taking is a layered behavior one, so that you can use these behaviors in a variety of use cases, some of which we didn’t even think of. Similar to what you said above about top layer etc.
I did read the document — that's where
position: top-layercame from! That document is why I wrote that the problems with the CSS approach stem from trying to do everything in CSS. Here is a more detailed response to the points raised in that document:
Oh ok. But that’s just what I said by “walks through the rest of the design” -- not a design that forces everything into CSS, but one that deals with the consequences of display:top-layer to see if it will work. For example, in the alternatives doc, the behaviors are provided via a set of events and some Javascript methods. It works, but it's dramatically less ergonomic.
I think part of this problem is actually unrelated to the exact syntax you pick. Even if
<popup>or<div popup>comes with magic that places it at the top-layer, once developers start (ab)using it to put things at the top-layer, the UA will need an even higher top-layer for its own stuff. It's basically thez-index: 99999problem in a different form, where many different components all want to be "above everything else on the page". You've already identified this in other places, since there are more than 1 ways to place things at the top-layer, so how do dialogs, popovers, and fullscreen elements interact? What about different popups that are open at the same time? You already need to have a layering order.
Actually, the Popover API provides access to the UA top-layer directly, and doesn't need to introduce a developer top layer. This is ultimately why it has to come with light dismiss and UA control aspects. It's also how it avoids the "z-index arms race".
I agree that you need a well-defined order in any top layer regardless. That order is enforced by this spec text (TL;DR top layer stuff renders in the order it was added to the top layer). Also, popover=auto popovers are automatically closed when something else like a modal <dialog> enters the top layer.
Another thing you could consider is two top layers, a developer one and a UA one. We considered that as well, but it has the problem that you wouldn’t be able to do stuff like showing a popover (like a select menu, in the developer top layer) on top of a modal dialog (in the UA top layer). That's a fairly common use case. Also see this CSSWG issue which is related.
Why? Could you please explain this a bit more?
Because of the developer top-layer vs UA top-layer issue I mentioned just above. By the way, I do think it would be fine to consider a developer top-layer (lots of discussion here), it’s just that it has to be lower than the UA top layer. And that precludes a number of common use cases, including most of the ones the Popover API aims to solve.
Why not? The UA can override whatever CSS it needs to.
Ok, but once the UA kicks a popover out of the top layer, the only way to get it back in would be to do something that causes the UA to stop forcing it out, such as calling a JS API that does it. And then you end up with grouping “light dismiss” and integrated JS/event stuff like the alternatives doc describes. This is different than the original way it might have arrived in the top layer via a regular CSS rule like position:top-layer.
—----
@mfreed7 I think in theory popover as an attribute could make sense, but in practice, the style adjustments triggered by top layer sort of limit the scope of the API, and what use cases are possible with it: https://fullscreen.spec.whatwg.org/#new-stacking-layer
@nt1m See above for more context, but the positioning is being proposed as a separate API: Anchor Positioning. I believe it very nicely "solves" the style adjustments problem you bring up. The popover API provides the "on top" behaviors (and position:fixed as you mention) and the anchor positioning API allows a popover to be easily positioned relative to an appropriate anchor element. Is there a use case that you don't think is adequately handled by a combination of Popover and Anchor Pos?
torgo
commented
1 year ago Hi - we discussed in our plenary call on 11-2 - discussion includes some thoughts from @LeaVerou @atanassov and @plinss. Concerns center around what is and is not controlled by CSS and whether popup/popover should be the only way to place an element on the top-layer. Once you can control "top layered ness" as a CSS property, the use cases that prevent this from being an element are easily dealt with.
nt1m
commented
1 year ago Once you can control "top layered ness" as a CSS property, the use cases that prevent this from being an element are easily dealt with.
The nice thing about JS controlling the top layer is that it can enforce restrictions that allow the painting order to be somewhat sensical whereas with a CSS property, you can't really do so. As it stands, what can push to top layer is requestFullscreen() and dialog.showModal(), and the painting order is enforced by the ordering of the calls (not the ordering of the elements in the DOM!), which works out quite nicely! And there are restrictions to prevent weird edge cases, for instance, you can't fullscreen a <dialog> element.
I would oppose allowing CSS to move things into the top layer, because you allow such a mechanism, the stacking nature of the top layer no longer works out (which position do we use for a CSS-top layer element in the stack?), and problems similar to z-index arise again.
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.
mfreed7
commented
1 year ago +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 thepopoverattribute 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:
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 concept. Since it's a stacking layer in the document, 3p content is constrained to the iframe it's in. The z-index: 999 problem is precisely what is avoided by having only one top layer, and having well-specified behaviors 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, as:
The top layer is an 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) 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:
atanassov
commented
1 year ago @mfreed7, a relevant conversation to your points 1 & 2 that lacks traction with the CSSWG is https://github.com/w3c/csswg-drafts/issues/4998. We thought that if your were to address it, it will allow for quicker progress here.
chrishtr
commented
1 year ago @mfreed7, a relevant conversation to your points 1 & 2 that lacks traction with the CSSWG is w3c/csswg-drafts#4998. We thought that if your were to address it, it will allow for quicker progress here.
One note: issue CSSWG issue 4998 is really a spec refactoring task, not a lack of definition in the previous spec location. Still worth doing of course.
torgo
commented
1 year ago webkit standards position: https://github.com/WebKit/standards-positions/issues/74#issuecomment-1311566112
chrishtr
commented
1 year ago One note: issue CSSWG issue 4998 is really a spec refactoring task, not a lack of definition in the previous spec location. Still worth doing of course.
In addition, I have reviewed the top layer definition in the past multiple times, looking for any potential problem. I found it well defined and logical, even with respect to all the ways scrolling, z-index and every possible visual effect on elements, including the root element. So I do think this is a robust and well-defined concept that we can safely build upon.
plinss
commented
1 year ago I still have concerns about an active popover being automatically placed in the top layer, I feel this is something that should be controlled by CSS and can happen by default via the UA stylesheet.
@chrishtr I also have strong concerns that while top layer may be well defined, I don't believe that it's being defined in the right place. The full screen spec is monkey-patching CSS. The top layer design should be brought to the CSSWG and discussed there. The resulting design should be folded into a CSS spec and referenced from full screen.
nt1m
commented
1 year ago I feel this is something that should be controlled by CSS
I'm not involved in the popover API, but again I strongly oppose this idea for the reasons stated in https://github.com/w3ctag/design-reviews/issues/743#issuecomment-1314204961
In a CSS-controlled top layer, what controls the z-order within the top layer of the elements? It's going to be completely arbitrary. It will pretty much behave the same as z-index: MAX_VALUE and have the same problems.
For consistency with other things in the top layer at the moment, perhaps a better way is a JS call that doesn't push to the top layer.
annevk
commented
1 year ago @plinss that's been brought up repeatedly, but nobody picked it up thus far:
I've been asking for the CSS WG to take that over since I started working on Fullscreen a decade ago or so. Not exactly my area of expertise.
mfreed7
commented
1 year ago I feel this is something that should be controlled by CSS
I'm not involved in the popover API, but again I strongly oppose this idea for the reasons stated in #743 (comment)
In a CSS-controlled top layer, what controls the z-order within the top layer of the elements? It's going to be completely arbitrary. It will pretty much behave the same as
z-index: MAX_VALUEand have the same problems.
+1. The top layer is an ordered set, so it depends on the order that things are placed there. I'm not sure you'll be able to re-define top-layer as a feature determined by CSS, because it won't play nicely with existing things like dialog and fullscreen. (See this issue for ways to animate top layer status via CSS.)
mfreed7
commented
1 year ago Quick followup on this TAG review: the spec has landed in WHATWG with multiple implementer support. https://html.spec.whatwg.org/multipage/popover.html
I'm going to close this design review. Thanks for all of the comments!
torgo
commented
1 year ago Hi - there seems to be a bit of confusion here. just because it's in WHATWG it doesn't mean the review should be closed. In general TAG should be closing issues with our own process. We're going to go ahead and re-open and leave some additional feedback. We remain concerned about the toplayer spec itself which this is based on. We recognize that this isn't an issue with this spec itself. We would like to suggest that you help us work through these issues in the CSS working group (see the links from Anne above).
mfreed7
commented
1 year ago Oops, sorry about that! Github gave me a shiny "close this issue" button, so I pressed it. I won't do that in the future. And yes, I'll participate in the top layer discussions as needed.
atanassov
commented
1 year ago Thank you @mfreed7. Ideally we can talk about it this Wednesday during the csswg vf2f.
Wotcher TAG!
I'm requesting a TAG review of the Popup API. This is a third attempt at a TAG review for this feature; see https://github.com/w3ctag/design-reviews/issues/599 for the first, and https://github.com/w3ctag/design-reviews/issues/680 for the second.
A very common UI pattern on the Web, for which there is no native API, is "popup UI" or "popups". Popups are a general class of UI that have three common behaviors:
We are proposing a set of APIs to make this type of UI easy to build.
Further details:
You should also know that...
This is a third attempt at a TAG review for this feature. The first attempt was closed due to the lack of an Anchor Positioning proposal. That has now been proposed, and there's a draft spec. The second attempt was closed because we changed directions from a
<popup>element to apopupcontent attribute. This third TAG review is for that new content-attribute-based approach.We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @mfreed7
Security and Privacy questionnaire for TAG
2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? None. This feature does not expose any extra information to sites.
2.2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses? Yes - no new information.
2.3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them? N/A - no PII.
2.4. How do the features in your specification deal with sensitive information? N/A - no sensitive information.
2.5. Do the features in your specification introduce new state for an origin that persists across browsing sessions? No.
2.6. Do the features in your specification expose information about the underlying platform to origins? No.
2.7. Does this specification allow an origin to send data to the underlying platform? No.
2.8. Do features in this specification enable access to device sensors? No.
2.9. Do features in this specification enable new script execution/loading mechanisms? No.
2.10. Do features in this specification allow an origin to access other devices? No.
2.11. Do features in this specification allow an origin some measure of control over a user agent’s native UI? No. While pop-ups are shown in the top-layer, they cannot escape the frame bounds, and cannot be shown over the top of a UA's native UI.
2.12. What temporary identifiers do the features in this specification create or expose to the web? None.
2.13. How does this specification distinguish between behavior in first-party and third-party contexts? It does not distinguish. Pop-ups are isolated to their frame, for both 1st and 3rd party frames.
2.14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode? Just fine. No exposure of private browsing state.
2.15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections? There are no known security impacts of the features in this specification.
2.16. Do features in your specification enable origins to downgrade default security protections? No.
2.17. How does your feature handle non-"fully active" documents? N/A
2.18. What should this questionnaire have asked? N/A