clash of class declarations: class="hidden"

  • When using the default Twenty Fourteen theme > Edit post > Open Screen Options menu in the top > menu appears blank (no form fields display) > I get the following error:

    event.returnValue is deprecated. Please use the standard event.preventDefault() instead.

    It seems the issue is caused by a conflict with CSS class declarations on the Twenty Fourteen theme – specifically, the use of class=”hidden” on several elements which are displayed initially.

    Although the use of this is normal, what is unconventional is the fact that you leave the class on after the element is displayed (visible). When .hidden{} is invoked, it does not include visibility: hidden;

    This causes issues with our plugin, GrabPress, because the CSS libraries we use in GrabPress and Bootstrap both have their own declarations for .hidden, which both do include visibility: hidden; — as what you expect from the .hidden class.

    Overriding this in the plugin does not seem like a logical or smart option either, however we have a publisher who thinks that this issue is due to a problem with our plugin. However, the issue persists even after you deactivate/uninstall the GrabPress plugin, so I know it’s not an issue with our plugin.

    I did however just upgrade to WordPress 3.8.1 (since we just released a version compatible with 3.7.1), and I noticed the issue was fixed. Is there any chance that you can submit a fix for this issue in a Theme update as well? I’m not sure how Theme updates go, just wondering. Thanks.

Viewing 1 replies (of 1 total)
  • Thread Starter grabmedia

    (@grabmedia)

    I want to correct the information in my post – the WordPress 3.8.1 upgrade did not resolve the issue. I only thought it did, when I replicated the fix/upgrade twice. However after starting a new session, I noticed the issue is still present, even in WP 3.8.1. One of our developers took a closer look and found the following.

    In the PHP file where the original state of the HTML for the screen options UI that is experiencing the issue is formed you’ll see that the class=”hidden” is present.
    wp-admin/includes/screen.php (line 917)

    <div id="screen-options-wrap" class="hidden" tabindex="-1" aria-label="<?php esc_attr_e('Screen Options Tab'); ?>">

    They have this class tied up to the following CSS:
    wp-admin/css/wp-admin.css (line 234 thru 243) 

    .hidden,
.js .closed .inside,
.js .hide-if-js,
.no-js .hide-if-no-js,
.js.wp-core-ui .hide-if-js,
.js .wp-core-ui .hide-if-js,
.no-js.wp-core-ui .hide-if-no-js,
.no-js .wp-core-ui .hide-if-no-js {
	display: none;
}

    So you can see that the ‘.hidden’ class (along with several others) has the property ‘display: none;’. This is perfectly fine and normal if they plan to toggle on and off the ‘.hidden’ class from the element. However they instead make use of jQuery’s ‘show()’ and ‘hide()’ methods and leave the ‘hidden’ class.
    wp-admin/js/common.js (lines 99 thru 143) 

    screenMeta = {
	element: null, // #screen-meta
	toggles: null, // .screen-meta-toggle
	page:    null, // #wpcontent

	init: function() {
		this.element = $('#screen-meta');
		this.toggles = $('.screen-meta-toggle a');
		this.page    = $('#wpcontent');

		this.toggles.click( this.toggleEvent );
	},

	toggleEvent: function( e ) {
		var panel = $( this.href.replace(/.+#/, '#') );
		e.preventDefault();

		if ( !panel.length )
			return;

		if ( panel.is(':visible') )
			screenMeta.close( panel, $(this) );
		else
			screenMeta.open( panel, $(this) );
	},

	open: function( panel, link ) {

		$('.screen-meta-toggle').not( link.parent() ).css('visibility', 'hidden');

		panel.parent().show();
		panel.slideDown( 'fast', function() {
			panel.focus();
			link.addClass('screen-meta-active').attr('aria-expanded', true);
		});
	},

	close: function( panel, link ) {
		panel.slideUp( 'fast', function() {
			link.removeClass('screen-meta-active').attr('aria-expanded', false);
			$('.screen-meta-toggle').css('visibility', '');
			panel.parent().hide();
		});
	}
};

    The use of these methods is also okay. The ‘show()’ and ‘hide()’ methods toggle the element’s display value between ‘display:none’ and ‘display:block’. The issue here is that WP used the ‘.hidden’ class to set the default display state and then use the Jquery toggle methods to adjust on the fly. However, this leaves the ‘.hidden’ class out there to snag itself in conflict against any CSS at play that uses the ‘visibility:hidden’ property instead of or in addition to ‘display:none’. Twitter Bootstrap for example, which GrabPress uses and is widely used across the web has the following declaration for ‘.hidden’: 

    .hidden {
  display: none;
  visibility: hidden;
}

    So my recommendation to WP would be to have their JavaScript toggle on/off the class ‘hidden’ from the element rather than leaving it there. To have ‘hidden’ on a unhidden element just makes no sense, even semantically speaking. It might also be good for them to toggle both the ‘display’ property and the ‘visibility’ property of the element.

    I’m going to have to post this somewhere else, as it seems this is a more generic WordPress issue, rather than a specific issue with the Twenty Fourteen theme. This issue also exists in some of the other default/common WordPress themes.

Viewing 1 replies (of 1 total)
  • The topic ‘clash of class declarations: class="hidden"’ is closed to new replies.