Portability Hub
Portability Hub
What's a tabber, and how are they used in Portable Infoboxes?
The idea of a tabber is that multiple images can be displayed in an infobox using tabs that the user can click on. The infobox displays a tabber only when a <tabber> or <gallery> is used as the field of an <image> tag. The caption of the image acts as the tab label. The tabs are swiped through on the mobile skin.
What's a nested tabber, and do they work in Portable Infoboxes?
Nested tabbers introduce a second set of tabs for images under another tab. However — if you put <tabber> or <gallery> tabs inside one another, only the first tag will be read by a Portable Infobox on any device; Only the first image in the nested tabber will appear.
You can use a <navigation> tag to recreate nested tabbers with the original template used on the wikitext infobox, but they won’t display on mobile correctly. At most, one image would be displayed through the mobile skin; it is possible that no image will appear, depending on the method used.
Can I use JavaScript to solve these problems, rather than <tabber>?
If your tabber template is using JavaScript rather than the supported tags, the result on the mobile skin would be compromised and will not be portable at all. JS can also make the nested tabber not work at all on a Portable Infobox, even on desktop.
This is the result of using JavaScript to alter content (in this case the image) AND presentation (the styling of the tab labels to indicate which is active). As JavaScript is not available on the mobile skin (nor any other future platform other than desktop, as results would be unpredictable), only the first image is displayed (unless the first image is inserted by JavaScript in the first place, as occurs in some user-generated methods).
Why can't I make them work ONLY on desktop?
The idea of portability is that an element on desktop can be shown on all platforms appropriately. As the nested tabber can't be displayed properly for mobiles, it's better to adapt the tabber so that desktop and mobile can both work.
Why is there no native support for nested tabbers in a Portable Infobox?
Nested tabbers are not portable from a design or functional perspective. A Portable Infobox that incorporates nested tabbers would compromise the portability of the infobox at whole, and would therefore not be portable. It goes against the portable philosophy. Functionally, it would be difficult for many devices to interpret.
In the article's source, the nested tabber would rely on a tabber within another tabber. This syntax can be far more intimidating and unintuitive to users than single-level tabbers. This is because the added complexity of placing a nested tag in a tab will break the consistency of the code. As syntax simplicity is one of the key factors in developing portable elements, this is not something the developers wish to encourage.
The JavaScript tabber style is not native to the infoboxes, so it is not introduced to the article with the correct formatting. This makes the images less semantic, so they won't be understood by search engines or loaded from Fandom servers efficiently. The code itself is hard to maintain or expand, as it is complicated and sensitive to changes.
What does it mean to be "not portable"?
The feature will not consistently carry over the supplied content to another platform or device in a meaningful way. Though even the "meaningful way" claim varies on a case-by-case basis, it would compromise the portability of Fandom infoboxes to introduce nested tabbers as the content of an infobox with nested tabbers will not consistently display well.
The change in rendering that the nested level would add to the infobox wouldn't be an attractive layout for mobile devices, as having a second row of tabs is not functional on any device other than desktop. The Mercury skin allows mobile users to swipe through images, which would not work well with nested tabbers.
I have 10 images in one infobox - how do I show them all without nesting?
You can use a <gallery> or a <tabber> tag to show a group of pictures, but 10 images in one infobox is too many. The tabber won't be able to display that number of tabs for each image in an attractive or compact manner without massive CSS. The tabs will overflow onto new lines in the template, increasing the height of the infobox and making the infobox data less prominent. As it is unlikely for readers to click on all the tabs and engage with the images, we recommend that you consider moving the pictures elsewhere on the page. They could go well as article images or on a gallery at the end of the page - both are portable.
How many images should I use at most?
8 tabs in an infobox on Metal Gear Wiki

The Metal Gear Wiki uses 8 different images for this Infobox and the result does not look great on desktop.

Generally speaking, as few as possible. You need to decide which images are really necessary to illustrate the subject. For example, if your character progresses throughout many video games, you can provide an image of the character for each game. However, if the difference between the images is rather small, you might choose to keep only the more important ones in the infobox.
The absolute maximum count of images is often determined by the length of the tabber text. Obviously, you can fit more tabs into the row with numbers or initials than tabs containing three words. The ultimate goal is to achieve something that looks good.
When does something "look good"?
As mentioned above, the goal is to find a solution that looks good. It's a loosely defined term, which actually requires further explanation. Something can look good because it has attractive customization added by CSS. But as we know, we can't affect the Mercury CSS, so the tabbers will look the same all the time. What we can influence though, is the layout itself. You can make shorter or longer tab texts, fewer and more tabber tabs. What matters most in that case is functionality. If you have to scroll to find the last tabber tab on your smartphone, that's probably a bad design with too many tabs. It may look good on desktop, but that doesn't necessarily mean that your tabber will look good on mobile devices. However, if the mobile version looks good, the desktop version will most likely look good too. Keep that in mind when designing tabbers.
Isn't Tabber or Gallery terribly complicated to learn, compared to {{Switch}}?
Actually, most {{Switch}} templates use JS code, which is also complicated to learn, and the code of {{Switch}} templates are often complicated syntax. While you're using tabber or gallery tags, the code is easier to use for your editors (especially new editors), and those editors can have no experience in wikitext templates with difficult code. Using simple tabbers or galleries are more friendly for them, but there are just a few options that are not possible on a Portable Infobox.
As a note, the original developer of Switch has since commented on its use.

Long time ago, I created a "Switch template". This template apparently was copied on various wikis. However, I don't think it's really "efficient" since it's more like a work-around which uses these template and scripts which also are quite "old". The code is complicated and it often creates errors, so I think if someone can create a valid alternative it would be really helpful.