Hello everyone! I want to start a conversation with the Wikia Community about a family of extensions I call "tabbing" extensions. A tabbing extension is a tool that divides page content up into tabs instead of H2 and H3 sections. See the image to the right for an illustration of what I mean.
At this time, Wikia has three tabbing extensions in our codebase. All three have some strengths and honestly all three have some fundamental flaws. I believe it is in Wikia's best interest to begin consolidating these extensions into a single extension - whether that means simply dropping support of the other two, re-writing significant portions of one extension, or trying to start from scratch all together. From a support and usability standpoint, it makes little sense to continue to try to fix each extension piece-by-piece.
So, an overview of what Wikia currently offers:
Tabber - Pros: Allows the content within the tabs to live within the same page. Allows for multiple tabs. Cons: Little customization ability for tabs. Can not set different default tab. Does not accept template parameters.
TabView - Pros: High levels of customization for tab design and tab functionality. Cons: Requires the content of the tabs to be stored on other pages, which makes maintenance difficult. AJAX methods are archaeic, which is leading to poor performance and even some browsers stopping to render the tool.
HeaderTabs - Pros: Third-party extension maintained by very active code reviewers. Simplest syntax and allows for linking directly to a tab. Cons: Configuration is mostly done on the backend level, so users would have to file a support request for design changes to be made on a wiki-by-wiki level. Needs tweaking on Wikia end to function, we only have it available on internal test wikis at the moment.
So ... in terms of discussion, here are a few questions:
What extensions do you use on your wiki?
What do you like about the way your tabbed pages are designed? What ways do you find yourself limited with the same extensions?
Do you have a unique way you try to use these extensions? Do you use in an infobox? Or a navigation template?
Is there a "wishlist" you have for tabs?
While I can't promise we can meet every feature request or remove every design flaw of these extensions, gathering user feedback will genuinely help us determine in what direction we want to go with tabbing extensions, so please give us all the thoughts you have about the matter. Tabbing is a great way to share information, especially with smaller and smaller mobile devices that make long pages bothersome, so we want to ensure we can support a productive extension that will meet user demands as devices and information display methods change over the coming years.
I've recently tried to implement Tabber on my w:c:wolfenstein with disappointing results (see w:c:wolfenstein:Guard) I only recently got around to that, and never knew there was more than one extension.
I tried to use Tabber with my enemy infobox, but this failed and I had to resort to a more brutish method to get it to work. The main reason was that my {{{1}}}s and {{{2}}}s and the like didn't want to parse if they were inside of the tabs.
To make {{{1}}} parse inside of a tabber, it has to be called as a parser function instead. What this mean, is it will look like {{#tag: tabber| Tabber stuff here }} instead. (you can read more here)
For what it's worth, the tabber looks fine on Guard.
I like tabber an lot because it's in fact the only one where you can change it totaly css unlike the others. There is an template version for tabber so it's really usefull. The only downside to this one is that it doens't support headertags. So when you use links it won't switch automaticly to the correct tab what's really frustrating. Also when you combine the template and the non template version it's possible to get sub-tabs, even it's not supported template sided. That can be usefull sometimes. Verry usefull for level lists: Example
The second tabview is also verry usefull to list subpages. Our users love this system for our Eggs and Stadium page. This however will not work for all pages since it's can't load scripts. Tabbers or other extensions will not work with this one. He would be perfect if he can do this since he loads the pages after and not directly.
The last I use in combination with Tabber to get tabs inside tabs on an template level. The best thing about this one is that he support tag links and will automaticly switch to the correct tab. Downside is that it won't work on the page itself.
I think the Tabber is currently the best extension out there and will be perfect if:
Fully config css
Css classes are supported
Tabs inside Tabs
Tag links work and switching to the tab (even on the page itself)
More function support for templates
Option to also load pages like the tabview system (maybe with an preload/aftherload option.
template "<h1tab></h1tab>", "<h2tab></h2tab>"
wikitag tag "-=header1=-", "-==header2==-"
I think there is currently none of these extensions that is good enouge to work inside an infobox. None of them where possible to fully controle the css and adjust them how I wanted to. In order to make it usefull for infobox css classes need to be supported for tabs and tag link need to work so you can create buttoms on other places. There also need to be an option to switch the tab without redirecting to the locations.
We use tabview on animanga main page, each tab has a lot of info so it would be a hassle to do it all on one page, also setting the default tab is important.
On other wikis, I've used tabber for simple infobox-like switching, in this case have the data on the same page is easier.
So a tabbing system that allows for theme customization and default tab, and allows tab data to be either included or in a template would be best. I personally haven't found a reason for passing parameters, maybe someone else has an example.
Parameter function is usefull when some of the tabs are not needed for example with that example of the infobox. Some of them maybe only need 2 tabs and other need 4 or 5. Than in that case template parameters can be usefull.
An other example is an navtemplate that list the data of an fell categories in tabs. Some of them need to list more categories than others.
Something that you have not mentioned in your Pros and Cons:
Tabber loads all tabs when the page is accessed.
Tabview only loads the active tab, and requires you to click on the other tab to load the content of that tab.
This means that if you have expensive content that isn't necessarily used frequently (such as a page of buildings with the same basic functions, but different images and statistics on each tab), only the primary tab loads and therefore you have faster pageloads with Tabview than Tabber.
I have tried both Tabber and TabView.
The wikis I edit use TabView for infoboxes, page content, and navbars.
The wikis I edit also use Tabber on a few of the pages, mostly for general content, but sometimes for infoboxes.
I can see a purpose for both extensions, but if I had to choose only one, I would chose TabView.
Rappy 4187 wrote:
To make {{{1}}} parse inside of a tabber, it has to be called as a parser function instead. What this mean, is it will look like {{#tag: tabber| Tabber stuff here }} instead. (you can read more here)
For what it's worth, the tabber looks fine on Guard.
It looks fine on that page because I used a far less eloquent solution than I'd hoped: writing out the entire <tabber></tabber> in the middle of my |image=. This as opposed to using the nice little eloquent parameters-for-individual-tabs solution which I'd previously implemented in the infobox itself, only to discover it wouldn't work.
Having said that, I'll look into this #tag business soon enough, thank you for bringing it to my attention.
I just hope the other 2 will remain there until all other functions are provide from the other 2. Merging tabber and tabview see to go really easy. Some specific points.
Is a pure CSS tabber using :checked not viable currently? It wouln't have the issues of all the tabs loading like tabber does, doesn't rely on AJAX like tabview and is going to be far more customisable and easily accessed that header tabs. It's supported in ie9[1] and I noticed another blog mentioning ie8 support was being phased out.
As for a wishlist, I'd like to see some sort of standardised switch infobox. Not every wiki has a js/css guru available and finding someone to maintain the relevant scripts isn't always easy.
Tabber is currently in use at Elder Scrolls Wiki, mostly implemented by me. But only because I didn't knew TabView existed. I ran into quite some issues with Tabber, especially when styling it. Parsing parameters was another issue, good to see it addressed on this page. I'm giving TabView a try to see if it's a better suit for TESWiki's needs. I wouldn't mind losing the Tabber widget as it won't be much work to replace it.
Cåm wrote:
Is a pure CSS tabber using :checked not viable currently? It wouln't have the issues of all the tabs loading like tabber does, doesn't rely on AJAX like tabview and is going to be far more customisable and easily accessed that header tabs. It's supported in ie9[1] and I noticed another blog mentioning ie8 support was being phased out.
I'd say no. A lot of people are still using IE below version 9 (like 7%, last time I checked).
Edit - that said, an extension using IE conditionals to present a js version on unsupported browsers but a CSS-only version on the newer ones sounds like a good solution.
We use Tabber in the Young Justice Wiki and I'm quite satisfied with it. It serves its purpose, which is supposed to be a simple one, and while customization is limited, it is quite enough to make it look pleasing.
Personally, I don't like any of the options. We mostly only use TabView on WoWWiki, but it is a pain to maintain. I think Tabber is the easiest to work with, but it does have its limitations. I don't think HeaderTabs will get much use, since it requires to much waiting on Wikia.
Are there any other options that haven't been explored?
I don't think having to put information on separate pages would be that big of a problem if someone really wanted tabs. Personally, I prefer longer pages because I can float content out around the "recent activity" and "photos" boxes that you shove onto every page (even for wikis devoted to a text subject and whose only real images are basically for test questions).
I'm the only person on my Wiki that uses any of these. I use the TabView. I had a longer page and wanted to condense it down to hide some info that the causal profile viewer might not have wanted to see. I love the idea but having to edit all the pages separately is more troublesome. If there was a way to have all the info on one page but displayed into the same tab form, that would be a huge plus.
Why not just use have tabs link to section names and use CSS to hide the rest of the sections when a tab is clicked? Thus, in the source of the page the default tab view would be the top of the page (bit before the TOC, before any sections). Everything on all tabs for a page could be edited in the source at once, tabs can be given any name that's desired, templates would all work just as they normally would, there'd be nothing further to maintain, no extension would need to be installed anywhere. I'm not seeing the downside of this method.
FYI, you can use transclusion with Tabber to put tab contents on separate pages. However, it will still load the contents of the tabs on page load. Having the tab load on demand is not great if the tab is slow to load, so it is really only better if you have less content also.
Fandyllic wrote:
FYI, you can use transclusion with Tabber to put tab contents on separate pages. However, it will still load the contents of the tabs on page load. Having the tab load on demand is not great if the tab is slow to load, so it is really only better if you have less content also.
I disagree. Having the tab load on demand is great if the tab content is slow to load, because you don't have to wait forever for all of the content to load, every time you visit the page. You only have to wait for that particular tab to load. This shortens page loading time considerably.
Cåm wrote:
Is a pure CSS tabber using :checked not viable currently? It wouln't have the issues of all the tabs loading like tabber does, doesn't rely on AJAX like tabview and is going to be far more customisable and easily accessed that header tabs. It's supported in ie9[1] and I noticed another blog mentioning ie8 support was being phased out.
I'd say no. A lot of people are still using IE below version 9 (like 7%, last time I checked).
Edit - that said, an extension using IE conditionals to present a js version on unsupported browsers but a CSS-only version on the newer ones sounds like a good solution.
In Kirkburn's most recent blog, he mentions IE8 support will be dropped relatively soon:
We plan to drop full support for IE8 in the near future. Released almost four years ago, it has now fallen far behind other browsers in many aspects.
I assume there will be some measure of backwards compatibility, but dropping IE8 support allows things like moving the wiki-nav to CSS using :hover (an excellent example would be Pecoes' Wikimarks) reducing the possibility of the javascript having a small syntax error and breaking the entire thing. Sure, CSS can still have syntax errors, but unless someone renames the classes it should be more or less fine.
Maybe I'm a little javascript-wary, but if there's a pure CSS way of doing things I'll take it every time. It's much harder to 'turn off' CSS and I see far fewer CSS bugs on Wikia than I do javascript, and CSS errors can be far more blatant even if I can't see them in Chrome's console.
Quick fyi,
I use 'tabber' and it can easily do tabs within tabs,
The only annoying thing is I'd like to change with it is to allow the use of images or other {{Test}} functions for the tab names themselves.
It just need to support classes. Currently it's terrible and has no support. In fact there full css is an mess and hard to override without the correct tag.
I'm in active phase of studying potential of tabbing extensions.
I think that Tabber is better implemented than TabView, but I agree with the opinion, that TabView is great for large expensive content. So I think it would be great, if there is possibility of loading content/pages in Tabber not only all-at-once, but also by demand like in TabView.
I have problems with TabView.
1. TabView makes sortable table unsortable. Example:
What do you mean, "Tabber... Cons: Little customization ability for tabs. Can not set different default tab. Does not accept template parameters."
Why would you need to try to send template parameters into the tab? If you give me some examples, I can probably figure out how to do what you want by using regular templates which then dump whatever into a tab thing, possibly. So, what exactly are you trying to do, what's the problem?
Tabber
Pros:
Allows the content within the tabs to live within the same page
Allows for multiple tabs.
Cons:
Little customization ability for tabs.
Can not set different default tab.
Does not accept template parameters.
Pros: Yes and Yes, Cons: Minimal, Always The First Tab Defined and there is a kludge to make it accept parameters.
{{#tag:tabber|
<!-- December -->
{{#ifexist:Project:Data/Traveling Merchant/{{{1|}}}/Dec|Dec={{Project:Data/Traveling Merchant/{{{1|}}}/Dec}}{{TM-Tabber-Editbar|{{#ifeq:{{#time:Y/M}}|{{{1|}}}/Dec|Edit|{{ucfirst:{{lc:{{{2|}}}}}}}}}|Dec|{{{1|}}}}}|{{#ifeq:{{#time:Y/M}}|{{{1|}}}/Dec|Dec=<Div align="centre" >[http://clashofthedragons.wikia.com/wiki/Project:Data/Traveling_Merchant/{{{1|}}}/Dec?action=edit§ion=new&preload=Template:Traveling_Merchant Click Here to Add - Dec {{{1|}}}]</Div>}}}}
{{!}}-{{!}}
<!-- November -->
The partial example above, shows it is able to accept two different options for a Dec tab depending on if the file to be transcluded existed or not, additionally the tranclusion carries a second table to define the embedded pages edit bar.
The trick to this is to not define the Tab Name= outside the query, so that only the query result is passed as Tab Name=Tab page to display or Tab Name=Other tab page to display.
Rather than Tab Name= query Tab page to display or Other tab page to display which breaks Tabber.
Just found the issue with Tabber tabs being non customizable.
The renderer uses htmlspecialchars to stop malicious scripting but... This also stops: wiki templates, divs, spans, and br_eaks from working.
If these could be filtered out prior to htmlspecialchars and replaced after, I believe tabber would then have div customizable tabs including images links etc.
I would love customizing the colors and the design. I like the second one a lot. I wish it would be easier to do the tabbers, since the coding is crazy for them. That's just about it.
Make it better looking, let us customize, making it easier to write.
Webkinz Mania wrote: I use the first one and I do not like it one bit.
I would love customizing the colors and the design. I like the second one a lot. I wish it would be easier to do the tabbers, since the coding is crazy for them. That's just about it.
Make it better looking, let us customize, making it easier to write.
Webkinz Mania wrote: I use the first one and I do not like it one bit.
I would love customizing the colors and the design. I like the second one a lot. I wish it would be easier to do the tabbers, since the coding is crazy for them. That's just about it.
Make it better looking, let us customize, making it easier to write.
Wait What...?
- Give us colors and options for the tabs.
- Make the coding simpler. No more
and |- and stuff.
- Customize it for the ways we want it.
Hello! Wikia Staff has been watching this thread closely the last few days, but we've tried to post minimal replies to let the community add as much feedback to the intial questions as possible. Now that we've slowed down the feedback, it's time to start grouping up the feedback into community wants and needs.
Here is a list of what seem to be the five most tangible community requests:
Fully configurable CSS
An easy, design-friendly way to nested tabs within tabs
An extension to both: tab information on the page and tab information on a different page
Allow setting the default tab
Quick page loads and quick tab loads
What do you think? Is there a 6th "clear need" we're missing? Are the five I posted as important to you all as I think they are?
I am also beginning to put the unique use cases into a document we can use for design presentation and future testing. Thanks for your examples!
Category filters (hide or display only mw-page, mw-subcategories, category-gallery and/or content
For pages content or discussion section (maybe outdate but comment section could also be something)
Full script support both loading as on page itself.
There also some good ideas listing on the extension talkpage [1]
Maybe as last point: Link controle:
Links that can switch tabs but won't redirect (work both for text as images)
Link taht can switch tabs but also redirect to it (work both for text as images)
Example:
[[#tabname]] move to location on the page and if needed the tab automaticly switch.
[[pagename#tabname]] move to location and if needed the tab automaticly switch.
[[~#tabname]] switch the tab but you won't change position.
Another last thing is support of sidetabs. That is possible with css but some support could be usefull like an default class or something.
Also the possibility for the tabs themselves to be images or image Div.
Or for truly customizable tabs you could do a Div display class with a button ID list, and a Button class that takes the display Div ID's this would then allow for multiple Tabbed layouts from one extension.
Top Tabs, Side Tabs, Tab selectors in the section headers and even an infobox with the tab buttons to change the rest of the displayed page (Transclusion on selection, or similar.)
DaNascat, the following would be an amazing list. If all those points were hit, I don't think anyone would be upset (well, other than having to redo pages to use whatever the next syntax is, if a change there is required). I think the vast majority of tabbsters who tab their tabs would rejoice.
Fully configurable CSS
An easy, design-friendly way to nested tabs within tabs
An extension to both: tab information on the page and tab information on a different page
Allow setting the default tab
Quick page loads and quick tab loads
Thanks DaNASCAT for the summary. A prototype with features from your list would be great! In general if we had a tab display solution that was clearly supported by a skilled developer that would be a good start. From that point we would at least have the promise of future improvement, so that getting all that we want at first wouldn't be as necessary.
Master Ceadeus 27, if the tab names or image headers were able to be whitespace-nowrap that should prevent the tabs from breaking apart.
Additionally, setting them to a default height (adjusted for images) would allow for 1 tab line per row when overrunning a single line, rather than distorting as per the example given.
Tabview is near perfect. I want something very much the same as it with the following changes:
It needs an [edit this tab] option to the right of the tabs.
It would be nice if we could set it so that instead of an open tabs name going bold it could become a link.
It should be possible to use it to load only a section of another page.
The last point would allow tabview to be entirely done within the local page, provided you hide the code for each tab from view and then link to the tabs code (but excepting the code that stops it being visible). Right?
One quick question; can you use tabview within a tab? That would be helpful.
I'm using both Tabber & TabView, and these two pages from my wiki - Trade goods & NPC Production are the example that uses heavily on those two extensions.
From what I've experienced each has its own purpose.
I think Tabber is good to small info tab within the page, but once the info is getting bigger the edit page becomes clutter & need great concentration to edit.
And then that's where TabView come in. But TabView has another benefit if wiki using heavily on templates. It reduces greatly the template include size to avoid the template limits & it increases page loading speed.
The page that having that benefits are London & Amsterdam compares to Lisbon & Marseilles which is not using TabView.
So now I've two wishlists for these two Tabbing extensions:
When using Tabber, I can edit just a part of a tab more like section edit.
Tabber or TabView can work with ImageMap Extension. For example in Marseilles page I can click the icon on the map then it'll send me to that section. But instead it will activate the related tab for London page.
So thank you for discussing this to the community :)
Because of how we set things up at South Park Archives, I may be more apt to like Tabview. Not only do we already have tab content on separate pages, but tabview seems to load content much faster. The only problem I have with tabview is the customization. I would really like to be able to add styles to all the unselected tabs, and style to the selected tab, or to each tab individually.
It does seem like a combination and eradication of all three might mess up a few Wiki's templates. I keep seeing extensive use of Tabber on Wikis, as well as TabView on many Character pages. HeaderTabs...I don't like the idea of having to request style changes for it, when I could just use Tabber and change it with a Wiki's local css.
all: All content from all tabs will load add the start of the page
none: All content from all tabs will not load add the start of the page until you click on an tab. Ones switched to another tab the content will be unload again. For example 0-0-0-0 to 1-0-0-0 to 0-1-0-0.
none-selected: All content from all tabs will not load add the start of the page until you click on an tab. Than all tabs that where active remain loaded. For example 0-0-0-0-0 to 0-0-1-0-0 to 1-0-1-0-0
none-active: All content from all tabs will not load add the start of the page with exeption of the active tab. For example 1-0-0-0-0 to 0-0-1-0-0
active: All content from all tabs will not load add the start of the page with exeption of the active tab. Than all tabs that where active remain loaded. For example 1-0-0-0-0 to 1-0-1-0-0.
tab-1-2-5--9: Only tab 1,2,5,6,7,8 and 9 will load add the start of the page.
delay-30: Content of the tabs will have an 30 second load delay vs the loading of the page.
forced: Content of the tabs will have priority to load before the other content from the page.
Note: This parameter is only for loading the content of the tabs, not for displaying it or marking the active tab. Simply said it are advance controles to speedup the loading time from an page.
An last advance option could be marking it for an specific tab:
For example: "active-4" and combine the marks like "active-4-delay-30" or "active-4-forced"
A sincere thanks to everyone for your feedback. The volume of interest we received on this thread was wonderful both because it does genuinely show the interest of our community in these types of extensions and provided a good variety of opinions & use cases. I am going to un-highlight this thread now since Rappy and I have combined the "short list" I posted in this channel last week with a more comprehensive list of examples & requests from this thread and will soon be making a formal pitch to our Community Engineering team. Hopefully we can see some changes a few months down the road. Getting the community feedback now is the best way we can ensure a useful and user-friendly tool down the road.
@DaNASCAT: Can you or Rappy do a blog on the short list you are pitching to the engineering team with some odds that each item will be implemented soon, possibly within the year, or farther out?
Also could you give a link to the short list you posted already? I can't find it.
It's in this thread:
Here is a list of what seem to be the five most tangible community requests:
Fully configurable CSS
An easy, design-friendly way to nested tabs within tabs
An extension to both: tab information on the page and tab information on a different page
Allow setting the default tab
Quick page loads and quick tab loads
Tabber is used extensively on the MSPA Wiki, while simple tags can be used for the tabber, if you want nested tabs (which we use on the wiki) you need to use the full code for all nested tabs, it would be nice if simple tags could be used at all the time instead of having to vary between the tags and the entire complex code.
For now, I'm fine with H2 and H3. If there were a way to specify the extensions for only certain select pages, I'd consider it. Portfolio pages about project history might have a good use for these, especially if every tab can include an SVG icon. If I ever reinstate Utterly Sims, I might find use for tabs that way also. Specific project articles, however, wouldn't need tabs for their sections. They work fine with H2 and H3, since the point of them is to be Wikipedia-like concerning that specific project in my history.
Tabber loads everything directly, while TabView loads on call. (Also the subpage-vs-pagecontent thing, but that is minor and directly related.) Different options fit for different purposes. I like the difference and the choice I have right now. WikiaTabs best still offer both solutions!
I've seen them around, butI haven't actually used any of them yet myself - couldn't really tell you which one it was in most cases.
We don't have much use for tabs on the Huntik Wiki, but I've considered using something like this on the Magi-Nation Wiki since that might be a lot easier for displaying character information.
So I'll basically say what we're contemplating doing. Virtually every human character is portrayed completely differently in the 3 primary media (TCG, Gameboy, and TV Series). This ranges from different backgrounds to different home region (called "Moonlands") to gender changes. The intro would, in most cases, be about the same with generl info about the character throughout all media. (Also at the top of the page would be a revamped sort of 3-columned infobox.) What would be great would to be able to have a tab below that to be able to shift between TCG, GBC, and TV tabs. In some cases, an individual tab would be about the equivalent of a full article.
I'm probably one of the more code-using individuals on the Magi-Nation Wiki, but I haven't dealt with any of the tab features apart from observation. Probably one of the first questions I'd have with the changes is what would be the ease in using them and editing, particularly as many of our users who wander in are already confused by more basic templating and formatting? Would there be potential issues as this would potentially be used on somewhere between 33% - 50% of the mainspace articles?
On the Resident Evil Wiki we employ significant usage of <tabview> and <tabber>. The "TabView" is used to separate larget articles that exceed 50k in size, while "Tabber" is used to compare the several-hundred in-game file articles with their original, Japanese transcriptions and offer translations.
On the Marvel: Avengers Alliance Wiki, we use <tabber> and <tabview> extensively. "Tabber" is used in pretty much ALL our enemy pages to list the different attack lists they use and the differing stats the have per their appearances, as well as a number of other pages scattered throughout. "Tabview" is a popular feature with the users for their pages.
I do wish they were a little easier to customize. I have some troubles figuring out which css tags define which elements in the tabs code so I can change the look of them. It takes a lot of trial and error to get it looking right.
For Skylanders with special variants, legendary forms, or multiple incarnations, on the Spyro Wiki we use tabs a ton. They are used to divide galleries among different versions and incarnations, characterboxes, etc.
Probably the best example of this on the Spyro Wiki. Another example.
I've sent it higher but I'll post it here for the record ^^.
TabView right now is using action=render for AJAX request which is... not so great.
MediaWiki API's action=parse is much better for this job. It allows to render specific code, not only the page. Using the page specified in TabView as template will fix <noinclude>, <includeonly> and <onlyinclude> tags.
The most important thing is the title parameter. Using it, content can be rendered as if it was transcluded on the given page. Meaning:
Bold selflinks will work as intended
{{PAGENAME}}, {{FULLPAGENAME}}, etc. magic words will return values of viewed page not the tab subpage
Basically using the API not action=render will result in TabView displaying the same thing Tabber below does.
At the bottom you can find links to both rendering methods - the API ones are slightly less readable to naked eye but if you got that far I guess you'll manage ;).
We tried to use two of the tabbing extensions about two years ago on the Phineas and Ferb Wiki and had to give up because they just didn't want to work. The Simpsons Wiki uses a template to generate the tabs that lead to the sub-pages. There were originally five different tabs for each of the five pages relating to an episode, but I was able to consolidate that down to one template with a switch to select which tabs to display.
I recently ran into a major -for me- problem while using Tabber and Tab View in combination, which I posted about here as well as sent in a proper bug report for. The support told me about this proposed overhaul, so here I am with a couple of things I would like to add as well.
- I hope that whatever is chosen in the long run that it properly renders in browsers written for Mac OSX. Right now both Tab View and Tabber work separately, but when Tabber is rendered within Tab View the content of the tabs renders but not in the Tabber boxes. See here for an example.
- This is probably never going to be a main consideration and would most likely be a pain in the neck to implement due to Tabber's nature, but Tabber doesn't work when implemented within a list's list item.
Example:
*content1
**subcontent1a
**<tabber>
First Tab Title=
subcontent1b1
|-|
Second Tab Title=
subcontent1b2
</tabber>
*content2
Renders this:
content1
subcontent1a
subcontent1b1
subcontent1b2
content2
Scratch that it doesn't even render at all in a forum post. Please, see here for what I meant.
I actually just made my own tabs for specific pages. It's part of a wrapper for those pages, and it's all wrapped up in a template. While the idea of an automated process seems kind of nice on the surface, it means that I don't have complete control over how it looks and how it functions; so I simply will keep doing this stuff by hand. The downside is that it takes longer, but the upside is that if I ever want to change how my tabs look, it'll be a quick and easy edit and I know they will come out looking the way that I want or need them to.