[HN Gopher] Using <details> for menus and dialogs (2019)
___________________________________________________________________
Using <details> for menus and dialogs (2019)
Author : todsacerdoti
Score : 50 points
Date : 2021-04-23 15:26 UTC (1 days ago)
(HTM) web link (css-tricks.com)
(TXT) w3m dump (css-tricks.com)
| montroser wrote:
| 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
| JonathonW wrote:
| But, unlike <details>, is not Javascript-free.
| montroser wrote:
| This is true. On the other hand, <details> for menus and
| dialogs is a stretch, semantically. And <dialog> natively
| supports ESC to close/cancel.
| worble wrote:
| 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 wrote:
| 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 wrote:
| Too late to throw this shade around, I'm afraid, because it's
| available now in Firefox nightly builds and looking pretty
| good to me.
| montroser wrote:
| Ah, yes indeed! Firefox nightly has native support for
| <dialog> now...
| shawnz wrote:
| 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.
| no_wizard wrote:
| The <menu> element is unfortunately deprecated[0]
|
| I would avoid using it.
|
| [0]: https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/me...
| dragonwriter wrote:
| 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.
| inopinatus wrote:
| Recommended: take a look at how hey.com uses <details>/<summary>
| with <a> to enable dynamic drop-down menus and progressive
| enhancement via Hotwire, it's inspiringly simple and elegant.
|
| I've also used them for modals and slideovers. Use in conjunction
| with an [open] selector and adjacency combinators for maximum
| utility.
|
| See also: <dialog>, for which Firefox's support has come along
| rapidly this year; and the :focus-within pseudo-class.
|
| From the department of "You might not need (much) JavaScript".
| [deleted]
| no_wizard wrote:
| As discussed in the podcast _ShopTalk Show_ [0], of which Chris
| Coyer is a host. this is actually a more complex idea than this
| article let's on, a corollary article from the co-host of that
| show, Dave Rupert, on why it's a difficult idea and maybe not the
| best thing to do[1]
|
| To quote the article:
|
| > _tl;dr - <summary> is a button and buttons eat semantics_
|
| [0]: https://shoptalkshow.com
|
| [1]: https://daverupert.com/2019/12/why-details-is-not-an-
| accordi...
| tyingq wrote:
| Now I'm very curious why <summary> is a button. Off to read
| more.
|
| That second link is great, and this sentence caught my
| attention: _" At the risk of being a broken record; HTML really
| needs <accordion> , <tabs>, <dialog>, <dropdown>, and <tooltip>
| elements."_ At first glance, that sure would simplify a lot of
| the work I've done in the past.
| eyelidlessness wrote:
| > Now I'm very curious why <summary> is a button.
|
| I'm fairly certain it's a shadow DOM implementation detail.
| While it technically toggles a binary state and is probably
| more semantically similar to a checkbox, I think the way it's
| exposed to web APIs makes that either impractical or non-
| obvious.
| eyelidlessness wrote:
| Came here to mention this too. It's even worse than the tl;dr,
| if I recall correctly those semantics can't be reinstated with
| more semantics.
|
| There are some other cases where certain newer features like
| display: contents also hide content from assistive tools. I'm
| pretty sure some of these are being worked on, but don't have
| great recall of whether that includes details/summary.
| afarrell wrote:
| I've taken to using <details> in markdown docs on github to make
| them more concise to read.
| Multicomp wrote:
| I've used details for optional or dynamic html forms, as they
| gracefully degrade even for mobile browsers from the pre iphone
| era that can't use JS. They work pretty well.
___________________________________________________________________
(page generated 2021-04-24 23:00 UTC)