News for hackers. Stuff that matters.
Re:Using <details> for menus and dialogs (2019) by montroser on Saturday April 24, 2021 @05:36PM (#26928412)
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/di...

[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/me...

[3]: https://github.com/GoogleChrome/dialog-polyfill

Re:Using &lt;details&gt; for menus and dialogs (2019) by worble on Saturday April 24, 2021 @05:55PM (#26928505)
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.
Re:Using &lt;details&gt; for menus and dialogs (2019) by montroser on Saturday April 24, 2021 @06:16PM (#26928641)
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.

Re:Using &lt;details&gt; for menus and dialogs (2019) by onion2k on Sunday April 25, 2021 @03:10AM (#26930909)
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.

Re:Using &lt;details&gt; for menus and dialogs (2019) by montroser on Sunday April 25, 2021 @07:15AM (#26931895)
It's a fair point that specs evolve, and that sometimes includes deprecation. I do feel slightly aggrieved about the `scoped` style attribute being spec'd, implemented, and then dropped shortly thereafter.

But overall I feel this approach has worked well over the years. With jQuery for example, I only learned enough to get by working in those codebases, but I committed to internalized all of the standardized DOM methods and Array methods and naive XHR workings. Now in these modern times, jQuery still _works_, but whatever I came to know of it is no longer very useful to me, day to day.

Re:Using &lt;details&gt; for menus and dialogs (2019) by ryanbrunner on Sunday April 25, 2021 @07:15AM (#26931893)
Deprecated HTML tags are relatively rare though, especially more recently. You can pretty much categorize every one of them into tags that are purely concerned with styling, frame support and applet type things. And in all cases, the deprecation took a long time, long enough that it would outlive most apps.

And nowadays, even if dialog happened to be deprecated, you could always continue to support it using a custom element if you really needed to (which probably wouldn't be the worst approach even if you were building it from scratch, to be honest).

Re:Using &lt;details&gt; for menus and dialogs (2019) by inopinatus on Saturday April 24, 2021 @07:05PM (#26928964)
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.
Re:Using &lt;details&gt; for menus and dialogs (2019) by saagarjha on Saturday April 24, 2021 @09:55PM (#26929720)
> On browsers, it's at 73% native support on caniuse

Alternatively: it works in Blink, but nowhere else.

Re:Using &lt;details&gt; for menus and dialogs (2019) by inopinatus on Saturday April 24, 2021 @06:19PM (#26928655)
Too late to throw this shade around, I’m afraid, because it’s also available now in Firefox nightly builds (GP may wish to edit to mention) and it’s looking pretty good to me.
Re:Using &lt;details&gt; for menus and dialogs (2019) by hnbad on Sunday April 25, 2021 @05:47AM (#26931519)
This seems to have been supported in nightly for over a year and behind a feature flag even longer but it's still nowhere near ready for GA.

Meanwhile Safari doesn't support it at all.

The stats on caniuse are skewed by Chromium as usual.

Re:Using &lt;details&gt; for menus and dialogs (2019) by inopinatus on Sunday April 25, 2021 @07:58AM (#26932066)
On the contrary. It’s very usable in FF nightly right now, including dialog forms, and I know this first-hand because I’m using it. Safari TP support is developmental, not absent.
Re:Using &lt;details&gt; for menus and dialogs (2019) by hnbad on Sunday April 25, 2021 @09:30AM (#26932559)
I'm not saying it's not usable in FF nightly, I'm saying there are major blockers for it to go into GA.

As far as I can tell the rendering is currently hacky (i.e. it doesn't follow the spec but achieves the same visual result) and the implementation is supposed to be tied to the `inert` attribute, which isn't currently implemented in FF. This may not matter to most users but if left as-is would result in cross-browser compatibility issues.

Re:Using &lt;details&gt; for menus and dialogs (2019) by inopinatus on Sunday April 25, 2021 @08:02PM (#26937940)
This scuttlebutt is misdirection. No GA browser has release support for the inert attribute, which sits behind an experimental feature flag for both Chrome and FF. The inert subtree work is ongoing, and notably, inert support is not showing as a release blocker. Yes, it'll be great to have, but it's far from mandatory.

The significant outstanding blocker for FF is re. focus twiddling for better a11y, per recent discussion at whatwg/html#5678, c.f. bugzilla#1660271 & #1701230, and this is hardly boiling-the-oceans stuff.

I'm excited for <dialog>, it's a survivor, and a great simplifier - particularly of dev conversations - and I recommend it (even with interim polyfill) to all and sundry.

Re:Using &lt;details&gt; for menus and dialogs (2019) by montroser on Saturday April 24, 2021 @06:46PM (#26928864)
Ah, yes indeed! Firefox nightly has native support for <dialog> now...
Re:Using &lt;details&gt; for menus and dialogs (2019) by SimeVidas on Sunday April 25, 2021 @12:05AM (#26930280)
Re:Using &lt;details&gt; for menus and dialogs (2019) by shawnz on Saturday April 24, 2021 @06:35PM (#26928784)
And similarly that library might as well reuse the standardized APIs of "<menu>" and "<dialog>" where possible. Then eventually, you might not need any library and there will be no code change required.
Re:Using &lt;details&gt; for menus and dialogs (2019) by no_wizard on Saturday April 24, 2021 @06:02PM (#26928542)
The <menu> element is unfortunately deprecated[0]

I would avoid using it.

[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/me...

Re:Using &lt;details&gt; for menus and dialogs (2019) by dragonwriter on Saturday April 24, 2021 @06:06PM (#26928567)
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.

Re:Using &lt;details&gt; for menus and dialogs (2019) by JonathonW on Saturday April 24, 2021 @05:49PM (#26928471)
But, unlike <details>, is not Javascript-free.
Re:Using &lt;details&gt; for menus and dialogs (2019) by montroser on Saturday April 24, 2021 @06:34PM (#26928780)
This is true. On the other hand, <details> for menus and dialogs is a stretch, semantically. And <dialog> natively supports ESC to close/cancel.
Re:Using &lt;details&gt; for menus and dialogs (2019) by dragonwriter on Sunday April 25, 2021 @06:07AM (#26931598)
> 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....

Re:Using &lt;details&gt; for menus and dialogs (2019) by bArray on Saturday April 24, 2021 @07:10PM (#26928998)
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

Re:Using &lt;details&gt; for menus and dialogs (2019) by inopinatus on Saturday April 24, 2021 @07:29PM (#26929113)
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

Re:Using &lt;details&gt; for menus and dialogs (2019) by c-smile on Saturday April 24, 2021 @11:40PM (#26930182)
For the note, in Sciter (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).