5 ms·

The <menu>[1] and <dialog>[2] elements are also pretty good for menus and dialogs. Full working example of a modal dialog: <dialog id="dialog"> <for

The <menu>[1] and <dialog>[2] elements are also pretty good for menus and dialogs. Full working example of a modal dialog: <dialog id="dialog"> <form method="dialog"> What is your favorite color? <input name="color"> <button>Save</button> </form> </dialog> <button onclick="dialog.showModal()"> Show dialog </button> The dialog element is fully supported in Chrome/Edge and Firefox nightly, and there's a polyfill[3] for the others. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di... [2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/menu https://developer.mozilla.org/en-US/docs/Web/HTML/Element/me... [3]: https://github.com/GoogleChrome/dialog-polyfill https://github.com/GoogleChrome/dialog-polyfill

JonathonW 6y ago
But, unlike <details>, is not Javascript-free.
- montroser 6y ago
  This is true. On the other hand, <details> for menus and dialogs is a stretch, semantically. And <dialog> natively supports ESC to close/cancel.
  - bArray 6y ago
    Sure, but this is at the cost of requiring Javascript (on non-supported browsers) just to display some links to navigate your website. Maybe you could use `<script>` and `<noscript>` to better extend support... [1] [1] https://www.w3schools.com/TAGs/tag_noscript.asp https://www.w3schools.com/TAGs/tag_noscript.asp
    - inopinatus 6y ago
      It is actually possible to style a <dialog> with a pure CSS fallback for reveal, e.g such that it also appears via :focus-within activated using a <label> that targets a nested but invisible input, which is feasible even if JS is disabled or locally malfunctioning. I’ve made this construction work but it is obviously a hack, and rather page-specific so we didn’t turn it into a library component. The result also had accessibility issues, which we did fix with JS, rationalised on the basis that ARIA by definition means JS availability. Personally I’d rather that the toggle was available as an activation behaviour, and this is an open issue for the HTML standard. https://github.com/whatwg/html/issues/3567 https://github.com/whatwg/html/issues/3567
  - dragonwriter 6y ago
    > On the other hand, <details> for menus and dialogs is a stretch, semantically. Not really, for either menus or non-modal dialogs: “The details element represents a disclosure widget from which the user can obtain additional information or controls.” https://html.spec.whatwg.org/multipage/interactive-elements.html#the-details-element https://html.spec.whatwg.org/multipage/interactive-elements....
worble 6y ago
If you need to polyfill for 2 of the most popular 3 browsers then you might as well just use a JS modal library that looks nicer and has more functionality.
- montroser 6y ago
  Those libraries will come and go, but <dialog> is part of the HTML specification. I like to invest in learning things that are more likely to be around for a while. On browsers, it's at 73% native support on caniuse, and the polyfill is high-quality, by the Chromium team. As far as looks, it's all fully styleable with CSS so you can make it look however you like.
  - inopinatus 6y ago
    It’s even better than that, stylistically speaking. It’s the first element whose default styling, irrespective of the parent node, is naturally centred both vertically and horizontally with height and width constrained to content size (this alone being one of the CSS holy grails), but also explicitly sidestepping z-index issues even for elements within a nested stack context. All things a polyfill cannot do without caveats.
  - saagarjha 6y ago
    > On browsers, it's at 73% native support on caniuse Alternatively: it works in Blink, but nowhere else.
  - onion2k 6y ago
    Those libraries will come and go, but <dialog> is part of the HTML specification. I like to invest in learning things that are more likely to be around for a while. Historically it's more likely that an unpopular tag will be removed from the HTML spec and removed from browsers than JS will lose compatibility with your code. For example, a JS flashing text effect from 25 years ago still works. <blink> tags don't. Most tags that are deprecated in the spec aren't removed (eg marquee) but you shouldn't assume something in the spec will be available forever.
no_wizard 6y ago
The <menu> element is unfortunately deprecated[0] I would avoid using it. [0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/menu#context_menu https://developer.mozilla.org/en-US/docs/Web/HTML/Element/me...
- dragonwriter 6y ago
  No, the context menu variant (<menu type="context">) is deprecated. Hence, why the deprecation note is on the example of that variant, not on the element of course, much of the rest is experimental and unimplemented.
c-smile 6y ago
For the note, in Sciter (https://sciter.com https://sciter.com) these (JS): Window.this.modal(<info>Hello world</info>); Window.this.modal(<alert>Hello world</alert>); let r = Window.this.modal(<question>Hello world</question>); will create real modal dialogs (as separate desktop windows).

JonathonW 6y ago

But, unlike <details>, is not Javascript-free.

montroser 6y ago
This is true. On the other hand, <details> for menus and dialogs is a stretch, semantically. And <dialog> natively supports ESC to close/cancel.
- bArray 6y ago
  Sure, but this is at the cost of requiring Javascript (on non-supported browsers) just to display some links to navigate your website. Maybe you could use `<script>` and `<noscript>` to better extend support... [1] [1] https://www.w3schools.com/TAGs/tag_noscript.asp https://www.w3schools.com/TAGs/tag_noscript.asp
  - inopinatus 6y ago
    It is actually possible to style a <dialog> with a pure CSS fallback for reveal, e.g such that it also appears via :focus-within activated using a <label> that targets a nested but invisible input, which is feasible even if JS is disabled or locally malfunctioning. I’ve made this construction work but it is obviously a hack, and rather page-specific so we didn’t turn it into a library component. The result also had accessibility issues, which we did fix with JS, rationalised on the basis that ARIA by definition means JS availability. Personally I’d rather that the toggle was available as an activation behaviour, and this is an open issue for the HTML standard. https://github.com/whatwg/html/issues/3567 https://github.com/whatwg/html/issues/3567
- dragonwriter 6y ago
  > On the other hand, <details> for menus and dialogs is a stretch, semantically. Not really, for either menus or non-modal dialogs: “The details element represents a disclosure widget from which the user can obtain additional information or controls.” https://html.spec.whatwg.org/multipage/interactive-elements.html#the-details-element https://html.spec.whatwg.org/multipage/interactive-elements....

worble 6y ago

If you need to polyfill for 2 of the most popular 3 browsers then you might as well just use a JS modal library that looks nicer and has more functionality.

montroser 6y ago
Those libraries will come and go, but <dialog> is part of the HTML specification. I like to invest in learning things that are more likely to be around for a while. On browsers, it's at 73% native support on caniuse, and the polyfill is high-quality, by the Chromium team. As far as looks, it's all fully styleable with CSS so you can make it look however you like.
- inopinatus 6y ago
  It’s even better than that, stylistically speaking. It’s the first element whose default styling, irrespective of the parent node, is naturally centred both vertically and horizontally with height and width constrained to content size (this alone being one of the CSS holy grails), but also explicitly sidestepping z-index issues even for elements within a nested stack context. All things a polyfill cannot do without caveats.
- saagarjha 6y ago
  > On browsers, it's at 73% native support on caniuse Alternatively: it works in Blink, but nowhere else.
- onion2k 6y ago
  Those libraries will come and go, but <dialog> is part of the HTML specification. I like to invest in learning things that are more likely to be around for a while. Historically it's more likely that an unpopular tag will be removed from the HTML spec and removed from browsers than JS will lose compatibility with your code. For example, a JS flashing text effect from 25 years ago still works. <blink> tags don't. Most tags that are deprecated in the spec aren't removed (eg marquee) but you shouldn't assume something in the spec will be available forever.

no_wizard 6y ago

The <menu> element is unfortunately deprecated[0] I would avoid using it. [0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/menu#context_menu https://developer.mozilla.org/en-US/docs/Web/HTML/Element/me...

dragonwriter 6y ago
No, the context menu variant (<menu type="context">) is deprecated. Hence, why the deprecation note is on the example of that variant, not on the element of course, much of the rest is experimental and unimplemented.

c-smile 6y ago

For the note, in Sciter (https://sciter.com https://sciter.com) these (JS): Window.this.modal(<info>Hello world</info>); Window.this.modal(<alert>Hello world</alert>); let r = Window.this.modal(<question>Hello world</question>); will create real modal dialogs (as separate desktop windows).