Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: Improve docs search engine indexing #31598

Open
josherich opened this issue Feb 1, 2020 · 4 comments
Open

doc: Improve docs search engine indexing #31598

josherich opened this issue Feb 1, 2020 · 4 comments
Labels
doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project.

Comments

@josherich
Copy link

josherich commented Feb 1, 2020

There's no way to access api from search engine in one click.

It's very hard to search node api from search engine. A typical example would be searching node writefilesync, the top result points to https://nodejs.org/api/fs.html without the heading hash #fs_fs_writefilesync_file_data_options.

image

In most cases, it's sth like the following, where there's a jump to xxx link to the hashed url https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#Body

Screen Shot 2020-01-30 at 2 40 14 PM

I'm not sure what's missing here, a quick search seems to suggest search engine need a unique id in headings like <h4 id="xxx"></h4> to tell the heading structure.

Since there's no search bar in the doc, it seems using search engine followed by Ctrl+F is the only way to find an api.

@Trott
Copy link
Member

Trott commented Feb 1, 2020

/ping @nodejs/website for suggestions

@cjihrig
Copy link
Contributor

cjihrig commented Feb 1, 2020

I'm just guessing here, but could the problem be that all of our link targets are just #? See the example below from the docs (with spacing added for readability):

<h2>
  <code>fs.writeFileSync(file, data[, options])</code>
  <span>
    <a class="mark" href="#fs_fs_writefilesync_file_data_options" 
       id="fs_fs_writefilesync_file_data_options">#</a>
  </span>
</h2>

@XhmikosR
Copy link
Contributor

XhmikosR commented Feb 1, 2020

I'd also guess it's because there are no IDs in headings. But we need to find some docs about this so that we are sure before making any changes.

Try using https://khan.github.io/tota11y/ and see how the headings are just identified as header-name# while in the MDN page they have proper IDs.

BTW another issue is with the anchors; their name is not descriptive, but this has to do with accessibility

@josherich
Copy link
Author

(could be outdated) According to using-named-anchors-to-identify

There are a few things you can do to increase the chances that they might appear on your pages. First, ensure that long, multi-topic pages on your site are well-structured and broken into distinct logical sections. Second, ensure that each section has an associated anchor with a descriptive name (i.e., not just "Section 2.1"), and that your page includes a "table of contents" which links to the individual anchors.

there's no exact rules to follow, a TOC and anchors should be sufficient. Most likely, id=xxx on h tag is considered more "well-structured".

@targos targos added the doc Issues and PRs related to the documentations. label Dec 26, 2020
@targos targos added the meta Issues and PRs related to the general management of the project. label Aug 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests

5 participants