#599: HTMLPopupElement - <popup>

Visit on Github.

Opened Jan 22, 2021

HIQaH! QaH! TAG!

I'm requesting a TAG review of the <popup> element.

A new HTML element, <popup>, which can be used to build transient user interface (UI) elements that are displayed on top of all other web app UI. These include user-interactive elements like action menus, form element suggestions, content pickers, and teaching UI. This new element is similar to <dialog>, but has several important differences, including light-dismiss behavior, anchoring, and the lack of a "modal" mode.

Does this specification allow an origin some measure of control over a user agent’s native UI? --> The <popup> element allows author-provided popup dialogs to be shown to the user. These popups are fully-contained within the owning frame, and do not overlap either parent frames or the browser UI. So there shouldn't be any issue here. But I'm bringing it up for completeness.

  • GitHub repo (if you prefer feedback filed there): I'd prefer feedback here on this issue.
  • Primary contacts (and their relationship to the specification):
    • Mason Freed (@mfreed7), Google
    • Melanie Richards (@melanierichards, Microsoft
  • Organization/project driving the design: Google DOM Team, Microsoft DOM/Editing Team
  • External status/issue trackers for this feature: https://chromestatus.com/guide/edit/5463833265045504

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
  • Existing major pieces of multi-stakeholder review or discussion of this design: {coming soon}
  • Major unresolved issues with or opposition to this design: "Major" is a strong word, but there is a section of the explainer that discusses open issues and questions. Thoughts on those issues would definitely be appreciated from TAG.
  • This work is being funded by: Google and Microsoft

You should also know that...

I like the TAG.

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 and @melanierichards

Discussions

Comment by @LeaVerou Feb 3, 2021 (See Github)

Firstly, this is addressing a very real gap in the Web Platform and I'm happy to see work in that direction.

If my understanding is correct, this proposal introduces a <popup> element with the following features:

  • An anchor attribute anchors this to another element, both in terms of styling, as well as other behaviors.
  • Can "spill out of" containers, ignoring overflow: hidden
  • It comes with some light behavior baked in, such as light dismiss
  • It includes show() and hide() methods
  • autofocus is handled specially when the popup is shown
  • There is a delegatefocus attribute to focus the first focusable descendant when the popup is focused

Here are some thoughts.

Positioning

It seems to me that the primary problems this is trying to solve are styling problems:

  • positioning a positioned element based on another element.
  • allowing an element to "spill out" of overflow: hidden ancestors.

I think these are problems we should solve in CSS, rather than by introducing new "magic" that cannot be described fully in the UA stylesheet. Not only for separation of concerns, but also because this is more broadly useful and we wouldn't want people to have to wrap everything in a <popup> every time they need to position an element based on another element. The <popup> element can then just use that CSS as part of its UA stylesheet rules.

There are a few CSSWG threads on this, though there's definitely room for new proposals in this space: https://github.com/w3c/csswg-drafts/issues/5304 https://github.com/w3c/csswg-drafts/issues/5699

Anchoring

I would suggest re-using the for attribute instead of introducing a new anchor attribute. This seems consistent with <label for> and <output for> usage.

It would be useful to have a default anchor, just like <label> elements default to form descendants when they do not have a for attribute. For example, the previous sibling and/or the parent element might be a good default. It also means that there is a more useful default than just displaying the popup at the top left corner, which is almost never desirable.

It is unclear to me if anchor affects tabbing order, but I think it should. There are many cases where the popup cannot be placed inside or next to the element it's anchored to, due to content model limitations or CSS inheritance. Authors should be able to continue the current practice of placing the popup as a child of <body>, without the current accessibility problems wrt tabbing order.

The hierarchy affects the event propagation path.

This could either be very useful, or very confusing, and I'm not sure which one it is. I suppose there is precedent, with form elements receiving input events when their associated label receives these events.

Focus

On autofocus:

To move focus to the popup itself when show is called—without the need to explicitly call popupElement.focus()—place the attribute directly on the popup:

Are there use cases of showing the popup but not focusing it?

On delegatefocus:

Some authors may need to automatically focus the popup's first focusable descendent, and may not wish to write script to determine at runtime which element that is.

I wonder if that is the actual gap here: it should be easier to determine what the first focusable descendant is. But I definitely see the point about exposing this via HTML so that authors don't have to write script. But is this something specific to <popup> or a more generally useful behavior? I have definitely needed this before with arbitrary focusable elements (e.g. collection items).

Show and hide

I would recommend adding an open attribute, just like <dialog> so that authors can a) open the popup declaratively and b) target opened popups with an attribute selector.

Layering

Are rendered on top of all other content in the host web application

Even over <dialog>?

Comment by @mfreed7 Feb 18, 2021 (See Github)

Firstly, this is addressing a very real gap in the Web Platform and I'm happy to see work in that direction.

@LeaVerou thanks for the great set of initial feedback here. I'm glad you think this is a useful addition. Responses below...

If my understanding is correct, this proposal introduces a <popup> element with the following features:

  • An anchor attribute anchors this to another element, both in terms of styling, as well as other behaviors.
  • Can "spill out of" containers, ignoring overflow: hidden
  • It comes with some light behavior baked in, such as light dismiss
  • It includes show() and hide() methods
  • autofocus is handled specially when the popup is shown
  • There is a delegatefocus attribute to focus the first focusable descendant when the popup is focused

The only thing I want to clarify here, which ties to the comments below, is that the positioning of the popup has been delegated to a separate platform proposal, for "anchored positioning". This has not been put forth yet, but the current <popup> proposal should be read in the context of a forthcoming proposal on positioning. I do understand the confusion here.

Positioning

It seems to me that the primary problems this is trying to solve are styling problems:

  • positioning a positioned element based on another element.
  • allowing an element to "spill out" of overflow: hidden ancestors.

I think these are problems we should solve in CSS, rather than by introducing new "magic" that cannot be described fully in the UA stylesheet. Not only for separation of concerns, but also because this is more broadly useful and we wouldn't want people to have to wrap everything in a <popup> every time they need to position an element based on another element. The <popup> element can then just use that CSS as part of its UA stylesheet rules.

See above. Really, I think the primary low-level problem that <popup> solves is access to the "top layer". I.e. the ability to position a popup over the top of everything else, regardless of position in the DOM tree or how many 9's you use in z-index:999999. The "magic" that isn't specified in this proposal is a way to anchor-position one element (the <popup> in this case) relative to the position of another element (e.g. the <popup>'s "anchor" element). As I mentioned, I believe a proposal is forthcoming. @melanierichards, @ipopescu93

Anchoring

I would suggest re-using the for attribute instead of introducing a new anchor attribute. This seems consistent with <label for> and <output for> usage.

Thanks for the feedback here. Consistency is important, but so is clarity. There is a discussion see this comment about naming, anchor positioning, and automatic (declarative) invokation. Those might require two separate attributes (e.g. "anchor" and "invokedby") that might need more verbose attribute names than just "for". Let's discuss further on the issue.

It would be useful to have a default anchor, just like <label> elements default to form descendants when they do not have a for attribute. For example, the previous sibling and/or the parent element might be a good default. It also means that there is a more useful default than just displaying the popup at the top left corner, which is almost never desirable.

I definitely agree with this point. We need to figure out the mechanics of this, since theoretically any element could be an anchor. The <label> spec is easier to implement because there's only one type of element to look for. Here, we might need to "stop" on an attribute or something, e.g.

<button im-the-anchor>
  <div id=not-the-anchor>
    <popup></popup>
  </div>
</button>

Suggestions appreciated here.

It is unclear to me if anchor affects tabbing order, but I think it should. There are many cases where the popup cannot be placed inside or next to the element it's anchored to, due to content model limitations or CSS inheritance. Authors should be able to continue the current practice of placing the popup as a child of <body>, without the current accessibility problems wrt tabbing order.

Hmm that's a very good point, which I don't think we've considered in the explainer. I would agree that since the <popup> can be placed anywhere, but will (usually) be visually next to the anchor element, it might make sense to modify tab order to account for this. @melanierichards thoughts?

The hierarchy affects the event propagation path.

This could either be very useful, or very confusing, and I'm not sure which one it is. I suppose there is precedent, with form elements receiving input events when their associated label receives these events.

I agree that it might be confusing. As I've been implementing the prototype in Chromium, wrapping my head around this part has been tricky at times. Again, suggestions appreciated for ways to make it less confusing in practice.

Focus

On autofocus:

To move focus to the popup itself when show is called—without the need to explicitly call popupElement.focus()—place the attribute directly on the popup:

Are there use cases of showing the popup but not focusing it?

@melanierichards for better examples here. But I think one is likely a "teaching bubble" that pops up on hover of some other control, but you wouldn't want focus to move to the bubble in that case.

On delegatefocus:

Some authors may need to automatically focus the popup's first focusable descendent, and may not wish to write script to determine at runtime which element that is.

I wonder if that is the actual gap here: it should be easier to determine what the first focusable descendant is. But I definitely see the point about exposing this via HTML so that authors don't have to write script. But is this something specific to <popup> or a more generally useful behavior? I have definitely needed this before with arbitrary focusable elements (e.g. collection items).

One quick first comment is that I think we should call it delegatesfocus (with plural 's') to match the similar concept for ShadowRoot. Perhaps that's also the more generally useful behavior you're looking for?

Show and hide

I would recommend adding an open attribute, just like <dialog> so that authors can a) open the popup declaratively and b) target opened popups with an attribute selector.

See this related comment from @domenic. It does seem like we should make sure <popup> and <dialog> are as parallel as they can be here.

One (potentially big?) issue with opening the popup declaratively is that only one popup can be open at a time (excepting "nested" popups) so the behavior might be a bit odd if more than one <popup> has an open attribute. That can be fixed, of course, but I'm wondering if it might be better to just remove "open" from <dialog> instead. Also, the use case for <popup> seems to be in "response" to something on the page, which should preclude popups that open themselves immediately on page load. But maybe I'm missing a use case for that.

Layering

Are rendered on top of all other content in the host web application

Even over <dialog>?

<popup>s are rendered on the "top layer", in the order they were added. So if a <dialog> was already open, and a <popup> is shown, it will be rendered on top of the <dialog>. Further, a <dialog> being shown will trigger "light dismiss" behavior on any already-showing <popup>s.

Comment by @LeaVerou Feb 18, 2021 (See Github)

I definitely agree with this point. We need to figure out the mechanics of this, since theoretically any element could be an anchor. The <label> spec is easier to implement because there's only one type of element to look for. Here, we might need to "stop" on an attribute or something, e.g.

<button im-the-anchor>
  <div id=not-the-anchor>
    <popup></popup>
  </div>
</button>

Suggestions appreciated here.

I think the previous sibling or the parent are both reasonable defaults. Slight preference for previous sibling, as it's less constrained and can work with empty elements as implicit anchors. A downside is that there might not be a previous sibling, but I suppose that is analogous to having a <label> with no for attribute and no form control descendants.

Show and hide

I would recommend adding an open attribute, just like <dialog> so that authors can a) open the popup declaratively and b) target opened popups with an attribute selector.

See this related comment from @domenic. It does seem like we should make sure <popup> and <dialog> are as parallel as they can be here.

One (potentially big?) issue with opening the popup declaratively is that only one popup can be open at a time (excepting "nested" popups) so the behavior might be a bit odd if more than one <popup> has an open attribute. That can be fixed, of course, but I'm wondering if it might be better to just remove "open" from <dialog> instead. Also, the use case for <popup> seems to be in "response" to something on the page, which should preclude popups that open themselves immediately on page load. But maybe I'm missing a use case for that.

Providing declarative HTML-based ways to interact with UI controls has several benefits. Off the top of my head:

  • It facilitates experimentation and iteration (much quicker to type open when iterating than to write script)
  • It makes it more learnable: there is a baseline uniform API (DOM) that novices can use to interact with the UI control via script, even before learning the more specialized API that might come with each individual control
  • It means behaviors can be expressed reactively in libraries supporting such syntax (e.g. open={{expression}}) and be handled by any library handling HTML generically.
  • It means UI states can be addressed via established and widely understood attribute selectors, instead of new pseudo-classes
  • It makes state inspectable via dev tools which facilitates debugging

Therefore, I think removing open from <dialog> would be a step in the wrong direction. It would be far better to instead of fix its issues so it can be adopted in <popup> as well.

The fact that only one popup can be open at a time is not a blocker; there is already precedent with radio buttons and their checked attribute or <option> elements and their selected attribute. But are you sure there are no use cases of showing multiple popups at once? Nested popups is one use case that is expressly listed as an exception. Could there be more?

Discussed Feb 22, 2021 (See Github)

Lea: I have opinions. Left a comment. The use cases are obvious, no doubts about that. Seems like a bunch of things all together and the utility has to do with positioning and overflow, and these are things that should be solved in CSS instead of adding more magic that cannot be described by the stylesheet. Already proposals in CSS WG about how to deal with it, space for more. I don't think we should solve this with a new html element, should solve in CSS and use it in UA stylesheet. Some more points about attribute names.

Tess: the html folks don't like to have magic either. I agree with Lea that positioning stuff, whichi snot spelled out, is the interesting part - missing in CSS that would be useful for tons of things. Beyond how the positioning works, it's not novel or challenging.

Lea: I think there are use cases for stuff beyond positining. Could come with basic defaults. Coule help with accessibility, tabbing order, things CSS can't address. Eg. anchor the popup to an element which could affect tabbing order.

Rossen: majority is already in dialog

Dan: so why are they proposing it? a lot of people behind it. Is it ergonomics? an easier way to do something that can be done already? Does the need for this highlight a hole in the platform that we need to be responsive about?

Lea: the platform doesn't do this, it just shouldn't be done by an html element. The behaviour of popups spilling out of a container with overflow:hidden there's no way to do that today declaratively. Ergonomics like the light dismiss behaviour, can be done already but is just a convenience. A bag of features that come with it, they're all useful, but not sure it's the right place.

Rossen: yep. Feedback I had from them was around that, compared to dialog there are problems they want solved.

Tess: I can leave a comment

Peter: the light dismiss behaviour, another review Tess and I did on [??] that should be coordinated into this. Should reuse instead of inventing something else.

[reassign at plenary]

Comment by @melanierichards Feb 25, 2021 (See Github)

Hi folks, apologies that I am so woefully behind in responding to this issue, and many thanks to @LeaVerou for reviewing the proposal!

Substantive changes to the proposal

  • delegatefocus was renamed to delegatesfocus (this was a typo, not intentional).
  • The open attribute is now part of the popup proposal. We're omitting the hidden attribute now given HTML editor/contributor interest in addressing some of the quirky behavior with dialog and removing the open attribute.
  • A popup attribute has been added to the proposal. This is applicable to a subset of interactive elements and can be used to invoke the popup without script. We considered using the for attribute for this (applied to the invoker element), but we felt this might be confusing for authors ("isn't my popup for this combobox input?"). Happy to bikeshed on this though.
    • We still consider invocation/controller relationships to be separate from anchoring, as your invoker may not always be your anchor. And you may have an anchor but no invoker element.
    • The popup attribute now also negates the need for aria-haspopup and aria-controls. Equivalent accessibility semantics will be mapped as a result of this attribute.
  • We weren't sure that the change to event bubbling was providing the right value in exchange for the added platform complexity, so we've moved this to the appendix and will track any author feedback on this.

Anchoring

  • The anchor attribute is meant only to be a hook for a CSS-based scheme that we have not yet published (working out how to deal with a couple specific use cases). I'll publish on the CSS issue thread with where our thinking is at right now.
  • We did chat about anchoring reordering trees, as the accessibility tree order matters in addition to the right tab cycle. While we hope that due to the top-layer positioning of popup it would become less of a common practice to insert the popup somewhere separate in the DOM, I think we need to anticipate having to heal distant anchors and popups. We weren't quite sure whether this reordering capability should be tied to the popup attribute, anchor attribute, or some fallback scenario between the two, so this was added as an open question.

Focus

  • Re "Are there use cases of showing the popup but not focusing it?": teaching UI is certainly one of these. With comboboxes, you also want to keep your focus in the text input by default even as you show available options in the listbox. And there are menu button + popup patterns where invoking the button shows the popup menu, but focus does not move into the menu until the user presses the down arrow key, for example.
  • I agree that the delegatesfocus attribute could be extended to other elements. This seems like a good one to raise in Open UI and similar forums to find out what other use cases authors might be tracking.
Comment by @torgo Mar 10, 2021 (See Github)

Thanks @melanierichards for letting us know about this. I'm putting this on our agenda for next week and we hope to have feedback back to you by then.

Comment by @melanierichards Mar 10, 2021 (See Github)

Thanks to @torgo and the rest of TAG!

As a heads up, the Open UI CG resolved to take up this work item for incubation before we bring any formal changes to the HTML spec (we have shared the early ideas with WHATWG, however). This doesn't have any bearing on the design of the APIs as of yet, but I thought it might be useful to know where we'll first take up any TAG feedback. Thanks again!

Discussed Mar 15, 2021 (See Github)

Lea: we gave a fair bit of feedback - they added an open attribute as part of that response. They also added a popup attribute - you put it on elements you want to trigger a specific popup but no indication on [how to use it]. Also: there was a lot of talk about how this relates to CSS. But this then becomes a 2-part proposal and the other part hasn't been proposed yet. There are autofocus and delegatesfocus attributes.. scoping issues. Dismiss behavior - no way to turn it off - has been a problem for dialog authors are complaining about customization. Could mean any time they have to do something custom they just implement it themselves.

Peter: there was another proposal for a dismiss listener

Tess: I like dialog behaviour, escape is always a way to get out. Sites don't always do the right thing, we don't want a user to get stuck in a modal without any way to get back to the page. Agree sites should be able to add custom ways of exiting the thing, but important for the browser to always provide a way to get out

Lea: there are valid reasons where you might want to make a popup not closeable. Isn't that the point of a modal?

Tess: fullscreen as an example, it has to be exitable. The app might have lots of reasons for making it not, but the applications reasons are lower than the users needs.

Lea: absolutely, but fullscreen takes over your entire screen where as a modal is only within the current page

Ken: on mobile it's full screen...

Tess: backdrop overlay behind a modal prevents selecting text on the page.. A lot that a modal can stop you from doing.

Lea: light dismiss is not.. it's easier to dismiss a popup than a dialog, not just escape key, cicking outside dismisses it, this seems like something authors would want to be able to trap

Tess: I think you should be able to exit by clicking outside, should be default

Ken: yeah

Lea: default yes, but only behaviour?

Tess: additional ways to exit that's fine. I don't think it should get in the way

Ken: don't want people to block it from exiting. Stupid mistakes like a cookie banner behind that you can't exit. I want really compelling use cases where you want to block people from exiting

Tess: block until you make a choice between three things but a script inserts content so you can't pick the things, and never get out of it

Lea: okay

Peter: if the api surface guarantees that there's always a way to exit the apps have to design around that, and respect the fact it might be exited without a choice and deal with that however they deal with it, and that's a better user experience. Agree that there should be a way for the authors to be notified of the fact it was dismissed, regardless of how it was dismissed

Lea: they have a close event, like dialog

Peter: context that it was dismissed vs closed because it was interacted with?

Lea: I don't think so.

Peter: might be important to know that

Lea: it's a hide event. That should probably be harmonised with dialog and have the same event name

Ken: that would make sense

Tess: yes should align with dialog. Consistency is good.

Peter: and there was another proposal, dismiss watcher, we had issues with that and think it shouldn't proceed but if it does, they should use that, consistently across the platform

Lea: what about the popup attribute?

Tess: am worried about it because we still don't know the positioning story. How that's going to work? We shouldn't be sprouting html features that tie into an undefined positining thing. The positining thing might inform us of how it should tie into html, maybe an attribute isn't the right way, we shouldn't constrain the CSS WG before it makes progress on this.

Lea: apply to anchor attribute as well? seems more essential

Tess: Maybe. Cart before the horse. I get the temptation to do the parts that aren't hard. We need enough of an idea of how the hard parts work so we can do this part.

Lea: what do you think about tabbing? if you have a popup anchored to another element should tabbing from the anchor focus the popup?

Tess: I don't know

Ken: should be easy to focus a popup

Tess: if anchor is a button and you press the button it causes the popup I wouldn't want the popup until I activate the button not just focus

Ken: but don't want focus on something behind the popup

Tess: if the popup pops up automatically when the button gets focussed you're in a weird positon where the focused element is behind the popup. If you wanta UI with a button to cause a popup, pressing the button should cause focus to move to inside the popup. Other UIs you might ave something that isn't a button that is focusable and you want when it focuses to cause a popup to come up.. can imagine wanting that.. seems problemantic because you get a cycle where youf ocus the thing, casues thepopup, focus gets moved inside the popup which blurs the thing that causes the popup to appear which causes the popup to disappear

Lea: moving automatically to the popup is disruptive

Ken: more weird if it stays behind and is like a toggle

Lea: anchor doesn't specify how the popup is shown, that is managed separately by adding open attribute or calling show method. Anchor tells the popup what was the invoker element. If you have an invoker element and press tab, where should focus go?

Tess: focus is currently in the popup?

Lea: no, focus is on the button that triggers the popup, button is still focussed, press tab

Tess: the button blurs and there's a chance the popup goes away. If you focus inside the popup and make the popup disappear that's not great

Lea: that will happen regardless of what the next focus eleemnt is. Should the anchoring relaitonship between the popup and the invoker override any existing tab order? should it also establish a tabbing order when you make an element the anchor of a popup?

Tess: if the popup is open you should be able to tab to the things in it, somehow. Where in the order I don't know.

Lea: that's a separate issue. Sometimes authors put the popup in a separate place in the DOM so without manual management of the tabbing order tabbing would go to another element not the popup. Could the relationship mandate a tabbing order? could help accessibility but could get in the way. Enforcing a tabbing order that is relative is a pain. if authors have to do this manually

Tess: they'll get it wrong. Does seem like it should do it.

Lea: maybe it should be easier to have a relative tabbing order

Peter: if you've activated a button that should move the focus within the popup

Lea: without tabbing? They have a separate attribute for that, autofocus. Also delegates focus attribute which means if the popup gets focussed the focus moves automatically to the first descendent element that is focusable.

Ken: that exists in web components

Lea: that sounds like more useful as a global concept and not special to popup

Ken: maybe

Dan: we're trying to design a feature.. What feedback can we give?

Hadley: have we asked them about tabbing?

Lea: they are trying to decide so wondering if we can provide input

Hadley: sounds like we might be in a better position to react to what they propose? I didn't hear consensus between all of you.

Peter: we'd like to see the rest of this designed before we thumbs up and they should come back when the rest has been figured out.

Lea: yeah

Peter: someone write that. Maybe premature to define some of these attributes until we have the rest of the story.

Lea: will write. Ask them to ping us when the rest is designed.

Ken: or maybe we have given the feedback on early and they should file a more mature review?

Peter: yeah. Close but tell them when the rest is designed please open a new issue and link a reference to this one.

Dan: feels like a lot of good valuable discussion just now.

Comment by @LeaVerou Mar 18, 2021 (See Github)

Thank you for the updates @melanierichards! It's good to see progress on this!

We discussed this again this Monday, and concluded that since this is essentially a two-part proposal (the HTML element and the CSS positioning scheme it hooks into), we would need to see both parts to review it further. Without this essential component, it is difficult to properly evaluate things like the anchor or popup attributes.

Therefore, we are going to close this early review and will continue to monitor open issues for a future review request where we can look at the entire proposal.

There was also some discussion on lower level design decisions in the breakout that you might find useful.

Comment by @melanierichards Mar 18, 2021 (See Github)

Thank you @LeaVerou & co, will re-file once we've got all our cohesive thoughts on anchored positioning down on paper! :)

Comment by @melanierichards Jun 17, 2021 (See Github)

Hi @LeaVerou @hober @kenchris and @atanassov, wanted to share an update with you in case it's a good time to revisit this review. (Please let us know if a separate issue is preferable to reopening this one, thought it nice that the history was here)

<popup> itself is in active incubation in the Open UI CG: initial proposal, issues we are working through, first editor's draft PR

CSS Anchored Positioning Scheme

  • An initial proposal has been published. We have two viable proposals here for a path forward: the primary at-rules-based syntax, and an "Alternate A" syntax which uses a position-set() function within various property values. We think that actually Alternate A might be a bit better implementation-wise, as it avoids a style-on-layout dependency introduced by the at-rules syntax. However, we've invited author feedback on the ergonomics of the various options; TBD on an assessment there.
  • The initial proposal aims to give enough flexibility to cover known use cases for anchored positioning. However, some authors may prefer "magic" over control (w/r/t repositioning anchored elements) and might find the current syntax somewhat overpowered for their use case. We plan to discuss how the proposals could evolve to empower 1) the developer who wants to express a preferred position and let the UA handle fallbacks and 2) the developer who has very specific requirements as to positioning-aware styling and fallback positioning logic.
  • The proposal is limited to browser-managed, top-layer elements for now, due to perf reasons. We want to see what we can do to expand that scope, even if the use of this scheme is not completely unrestricted.
  • Open UI has agreed to incubate this proposal/discussion and get it to a more mature place before formally bringing this proposal to CSSWG for specification. CSSWG has been notified of this work. FYI, given that the reviewers are chairs/members of CSS: we plan to request a 5 minute agenda item presenting this scheme/inviting collaboration in Open UI. That will occur after yours truly is out of office next week. :)

Clearly, we're still early in co-designing a solution here for anchored positioning, but we wanted to prioritize giving the TAG a heads up. Thanks in advance!

cc / @mfreed7 @BoCupp-Microsoft

Comment by @mfreed7 Jun 18, 2021 (See Github)

Thanks @melanierichards!