4 ms·

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

• montroser 5y 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 5y 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 5y 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 5y 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....