4 ms·
This is true. On the other hand, <details> for menus and dialogs is a stretch, semantically. And <dialog> natively supports ESC to close/cancel.
by 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 agoSure, 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 agoIt 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....