Bikeshed a name for "light dismiss for dialog"

[mfreed7]

See https://github.com/whatwg/html/issues/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 :-1: 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 :-1: 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 :laughing:

[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 https://github.com/whatwg/html/pull/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.

[josepharhar]

@muan So you're saying that it would be better to do close=light rather than lightclose?

[muan]

@hidde and I had a chat about this and I managed to convince him. I know everyone has already put a lot of thoughts into this, just bikeshedding here. I'd like to propose something like this:

closebehavior="explicit" <!-- dialog default, and what UA decides as explicit -->
closebehavior="implicit" <!-- popover default, and what UA decides as implicit -->
closebehavior="escape backdrop focusout attentionlost vrwhatever"
<!-- optional now, DOMTokenList for potential future use cases, 
     or some current use cases I can't think of,
     subjected to bikeshedding (AT/VR/What engines what to expose) -->

or (mind the 🇬🇧 ) close, closing (think loading), closetrigger, close-means (ref accept-chartset).

I think using a space-separated DOMTokenList is more future proof. It's not about knowing what people want in the future but more about not limiting the options. I think the last thing we want is having authors saying "because this doesn't work consistently across UA" or "because I don’t like how implicit includes X", "here’s a snippet to roll your own <dialog>/popover".

My qualms with the above suggestions are:

• light/soft/heavy: I think they are up for interpretation, for their implicitness. I think of light like a light bulb or as a feather, and soft like a pillow, and not anything specific to do with behaviors/triggers. Even though implicit/explicit are indeed harder to spell, once you look it up it is clear.
• autoclose/autodismiss: It reminds me of autofocus but the behavior is still activated by some sort of unknown user actions decided by the UA, very much unlike autofocus.
• dismiss: Basically I agree with Domenic's comment.

💁🏻‍♀️

[keithamus]

If we're going that route, what about closeaction=?

[muan]

Sorry. Yes. I did read your comment above. I just added close and closetrigger to the comment as well.

closeaction reminds me of form[action] and [popovertargetaction] which are for specifying what an element does instead of what will inform an element to [...].

[mayank99]

i feel that none of these options so far are intuitive unless you're already familiar with the term "light dismiss" or "soft dismiss".

something like closeonbackdropclick or closeonoutsideclick feels more intuitive and reads like natural language.

---

that said, i do like \@muan's suggestion about listing multiple events in closebehavior. it might be nice to also expose all of these values as real javascript events too (i for one would love a backdropclick event).

closebehavior="escapekey backdropclick focusout attentionlost"

[hidde]

@mayank99 thanks. To be honest, a name using 'click' would not seem suitable to me, for reasons mentioned in the discussions above: light dismiss can oftentimes be not on click, but on scroll, window blur, “looking away in VR” (a made up use case, but maybe a real one?). (Users will likely use different input methods/assistive technologies).

I would have similar concerns adding 'backdrop' or 'outside', because the component could have no backdrop (well, no visible backdrop, top layer els always have a backdrop).

[mayank99]

thanks. To be honest, a name using 'click' would not seem suitable to me, for reasons mentioned in the discussions above: light dismiss can oftentimes be not on click, but on scroll, window blur, “looking away in VR” (a made up use case, but maybe a real one?).

i think this is even more reason to separate out these events. it may be desirable to close the dialog on backdrop click, but leave it open on scroll or window blur. i like \@muan's closebehavior idea even more now. the implicit shorthand also makes more sense than "light dismiss".

I would have similar concerns adding 'backdrop' or 'outside', because the component could have no backdrop (well, no visible backdrop, top layer els always have a bakdrop).

that's the thing though: ::backdrop exists, it can be seen in dev tools, developers encounter this element directly, and can style it etc. whereas the concept of "light dismiss" is something developers would need to read up on (i hadn't heard this term until a few months ago, and i've been building dialogs for many years). if this concept is surfaced early on in documentation though, this unfamiliarity might not be big concern.

[hidde]

i think this is even more reason to separate out these events. it may be desirable to close the dialog on backdrop click, but leave it open on scroll or window blur. i like @muan's closebehavior idea even more now.

I'm all for separating the events so that people have the option, but I do worry it makes it very easy for developers to forget use cases (I know I would… so would probably useimplicit myself most of the time, so that the UA can decide what's most appropriate given the circumstancs they know more about).

whereas the concept of "light dismiss" is something developers would need to read up on (i hadn't heard this term until a few months ago, and i've been building dialogs for many years)

Fwiw, popover is the first (?) time the web platform gets a way for an element to have “light dismiss”, it shipped some months ago, so you're right, it is fairly new.

Bit of a tangient, but I think important for naming… for dialogs with visible backdrops, in many cases (not all) it would probably make more sense as a modal dialog, not a popover (because if visually obscuring rest of page, why not also make the rest of the page inert?).

[mayank99]

I'm all for separating the events so that people have the option, but I do worry it makes it very easy for developers to forget use cases (I know I would… so would probably useimplicit myself most of the time, so that the UA can decide what's most appropriate given the circumstancs they know more about).

This is a good point indeed. But the implicit behavior would need to make sense for most cases. And what makes sense may change based on what kind of popover it is. For a modal dialog, I can't think of why it should close on scroll; it could be very frustrating UX (depending on overscroll chaining behavior of the scrollbars inside the dialog). Instead of closing on scroll, I would want to prevent the document from scrolling altogether.

There may also be other events that would be useful to have shortcuts for but may not make sense as a default. On mobile devices for example, I would like the dialog to be closed when going "back" (similar to how it works in native mobile apps) instead of performing a page navigation. But this behavior might not be desirable by everyone, so it could be opt-in.

[keithamus]

It's worth pointing out to those who are getting involved now, that there is only one real concrete use case for this. Currently dialogs will close given a device gesture - which most typically is pressing Esc on a keyboard (but can also be triggered by other device specific gestures). Currently interacting with the backdrop does not close a dialog. This proposal seeks to add an opt-in for users interacting with the backdrop (typically via mouse click) to also close the dialog.

Any talk of looking away or interacting with another window or focusing out of the dialog are conjecture, and will need to be specified separately and all come with their own concerns such as privacy, usability, security. I'm not trying to shut down conversation around ensuring the opt-in is future-proof but I'd also think there's a high chance that no other styles of interaction will be added and this will be the only opt-in enhancement. We should consider the trade-off around heavy discussions around such conjecture and try to remain productive toward solving the concrete problem we have today.

To reiterate; in this issue we're asking what is an ergonomic way to mark an element to say "when the backdrop is interacted with, this element should close".

To that end, I'm satisfied with closetrigger=implicit. Does anyone disagree with closetrigger=implicit?

[mayank99]

If this is only about backdrop, why not spell it out explicitly? i.e. closetrigger="backdropclick".

The whole point of implicit was to introduce ambiguity in order to support additional triggers determined by the browser.

[keithamus]

@mayank99 this has been covered in this comment, and this one:

To be honest, a name using 'click' would not seem suitable to me, for reasons mentioned in the discussions above: light dismiss can oftentimes be not on click

I'm all for separating the events so that people have the option, but I do worry it makes it very easy for developers to forget use cases (I know I would… so would probably useimplicit myself most of the time, so that the UA can decide what's most appropriate given the circumstancs they know more about).

[mayank99]

@keithamus Those points were made before your added clarification that this issue is only about backdrop. In other words, light dismiss will in fact never not be a backdrop click (for the purposes of this issue).

As for "click", I understand it to be a generic term not necessarily tied to mouse, but it's the less important part of backdropclick. closetrigger="backdrop" would work just as well.

implicit makes sense when there are additional triggers. But if it initially ships only handling backdrop behavior, then it would be very risky to change the behavior 2 years later. Developers would use this attribute expecting it to only close on backdrop click, and then suddenly it might start closing on focusout/scroll/windowblur? That's a breaking change that reduces trust in the platform.

For this reason, closetrigger="backdrop" is the safer option.

[lukewarlow]

For this reason, closetrigger="backdrop" is the safer option.

I'm concerned developers might think this would disable Esc and Android back?

[mayank99]

@lukewarlow That's a good point about Esc, although I haven't seen the dialog close on Back button on Android (i tried it just now to confirm that it performs page navigation).

To avoid confusion, i can see two ways:

1. bring back backdrop or clickoutside in the attribute name. examples:

   closeonbackdrop=""

   backdropclose="auto"

   clickoutside="close"

2. use something like closetrigger="backdrop escapekey" for now.
   • In the future (potentially), this could be extended to closetrigger="backdrop escapekey back focusout ..." and once there is enough certainty about having covered the most common cases, closetrigger="implicit" could be added as a convenience api. Importantly, adding this in the future avoids breaking changes, whereas adding it now and introducing additional triggers in the future would be disruptive.

[lukewarlow]

I would avoid escape key because the new html closewatchers concept has a close signal which is deliberately abstract to include ESC and back button. I should have been more specific the Android back button will be supported soon but isn't currently.

[lukewarlow]

Removing agenda+ as it's not recent. Re add if that's a mistake and you do want to discuss this

[mfreed7]

I'd like to discuss this and get it moving. I feel like this issue has had quite some time to explore the area, and I'd like to finish bikeshedding a name.

A few comments, with my opinions:

1. We've already defined the algorithm for this, which is already used by Popover. We're now just trying to find a name for the attribute that would enable it for <dialog>. I'd really like to avoid redesigning the feature, particularly the part that would affect Popover.
2. I'd be fairly against providing direct access to different "ways" to dismiss a dialog (or popover) based on different user actions, such as ESC, click, scroll. The behavior we arrived on for popover took significant time and energy to ensure it worked well for most users. That was not trivial. It is unreasonable to assume all developers will spend as much time thinking about getting the particular set of actions just right. A better assumption is that developers will choose the value that sounds right to them and works for their particular way of interacting with the web, and that might not be the best for all users. That's not a knock on developers - it's just how time gets spent.
3. Given the two above, let's just pick a name for a boolean attribute or equivalent.

I'd like to create a poll so we can vote. The names I've heard (and removing some that didn't seem popular):

• lightdismiss
• closebehavior=light/explicit/implicit
• closetrigger=light/explicit/implicit
• close=light/explicit/implicit
• lightclose
• softdismiss
• softclose
• explicitdismiss
• explicitclose
• autodismiss
• autoclose

Any others that I missed? Else I'll put together a poll and we can vote.

[domenic]

I agree with your 1-3. However, I hope we can remove all names that don't include close before starting any poll, per prior feedback from myself and others on this thread and at TPAC.

[mfreed7]

I agree with your 1-3. However, I hope we can remove all names that don't include close before starting any poll, per prior feedback from myself and others on this thread and at TPAC.

My rough reading of the comments in this thread is that the names that include "close" are confusing to developers. Wouldn't it be interesting poll feedback if that's confirmed? Surely we don't want to choose a name that most people find confusing, do we? The entire point (I think?) of keeping things "consistent with the platform" is that they make it easier for developers. When that's not achieved, I'd hope we'd want to adjust.

[domenic]

I'm not comfortable introducing that sort of inconsistency, even if some of the people arguing above are promoting it.

[mfreed7]

I'm not comfortable introducing that sort of inconsistency, even if some of the people arguing above are promoting it.

Presumably though, the strive for consistency is in the name of ease of understanding by developers. Would you agree with that? Or if not, why is self-consistency a top goal for the platform?

[domenic]

Consistency has many goals. It provides a foundation for the platform going forward, to give us a good path that other features can build on. It makes things easier to document and explain. It makes things easier to build. You can learn more in https://www.w3.org/TR/design-principles/#consistency .

[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

<jarhar> masonf: i dont want to bikeshed, but i want to summarize where we are on the issue and have people go to the issue
<jarhar> masonf: this is a new feature, similar to what popover light dismiss does but for modal dialog elements
<jarhar> masonf: lets make a new attribute on the dialog element, which when present, gives the modal dialog light dismiss behavior. click outside of it makes it go away
<jarhar> masonf: whats the right name for that attribute? and values for attributes, some are boolean attributes
<jarhar> masonf: really wanted to put this on the agenda to make sure that i have the full list, and then i want to make a poll
<gregwhitworth> q+
<bkardell_> q+
<jarhar> masonf: there is a side conversation happening about whether its going to be allowed that doesnt include the word close
<Luke> q+
<jarhar> masonf: im not quite convinced on that one. the list does contain items that dont include the word close
<keithamus> q+
<jarhar> masonf: are there any others? if theres something that includes the word closed, please produce it now or in the issue
<jarhar> gregwhitworth: i agree with your comment prior to domenics comment
<jarhar> gregwhitworth: this group can always come back, the whatwg design principles for consistency makes sense
<jarhar> gregwhitworth: lets say 60
<jarhar> gregwhitworth: percent of people want one
<masonf> q+
<jarhar> gregwhitworth: from a poll perspective, that makes the resolution happen
<jarhar> gregwhitworth: i dont have any great names
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: i opened this yesterday and started typing a response, and after a long time i decided not to post it
<jarhar> bkardell_: basically its what greg said, with caveat that it does seem that theres a reality that would be very easy to just ignore the - because it will be a small sample size and that its not overwhelming
<jarhar> bkardell_: for what its worth, i dont think its likely to convince anyone because it wont be overwhelming
<gregwhitworth> ack Luke
<jarhar> Luke: i was going to say i think were better off removing the ones that dont meet his requirement plus i think we should include light dismiss
<jarhar> Luke: we shouldnt include them and then if everyone picks the other one and they say no thats bad
<jarhar> Luke: but including all of them might help people add more ideas
<jarhar> Luke: for form sizing for text area, people came along with other suggestions and maybe one of those is better
<jarhar> Luke: maybe just put it out and include the options and see what people go with
<jarhar> Luke: we might get another suggestion from someone whose not involved in openui
<gregwhitworth> ack keithamus
<gregwhitworth> q++
<gregwhitworth> qq+
<jarhar> keithamus: is that problematic to yield to domenics request? if we all want to ship this feature, all these names seem fine to me
<gregwhitworth> ack +
<jarhar> keithamus: softclose is fine. should we pick one and go with it? a lot of these things are you copy and paste from mdn and you move on with your life
<jarhar> keithamus: i dont know if devs care that much
<gregwhitworth> ack masonf
<jarhar> masonf: for the last point, yeah you do go to mdn and copypaste, but the hope is that after doing it you remember it
<jarhar> masonf: if its always confusing, thats painful for everyone
<gregwhitworth> ack gregwhitworth
<Zakim> gregwhitworth, you wanted to react to keithamus
<jarhar> masonf: my thoughts are along with what greg and luke said: include all the results but know that the one that gets the most results isnt necessarily the one were going to choose
<jarhar> masonf: if the best one doesnt have close, thats a useful data point
<jarhar> masonf: im in favor of deciding what to do after the poll
<jarhar> masonf: there was an ax accordion poll that got 200 votes. if anyone knows how that happened, please do this for all future polls
<jarhar> masonf: davids only had that without miles of content, and a bunch of us tweeted about it
<jarhar> ^ actually was gregwhitworth
<jarhar> masonf: the quantity of data is important
<jarhar> gregwhitworth: we dont need a resolution on this one
<keithamus> If you open a GitHub Discussion you can add a poll, and it might be easier for folks to consume vs an issue

[mfreed7]

Ok, I added a Github Poll for the naming of this attribute:

https://github.com/openui/open-ui/discussions/950

I included only attributes that include "close", per the requirement from WHATWG. Please take a look and add your vote! Also please feel free to signal boost the above poll via social media.

[mfreed7]

Based on lots of discussion, I've closed the poll above, and started two more:

• https://github.com/openui/open-ui/discussions/960
• https://github.com/openui/open-ui/discussions/961

Please vote early and often.

[keithamus]

This was useful data and the result seems to be a consensus on the attribute name of closedby, and the values being any, closerequest, none. See https://github.com/whatwg/html/pull/10157 & https://github.com/whatwg/html/issues/9373