pymdown-extensions
pymdown-extensions copied to clipboard
facelessuser
Ability to focus on a given tab in a tab set.
Description
Currently, there is no way to focus on a given tab (among tabs). The first tab always gets the focus. It would be nice if there was a way to put focus on a specific tab.
Relevant mkdocs-material discussion https://github.com/squidfunk/mkdocs-material/discussions/3982
Benefits
One use case I have is described here https://github.com/squidfunk/mkdocs-material/discussions/3982#discussioncomment-2881853
Solution Idea
One possible solution using ===+ is described here https://github.com/squidfunk/mkdocs-material/discussions/3982#discussioncomment-2881832
It appears the new tab select feature will be incompatible with MkDoc Material's content.tabs.link feature. @squidfunk FYI.
Material will try and normalize link selection on page load.
This would normally be fine if the normalization occurred after a tab was manually selected on a page, but I think Material just does this all the time, and does it across pages as well. So if you select a tab on one page, the next page will auto select what was selected on the previous pages.
Somehow related to #1766. If we could identify manual focus on a content tab section, we could detect an author-provided override and skip the content.tabs.link feature for that tab group.
I already have a PR open that adds specifying focus in #1725, it is not limited by the need of attribute lists as much as it is limited by the inability to use it in MkDocs Material due to conflicting features.
In general, we need something discernable to detect user overrides. As I understand, Tabbed will always set checked for the first tab right? Thus, if another tab is set to active, we could skip the linking logic altogether. This would however not work for the first tab, i.e. if the user adds + to the first tab. In that case we would need something else that tells us "don't link, override in place".
We could always add some CSS class to note the tab was forced to a linking. Though, I would argue that the problem is really only important on the initial page load. A user may want to force a default, but once a tab is selected, tab syncing could also begin. Or maybe not, I'm just thinking out loud here.
I will be merging this feature in. I do not have a solution for Material to determine if a tab is manually selected. I am open to a well thought out proposal though. I do not view the lack of such functionality as a bug, but an enhancement only for projects that attempt to remember tab select states across pages and/or initialize tab select states on page load, for all other cases, things should work fine.
It shouldn't conflict with the feature, but I'll double check that I have accounted for it properly in the logic.
Oh, I see, it's a feature to adjust the URL so you can share a link to a tab. In this case, even if it overrides the user's set default, in this case, it would make sense. If you are using a URL to navigate to a specific tab, I would expect it to take priority.