Naming for an attribute to enable "light dismiss for dialog"

[mfreed7]

There's a desire to add an attribute on <dialog> that adds "light dismiss" behavior to the dialog. The proposal is to add that via an attribute:

<dialog attribute_name_here> I'm a light dismiss dialog </dialog>

Adding attribute_name_here to the makes the dialog get closed (as if dialog.close() were called) when the user "light dismisses" it, e.g. by clicking outside the bounds of the dialog.

Note: "Esc" key handling is separate to this light dismiss behaviour.

[matthewp]

Shouldn't this be the default? Why is it not?

[keithamus]

It cannot be the default for web compatibility reasons. See whatwg/html#9373 (comment)

[matthewp]

Yeah, totally understand that it can't be the default now, I'm more curious why it didn't work this way from the beginning. If you know the answer or have any background links I'd love to understand more.

[domenic]

Most dialogs on your computer cannot be closed by clicking outside of them. Checking the ones I have quick access to:

• Firefox about dialog
• Microsoft Outlook add account dialog
• Notepad Save As dialog
• Visual Studio Code "There are currently no updates available" dialog

[matthewp]

I'm not familiar with the "light dismiss" phrase. Is there any background or links on what that means?

[keithamus]

Please see https://developer.mozilla.org/en-US/docs/Web/API/Popover_API/Using#auto_state_and_light_dismiss

[lukewarlow]

The below section explains how to achieve what this attribute would do in your own code. To give a concrete example of what "light dismiss" means in this context.

https://web.dev/articles/building/a-dialog-component#adding_light_dismiss

[matthewp]

Interesting, so it sounds like this an old term that I guess I've just somehow never encountered?

[matthewp]

I only bring this up as 1 data point, I would be confused seeing this attribute name. But if it's common knowledge then dismiss this data point.

[jamiebuilds]

In design systems I've always seen clicks like this referred to as "outside clicks" for all sorts of popover elements. I feel like that makes more sense than "light". Also if there are ever any future options here, I'd rather they be exposed as a list:

<dialog closetrigger="outside delay blur etc">

[lukewarlow]

Wrt MDN mdn/content#30309 I raised an issue to sort out the fact it refers to escape as light dismiss

[karlhorky]

I like closetrigger and exposing a list 👍

However, as @domenic mentioned in the comment below, ::backdrop is the official name of the pseudo-element, so would be probably a better replacement for subjective words like "outside":

<dialog closetrigger="backdrop delay blur etc">

[zandermax]

I'm a big fan of this, since it uses existing terminology with no potential spelling pitfalls, there's no ambiguity to what it refers to - i.e. these things will trigger .close() - and using a list to allow for several ways to close it in a single property.

If this is a list that can contain multiple values, what about using closetriggers ? Is there a paradigm we are attempting to follow by using the singular?

What about using closeon ? I am aware this is close to onclose, but because it is flipped would it be more intuitive? I am actually liking it a bit better because closetrigger suggests that the list must be comprehensive, i.e. these are all of the ways this dialog can be closed (does it need to include submit for example?), whereas closeon does not suggest the same.

<dialog closeon="backdrop delay blur etc">

[domenic]

Some further discussion of this list idea in whatwg/html#9373 (comment)

[lukewarlow]

For me closeon is far too close to onclose and will lead to confusion especially when teaching to new developers.

I like the list idea closes="" or closetrigger(s) seem nice?

[brunoprietog]

close-on-click-outside?

[RoyalIcing]

In Cocoa this property is called “transient”. See https://developer.apple.com/documentation/appkit/nspopover/behavior/transient

<dialog transient> Tap the background to close me. </dialog>

I like @jamiebuilds idea of it being extensible so this attribute could also support a string value.

<dialog transient="outside blur etc"> Focus anything else to close me. </dialog>

(Btw I’m not a fan of the term “light close” because it sounds like it could be referring to the light DOM.)

[CyberAP]

dismiss="light" to better follow the language of the popover spec?

[simevidas]

Or just boolean dismiss, since it’s a simple opt in.

[WebReflection]

<dialog disposable>

[mtgentry]

Soft-dismissal?

[aarjithn]

onblur-close

Or

close-onblur

[dfkaye]

<dialog dismissible>

[GrimLink]

This makes the most sense for the attribute name 👍

[simevidas]

Maybe the -ible suffix isn’t needed. Keeping it short sounds good. These are just keywords that developers will get used to anyway.

[keithamus]

My two concerns around dismissible:

• Words with doubled letters can be tricky to spell (especially given the word contains 3 s letters in total). Similarly ible/able can be something folks trip up on. Given the presence of an incorrectly spelled attribute will silently fail, I can imagine a world with lots of dismissable, dissmissable, dissmisable, dissmisble... attributes that do nothing.
• Dialogs are always dismissible with the Esc key. It may be surprising to someone that removing dismissible from <dialog dismissible> does not make it non-dismissible.

[nuxodin]

Could you make it the default behavior, but clicking on the backdrop prevents it from closing?
Then this could work:

.dialog::backdrop {
    pointer-events: none;
}

[lukewarlow]

How would it be the default if clicking on the backdrop didn't cause this?

[nuxodin]

I mean when clicking outside the dialogue element including backdrop, closes the dialog

[lukewarlow]

Android flips the default (click outside closes by default), but they have a setCanceledOnTouchOutside() https://developer.android.com/reference/android/app/Dialog#setCanceledOnTouchOutside(boolean)

I think it's interesting that they use the cancel rather than close terminology here.

@mfreed7 am I correct in thinking this behaviour would trigger a cancel even like escape and back gesture do currently?

If so is it worth considering using the cancel term instead of close? (Not overly fussed just thought it was interesting)

[WebReflection]

I like cancelable too 👍

[keithamus]

@WebReflection if you like this would you kindly upvote this comment, as it'll make it easier to collect votes.

[WebReflection]

forgot to ... done

[domenic]

For CloseWatcher, the two methods are close() (goes straight to closing) and requestClose() (also fires cancel, giving you a chance to abort the close request).

[mfreed7]

@mfreed7 am I correct in thinking this behaviour would trigger a cancel even like escape and back gesture do currently?

If so is it worth considering using the cancel term instead of close? (Not overly fussed just thought it was interesting)

I was thinking this new behavior would trigger a close, not a cancel, but I don't have strong opinions. @domenic you have a better understanding of close vs. cancel, and stronger opinions about the naming. What do you think?

[domenic]

I think generally cancels are useful: clicking outside a dialog should give authors the opportunity to pop up an "are you sure want to close this dialog? you have unsaved changes" sub-dialog, or other UI.

However, right now dialog doesn't have any method of triggering a cancel besides close requests. E.g. there's no requestClose() like CloseWatcher has. Saying that you can only get a cancel via close requests or via click-outside is a bit strange, at that point. It might be good to solve that problem first.

[lukewarlow]

This was something we recently discussed in openUI wrt invokers. Am I to understand that you'd be open to a cancel (name tbd) function added to dialogs that fires cancel and close events? To allow a dialog cancel button to correctly reflect that in the events.

[domenic]

Yes, and I think it should be called requestClose() to match CloseWatcher.

[mfreed7]

So with 47 votes at this point, the winner with 27% is... <dialog other>! 😵‍💫 Clearly there's no obvious good name here. (I strongly suspect that if lightdismiss were included in the list, it likely would have won, because #834 (comment).)

Looks like perhaps I need to collect some of the many suggestions made in comments here and run another survey? Some of the interesting ones include:

• <dialog transient>
• <dialog disposable>
• <dialog cancelable> (UK/US debatable spelling here)

Note that I skipped ones that have "dismiss" in them due to #834 (comment), and those that try to specify the particular mechanisms to light dismiss (e.g. click vs. blur) due to #834 (comment).

@domenic you have strong opinions that "dismiss" should not be in the name. Do you have issues with unrelated words like transient? Personally I like that one the best, since it doesn't imply how the dialog can be dismissed or what happens when it is dismissed, but does imply the dialog is easier to get rid of, which is really what light dismiss means in some sense.

[WebReflection]

FWIW I’d be ok with transient and where there’s some prior case to reason about it’s easier for everyone else to reason about it too 👍

[domenic]

My request is that "close" is in the name, since it triggers the close event and behaves like the close() method. If you want to use another word in such a name, like transientclose, that seems reasonable.

It's true that I'd like to completely stamp out this usage of the term "dismiss", which is just confusing. We already have close as a perfectly good verb for dialogs. Not to mention cancel, and toggle, and beforetoggle. We don't need yet another term. I think it'd be helpful if we were careful in how we talked about it, e.g. instead of your above sentence, we'd say

Personally I like that one the best, since it doesn't imply how the dialog can be closed or what happens when it is closed, but does imply the dialog is easier to get rid of, which is really what light close means in some sense.

Maybe another good step would be to remove the usage of the term "dismiss" in the HTML spec text.

[WebReflection]

Is closable on the table?

[domenic]

I wonder about explicitly using the word "backdrop", to match the ::backdrop API that this represents? Remember, the behavior we're trying to sum up is "closes when clicking on the backdrop".

• backdropclose=""
• closeviabackdrop=""

?

[karlhorky]

or adding backdrop to the closetrigger list like @jamiebuilds suggestion in the comment above

<dialog closetrigger="backdrop delay blur etc">

[WickyNilliams]

I really like the idea of using "backdrop" as part of the vocabulary of this API. Not sure about it being in the attribute name though

[domenic]

Note that close=light/explicit/implicit is not really possible because it collides with the existing close() method. (Similar problem with the old shadowroot="" attribute proposal that collided with the shadowRoot property and needed to get renamed to shadowrootmode="".)

[mfreed7]

FYI, this conversation seems to have moved to whatwg/html#9373.

I guess we'll pick it up there. It's too bad it's happening in two places.

[mfreed7]

Based on that conversation, I've created two more polls, to replace this one:

#960
#961