Bikeshed a name for "light dismiss for dialog"

[mfreed7]

See whatwg/html#9373 for more context about this issue. Also see the notes from the 2023 TPAC meeting.

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 lightdismiss> I'm a light dismiss dialog </dialog>

Adding lightdismiss to the <dialog> 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.

At TPAC, there was fairly good support for adding this behavior, and for adding it via a new attribute on <dialog>. But there was concern about the name of the attribute. There was a strong desire to have a name that links closely to close(). There were also comments that "light dismiss" is not well defined, and maybe Popover documentation should be updated to link to a new name that is shared with the proposed <dialog> feature.

So this issue is to bikeshed the proper name for "light dismiss", particularly as it relates to the attribute discussed above. Some preliminary ideas I heard in the meeting:

• lightdismiss
• closebehavior=something
• lightclose
• softdismiss
• softclose
• maximaldismiss / minimaldismiss
• {your idea here}

[hidde]

Fwiw, in my talks (eg search “light dismiss” in this slidedeck) and articles (eg this one) about popover I've been explaining light dismiss (dismissed by some heuristic) as the opposite of explicit dismiss (closed by user (eg a button click) or author (some script)). In the meeting we talked about “heavy” as the opposite, so wanted to throw “explicit” in there.

Maybe it's just because I've grown into it, but I wouldn't mind keeping “lightdismiss”. As for the others:

• I kind of like close and how that matches close in the method name, but if we're picking a different name, I prefer “soft” to “light”
• I think maximal/minimal dismiss is a bit far fetched… and the dismissing itself isn't more or less, isn't the difference more about who/what does the closing?
• I feel closebehavior is a bit long. I also wonder if that wrongly suggests one closing behaviour will apply (I think multiple could exist, eg a light dismissable popover could additionally be closable with a button and/or via script?)

As an additional suggestion… maybe “auto” (instead of light) vs “manual” (instead of explicit) could work?

[lukewarlow]

I vote for lightdismiss it's the term people use to describe this behaviour (in my experience at least). It's what's already used to describe the behaviour for popover. It's also a term used in other platforms not just the web.

Example of usage: web.dev: adding light dismiss , mdn: popover light dismiss,
and even an issue to Microsoft UI XML for a similar request with the same terminology.

[mfreed7]

Thanks for the great comments - please keep them coming!

It's what's already used to describe the behaviour for popover.

I just wanted to quickly address this one: if we do choose a different name for this concept, the idea would be to re-write all of the documentation for popover to use the new name. It would indeed be confusing to call it "light dismiss" in popover documentation, and something else elsewhere.

[brechtDR]

I vote for lightdismiss it's the term people use to describe this behaviour (in my experience at least). It's what's already used to describe the behaviour for popover. It's also a term used in other platforms not just the web.

I agree with this :)

[keithamus]

@domenic's request, I believe, was to not use dismiss and instead use close as it aligns with the CloseWatcher work - but hopefully Domenic can correct me if that was wrong.

I'd also vote 👎 for dismiss as (although I don't have lived experience of this) I believe words with consecutive double letters can pose challenging for EFL or dyslexia.

I'd also vote 👎 for behavior because, as a Brit, it's bad enough I have to use color everywhere so please don't force me to misspell behaviour too 😆

[domenic]

Yeah, I think it's pretty important that if we ever expose this term in the API, it matches the existing API name the web platform uses for closing things, which is "close". I'm not sure who decided to create the "dismiss" synonym, but let's not expose two names for the same thing in the API, even if the damage has already been done in some of the documentation and spec-internal terminology. (The latter two can always be fixed!)

To be clear on the landscape as it stands:

• close: used by <dialog> for close() and the close event. (Also used by window.close(), which sort of counts.)
• "close request" and CloseWatcher: introduced in Add close requests and close watchers whatwg/html#9462 (which is not yet merged). A "close request" is a user-initiated platform-specific request to initiate the close process, like the Esc key or Android back gesture. A CloseWatcher watches for close requests and fires cancel + close events; it also has requestClose() and close() methods.

The API invented here should sit alongside these existing and upcoming APIs, so it really should use the word "close". How you want to qualify it, I have no current feelings about.

[lukewarlow]

There's currently 19 instances of the term dismiss (in various forms) within the HTML spec (excluding an example block quote) while obviously some will be light-dismiss from popover not all of them will be. So the term clearly pre-dates popover (some date back to 2013) and also I really do feel strongly that this is the terminology that people understand hence why it was used for popover in the first place.

I'd also like to add this is a declarative behaviour being defined not an imperative instruction so the language being different isn't completely weird. We already have an open attribute for dialog which corresponds effectively to a show method?

Also imo (the ship has sailed on this) but close() as a method name for dialog should be hide() because you show() it not open() it. Window is close() because it's open() AND also (iirc) gets destroyed by the action. Again this is something I consider popover to have gotten correct.

Out of the options listed above I guess lightclose cause it's as close to lightdismiss without the dismiss contention.

Having said all that if we can't use the dismiss terminology. could clickoutside="close" or clickoutsideclose be considered. I know it's bad that it uses click but what does this lightdismiss introduce other than the click outside?. Esc etc are already considered (heavy?/strong) close signals.

backdropaction="close" or backdropclose?

I guess with ones like backdrop* or clickoutside* it kinda makes sense to be two values backdropaction="none" and backdropaction="close" for heavy vs light and the default would be "none"?

[hidde]

I've thought of ‘light dismiss’ as ‘it goes away due to some heuristic’. To me telling an element to light dismiss (it goes away when deemed appropriate) is something quite different from telling it to dismiss or close (it goes away right now).

This ‘some heuristic’ is up to the browser / tool implementing it. It could be following a user's click outside, but in my mind it could also be other things, like tab outside or scroll outside (and in future environments maybe something even more different; eg 'user starts walking to a different direction in VR environment'). So, I'd say, yes it closes, but it closes specifically when certain circumstances are met.

Light close seems unusual, light dismiss much more common.

[lukewarlow]

Okay the VR point is a very good one and knocks out all my suggestions other than we should just go with lightdismiss. I agree lightclose feels very very weird.

[lukewarlow]

Looking through various older open ui issues regarding light dismiss there's also talk of lightdismiss on window resize and scroll etc which all feel like reasonable discussions and extra wipe out my suggestions

[css-meeting-bot]

The Open UI Community Group just discussed Bikeshed a name for "light dismiss for dialog".

The full IRC log of that discussion

<hdv> keithamus: we discussed this at TPAC
<hdv> keithamus: there is good interest, but there's contention around the name. Domenic at TPAC said it would be nice to align it to all of the other close stuff that is in HTML
<hdv> keithamus: Domenic said there is existing precedent for dismiss, but it is not a concept in his mind
<hdv> keithamus: right now there is some options… lightdismiss, softdismiss… I think Domenic's preference would be to have something with 'close'
<gregwhitworth> q?
<jarhar> q+
<hdv> q+
<gregwhitworth> ack jarhar
<gregwhitworth> q+
<brecht_dr> q+
<hdv> jarhar: lightclose or softclose sounds good to me… I wrote the behaviour for popover in HTML spec as lightdismiss, so technically there is precedent
<hdv> jarhar: but I understand
<gregwhitworth> ack hdv
<gregwhitworth> hdv: I still like light dismiss a lot
<gregwhitworth> hdv: I've been doing talks about this and it makes sense to them. The other words they don't seem to make as much sense to me
<gregwhitworth> hdv: they of course close it but it still is confusing
<Luke> q?
<Luke> q+
<keithamus> q+
<hdv> gregwhitworth: I did a quick scan of lightdismiss … it doesn't seem to be a massively used
<hdv> gregwhitworth: i also prefer it, but like Hidde said it's probably because we've been using it so much
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack brecht_dr
<scotto> lightclosedismiss
<hdv> brecht_dr: the word dismiss is 'strong, also used in places like Bootstrap and Tailwind and other frameworks… the dismiss thing seems to be more of a common thing than close
<gregwhitworth> ack Luke
<hdv> Luke: while lightdismiss is mostly used in Open UI and predecessors, it is used in other places, like Microsoft have other places
<hdv> Luke: and dismiss on its own is used in even more places
<hdv> Luke: I'm not convinced by the argument that it is 'close' in other places
<hdv> Luke: close as a method in general is incorrect on a dialog, should be hide
<hdv> Luke: I would like lightdismiss, but as people have said, it is probably easier not to fight it with WHATWG
<hdv> Luke: problem with click is that maybe in some future people don't use mice anymore, that could age quickly
<hdv> q+
<hdv> q+ to say not always on (visible) backdrop
<gregwhitworth> ack keithamus
<hdv> keithamus: we could flip it on its head… the attribute could be assigning the behaviour and the value could be light or soft
<hdv> keithamus: if we think dismiss=light that could maybe spark some delight
<zcorpan> q+
<keithamus> s/delight/thought
<gregwhitworth> hdv: wanted to respond to backdrop, it can still happen when you don't have a visible backdrop
<gregwhitworth> ack zcorpan
<gregwhitworth> ack hdv
<Zakim> hdv, you wanted to say not always on (visible) backdrop
<hdv> zcorpan: so the behaviour is that the user can close it by clicking outside
<hdv> q+
<jarhar> yeah you can already close the dialog with escape
<hdv> keithamus: Escape always works
<hdv> s/always/already
<Luke> q+
<gregwhitworth> hdv: there is a heuristic that makes it disappear
<gregwhitworth> hdv: did they click, did they tap, did they scroll; etc
<gregwhitworth> ack hdv
<gregwhitworth> ack Luke
<hdv> s/there is a/I've been thinking about light dismiss as hiding/closing based on a
<hdv> Luke: window resizing could also be a light dismiss
<hdv> Luke: the one aspect that makes it slightly different… light dismiss for a modal dialog probably has less ways for it to be closed
<keithamus> q+
<hdv> Luke: so maybe in modal dialogs light dismiss wouldn't exist at all
<hdv> Luke: we did also talk about lightdismiss on window blur
<gregwhitworth> ack keithamus
<gregwhitworth> q+
<hdv> keithamus: one of the concrete gesture that has been discussed about light dismiss is the Android back button
<hdv> keithamus: I'm not an Android user, but seems a bit like a Escape works on desktop
<hdv> Luke: that's probably more like Escape / 'heavy' dismiss
<hdv> [ maybe 'auto' dismiss, to capture 'heuristic' ]
<hdv> gregwhitworth: I'm hearing different things… is there some action we can take? doesn't sound like we can resolve on a name?
<zcorpan> autoclose?
<hdv> jarhar: I guesss heavy dismiss… as we just invented as a term… is the current behaviour
<keithamus> I like `autoclose=light/auto`
<hdv> Luke: it would be in spec when close signal bit would be merged
<hdv> zcorpan: what would auto value do?
<hdv> gregwhitworth: 'heavy' dismiss
<hdv> gregwhitworth: I like it… but my stance stays, let's take it to GitHub
<zcorpan> autoclose as a boolean attribute (present = allow light dismiss)
<keithamus> GitHub Discussions now have polls which are a bit easier to use than reaction emoji, fwiw
<hdv> gregwhitworth: let's do that and then we all try and share it on our socials
<hdv> Luke: I think it should be a new issue… so that developers would not read the topic and know what the majority here thinks
<hdv> gregwhitworth: I'll spin up a new issue then

[muan]

Not sure where that issue is but just want to highlight this part from TPAC about multiple values, ESL, and interpretation of heavy/light specifically, and seconding preserving the potential for more than two multiple values.