What is the maintainers position of Javascript Disabled experience?

[felquis]

In summary,

• What if Radix add to its list of features of each component an item saying "Works when JavaScript disabled or not loaded"
  

This way I can at a glance without the need to disable JavaScript thy the component I can know if for my use case I want to continue with that component or not.

Also, disabling the JavaScript and looking at how it works today, may also lead to insights of how it could possible work better without JavaScript in an progressive enhancement manner.

A session on the documentation mentioning the lib position on this matter after all could prevent future people asking the same questions I am asking now. (if there is already a session please share it with me.)

---

Ultimately, pushing for a progressive enhancement approach may also help to deliver accessible interfaces as well.

---

A short story

These days I built a mobile menu that works without JavaScript loaded, and when the JavaScript loaded it just adds extra functionalities to it making it even more awesome.

What I gain with it I presume is a faster time to interactive since SSR works fine, the HTML/CSS is fully loaded and some 70kb of JavaScript may be on the way.

---

I tried to find discussions on this topic on issues and discussions but I couldn't, so this is my kindly attempt to open the discussion, if it already happened somewhere else, please share a link to the it and I'll follow. If this is the first discussion on the topic, please be mindful and do not send short aggressive answers since I'm genuinely questioning something I care about.

Thank you all in advance.

[benoitgrelard]

Hi @felquis, this is a great topic and one we hope to get to eventually as we have discussed a lot about progressive enhancement and no-JS. Right now, most of the primitives (if not all) won't work without javascript as we haven't catered for it.

We have discussed potential ideas but I would say these are much further down the line.

[SachaG]

That would definitely be a great feature to have! The experience of course doesn't need to be the same without JS, but it would be nice if the component was functional at least.

[6TELOIV]

I think progressive enhancement is a great and very achievable goal! It also helps make components accessible by default, and have better functionality in noscript environments.

In my mind, the main things that need to change are:

1. Radio cards, toggle Groups, checkbox cards, checkboxes, toggles, switches, and sliders should be build off of their radio, checkbox and range native input elements. This may introduce breaking changes for styling the components.
2. Select is more difficult due to it's more complex behavior. Possibly it should render differently on the server and client (native select on server, hydrate to button with more advanced presentation and styling on client). Both can be styled identically to keep apearance identical to the user until the select is opened.
3. Tabs and accordions can be implemented with either summary/details, or radio inputs.
4. Dropdowns, collapsibles, popovers, menu bars, and possiby nav menus should be built off of the summary/details native elements. Same potential issues as above.
5. Scroll areas should overflow by default (?); I'm not sure how they are implemented, but as it stands they don't work for noscript.
6. Hover cards and tooltips can maybe be implemented purely with CSS. Using aria-describedby, this could make it accessible to screen readers as well, though I'm not 100% sure about that. Pure CSS is also maybe an option for nav menus to support the reveal on hover/focus pattern. See this MDN example for hover/focus revealed tooltips made with html/css only
7. Noscript toasts, dialogs, and alert dialogs probably can't be solved within this project. They can be implemented in noscript environments using a route-based approach like Nextjs suggests, but that is out of scope for this project, and I don't think any primative elements exist that can achieve the desired behavior without some server-sided action.