Make WordPress Core

Opened 12 months ago

Last modified 8 months ago

#60064 new enhancement

Edit no-js CSS in bundled themes

Reported by: shawfactor's profile shawfactor Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version:
Component: Bundled Theme Keywords: dev-feedback
Focuses: Cc:

Description (last modified by sabernhardt)

The CSS directive in style.css of the Twenty Fifteen theme

.no-js .main-navigation ul ul

should be altered to this

html.no-js .main-navigation ul ul

As other plugins like buddypress add their own no-js classes to the body which can cause conflicts. I have raised this with them directly:

#buddypress9033

This could be widened into a broader ticket on a standard way of adding no-js classes that themes or plugins could follow as right now some add it to the html and some to the body class

Change History (4)

#1 @shawfactor
12 months ago

  • Summary changed from The no-js css rule in twenty fifteen should be more specific to The no-js css rule in twenty fifteen and twentysixteen should be more specific

This occurs on twentysixteen as well, probably other themes

#2 @sabernhardt
12 months ago

  • Component changed from Themes to Bundled Theme
  • Description modified (diff)
  • Keywords 2nd-opinion added
  • Summary changed from The no-js css rule in twenty fifteen and twentysixteen should be more specific to Edit no-js CSS in bundled themes
  • Type changed from defect (bug) to enhancement

The bug is in BuddyPress 12.0.0, not the themes, and that should be fixed in 12.1.0.

While the BuddyPress 12 bug would not affect all 1,917 themes that use a .no-js selector, it probably changed the display in hundreds of them. In addition to Twenty Twenty-One, which removes the no-js body class when JavaScript is enabled, the 12 themes that target `html.no-js` should not break. Any similar bugs that might occur in a future plugin theoretically would be easier to find in one of the bundled themes than in one of the others.

The CSS Coding Standards encourages to "refrain from using over-qualified selectors," though sometimes it can be necessary. When it is, adding an explanatory comment usually is helpful.

Increasing the specificity could break sites' custom styles added later in the cascade. That probably is very rare with the display property of these elements, but it's still possible.

If it's worth hardening the bundled themes against future bugs with the no-js class, it could affect three of them.

Twenty Fifteen adds the class on the html element, and the stylesheet uses .no-js to expand any submenus in the main navigation.

.no-js .main-navigation ul ul {
	display: block;
}

Twenty Sixteen also adds the class on the html element. Its stylesheet uses .no-js to show the main navigation, expand any submenus, and hide the menu toggle button.

.no-js .site-header-menu {
	display: block;
}
.no-js .main-navigation ul ul {
	display: block;
}
.no-js .menu-toggle {
	display: none;
}

Again, Twenty Twenty adds the class on the html element. Its styles use both .js and .no-js, but the .no-js class is only used on the search toggle button within the header.

.js .show-js {
	display: block !important;
}
.js .hide-js {
	display: none !important;
}
.no-js .show-no-js {
	display: block !important;
}
.no-js .hide-no-js {
	display: none !important;
}

Twenty Seventeen likewise adds the class on the html element. However, the stylesheet relies on .js instead of .no-js to determine whether to show or hide elements.

Twenty Twenty-One adds the .no-js class on the body element and then its script removes the class instead of replacing it with .js. The stylesheets use .no-js to hide the dark mode toggle button when that is enabled.

	.no-js #dark-mode-toggler {
		display: none;
	}
Last edited 12 months ago by sabernhardt (previous) (diff)

#3 @sabernhardt
12 months ago

  • Description modified (diff)

#4 @karmatosed
8 months ago

  • Keywords dev-feedback added; 2nd-opinion removed
Note: See TracTickets for help on using tickets.