Add HTMLDialogElement

[kgmt0]

Prerequisites

• Before opening a pull request, please check the HTML standard (https://dom.spec.whatwg.org/). If it doesn't appear in this spec, it may be present in the spec for one of the other purescript-web projects. Although MDN is a great resource, it is not a suitable reference for this project.

https://html.spec.whatwg.org/#the-dialog-element

Description of the change

This adds a new module for HTMLDialogElement, which corresponds to <dialog>.

---

Checklist:

• Added the change to the changelog's "Unreleased" section with a reference to this PR (e.g. "- Made a change (#0000)")
• Linked any existing issues or proposals that this pull request should close
• Updated or added relevant documentation
• Added a test for the contribution (if applicable)

[leoliu]

I run into a similar issue of needing this dialog element. Any possibility of merging the PR?

[cwinebr]

It appears this should be something like:

foreign import _returnValue :: HTMLDialogElement -> Effect (Nullable String)

[leoliu]

MDN says it’s a string though see https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/returnValue

[cwinebr]

The PR template includes:

Although MDN is a great resource, it is not a suitable reference for this project.

That being said, I believe it is correct.

I think I misinterpreted the following from sections in the spec on close(returnValue) and requestClose(returnValue):

If returnValue is not given, then set it to null.

Upon reading further just now, I saw this:

When a dialog element subject is to be closed, with null or a string result and an Element or null source, run these steps:
[...]
9. If result is not null, then set subject's returnValue attribute to result.
[...]

Sorry for the noise.

[cwinebr]

Explicitly passing null to HTMLDialogElement.close results in the returnValue being set to the string "null", which seems surprising at least.

[leoliu]

It seems the method is expecting undefined or string so the input type should be refined to Undefined String

[thomashoneyman]

Only things I see missing here are requestClose and closedBy methods, but I believe those are a bit newer. Otherwise looks good to me 👍

[cwinebr]

Only things I see missing here are requestClose and closedBy methods, but I believe those are a bit newer. Otherwise looks good to me 👍

The behavior of close when passing Nothing for the first argument seems inappropriate to me, as I noted above. Acknowledgment of the comment, at least, would be appreciated. It seems to me that it would make more sense to invoke close() instead of close(null) in that case.

[thomashoneyman]

Only things I see missing here are requestClose and closedBy methods, but I believe those are a bit newer. Otherwise looks good to me 👍

The behavior of close when passing Nothing for the first argument seems inappropriate to me, as I noted above. Acknowledgment of the comment, at least, would be appreciated. It seems to me that it would make more sense to invoke close() instead of close(null) in that case.

Could you open a followup to this? I don't see @kgmt0 active in the replies and the original pull request is quite old.

[leoliu]

Since there is no equivalent of Data.Undefined it seems the best way forward is to modify the foreign code to treat null as undefined.