Closed domenic closed 1 year ago
The first two options seem nice and straightforward, but they have the minor drawback of making the cancel-and-close version more verbose, and demoting it to feeling second-class
What about just calling it "cancel()"? Just a thought, I don't have strong opinions on this
That's... pretty great! I'm promoting that to front-runner, pending any further opinions.
cancel
does really feel like a winner :)
Otherwise yeah I think focusing on the distinction between a UI close and a close action would be useful. requestClose
would be my suggestion, but shrug
I'm deciding on requestClose()
, after writing some example code and realizing that stuff like
myPicker.querySelector(".close-button").onclick = () => watcher.requestClose();
seems more readable than
myPicker.querySelector(".close-button").onclick = () => watcher.cancel();
Fixed this in the spec PR and in this repo's explainer. I also did a general update from "close signals" to "close requests".
Still TODO, updating Chromium.
@josepharhar noticed that for
<dialog>
,dialogEl.close()
does not trigger thecancel
event. Only a proper user-driven close signal will trigger acancel
event.I tend to think the
CloseWatcher
design is more useful for developers: if you have code likeyou probably would be surprised that clicking
.close-button
skips your unsaved-data check in thecancel
event, and instead goes straight to theclose
event. You're forced to duplicate the unsaved-data check inside theonclick
handler, which is silly.However, symmetry between
<dialog>
andCloseWatcher
is very important, to avoid web developer confusion. That's why we're using theclose
/cancel
event names in the first place.My proposal is that we provide both behaviors:
closeWatcher.close()
behaves likedialog.close()
, and goes straight to theclose
event.closeWatcher.bikeshed()
behaves as if a close signal has been sent, doing bothcancel
+close
.Naming for the
cancel
+close
variant remains the tricky problem. I likesignalClose()
(meaning "send the close signal as if the user did"), but per #13 @annevk and @smaug---- did not. Some options:cancelAndClose()
close({ withCancel: true })
closeCommand()
ortriggerClose()
or something like that.exit()
,shutdown()
.The first two options seem nice and straightforward, but they have the minor drawback of making the
cancel
-and-close
version more verbose, and demoting it to feeling second-class. (Whereas, per my above reasoning, I think it's actually the more likely behavior.) The latter two options are trickier but maybe worthwhile?We can also consider porting whatever we come up with here to
<dialog>
.