[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.