Polyfills the HTML popover attribute and showPopover/hidePopover/togglePopover methods onto HTMLElement, as well as the popovertarget and popovertargetaction attributes on <button> elements.
The Drupal project is working on two new features that will use the Popover API. These are is taking place here. Part of the process of adding a dependency is a standard stability review. If any of this leads to you asking "why is this kind of thing being asked about a simple polyfill", it is kind of a broad policy, but we've also been surprised at which dependencies resulted in the need to be aware of such things.
It seems like this a well maintained and trusted project, and essentially the canonical way to ensure popover API syntax will work on any modern browser. Even with that know we like to at least check if there are official policies documented somewhere WRT to:
Security releases:
For example, does more than one version receive security fixes, or only the current version? Would this change if a 1.x was released parallel to the 0.x releases currently happening?
Release windows/cadence
For example, do they happen as necessary on any given day, or on a set schedule after a certain passage of time (e.g. once a month)? If necessary, could a release date be arranged with other projects if it's beneficial to have a coordinated disclosure of a vulnerability.
Backwards compatibility guarantees:
I assume the project uses semver based on the numbering so I assume the major version promises not to break BC. Are there any guarantees that a version will be supported for some period of time (an LTS version, for example)? If not, do you not anticipate the need to do this based on what the polyfill does & growing browser support?
If any of these don't have straightforward answers, that's absolutely fine. Having record of this being read and acknowledged is what will most help us get this polyfill into Drupal core.
jamesnw
commented
1 month ago
The Drupal project is working on two new features that will use the Popover API. These are is taking place here. Part of the process of adding a dependency is a standard stability review. If any of this leads to you asking "why is this kind of thing being asked about a simple polyfill", it is kind of a broad policy, but we've also been surprised at which dependencies resulted in the need to be aware of such things.
It seems like this a well maintained and trusted project, and essentially the canonical way to ensure popover API syntax will work on any modern browser. Even with that know we like to at least check if there are official policies documented somewhere WRT to:
Security releases: For example, does more than one version receive security fixes, or only the current version? Would this change if a 1.x was released parallel to the 0.x releases currently happening?
Release windows/cadence For example, do they happen as necessary on any given day, or on a set schedule after a certain passage of time (e.g. once a month)? If necessary, could a release date be arranged with other projects if it's beneficial to have a coordinated disclosure of a vulnerability.
Backwards compatibility guarantees: I assume the project uses semver based on the numbering so I assume the major version promises not to break BC. Are there any guarantees that a version will be supported for some period of time (an LTS version, for example)? If not, do you not anticipate the need to do this based on what the polyfill does & growing browser support?
If any of these don't have straightforward answers, that's absolutely fine. Having record of this being read and acknowledged is what will most help us get this polyfill into Drupal core.