Make site usable without any JavaScript

[slorber]

🐛 Bug Report

The site is able to work mostly fine without JS.
In such case, navigation is not SPA/history push based, but is a regular html nav (like Docusaurus v1)

But, docs have collapsible menus, and these menus won't expand without JS:

I think we should find a html/css only solution to enable the user to expand those collapsible menus. It should be possible using :focus / :focus-within, here's a random example: https://codepen.io/josy-star/pen/KymaJw

If this is done correctly, users may even be able to enter submenus by using keyboard focus navigation (using tab).

Yes, users don't disable JS anymore in 2020, yet I think this is important to support. Main reason is that users on a bad connexion may experience slow JS hydration time, and for a few seconds, the JS is not loaded. I think we should ensure the nav still work during that time.

Other important reasons here: https://kryogenix.org/code/browser/everyonehasjs.html

(useful extension: https://github.com/maximelebreton/quick-javascript-switcher)

---

This is a non-exhaustive list of what can be easily fixed to support a no-js mode. If you find other issues that can have a significant impact and are easy to fix, that can be nice. The purpose if probably not to make everything work without JS, but if we can have at least major features like the navigation, it's a nice win that all our users will benefit.

Note: maybe some parts of the fix would require being backported to Infima?

---

Related draft PR: #3237

[anshulrgoyal]

I am working on this.

[anshulrgoyal]

@slorber Navbar dropdown work without js.

[slorber]

ah yes it's :hover

so it's probably only the collapsible doc sections that don't expand without js (here, :hover is not enough, we need to support multi-level nesting)

[anshulrgoyal]

ah yes it's :hover

so it's probably only the collapsible doc sections that don't expand without js (here, :hover is not enough, we need to support multi-level nesting)

I am trying to use the hidden checkbox. This is a good example https://codepen.io/jboeijenga/pen/eqzal

[slorber]

hmmm, that could do the trick. Wonder what's the advantage of using something like tabindex and :focus-within ?

Will this work if I use tab navigation to give the focus to an item for example?

Here I used tab navigation, we can see it with the collapsible outline. In such case that should be nice to expand it automatically:

I can see how using checkboxes would be nice to give some state and keep the collapsible expanded when they lose focus, but still think it may be useful to make it work without the checkboxes ;)

[sarthakkundra]

@slorber The current classic template for version 2.0.0-alpha.65 doesn't seem to have a dropdown menu for the docs. The generated site does seem to have some JS but that's only to store the theme preference. Please correct me if I'm wrong in understanding the issue or if any other changes are required.

[slorber]

Hi @sarthakkundra

The generated site is not versioned so it does not have a versions dropdown.

The best is to make sure that our own website (that you can run with yarn start:v2) mostly works with JS disabled, as the dropdown is already there for you.

Let's assume that if a component absolutely need JS to run (search, theme toggle...) we'll just hide such element in noJS mode.
I don't expect everything to work without JS, but what can work without JS should rather work without JS. And the dropdown can work without js.

[slorber]

It's not useful anymore to allow uncollapsing categories of the sidebar with CSS/HTML only.

We now have "lazy/partial sidebars", and reduce the HTML markup rendered on the server by not rendering collapsed categories subitems: #5136
This is important for perf on sites rendering very large sidebars.

Instead, we'll solve the no-JS category uncollapsing by making the category a link targeting a page (category index page, or first doc of that category...), and the target page will have the category uncollapsed by default.
Track #2643

Also may apply the suggestion of @m-allanson here, using the first doc of a category as a SSR link fallback: facebookincubator/infima#36 (comment)

[waldyrious]

Has the possibility to use HTML5 <details>/<summary> tags been discussed for this purpose?

[slorber]

@waldyrious I was considering it but since now sidebar categories are lazy, the summary content is not always server-rendered so it wouldn't work in this way. I think it's fine if we implement the "category index" page, and also users with JS disabled are more likely to expect a navigation on category click rather than a client-side expansion (even if it's technically possible to make it)

[waldyrious]

I see, thanks for the quick response. I've been hoping to see more usage of <details> in the wild for this kind of purpose; too bad it won't be possible for Docusaurus.

[jwalton]

The hidden checkbox idea is great, but a "quick and easy" alternative would be to render expandable items as links. For example, if you click on "Getting Started >" and there's no javascript, we could take the user to a page that has a list of all the catagories underneath "Getting Started". It's not as fancy, but it at least makes it so the page can be used.

[slorber]

@jwalton as part of #5830 we are adding the ability to link to a doc or an automatically generated index page (https://deploy-preview-5830--docusaurus-2.netlify.app/docs/next/category/getting-started/)

This is however optional.

For categories not linking to any URL, I'll link them to the first child until React is able to hydrate, so that you'd be able to click on the category if the JS fails to load (suggested in facebookincubator/infima#36 (comment))

The only case where we you wouldn't be able to "open" the category without JS is:

• When there is no explicit link (doc or generated index)
• When the category has no child, or none of the child have any link (which is a weird use-case IMHO)

[slorber]

I implemented the fallback described above as part of #5830

Now the sidebar is partially rendered on the server and we can still navigate it entirely with JS disabled.

Test URL: https://deploy-preview-5830--docusaurus-2.netlify.app/docs/next/category/guides/
The only edge-case where we can't navigate with JS disabled is when a category has no subitems (which is a weird use-case anyway)
Let me know if you see any issues.

[Josh-Cena]

From my tests, our website now almost works perfectly with JS disabled. However, when you navigate between pages, there's a flash of the navbar dropdown:

Probably because we render the dropdown on SSR?

[slorber]

😅 I don't see this happening for me on the docusaurus website

Yes, we render the dropdown on purpose: it should work without JS using :hover

[gordonbazeley]

Is there any way to specify that the site shouldn't deliver JS to the browser please? I'm looking to build a site with as small a carbon weight as possible and would rather do without JS if possible

[slorber]

@gordonbazeley we don't have such an option atm, there's only this draft PR: #3237

[Josh-Cena]

@slorber Is this good to close now? I haven't observed any significant problem with using the site without JS.

[slorber]

I'd like to keep this issue open and alive forever, as a central issue to discuss and report everything related to progressive enhancements

We still have a few things we could work on:

• search (Algolia may implement a fallback server-side UI)
• mobile drawer menu (looks the most important, can probably work with checkbox)
• tabs (can probably work with radio when tabs are not lazy)
• dark mode toggle (low ROI, but can probably work with checkbox)
• probably other little details

[Josh-Cena]

Ah, makes sense.

[slorber]

Notes to myself:

Interesting suggestions on how to support a no-js version of the mobile drawer using recent CSS features: https://twitter.com/sebastienlorber/status/1582788081668616192
Edit, more recently: https://twitter.com/Una/status/1729236000294174733

No-js search can likely be implemented with a simple GET form fallback redirecting to google site search URL:
https://www.google.fr/search?q=site:docusaurus.io&q=mdx

[slorber]

Note to self:

The mobile drawer menu doesn't work well without JS

When the time comes to refactor it, make sure to also take into consideration the comments from @timveld regarding keyboard/accessibility in #8207 (comment)

[slorber]

Related: when JS is disabled it should be possible to keep theme respect OS color scheme (initially reported in #9579)

[SethFalco]

when JS is disabled it should be possible to keep theme respect OS color scheme

I've been working on this, and have a proof of concept ready. Dark mode will look the same with JavaScript disabled, except for code blocks due to Prism's inline styles.

The proposed approach using PostCSS to retroactively replace selectors from [data-theme=…] to @media (prefers-color-scheme: …), when both prefers-color-scheme is enabled and the switch UI is disabled.

I'll hold off on opening a PR for now so I can investigate the Prism issue further, and see how to approach tests for this.

You can find the WIP branch here:

• https://github.com/facebook/docusaurus/compare/main...SethFalco:docusaurus:fix/dark-mode-no-js?expand=1

This does not conditionally omit noFlashColorMode(), as Prism still depends on it for theming code blocks.

The following screenshots are taken with JavaScript disabled:

---

Alternatively, here is our plugin for Docusaurus:

• https://github.com/svg/svgo.dev/blob/main/src/plugins/prefers-color-scheme.js

This plugin is currently in use on svgo.dev.

[slorber]

Apparently we can implement tabs without JS thanks to the new <details> name attribute and some CSS

Source: https://twitter.com/naman34/status/1734367676536078755
Not sure it's good for a11y, but worth exploring.

---

This feature is normally meant to create accordions. Preview without tab styling:

Tab 1

1. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Ullam explicabo, dolore voluptatibus corrupti quia vitae iure exercitationem, incidunt eius magnam voluptates, voluptatum sit dicta cupiditate ducimus molestiae repellendus in perferendis!

Tab 2

2. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Ullam explicabo, dolore voluptatibus corrupti quia vitae iure exercitationem, incidunt eius magnam voluptates, voluptatum sit dicta cupiditate ducimus molestiae repellendus in perferendis!

Tab 3

3. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Ullam explicabo, dolore voluptatibus corrupti quia vitae iure exercitationem, incidunt eius magnam voluptates, voluptatum sit dicta cupiditate ducimus molestiae repellendus in perferendis!

Tab 4

4. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Ullam explicabo, dolore voluptatibus corrupti quia vitae iure exercitationem, incidunt eius magnam voluptates, voluptatum sit dicta cupiditate ducimus molestiae repellendus in perferendis!

Tab 5

5. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Ullam explicabo, dolore voluptatibus corrupti quia vitae iure exercitationem, incidunt eius magnam voluptates, voluptatum sit dicta cupiditate ducimus molestiae repellendus in perferendis!