Add support for Custom Element

[vtsvetkov-splunk]

Context

I added Custom Elements with shadow root via custom elements because I don't want the styles of mkdocs has influence on forms I am adding. When I have a form inside my custom component, the global keyboard handler catches some keys I am typing like s and takes focus to search.
The reason is if there is input focused inside the shadow root, the parent's document.activeElement would point to the custom element itself, not to it's underlying element.

Since 'the bug' is caused by extra javascript, I cannot mark it as a bug, so I am asking about adding support for custom elements.

Description

While having additional functionality via extra_javascript is a great feature, it lacks a full support for adding custom elements. I was able to add the custom element, but the keyboard shortcut is not aware about such type of element.
There is a check for activeElement which works differently for elements with shadowRoot. I am asking to add support for such kind of elements here:

mkdocs-material/src/templates/assets/javascripts/browser/element/_/index.ts

Lines 116 to 120 in 4498245

	export function getActiveElement(): HTMLElement | undefined {
	return document.activeElement instanceof HTMLElement
	? document.activeElement || undefined
	: undefined
	}

The active element of shadowRoot can be accessed via document.activeElement.shadowRoot.activeElement.

Related links

• Custom elements
• Shadow DOM v1 - Self-Contained Web Components # Handling Focus.

Use Cases

It will allow to have forms inside custom elements

Visuals

No response

Before submitting

• I have read and followed the change request guidelines.
• I have verified that my idea is a change request and not a bug report.
• I have ensured that, to the best of my knowledge, my idea will benefit the entire community.
• I have included relevant links to the documentation, related issues, and discussions to underline the need for my idea.

[squidfunk]

Thanks for reporting. Please provide a reproduction that showcases the issues. We cannot merge a PR without knowing what it impacts and for that we need to see it in action.

[vtsvetkov-splunk]

@squidfunk sure

• a repo: https://github.com/vtsvetkov-splunk/mkdocs-material-custom-element-demo
• a deployed version: https://vtsvetkov-splunk.github.io/mkdocs-material-custom-element-demo/

[humitos]

I have a pretty similar issue and I asked about a possibility to disable the hotkeys in Material for MkDocs but I was told the only way to do it currently it by removing that chunk of code and re-compile the theme 😞 : #4273

I'm also working with Custom Elements that contain inputs/forms inside them and this is a problem since every time that p, n or other keys are pressed, Material for MkDocs captures them and perform an action that it's not expected.

[squidfunk]

We can make hotkeys configurable in the future, but it is currently not a priority for us, so no ETA.

[vtsvetkov-splunk]

@humitos,

I'm also working with Custom Elements that contain inputs/forms inside them

If you use open mode when attaching shadow root, then my PR would mitigate that issue.

[vtsvetkov-splunk]

To workaround the issue, I added a keyDown event listener for every input inside the custom element and called stopPropagation. I hope that would help who also experiences the issue.

[squidfunk]

Fixed in be95f49 (superseding #6653) and released as part of 9.5.5.

[humitos]

I can confirm that this fix works for me. I created a small example at https://test-builds.readthedocs.io/en/mkdocs-material/ and opening the search modal (CustomElement) and typing n or p inside the text input doesn't trigger the Next or Previous MkDocs hotkey 🎉 . Thanks @vtsvetkov-splunk and @squidfunk for the fix 💪🏼