Lowercase all IDs

[peterbe]

In mdn/content#578 and mdn/content#499 @bershanskiy uncovered an interesting inconsistency. Sometimes it's <h2 id="See_Also">See Also</h2> and sometimes it's <h2 id="See_also">See also</h2> (and same with Browser compatibility vs Browser Compatibility). He's fixing the inconsistency and I wholeheartedly support that because consistency makes MDN look more accurate and professional and also more "accessible" to the pattern-loving brain.

But his cleanup effect will break links. :(
Imagine some blog post that contains:

<p>
  <a href="https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#Browser_Compatibility">Compat data for this on MDN</a>
</p>

that link will now not go to the right section of the page :(
...once his PR lands.

But there's a solution!
We control these <h2> and <h3> injections into the DOM/HTML here. So we can easily force them all to be lowercase. Then, once that's in place, we can salvage all the clicks into MDN when they arrive with a #Anchor that's in the wrong case. Possible draft of a solution:

window.onload = () => {
  if (location.hash && location.hash !== location.hash.toLowerCase() && !document.querySelector(location.hash) && document.querySelector(location.hash.toLowerCase())) {
    location.hash = location.hash.toLowerCase()
  }
}

I haven't tested it beyond the web console, but I think it'll work.

Slowly, over time, we'll get all incoming links, that use an anchor, to be in lowercase.

What do you think?

[peterbe]

Humbly pinging @escattone @chrisdavidmills @Elchi3 @sideshowbarker @nschonni @SphinxKnight @fiji-flo for feedback.

[SphinxKnight]

I don't have a strong feeling here and agree with the idea of consistency :)

[escattone]

I really like the idea of consistency, thanks @peterbe !

[peterbe]

I couldn't help myself.
#2266 actually works.
I haven't tested it in "non-ascii languages" like zh-CN. But that's also why it's only a draft.

[ghost]

I agree. I'm not sure doing hashes on client.

[ghost]

#2269

[nschonni]

I opened mdn/content#434, but it seems like a similar discussion.
I think a first step could be to generate (at build) an empty anchor with an ID just before the heading. This is a manual workaround often used in Markdown when renaming the ID would break alot of existing external references.
💯 on the fact that they should be lowercase. I'd probably go to kebab-case if you go generated

[bershanskiy]

I like lower case better as well.

Also, should we (proactively) remove leading and trailing _? Like here:

 <h2 id="_Example">_Example</h2>

It's not an issue yet, but preventing it in advance might save broken links in the future.

[Ryuno-Ki]

From a SEO point of view, I can report, there is an argument whether underscores or dashes „rank better”.
Personally, I prefer dashes.

[nschonni]

You can see how DocFX does it for the markdown headings here https://github.com/dotnet/docfx/blob/920dd053453999acfd93b4d171f55074058a9aff/src/Microsoft.DocAsCode.MarkdownLite/Basic/BlockRules/MarkdownHeadingBlockRule.cs#L52
As far as I read the regex, it strips anything that isn't a letter, space, or dash, and then escapes spaces with -

[ghost]

kebab-case: ^([a-z][a-z0-9]*)(-[a-z0-9]+)*$.
Ref: https://stylelint.io/user-guide/rules/regex

This should:

• not start with 0-9
• start with a-z
• permits 0 to * times a a-z or a - or 0-9 as a second character
• ends with at least 1 a-z

Test
https://regex101.com/

[sideshowbarker]

💯% agreed on making Yari normalize all IDs. I don’t have any strong opinion on the exact normalization that should be done, but lowercase-everything sounds the simplest, so I’d be happy with that.

[ghost]

Slowly working on the project I am realizing that perhaps it is better to want to do it and do it with PR on content. On the past I do not know well at the moment.

It could be a labelable thing.

[ghost]

• https://github.com/mdn/content/search?l=HTML&q=id&type=
• https://github.com/mdn/content/search?q=See_Also&type=

[escattone]

I'd prefer the lowercase-everything normalization approach just because it's simplest as well.

[schalkneethling]

@mdn/core-dev Does this sound like a discussion we want to keep around and bring to more people's attention, or should we remove the discussion. There are, unfortunately, only two options, lock or delete. Thank you.

[caugner]

Since #2266 has landed, I would consider this discussion resolved.