I am working on some changes related to SEO that involve edits to querySelectorX methods and things around them, and started work on merging these all into the ParentNode interface with the intent to turn the entries in Document and Element into redirects. Then it occurred to me that we probably want to be able to have something appear in the article explaining how you got to where you are.
As such, I propose the following:
First, we introduce a macro named MixinInfo which would be included on subpages of mixins to establish an insertion point for an explanation of how the mixin subpage was reached. Its syntax would be something like:
{{MixinInfo(list-of-implementors)}}
When viewed on a page embedding the mixin page, the output would be a box containing text like:
This interface implements this {{property||method}} based on its definition in the {{mixin’s name}} mixin. It is also implemented by the {{list-of-implementors minus current interface}} interfaces.
Second, we create a second new macro named EmbedMixinPage which would replace the contents of any of an interface’s subpages that should show the mixin page’s. This macro’s job is to embed the page from the mixin. By using this instead of a redirect, we get to maintain the sidebar organization we already have in place while still using the same content for all of the pg the method or property.
I propose a specific macro because doing so gives us the option of having it load and alter the page text, such as swapping out interface names and the like. But for starters it could simply do a straight embed of the mixin content.
Any thoughts? This would help reduce the issue of having clashing information about the same functions in different places, as well as allow us to maintain a usable navigational structure within each individual interface and API.
Sheppy