WP-Tab css

[WraithKenny]

The classes wp-tab-panel, wp-tab-bar, and wp-tab-active should adjust to side tabs in the post column (to match the behavior of categories for example)

Also, there are several unneeded duplicate css classes that can be cleaned up.

[WraithKenny]

tab cleanup

[WraithKenny]

patch assumes markup usage like so:

<ul class="wp-tab-bar">
	<li class="wp-tab-active"><a href="#tabs-1">Tab 1</a></li>
	<li><a href="#tabs-2">Tab 2</a></li>
	<li><a href="#tabs-3">Tab 3</a></li>
</ul>
<div class="wp-tab-panel" id="tabs-1">
	<p>Tab 1 content</p>
</div>
<div class="wp-tab-panel" id="tabs-2">
	<p>Tab 2 content</p>
</div>
<div class="wp-tab-panel" id="tabs-3">
	<p>Tab 3 content</p>
</div>

[scribu]

+1.

Related: #17699

[WraithKenny]

Tested patch with this plugin ​https://github.com/WraithKenny/Metabox-Tabs on trunk with SCRIPT_DEBUG true.

[WraithKenny]

Most of the duplicate css has been cleaned up by #18314

[WraithKenny]

wp-tab css update without duplication cleanups

[WraithKenny]

patch is refreshed against today's trunk and accounts for changes in #19129 and #18198

[WraithKenny]

screenshot

[WraithKenny]

Just a note, when I originally did the first patch, the wp-tab-* classes weren't complete enough to use without added custom css. Although they now work as is (without this patch), but this patch adds missing styles: the #Normal-Sortable (editor) column styling of the tabs for Category Meta-box (with tabs on the side).

It would be possible after this patch to separate the style classes from the behavior classes on Category tabs (use wp-tab-* classes on the category metabox). The reason authors couldn't simple use the category tabs css classes is because they were being selected for in JavaScript.

This patch also fixes a really minor css error where the a pixel is out of place in the category tabs do to top-right still having 3px rounding on.

[WraithKenny]

It'd be kinda snazzy to include a link.js style jQuery script to handle tab-switching automatically for authors who use the wp-tab-* classes. This way, authors need only write the markup, with the wp-tab-* classes, and they get the whole treatment.

[scribu]

I think that's a good idea. It's annoying to have to write that basic JS every time.

We already enhance other elements, such as checkbox columns.

[WraithKenny]

The generic script to achieve it is:

jQuery(document).ready( function($) {
	// wp tabs
	$('.wp-tab-bar a').click(function(event){
		event.preventDefault();
		// Limit effect to the container element.
		var context = $(this).parents('.wp-tab-bar').first().parent();
		$('.wp-tab-bar li', context).removeClass('wp-tab-active');
		$(this).parents('li').first().addClass('wp-tab-active');
		$('.wp-tab-panel', context).hide();
		$( $(this).attr('href'), context ).show();
	});
	// Make setting wp-tab-active optional.
	$('.wp-tab-bar').each(function(){
		if ( $('.wp-tab-active', this).length )
			$('.wp-tab-active', this).click();
		else $('a', this).first().click();
	});
});

The purpose of doing .parents('...').first() is to allow flexibility in the markup. Incoming patch adds this script, and makes postbox dependent on this script to include it anywhere that postbox is.

[scribu]

.closest('...') is a more efficient way of doing .parents('...').first().

Also,

else $('a', this).first().click();

should be:

else
  $('a', this).first().click();

[WraithKenny]

WP-Tabs CSS and Behaviors

[chrisvanpatten]

This is fantastic. I just started a plugin and was surprised to find there's nothing built in to handle tabs in WordPress already. This also seems much better than the jQuery UI options that seem quite bulky.

I think it's worth mentioning that with this option you need to manually set which tab panel is active (I'm doing this by adding style="display: none" to the non-active tabs). Is this something that the JavaScript could be tweaked to handle auto-magically, so stuff doesn't get hidden from view if JS is disabled for whatever reason? I had a go at it but was getting an ugly flash of content, which is even less ideal.

The category tabs seem to handle this by defaulting to one tab (hiding "Most Used" completely) which works in that situation but doesn't seem ideal for tabs in general.

EDIT: Also, thanks for noticing the border-top-right-radius bug. Even if the rest of these fixes don't get in core that definitely should as it also impacts category tabs in their current state.

[WraithKenny]

If you use the "assumed markup", you shouldn't have to manually set the active tab with anything but a class name. It also should be handling the default active tab if non is set.

I'll refresh the patch again I guess. There was a sort of "core css cleanup push" since the last time. Maybe some of this was taken care of then.

The "flash of content" issue could be handled with the .js and .no-js toggle.

[SergeyBiryukov]

Related: #20570

[helen]

This has been sitting for this long because it's difficult to action on independently without thinking about bigger picture items like components, clean up, and whether we really want to maintain our own mini JS library for it. Closing as maybelater - assuming we can actually get moving on a clean up and modernization of CSS, I imagine this would get fixed along the way eventually.