You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow on from the OpenUI issue where initial discussion for how the proposed popup attribute would be exposed by browser accessibility apis.
The popup attribute has three different values that represent variations in behavior for the popup.
popup="" or auto represent the default behavior, where the popup is rendered as display:none until a user invokes it by activating its associated control. e.g., a button, or combobox triggering element.
popup="hint" (name of this value could still change) is a popup that would behave like a tooltip, invoked on hover or focus of an element to which the popup is associated.
popup=manual would be for other instances of needing a popup element where there may only be a loose association with the element that invokes them, or there may be no explicit element to which the popup is associated with. For instance, a toast notification or possibly a persistent chat dialog which needs to be rendered in the browser's top layer. Unlike other popup types, there can be multiple manual popups rendered on a page at once.
The general intent of the popup attribute is to keep the semantics of the element it is used upon, but there would still be a need to expose the element as a "popup". E.g., a listbox may be rendered as an form control within the normal flow of a web page, or it may be rendered as a "popup", and if keyboard focus were to leave the listbox, it would auto-dismiss.
The intent of the attribute over a popup element was that there are many types of "popups", and there is no one role that accurately represents all of them. However, with a global attribute which can be used on generic elements, there is the question of how this should be exposed to accessibility apis if authors fail to add an explicit ARIA role to such elements. There is a similar issue with contenteditable - where the attribute can make any element editable, whether that practically makes sense or not - but it is still unclear what role, if any, should be applied to generic elements that have been made editable.
Other attributes related to popup which also need mappings discussed (though these are generally more straight forward):
togglepopup - used on invoking element
showpopup - used on invoking element
hidepopup - used on element within a popup to close said popup
defaultopen - used on a popup to set it to open by default. This will not work with popup=hint.
The text was updated successfully, but these errors were encountered:
Follow on from the OpenUI issue where initial discussion for how the proposed
popup
attribute would be exposed by browser accessibility apis.The
popup
attribute has three different values that represent variations in behavior for the popup.popup=""
orauto
represent the default behavior, where the popup is rendered asdisplay:none
until a user invokes it by activating its associated control. e.g., a button, or combobox triggering element.popup="hint"
(name of this value could still change) is a popup that would behave like a tooltip, invoked on hover or focus of an element to which the popup is associated.popup=manual
would be for other instances of needing a popup element where there may only be a loose association with the element that invokes them, or there may be no explicit element to which the popup is associated with. For instance, a toast notification or possibly a persistent chat dialog which needs to be rendered in the browser's top layer. Unlike other popup types, there can be multiplemanual
popups rendered on a page at once.The popup explainer on openui has additional details.
The general intent of the
popup
attribute is to keep the semantics of the element it is used upon, but there would still be a need to expose the element as a "popup". E.g., alistbox
may be rendered as an form control within the normal flow of a web page, or it may be rendered as a "popup", and if keyboard focus were to leave the listbox, it would auto-dismiss.The intent of the attribute over a popup element was that there are many types of "popups", and there is no one role that accurately represents all of them. However, with a global attribute which can be used on generic elements, there is the question of how this should be exposed to accessibility apis if authors fail to add an explicit ARIA role to such elements. There is a similar issue with
contenteditable
- where the attribute can make any element editable, whether that practically makes sense or not - but it is still unclear what role, if any, should be applied to generic elements that have been made editable.Other attributes related to
popup
which also need mappings discussed (though these are generally more straight forward):togglepopup
- used on invoking elementshowpopup
- used on invoking elementhidepopup
- used on element within apopup
to close saidpopup
defaultopen
- used on apopup
to set it to open by default. This will not work withpopup=hint
.The text was updated successfully, but these errors were encountered: