Make Menus useable without JavaScript

[mc-0bit]

Describe what feature you'd like. Pseudo-code, mockups, or screenshots of similar solutions are encouraged!

Currently, Menus rely on Svelte Actions, but this is causing them to break when the client does not have access to JavaScript for whatever reason.

This would not be an issue if Menus would purely use HTML and CSS to provide basic functionality. If JS is available, then use:menu can take over.

2023-02-14.12-25-56.mp4

The first menu is copied from the docs, while the second one is based on the checkbox version of this example I found and thus works the same without JS enabled.

What type of pull request would this be?

Enhancement

Any links to similar examples or other references we should review?

No response

[Sarenor]

We're currently in the process of doing a polishing pass on our utility features here and you're certainly welcome to chime in with your enhancement proposal there. If your use case is that the user doesn't have JavaScript, Skeleton is probably not the right component library for you. Especially our more advanced features like Utilities and some components rely on it because they rely on Svelte Component logic working.

My initial reaction might be wrong though and it could easily fit the Menu, @endigo9740 will have to decide that.
Just wanted to give you the general information that menus certainly aren't the only thing that suffer from degraded performance without JavaScript.

[knd775]

Progressive enhancement is a big part of sveltekit. Not supporting it in a UI library is a pretty big limitation.

[Sarenor]

And for most features it'll work. I'm just not sure if it's possible or useful in a dynamic thing like a menu, honestly.
Most Form Components in Skeleton work progressively, AppBar works progressively, etc.
You're just going to run into limitations with things like InputChips for example. Or Menus or Modals since these are usually highly dynamic things that require JS.

[knd775]

That's fair! I just think it's something that should be considered where possible. In this case, yeah, probably not. I've implemented css only menus, and they're not fun 😅

[Sarenor]

It's definitely considered, of that I'm pretty sure! At least for me it's also part of the reason for the Elements/Components/Utilities split.
Elements will always work without JS since they are just CSS, Components should mostly work without JS for things like form submission (ListBoxes and InputChips being the exception here) and Utilities definitely need JS.

I was mostly trying to say that if you're in an environment where users not having JS is the default, you might want to be careful when using Skeleton cause there's definitely things that aren't going to work.

Edited the initial comment for hopefully a bit more clarity.

[mc-0bit]

Since SvelteKit makes it relatively easy to build more accessible websites, it would be great if Skeleton would support that whenever possible. As you said, a lot of the Skeleton features already work without JS. Some things just need JS and that is fine.

I believe that it should be possible to create basic menus that do not require JS but are enhanced with JS to offer a smooth experience.

[endigo9740]

So I've been doing web dev and frontend design for a couple decades at this point, but I can tell you, anchored popup overlays are one of the hardest features to get right. At least for me. I realize our menus and tooltips leave a bit to be desired, which is why I added this as one of the primary goals for the Utility polish pass:

Per:

• Polish Pass: Utility Features #922

Joking aside, my top priority is making these features work well. As in they're easy to setup, they are visually appealing (transitions, etc), and most importantly they're accessible. While yes, it's possible to set these up with pure CSS, the accessibility is usually the trade-off. You just straight up cannot setup keyboard interaction such as tapping ESC to close with pure HTML/CSS.

Not to go off on a rant, but the number of folks working in an environment where JS is not enable is slim. I'm not saying it doesn't happen, and there's not some folks opting to turn off JS manually. But in my opinion it's a novelty. It's not the norm by any stretch of the imagination. Whereas a11y affects everyone, whether you're disabled or not. Everyone likes to be able to tap a key and dismiss a menu for example.

Given that I don't think this will be a priority for us. I appreciate the suggestion, but unfortunately that's not the path we're treading. If you wish to create non-JS menus, you may need to do so yourself. Here's a quick visualization:

1. You need wrapping element set to relative position. Paired with an origin class to set the anchor position.
2. You need a trigger element, that triggers the menu to appear on hover/click
3. You need the menu itself, set to absolute position

The tricky bit is the hover/click. Essentially you have to use CSS to control the siblings:

1. When button is focused, switch the menu from hidden to block
2. When the wrapping group is hovered, switch the menu from hover to block

There are special Tailwind "group" selectors for controlling this:
https://tailwindcss.com/docs/hover-focus-and-other-states#arbitrary-groups

For now I think this suggestion is out of scope for us, so I'm going to close it. But feel free to reach out on our Discord if you need help setting up a pure CSS alternative. We may be able to help if time allows.

[mc-0bit]

Maybe I worded that poorly 😅. I did not mean to fully replace the current menu with a pure CSS alternative that has the exact same accessibility without JS. Much rather, I meant that we still let the use:menu action take full control but in case JS is not available, we can fall back to the imperfect CSS solution. A11y would still be exactly the same as it is now, since it would still be handled by the svelte action.

But it is understandable if you do not want to mess with that since the whole reason why I use UI libraries is because I hate CSS and all the pain it brings 😅

[endigo9740]

There is no fallback though - you have to purposely build for CSS or JS. They are not really interchangeable like that.

That said, we might could build some Tailwind > Presentation styles for this in the future, give it's all possible with HTML/CSS. This would be similar to the Gradient Headings now. Canned styles we provide for you to use as you see fit.