How to add indicator to alternate tabbed style?

[MichaIng]

PyMdown Tabbed added an alternate tab style with a scrollable label bar, which is nice for mobile devices. It is supported by MkDocs material and the old style will be deprecated with next release: https://squidfunk.github.io/mkdocs-material/reference/content-tabs/#tabbed

The new style supports visual indicators via JavaScript: https://facelessuser.github.io/pymdown-extensions/extensions/tabbed/#alternate-style
Are those supposed to be present OOTB when using this alternate style in MkDocs material? I'm currently testing it and don't see any indicator and not a single reference of the related tabbed-scroll-left/tabbed-scroll-right classes in the generated assets. Else, how can it be enabled? Manually adding the CSS and JS code from PyMdown docs as custom code should work, but I just wanted to assure that this is the intended way. If so probably it can be merged into MkDocs material to be added automatically, or via mkdocs.yml setting?

[facelessuser]

As far as I am aware, Material does not yet provide JS indicators OOTB. Though, it should be easy enough to pull it from the Pymdown Extensions examples in its documentation.

[squidfunk]

They will be added soon.

[MichaIng]

Thanks guys. I implemented it now like that: https://github.com/MichaIng/DietPi-Docs/pull/587/files

• The indicator classes in the example were only updated when hovering the bar, but not when scrolling it. So I trigger it on scroll events. E.g. on mobile devices with touch screen, there is no hovering, so the indicators were completely missing and also due to an unlucky screen size one might not see that further tabs are available, so I wanted have them always visible. This could however be adjusted via a single CSS to only show them when being hovered, focused or active (the letter I hope is possible, meaning when a tab label was just clicked).
• I didn't fully understand the example JS scroll state identification, e.g. isn't this:

  if (e.type === "mouseover") {
    const scrollWidth = target.scrollWidth - target.clientWidth
    let hscroll = target.scrollLeft
    if (!hscroll) {
      target.scrollLeft = 1
      hscroll = target.scrollLeft
      target.scrollLeft = 0
      if (hscroll) {
        target.classList.add('tabbed-scroll-right')
      }
    } else if (hscroll !== scrollWidth){
      target.classList.add('tabbed-scroll-left', 'tabbed-scroll-right')
    } else if (hscroll) {
      target.classList.add('tabbed-scroll-left')
    }
  }

  actually this?

  if (e.type === "mouseover") {
    const scrollWidth = target.scrollWidth - target.clientWidth
    if (!target.scrollLeft) {
      target.classList.add('tabbed-scroll-right')
    } else if (target.scrollLeft !== scrollWidth){
      target.classList.add('tabbed-scroll-left', 'tabbed-scroll-right')
    } else {
      target.classList.add('tabbed-scroll-left')
    }
  }

  Or is target.scrollLeft somehow forcefully kept 0 or empty when there is no overflow so that this is a hack to check whether it can be scrolled at all? Wouldn't be ((target.scrollWidth - target.clientWidth) > 0) the cleaner check to know whether to show indicators at all or not?
  However, I simplified it to add/remove the classes individually in our implementation.
• What I still don't like is that it cannot be scrollen via mouse drag. This is expected when no scroll bar is shown, but it is bad when because of unluck the right tab ends exactly at the screen end so that the next tab cannot be clicked, which makes scrolling impossible then. Possibly it makes sense to turn the scroll indicators into actual buttons to scroll left/right, respectively switch the active tab to one left/right?

I hope this helps to further polish things.

[squidfunk]

Yes, the implementation still needs some polishing, but it's already way better than before, so please consider the new implementation the polishing of the old one. This project is so huge, when you finished polishing everything, you can make another pass and another pass etc. I'm happy to collect some feedback on the tabs implementation, but currently, it's not really a priority. IMHO the implementation is already pretty good, it works without JavaScript, on mobile, and with keyboard navigation, thus it's also accessible, which is also a priority.

You can create a new discussion to collect some feedback, but unless something doesn't work, I'm currently not considering this to be an issue/bug/problem. As you already said, you're free to use an older version of Material for MkDocs, or port the old styles to some extra CSS. Material for MkDocs always tries to provide reasonable defaults, but bringing your own is easily possible and encouraged.

[facelessuser]

But it is a rare care anyway, I mean the selected tab can only be out of view when it was manually scrolled via touch drag or shift + mouse wheel already.

Yep, that's exactly why I didn't worry about it much. But, I agree that it could be better. I've kind of been iterating on it little by little. Overall, I think it works better than the old way, but yeah more polish is still probably needed.

[MichaIng]

Okay thanks for clarifying. Probably it's really me being picky about that, or our documentation where it is essential that visitors see all available tabs, respectively an indication that there are more tabs.

Defending the old way: At least every tab was always visible and always selectable with a single click/tap. Whether having those across multiple lines or not is a purely visual aspect that one can like or not. At least me and one team member weren't unhappy with those being shown across multiple lines, i.e. we never saw this as a issue which needs to be addressed. But this is really a question of personal taste, and then of course whether the implications of a single line solution are seen as as larger downside than multi-line labels were. But I'm closing the feedback on this now 😄. This decision has been made and we are always free to implement it differently if we wanted.

[facelessuser]

I will say, the Tabbed extension has not necessarily abandoned the old way. That is still too be decided, which is separate from whether Material provides default styling for it

[squidfunk]

Material for MkDocs never supported all Python Markdown Extensions. We support a large subset of them, but for some not the entirety of available options, like for example line anchors etc. However, @facelessuser does a very good job explaining how you can add them to your documentation. We might add support for more features gradually, but we will probably never support all of them.

This is an opinionated project. I understand that it generates a website that you want to give to your users, and when that website doesn't match 100% of your expectations, you want to change things because it represents your brand. However, so do all other users. I'm trying to provide sensible defaults, but it's absolutely impossible to make everybody happy.

Recommended read:

• Author's notes – How this project is maintained #2399