Opened 12 months ago
Last modified 8 months ago
#60064 new enhancement
Edit no-js CSS in bundled themes
Reported by: | shawfactor | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | minor | Version: | |
Component: | Bundled Theme | Keywords: | dev-feedback |
Focuses: | Cc: |
Description (last modified by )
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:
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
@
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
#2
@
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; }
This occurs on twentysixteen as well, probably other themes