Consider renaming <dialog>.close() to .hide()

[mfreed7]

This has been discussed in the context of the Popup API within OpenUI, here. The general consensus there was to adopt a more "parallel" set of names for Popup, show and hide. The <dialog> API was called out for not being consistent: show and close.

Perhaps we should consider deprecating <dialog>.close() and replacing it with .hide()? Unfortunately, Chromium doesn't have a use counter for <dialog>.close() but I would imagine it's close to the usage of .showModal() plus .show(), which is around 0.025%. That's a surprisingly small percentage of the overall usage of the dialog element, which is around 4%. Perhaps most people are adding/removing the open attribute?

[domenic]

This has been discussed many times in the past, and is not desirable. Popup should instead align with dialog.

See https://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-December/041799.html and surrounding messages. A brief summary: closing the dialog is different than hiding it; in particular closing it gives it a return value and unblocks the page for other dialogs and so on. Whereas hiding it is something you can do with the hidden="" attribute already, and has very different behavior. Also, close is more aligned with many existing UI frameworks.

That is, conceptually, if this is a conversation the user is
having with someone, Hide() is like that person stepping out of the way to
afford the user a better view of the topic of conversation, while Close()
is that person leaving the conversation.

[annevk]

I like that rationale. @mfreed7 what do you think? Should we fold this into #7785?

[mfreed7]

So if you look at the discussion at OpenUI about this, the biggest holdup was the lack of symmetry. I definitely agree. Dialog’s show/close pair isn’t symmetric. Folks were fairly happy with either show/hide or open/close. Since it sounds like there’s pushback on changing close, perhaps I could propose we change to open (and openModal)?

[annevk]

@mfreed7 but did they consider the argument brought to light above? Looking at that issue it doesn't seem like it. As Ian explains in the email, show, hide, and close are distinct things that all make sense for the element.

[mfreed7]

So reading through the 2013 naming thread for <dialog>, the logic seems fundamentally different between <dialog> and the new Popup API. In the <dialog> case, as @domenic pointed out above, dialog.close() means that dialog is "done", giving a return value and going away completely. In the Popup case, "hide" is a better verb, since it is really just being hidden, and a call to "show" will bring it right back. There is no return value, and hiding a popup really is the direct opposite of showing it.

It sounds like there isn't too much appetite to try to change <dialog> here, and I think the decision we've made for Popup (to go with show/hide) still makes sense, even if it isn't parallel to <dialog>. It is anti-parallel in exactly the same way that the features themselves aren't parallel, so that sounds ok. Yes, it'll cause some developer confusion, but I can see the arguments for keeping them different.

I'm ok closing this issue, if you'd like.

[domenic]

I'll try to add a clarification note to the spec before closing this, basically outlining the logic here.