[popup] Note that popup=async + JavaScript allows custom behavior

[mfreed7]

This issue was reported by @domenic here, and is being moved to the OpenUI repo.

---

This was a nice bonus I discovered upon reflection, and comparing with the old popup proposal.

If a developer wants some sort of custom behavior, e.g., "close all other toasts that are of a similar application-specific type", or "no force-close but yes light dismiss", then they can accomplish it using popup=async plus some custom JavaScript code for the entertoplayer handler.

This is good! It counters any arguments that, by providing somewhat-opinionated classes of UI, we're doing something too magic that will make developers sad.

I think this is worth pointing out in https://github.com/mfreed7/popup#classes-of-ui---dismiss-behavior-and-interactions .

(Also it may feed into the bikeshed discussion, e.g. popup=manual might be a better name than popup=async.)

[gregwhitworth]

@mfreed7 is the sole purpose of this to be a reminder for you to add a positive note to the spec regarding this?

[mfreed7]

I think this warrants some discussion, actually. I was discussing this with @una today, and we came to the conclusion that <div popup=async> and <dialog>.show() behave very similarly:

• Both stay open until explicitly closed.
• Both allow multiple elements to remain open at the same time.
• Both are typically (?) used for UI that is akin to an alert that doesn't need immediate action, in contrast to a modal dialog or a transient popup, for example.

There are some differences:

• non-modal <dialog> is not top layer, while <div popup=async> is.
• <dialog> has role=dialog semantics, while <element popup=*> has the semantics/a11y role of <element>.
• <dialog> has no open event, while popups do have a show event. This allows the "customizability" described in the OP here.

The above begs the question: do we need both? Are these two things (non-modal dialog and async popup) close enough that we shouldn't introduce both? Or are the differences both a) useful enough, and b) not too confusing, such that we should ship both.

Side note: I really like the suggestion to rename popup=async to popup=manual. It is more descriptive, I think. It would also give another suggestion for the bikeshedding issue for popup=popup: popup=auto.

[chrisdholt]

@mfreed7 it seems like the underlying question here is, "Are all instances of popup=async instances of a non-modal dialog"? If they are, then that provides an answer - but if they aren't, are we getting into territory of running into scenarios where semantics are being overridden on dialog to accomplish something? And in that case, would we then be running afoul of the reason we moved away from <popup> as an element? I don't know that I have an explicit answer there myself, but I am naturally a bit dubious (without examples of course...) that dialog semantics would always fit or apply here.

[scottaohara]

agreed. we are verging on discussing what toasts-like notifications should be marked up as without discussing them directly. are hey non-modal dialogs? are they non-modal dialogs which have also been marked as popups to get them in the top layer? are they something else entirely?

Note: there are also a variety of open questions / spec-gaps for non-modal dialog which may further diverge these two concepts. so what a non-modal dialog behaves like now is not necessarily how it should be behaving

[mfreed7]

After a discussion with @aleventhal, and based on the comments above, it seems increasingly clear that there are really only two use cases currently being discussed for popup=async:

1. notifications/alerts/toasts/snackbars (all different names for roughly the same use case)
2. "Everything else"

Since the "everything else" use case is rather nebulous, it becomes tough to design things like accessibility. We were wondering if it might make sense to rename popup=async to popup=alert (as it was decided here, or we could choose one of the other names) and make this use case more explicitly for notifications/alerts/toasts/snackbars. That would allow us to define more precisely the accessibility expectations. E.g. should they all be announced? Should they all be landmarks?

Given our previous IDL resolution, the available values for the popup attribute are feature-detectable. So we can always come back and create additional values to support additional use cases in the future, as they become apparent. But for now, let's scope this to the one concrete use case. Thoughts?

[domenic]

[chrisdholt]

I could see alert implying a relationship with a11y and the role of the same name. Inferring a bit from @domenic's "vote" (?), toast may be more desirable here if we are looking at managing expectations around accessibility and aren't going to directly tie this to the alert role. ¯_(ツ)_/¯

[domenic]

I was mostly being silly, please ignore!

[chrisdholt]

I was mostly being silly, please ignore!

Noted! I'll stand by the potential implication of having a name that also represents an intuitive role here. I know we were hesitant to tie popup to role so I think it's worth consideration. FWIW, I'm not a fan of names like "toast" or "snackbar" but in this case I'd take the first over the last myself :)

[scottaohara]

i think the thing we need to keep in mind if we go this direction, we take into account it was previously decided that there could be multiple of these on a page at once, on page load even. if they all have the potential to be individual live region elements, that could create A LOT of dynamic announcements.

Live regions competing with each other (when multiple are declared and fired at the same time on a web page) resulting in having their announcements overwritten by each other, or accidentally cancelled out by users is unfortunately common.

As I mentioned in the other doc we were working on (so i'm not going to repeat myself here for now), i'm not opposed to going this way with the attribute value. I would just want to tread carefully.

re: the potential new attribute name. i'd submit we should have another naming discussion on that (everyone's favorite thing to do, i realize). A lot of things have changed since that resolution.

However, if we codify the image of toast that domenic posted into an emoji that could be used as the attribute's value... then i rescind that statement, and we absolutely should just make the value 'toast emoji' (of which i could not easily find one in my 3 minutes of looking)

<div popup=🍞> a loaf of bread is just a lot of future toast, right?</div>

[aleventhal]

No matter how hard we try, this may be something the author needs to at least think about.

How about this: we support both popup=async and popup=notification.
They will do the same thing except that popup=notification will be exposed as an alert or alertdialog.
Benefits:

• The name "notification" would attract authors who are using it for that. In most cases notifications should be announced, so this would provide the best default behavior.
• The name "async" would attract authors who need the functionality but don't think of their dialog as a notification.

There is no perfect solution, but if we can be 80% right that would be great.
The spec can explain the difference. Having the 2 different values would encourage authors reading about it or blogging about it to explain the difference. In short, we get the best behavior we can by default, make it easy to change, and show that it's a decision point worth thinking about.

[scottaohara]

i like that @aleventhal

[aleventhal]

I wonder if it's preferable to have an element, like <notification>, because it could come with a close button and Escape-to-close behavior, "for free".

[scottaohara]

i absolutely think that's the preferable end goal. if something like a <notification> or <message> ... or even <tooltip> existed, then those would be what developers would/should (hopefully) reach for.

[domenic]

I feel like this is veering a bit away from the spirit of popup="".

From what I can tell, we are building popup="" as an API for managing the top layer, basically bundling up a bunch of logic for moving things in and out of the top layer. I think that technology would be better as a JavaScript API, but many others don't, it seems.

Like other such APIs, it needs to be combined with CSS and ARIA to give good presentation and accessibility. It is a low-level API, in other words.

One day we should build <toast>, <tooltip>, etc. But for now we're just building the low-level top layer management API. And although this discussion seems to have started to be about naming and surface features (which I thought was #532), I opened the thread by pointing out a positive feature of popup=async: that it's the most bare-bones, "pure" part of the HTML API you are creating. It's the complete-manual-control one. And for a low-level API like popup="", that's a good feature to have. So really I was just opening this issue to say, "we should document this power!"

If we're going to make this a high-level API, then we should go back to an element, indeed! Such an element should have default accessibility semantics, default styling, and all that fun stuff. But I thought we decided to punt on that and just build the top layer primitive, when we decided to move from <popup> to popup="".

So to circle back around to naming (#532), that's why I think popup=manual is a good name for this behavior. We don't want to have people thinking this is an accessible piece of technology, or one coupled to certain semantics and behaviors, because it isn't.

[aleventhal]

@domenic you make a lot of good points. I'm not sure it's cut and dried here tho. We are already including default behavior for popup=hint, because it seems like a very solid signal. I think popup=async is also a signal, that there is something happening a screen reader user probably needs to know about. We don't know how noisy of a signal it will be.

[domenic]

We are already including default behavior for popup=hint

What do you mean by default "behavior"?

[aleventhal]

A hint popup will automatically show up on hover, and I believe it should automatically show up on focus.
If there is no other name for the item it applies to, we will use it for that, otherwise we will use it for the accessible description.
If it has a generic role (e.g. div), it will be reassigned a role of tooltip.

[domenic]

Oh, that seems really unfortunate. Now I don't know what the popup="" attribute is supposed to be. It seems more like an element than an attribute at this point.

I would urge the group to reconsider, perhaps by moving hint popups to their own element.

[aleventhal]

@domenic would you prefer that we wouldn't have gleaned a11y signals from the hint tooltip? Or you understand the decision, and it just makes you question that it's an attribute.

[domenic]

Either of those path sounds good. Either leave popup="" as a low-level top-layer API, with no semantics/a11y implications, or make popup=hint an element, with semantics/a11y/styling. But having an attribute that does unclear-semantics, yes-a11y for some states and no-a11y for others, no-styling, yes-behavior... that seems bad.

[aleventhal]

@mfreed7 what's your take?

[scottaohara]

@domenic @aleventhal I would propose we go down the middle here. As I do agree with not using the attribute to essentially implement a new element without actually implementing the new element (e.g., toast or tooltip). But there are some attributes in HTML now that do modify the semantics/a11y properties of an element. title as an obvious global element, but then even attributes like value, multiple and list - where each of these might have different semantics and a11y properties depending on the element they're used on.

[domenic]

There are two things that make this different:

• popup="" is a global attribute. It's expected that attributes contribute to a given element's semantics and a11y as part of the element definition. That's about the definition of the element though, and how elements are configured via attributes. It's not a property of the attribute itself.

• A global attribute can contribute to semantics/a11y. But it should do so in a consistent way. Having some values be element-lite, and some be no-semantics/a11y, is bad. I.e., the way popup="" has an exception carved out for when you use the value "hint", is bad. (Similarly, the way title="" has an exception carved out for how it behaves on <link> is bad.)

So I guess a third path would be to assign semantics and default ARIA roles and a11y mappings to all values of popup="". That way popup="" is always a semantic attribute, with clear a11y impacts. But in that case I really think you should just go the extra mile and make each state into its own element; the only delta is adding some default styling.

[scottaohara]

I think your points are clear and we should be able to work in the confines of those, and if we find instances where we are veering out, then we have identified features of the element that we should be creating.

[aleventhal]

I'm unclear about what the proposal is going forward.

[domenic]

I double-checked https://w3c.github.io/html-aam/. As defined there, there are no global attributes that impact role computation. (Including, e.g., contenteditable="" or hidden="".) Roles are so far impacted by:

• Element-specific attributes. All (?) of these arguably split up a single element into multiple "under-the-hood elements", in the sense that if we were designing HTML today we would use multiple elements. (E.g.: <a> vs. <a href="...">, <input>'s type="", <select> vs. <select multiple>.)
• The element's position within the tree. (E.g., <footer> under <body> is different than <footer> under <main>.)
• Whether the element has an accessible name. (<aside> and <section> only.)

So, introducing a global attribute with role impacts would be unprecedented, at least per specs. This is important because global attributes need their accessibility impacts spelled out for every element in the spec, e.g. we need to say what <select popup="hint"> means.

I don't think there's any good answer to that question. If we're saying popup="hint" has semantic meaning, then we just have a direct conflict between popup="hint" and the select element name. So that is my first strike against giving popup="hint" semantics and letting it have an input into role computation.

A proposal on the table is that popup="hint" serves as input to role computation if the element's role would otherwise be generic. I think this solution is bad because it makes the attribute unpredictable and fragile. For example:

• If you do <footer popup="hint"> under <main>, your popup-footer will have the contentinfo role. But then if you move your <footer popup="hint"> under <main>, it will have the tooltip role. (This example is not terribly realistic, but exemplifies the unpredictability.)
• If you do <section popup="hint"> (with no accessible name), you will have the tooltip role. But if you then do the right thing and go back and add an accessible name, you will now have the region role.
• If you do <div popup="hint"> it will have the tooltip role. But then you realize that your <div> is just a "useless" wrapper around a <figure>, so you refactor your code to use <figure popup="hint"> directly. Now you have a figure role! This fallback behavior has essentially given accessibility behavior to <div>s, which makes removing them no longer the accessibility no-op that it was before.

Right now we have a pretty clear message for how to indicate accessibility role: use an appropriate element if you can, otherwise use role="". Now we have no clear message. The best we can do is: try using an appropriate element, unless you want the tooltip role, in which case you should be sure not to use an appropriate element, but instead use a <div> or <span> wrapper plus the popup="" attribute.

That is why I think that, when introducing new HTML elements and attributes, we should use elements for things that impact role computation. We should not use global attributes to impact role computation.

Given this, I suggest the following concrete proposal:

• Create elements for the values of popup which want to have their own roles. E.g. <tooltip>, <notification>.
• Create an attribute for the values of popup where we cannot determine the role because they are too multipurpose. E.g. popup="manual", popup="auto".
• Explain and spec both of these with the same shared infrastructure.

Then there is never a confusion. If you are using popup="", you should follow the usual HTML advice: use it on an element with defined semantics (e.g. <menu popup="auto">), or use it with a role="" override (e.g. <div popup="auto" role="listbox">). If you are using <notification> or <tooltip>, then like other semantic HTML elements, you will get accessibility for free, and should avoid using role="". And it's impossible to create confusing situations like <section popup="hint"> (is it a region? is it a tooltip?). Or to create accidentally-broken situations like refactoring from <div popup="hint"><figure>...</figure></div> to <figure popup="hint">...</figure>. You'd just use <tooltip><section>...</section></tooltip> and <tooltip><figure>...</figure></tooltip>.

[jcsteh]

I double-checked https://w3c.github.io/html-aam/. As defined there, there are no global attributes that impact role computation. (Including, e.g., contenteditable="" or hidden="".)

It's true that hidden and contenteditable don't impact roles, but they do have a pretty significant semantic impact, albeit not the role. Hidden removes those elements from the a11y tree altogether. Contenteditable significantly changes the semantics in that now this thing is an editor.

* Create elements for the values of popup which want to have their own roles. E.g. `<tooltip>`, `<notification>`.

That makes sense to me. To clarify, are you proposing that popup="hint" would no longer exist? That is, there wouldn't be an equivalent way of doing <notification> or <tooltip> with an attribute (unless you also used your own JS)?

[aleventhal]

While <notification> and <tooltip> are helpful, they do not cover the generic popup case. In a generic popup, it's important for user to know that the contents within a generic popup belong together.

In the case that the popup is a semantically meaningful element, this is not a problem. The base role will already help the user experience the popup as a separate object. However, it is a problem if the popup is a generic element. What will differentiate this object from any other generic objects for the user?

At the moment, the only technique that I know of is to change the role, e.g. to group or region. However, I'd be fine with committing to working with the a11y community and AT vendors on a new technique, such as a new property in the AX tree. It would describe that the contents of a subtree are grouped together in a meaningful way. I'm actually excited by it because it lines up with another problem I had on the back burner, which is that users sometimes accidentally "fall out of" the container they are working in, getting lost.

So perhaps this is another example of a discussion that actually leads to other improvements. It will take time to develop a new technique, because of the slow/paid AT upgrade cycles. So, I propose we keep the role change on a generic popup (e.g. <div popup>) as an interim technique.

[domenic]

That makes sense to me. To clarify, are you proposing that popup="hint" would no longer exist? That is, there wouldn't be an equivalent way of doing <notification> or <tooltip> with an attribute (unless you also used your own JS)?

Note that <notification> would be doable, minus the computed role impact (and any default styling), with popup="manual". (Or, in my proposed naming scheme, popup="auto".) But yeah, my proposal is that <tooltip> would not be doable with just an attribute.

However, I think it'd be possible to have an attribute value that doesn't imply the tooltip role, and does get the popup="hint" behavior. So, here's an alternate proposal:

• Create a popup="" attribute. It is meant to be multipurpose behavior-only, so for now if you want to use it to create a tooltip or notification you need to combine it with role="". Its names reflect that. The behaviors are:
  • popup="manual" (useful for implementing anything where you need manual control over opening/closing)
  • popup="auto" (useful for implementing one-popup-a-time)
  • popup="???" (useful for implementing one-of-these-at-a-time)
• Create elements for the values of popup which want to have their own roles. E.g. <tooltip> (tooltip role, popup="hint" behavior), <notification> (alert or alertdialog role, popup="manual" behavior).

For the "???", maybe "hint" is fine. It'd be ideal to have a name that was very behavior-focused, and didn't have any indications of what type of control it should be used for. But I can't think of any good ones off the top of my head. Maybe "weak"?

So, I propose we keep the role change on a generic popup (e.g. <div popup>) as an interim technique.

I think the role change is a footgun, as I pointed out above. I'm not very comfortable introducing a new attribute into the HTML Standard if the intent of the HTML-AAM authors is to immediately use it to cause role computation to become fragile in that way, for an unknown amount of time until new technology appears. But maybe as an interim technique, not encoded in any specs but just something Chromium is experimenting with, it's a reasonable tradeoff.

[mfreed7]

Proposed plan for the popup attribute

TL;DR

The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility).

Details

Phase 1:

• The popup attribute in HTML has only behavior and no semantics attached. The names for the values should indicate behavior as much as possible.
• Keep popup=auto as proposed.
• Rename popup=async to popup=manual. This aligns better with the behavior ("manual") and contrasts well with popup=auto. Behavior stays the same as the current proposal for popup=async.
• Brainstorm a better name for popup=hint, which better-describes the behavior, and is less tied to a particular use case. A few suggestions are popup=weak, light, transitory, transient, ancillary. If we can't come up with a better alternative, popup=hint is ok. Behavior stays the same as the current proposal for popup=hint.
• Draft an HTML spec PR for the popup API which makes it clear that semantics come from the element, not the popup attribute. The popup attribute only confers behavior on the element, which maintains its existing semantics.
• Of course, bring the proposal to the ARIA working group for consideration and feedback as well.

Phase 2:

• Put together proposals for new elements, such as <tooltip> and <notification>, which use the algorithms defined above to add popup behavior to these elements. These elements will have explicit roles; for example tooltip will have role=tooltip and notification will have role=alert{dialog}, plus appropriate styles.

[mfreed7]

Agenda+ to hopefully resolve on the comment above.

I've slightly re-purposed #532 to bikeshed a new name for popup=hint.

[mfreed7]

I'm not sure minutes are going to get posted, but just in case they don't, here is a copy:

https://www.w3.org/2022/06/23-openui-minutes.html#t02

RESOLUTION: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility, including the role and aria-* attributes). Also rename popup=async to popup=manual.

Based on that resolution, I'm going to close this issue. Hopefully the real minutes get posted soon.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Note that popup=async + JavaScript allows custom behavior, and agreed to the following:

• RESOLVED: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility, including the role and aria-* attributes). Also rename popup=async to popup=manual.
• RESOLVED: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility, including the role and aria-* attributes). Also rename popup=async to popup=manual.

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] Note that popup=async + JavaScript allows custom behavior
<gregwhitworth> github: https://github.com//issues/495
<andrico1234> masonf: take it as an action to spin up issue about default styles
<andrico1234> masonf: we've talked about this issue. does popup attributes affect semantics. popup attribute only describes behaviour. all of it is behaviour, none of it is semantics. side thing, popup async to popup=manual
<andrico1234> masonf: aligns more with popup=auto, it feels parallel and easier to understand
<andrico1234> masonf: a side issue with renaming popup=hint, but a separate issue. last thing is not part of resolution. phase 1 is what we've talked about with 3 values. phase 2 is to define actual elements for some of these usecases with these semantics, like tooltips and notification
<andrico1234> masonf: use these values, but semantic elements with base styles
<masonf> Proposed resolution: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility). Also rename popup=async to popup=manual.
<gregwhitworth> q?
<dandclark> q+ to agree
<gregwhitworth> ack dandclark
<Zakim> dandclark, you wanted to agree
<gregwhitworth> +1 to the proposal, I don't need to rehash my opinion
<andrico1234> dandclark: i agree with these points. we had long conversations about defining semantics for popups as they're used for so many things. feels right to not add semantic baggage. also manual seems reasonable
<una> q?
<JonathanNeal> q+
<gregwhitworth> ack JonathanNeal
<una> q+
<andrico1234> JonathanNeal: i just want to clarify, does that mean things like role, and aria attributes?
<andrico1234> masonf: yes that's correct. you apply attribute to element, that element comes with its own role and how its calculate. it doesn't change
<gregwhitworth> ack una
<gregwhitworth> q+ vicgutt
<gregwhitworth> q+
<masonf> una, you have a substantial echo on your audio
<una> +1 the resolution, popup is at risk for a11y concerns, this resolves the concerns and still provides the needed functionality
<una> we can provide demos for common usecases
<una> that are accessible
<gregwhitworth> ack vicgutt
<andrico1234> vicgutt: wrt to a11y, the definition of the element we add attribute to. there would be a dedicated element for these popups? is that correct? and those elements would have the semantics defined
<una> but i'd also want the UA to accessibly focus/apply semantics on the element when popup is open
<andrico1234> masonf: yes, but that would be phase 2
<una> Would that mean that folks would still need to use JS for accessible elements?
<andrico1234> vicgutt: it would be beneficial to have that
<andrico1234> masonf: it's phase 2, but once we have the mechanics, then defining an element becomes a lot easier
<JonathanNeal> Oo, thank you for that great question, vicgutt. Now I feel I can +1 this.
<andrico1234> gregwhitworth: semantics for roles, as it relates to aria-haspopup, will that be owned by popup, that would be in the controller code. if i have popup attribute. that anchor is no longer adding aria-haspopup by default. the new element will add that
<una> +1 to make sure popup still provides a11y semantics for popup focus
<una> (regardless of role)
<andrico1234> masonf: we're not changing roles, attributes are a grey area.
<andrico1234> masonf: the way ATs look at the tree and decides what to do is up to the a11y side of things, how it's interpreted. your question might fall on that side of the line. i'm unclear whether it would be ok for us to haspopup, but good question
<JonathanNeal> Unless we have good element internals for ARIA, messing with just ARIA could still be messy. If I remove the popup attribute, would it also strip the ARIA attributes? Unless I overwrote them?
<una> I have the same questions/concerns as Greg
<chrishtr> q+
<andrico1234> gregwhitworth: selectmenu does this out of the box. does the popup attribute come bundled with it? they are accessibility ones and make attribute accessible by default. the a11y comes the minute we implement tooltip elements, we'll do that wiring. i like that personally
<JonathanNeal> If only the ARIA attributes existed in CSS, this would be a lot easier.
<andrico1234> gregwhitworth: the attribute isn't bringing semantic baggage
<andrico1234> masonf: i agree, selectmenu has controller code builtin and wiring is done correctly. maybe we shouldn't be doing anything at all attribute wise
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack chrishtr
<JonathanNeal> q+
<andrico1234> chrishtr: i thought the plan was that there would be not any implied attribute. popup attribute would be behavioural, and wouldn't say anyting about semantics, new elements would instead. and bring their own things like their own implied haspopup
<andrico1234> chrishtr: in the meantime ATs can do their best, but devs should add their own aria attributes so ATs now what they're doing
<andrico1234> in the meantime until phase 2
<andrico1234> chrishtr: what you said about unclear to devs about what's going on, i.e. some attributes imply other things. good the atribute is explicit about behaviour. its a layering of api surfaces, 1. it's speaking to make it easy to achieve larger goals without doing it all at once
<andrico1234> chrishtr: 2. for compat, there will be additional types of popups that we've missed, other edge cases. other popup behaviour, they can use it how they want, then we can codify it in Open UI
<masonf> RESOLVED: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility, including the role and aria-* attributes). Also rename popup=async to popup=manual.
<gregwhitworth> ack JonathanNeal
<masonf> SORRY, didn't mean to add RESOLVED there.
<masonf> Proposed resolution: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility, including the role and aria-* attributes). Also rename popup=async to popup=manual.
<andrico1234> JonathanNeal: i want to +1 this, and +1 not messing with attributes. could be hard to remember. if i put popup on something, and it implicitly adds an aria attribute, what happens when I remove it
<andrico1234> JonathanNeal: would been alot easier to discuss if we brought AT apis to CSS
<JonathanNeal> +1
<andrico1234> gregwhitworth: i like the move from async, super confusing for me
<andrico1234> masonf: sorry fr accidentally resolving, but added an extra bit on the end
<masonf> RESOLVED: The popup attribute in HTML will describe only behavior (what it does, such as top layer, dismiss behavior and so on) and not semantics (what it should mean to other tools such as accessibility, including the role and aria-* attributes). Also rename popup=async to popup=manual.
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been gregwhitworth, JonathanNeal, dandclark, andrico, bkardell_, una, chrishtr, masonf, tantek
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/06/23-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye
<gregwhitworth> RRSAgent, please leave
<RRSAgent> I see no action items