Feature Requests

Currently it's a little tough for non-technical people to edit markdown content as they are not familiar with the Git model and sometimes end up editing through GitHub. We could invest in solutions where content editing is made easier without an external CMS: Netlify CMS: https://github.com/netlify/netlify-cms StackEdit: https://github.com/benweet/stackedit Edit inline - https://www.dropbox.com/s/mm0vcld8lyl12qz/zeit_serverless_github_demo.mp4?dl=0

Currently it seems that all external links in content are opened by default in new tabs. It would be nice if that were configurable, because there's a general consensus that it's bad for accessibility. The link behavior seems to be a core part of <Link/> : https://docusaurus.io/docs/docusaurus-core#link ("External links also work, and automatically have these props: target="_blank" rel="noopener noreferrer". " as of 2.0.0-beta.17) It looks like controlling the target of external links in the sidebar is planned -- https://docusaurus.io/feature-requests/p/support-target-for-sidebar-links -- maybe for navbars too? (At the moment target isn't listed as an available option on either.) But even if that ability lands, what I'm talking about is the default behavior of links within content pages. Overriding the default behavior would currently require using HTML <a> elements instead of standard Markdown links -- on every link. Evidence on why opening new tabs automatically is bad for a11y is pretty voluminous, but here's a quick rundown of links: https://www.w3.org/TR/WCAG20-TECHS/G200.html and the related failure criterion https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F22 https://webaim.org/techniques/hypertext/hypertext_links#new_window https://www.nngroup.com/articles/new-browser-windows-and-tabs/ https://design-system.service.gov.uk/styles/typography/#opening-links-in-a-new-tab https://css-tricks.com/use-target_blank/ https://www.smashingmagazine.com/2008/07/should-links-open-in-new-windows/ https://belikewater.ca/blog/entry/linking-best-practice https://www.tempertemper.net/blog/opening-links-in-a-new-tab-or-window-is-better-avoided I'm not suggesting here to change the default behavior (although I'd be in favor of that), just to give Docusaurus users the ability to control this behavior. Especially since the current behavior will result in failure of WCAG 2.0 AA level and the UK gov'ts accessibility guidelines, as noted above. If for some reason you cannot provide control over this behavior, it would be nice to at the very least inform screen readers that these links will be opening a new tab using screen-reader-only text (CSS off-screen -- detailed here https://codersblock.com/blog/external-links-new-tabs-and-accessibility/#how-to-inform-your-users ) Thanks for considering.

It would be great if there was an easy way to implement FAQs that contain structured data. This would allow creation of rich snippets for Google. https://developers.google.com/search/docs/advanced/structured-data/faqpage

I have a usecase which multi-level navbar is usefull for me. Also it can be used for nested docs.

I want word(s) highlighting for my code block, something like on Tailwind docs.

I believe the user needs to have three options to select: Light, Dark, and System. I just saw this on https://monorepo.tools/ and I immediately noticed that Docusaurus could also do the same. Currently, if a user toggles the theme, it becomes "chosen by the user", and to revert to "chosen by the system", they need to clean cookies, right? Not optimal, I think. What do you guys think?

This should make the browser automatically navigate to the route when a content page changes. Hugo has this command and it's great when you have a large site, it makes it so you can quickly edit a markdown file and view the changes without having to navigate to the page within the browser. High-level steps: Watch for file changes within the project root directory (and sub-directories). On file change, work out if the file is a content file that corresponds to a specific route. If it does, make the browser navigate to this page.

An alternative to Algolia search. Working offline, under VPN and in private networks.

While we have Markdown linkification that resolves [](path) links, these are just turned into plain <a> tags. Gitbook allows the {% page-ref page="./ path.md " %} syntax, which produces a nice standalone link, displaying the permalink and the target page title. We can probably expose a linkify API that takes a Markdown path and returns a page's metadata, containing permalink, title, etc., maybe even an OOTB standalone link component. Don't know how non-trivial it would be to implement such a feature, and it would probably require reaching deep into the current infrastructure.

When writing tutorials, one may need to provide the content in different "flavors" (e.g., different prog. language and IDE combinations). Currently this can be done by using tabs or by embedding the variants into the docs structure. It would be nice if we could instead have a dropdown selector for something like this.