Feature Request: Browser History Support

What do you mean by browser history support?

The plugin already supports being able to specify which tab is open on page load via the url. See the section of the plugin page documentation entitled Controlling which tab is open when linking to the page:

You can use a ‘target’ URL parameter to set which tab will be open. The value of this parameter is based on tab title specified in the tabby shortcode with punctuation & special characters removed and with spaces replaced by dashes.

If you want to link to a ‘contacts’ page with a tab titled ‘Phone Numbers’ open, the url you use to link to this page would look like:

https://yoursite.com/contact/?target=phone-numbers

If you want a tab with the title ’email addresses’ to be open, the url would look like:

https://yoursite.com/contact/?target=email-addresses

I meant having it where clicking on a tab updates the URL of their browser. That way they can use the back/forward buttons in their browser to go through the tabs (also, navigating away from that page & then going back in their browser history would return it with the last tab they were viewing still shown). Likewise, you can use that URL to allow someone to share the URL and make it open the tab they were currently viewing (more on this below).

Regarding having it open a specified tab… the ?target= option allows someone creating links to specify the tab. I guess I meant it where someone can navigate to a tab (not necessarily the one that’s loaded at the start)… copy the URL from their browser, share that URL with someone, and then have it so the person that clicks on the link is taken to that specific tab they were viewing.

You could use something like hashchange for handling this (in addition to looking for the hash at first load for those that were given the link to a specific tab).

That isn’t currently possible. I don’t have any plans to add this, but I might look into it when I have some time.

Would there be a recommendable way in which we could propose/send you a code change if we were to implement this feature for the plugin?

I suppose we could reply to this forum topic if that works.

If it can be done without adding a lot of code so the plugin doesn’t get unnecessarily bloated, and doesn’t impact any of the existing functionality I’d consider adding in the changes. I guess posting any snippets here referencing the line numbers that need to change should work for small amounts of code.

Okay, this only required 1 line to be edited & 10 short lines to be added (6 if you don’t count comments/formatting).

I’ve saved the resulting tabby.js as a whole here: https://gist.github.com/KZeni/1d7e360b561c6e8bfdbd
You can view the changes here: https://gist.github.com/KZeni/1d7e360b561c6e8bfdbd/revisions

This utilizes onhashchange and will natively support IE8 and newer.

Let me know if you have any questions or concerns. I could see some people might wanting this to be an option, but I didn’t want to dive too deep into making changes to the plugin right away.

I’d really appreciate this being added to the plugin officially so we can still use this plugin while having this feature that we need to utilize on site(s) of ours. Also, I’m sure we’re not the only ones that might want this feature. Thanks!

Thank you KZeni. Your changes work very well, however my testing has identified just one potential issue in cases where a page contains multiple tabgoups, and in which some of the tabs have the same title text.

Any tabs with the same name in different tab groups will all open together whenever one of them is selected. I can imagine that this behaviour could seem a little weird and possibly confusing to the user.

If an amendment to your changes can be made to target the tabs by a unique identifier rather than the tab title to prevent this from occurring, I’d be very pleased to add this to the plugin and credit you in the documentation for the feature.

Thanks again

Thankfully, that was quick & easy since tablistcount was readily available where it was needed.

Here’s the version with this implemented: https://gist.github.com/KZeni/1d7e360b561c6e8bfdbd
Showing the minor change: https://gist.github.com/KZeni/1d7e360b561c6e8bfdbd/revisions

EDIT

I thought of a clean & simple way of only including the tablistcount in the URL if needed (only include on tab lists with a count greater than 1). This way pages with only one Tabby instance don’t have numbers thrown in when they aren’t needed, but it’s there when there are multiples in order to prevent a conflict.

Latest: https://gist.github.com/KZeni/1d7e360b561c6e8bfdbd
Again, showing this latest update: https://gist.github.com/KZeni/1d7e360b561c6e8bfdbd/revisions

Thank you!

Thanks again. I’m afraid this didn’t make it into v1.2.0 which I had planned to go live tonight and now has, however it should make it into the next version.

Thanks for the new version of your ammendment. I’ve had a chance to do some further testing.

An issue I have discovered is that the tab titles are now wrapped in an anchor, this concerns me as it results in the titles being styled by any rules in the theme stylesheet targeting links within the content – such as text-decoration, border-bottom, color etc.

This change also means that the styles for the titles set in the Tabby Responsive Tabs Customiser add-on plugin will become broken.

I will need to make some CSS changes to both plugins and thoroughly test before the amendment can be included.

I totally support this!

Do you think it will be implemented in the next version and if so, when does the next version launch?

An immediate problem I encountered with the revised code from KZeni:

1. If a url is created by clicking a tab – when the browser is force refreshed the plugin stops working.

Wishes:

1. Would be great to have dashes “-” instead of +’s in the url creation. Also, the last plus at the end of the url seems unnecessary?

2. When urls are created, they are created on the “.a”, not the “.li” or otherwise and this makes it so that when you click on the tab, it doesn’t necessarily create a url unless you directly click on the text.
So while the tab changes, the url doesn’t if you click on the actual tab.

Anyways, I hope it gets implemented soon with cleaner URLS and some fixes!

I appreciate the work KZeni put into this, however I currently am not planning to add this feature to the core plugin as it results in changes to the markup of the tab titles. Additional rules can be added to the plugin’s default css to compensate for these changes, however the plugin has has nearly 30,000 downloads to date, and many of the people using it are using their own custom styles, or the customiser add-on. If the markup changes after a plugin update, the custom CSS already used on these sites will no longer style the tab titles correctly.

@nico Collu, using the latest version of my changes from 2 months ago (https://gist.github.com/KZeni/1d7e360b561c6e8bfdbd) should work if you refresh a page as it should return them to the previously opened tab. Also, it shouldn’t be adding an extra plus at the end either (at least it isn’t when I use the latest version of the change).

Also, I decided to use pluses as I didn’t want to confuse it with being a part of the main site URL and follows Google’s (among others) URL scheme for spaces. Maybe it’s a design decision worth changing if you let me know what your thinking is for changing it to dashes.

When it comes to using <a> tags… we’re linking to specific content on the site that changes the URL when clicked. Wouldn’t it be weirder if we weren’t to use an <a> tag for this? Also, you just need to style the <a> tag to fill the entire space of the parent <li> so clicking on any part of the tab also triggers the <a> tag. That’s just part of having the design be fleshed out to fit your needs.

If you want to see what I’m talking about, you can see how I’m using the updated version of the plugin here: https://www.gcrcf.org/about/publications/#videos

Oh, and I’ve updated the js/tabby.js file so my changes work with Tabby 1.2.0! You can view it here: https://gist.github.com/KZeni/1d7e360b561c6e8bfdbd (revisions can be seen here: https://gist.github.com/KZeni/1d7e360b561c6e8bfdbd/revisions)

@cubecolour, couldn’t you update the css/tabby.css file to include styles to make the <a> tags inherit the color, font-weight, text-decoration, etc. of the li/parent elements? Also, you can include a notice in the plugin update screen so people using this plugin know that they should check their styling after updating to accommodate the new <a> tag that goes along with this new feature addition. I’m just trying to think of ways that this important feature can be added with limited/no headaches ??