Page titles rendered using H1 should have an ID for permanent link

🐛 Bug Report

Currently in V1 of docusaurus, when the site is generated, it uses the title metadata of each markdown files (default/out of the box behaviour). However, this title does not have any id or anchor links unlike all other headings found in the markdown files.

This is causing a very weird behaviour when the title of the page matches search results (if algolia search is integrated). Clicking on the link from algolia search result, takes us to the correct page but the header/title of the page is tucked under the site navigation header.

I believe this is happening because the title of the page does not have an “id”. When the search query matches the page title, it tries to generate a permanent link to that particular “heading”. So, Algolia search result generates a permanent link using the closest parent that has an id, which is docsNav.

The issue is easier to see with an illustration.

Have you read the Contributing Guidelines on issues?

Yes

To Reproduce

1. Go to Docusaurus’ documentation site here: https://docusaurus.io/docs/en/installation
2. In the search box, type query such as version. The search result might look like this:

• 

1. Click on the result that matches the title/heading of this page (the first result in the above screenshot): https://docusaurus.io/docs/en/versioning
2. You’ll be taken to a page whose URL looks like this: https://docusaurus.io/docs/en/versioning#docsNav

Expected behavior

Clicking on the search result that matches the page title should have taken me to that page anchored to the page title properly. It should be displayed like this:

Actual Behavior

Clicking on link (https://docusaurus.io/docs/en/versioning#docsNav) from search result takes me to the correct page but the display is skewed. The title is touching the bottom of the top navigation bar:

This does not happen if you try any other anchor links on the page from the right hand side table of content.

Reproducible Demo

(Paste the link to an example repo, including a siteConfig.js, and exact instructions to reproduce the issue.)

[s-pace]

Thanks for the prompt reply and the clarification @endiliey

DocSearch Documentation doesn’t expose an id for h1 because there is no need to scroll down for these results since h1 are at the top of the page. Every other header does/should expose a unique id or name. By headers, I meant every <hX/> markup, not only h1. Same reasoning applies for webpack. Just notice that this issue is only about <h1/>.

Table of content is always an edge case and I do agree that these elements should not be part of the search either. This one of the reasons why we do recommend to remove them from the DOM before to parse it at the crawling time.

We are going to move our own documentation to docusaurus. I will keep you posted regarding what are the room of improvement in order to provide the best learn-as-you-type experience.

[JoelMarcey]

Well, to be honest I don’t really know why we did so. (had to ask @JoelMarcey as the original author of Docusaurus), but I think its because we actually just don’t want the page title as destination anchors. Similar to how the wc3 example don’t want Table of Contents to be a destination anchor. That’s why the h1 doesnt have an id

I don’t recall the exact reason for this, but I believe @endiliey is correct. At the time, we were not going to anchor h1s. It’s very possible though it was just an artifact of how we developed the project and wasn’t a real conscience decision.

cc @deltice in case he remembers (Hi 👋)