Material uses IDs that are easy to conflict with.

[facelessuser]

Description

MkDocs Material injects a couple of ids that aren't expected. For instance in my document, the id search, drawer, github are all found in Material's header. I imagine there are at least a couple more that just aren't present in documents. The problem is that this isn't exactly expected, or intuitive to figure out. It is easy for a user to do the following, and none of of the links to work. And it won't be noticed until someone happens to click on anchors for the headers or the links referencing the header, and none of it work.

## Search

Some text.

## Drawer

[ref](#search)

A user would have to explicitly assign an id to the header that does not conflict. While I realize it is probably impossible to come up with a name no one could accidentally stumble upon, I feel like we could definitely make it more difficult.

Expected behavior

I would normally expect that id's for Material to be more difficult to happen upon so a user doesn't have to explicitly be aware of all ids that Material uses. Maybe something like 07328739847_search, or something that would be fairly unique.

Actual behavior

Unfortunately, Material uses very common ids that are easy to accidentally conflict with.

Steps to reproduce the bug

1. Create document with header Search. Header anchors and links referencing the header won't properly work.

Package versions

• Python: NA
• MkDocs: NA
• Material: Latest

Project configuration

NA

System information

• OS: NA
• Browser: NA

[squidfunk]

Thanks for reporting. I would probably just add two underscores to all internally used IDs, so search becomes __search. I've already done it for __comments (Disqus integration). However, this means a major release, because renaming ID tags may break customized JavaScript. There's quite some stuff now which would demand a new major release but I wanted to wait until I refactored the code to RxJS/TypeScript. However, my time budget for Material is very, very small at the moment, so I probably just fix some of the open issues (including GDPR compliance) and roll out 3.0.

[facelessuser]

Sounds good.

[facelessuser]

If I have the time, I may issue a pull for this.

[squidfunk]

Fixed in a42fdb3, should be released soon.

[squidfunk]

I decided to do a minor release as I consider this not being something that is customized quite often. 2.8.0 is out which includes all changes.