Remove JS-conditional classes #3222
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
coliff
approved these changes
Mar 6, 2025
|
Great PR - thank you! I fully agree that this should be removed.. I was thinking about this just yesterday actually. |
|
I missed removing it when I removed Modernizr THANKS! |
|
I might cut an interim release. |
|
@roblarsen - there's a lot of docs stuff I'd like to update... shall we set a 'deadline' to get it updated? next week sometime? |
|
Sounds good. I've got time this week |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently a
no-jsclass is added to the<html>element, which is immediately replaced with ajsclass to allow targeting styles to whether JavaScript is or isn't enabled. This works well however has a few drawbacks:It is mostly incompatible with server-side-rendered frameworks. For example, using a React-based SSR framework causes warnings due to a props mismatch on hydration, so the only safe way to perform the class swapping would be waiting until hydration has completed leading to FOUT.
Requires coordination of HTML and CSS so could not reliably be part of e.g. a CSS-only library or a WordPress plugin without control of the site's theme.
Requires managing an inline script which on its own is additional complexity and also complicates configuring a JavaScript content security policy.
Things have progressed since the class-based approach was developed, and there is now a
scriptingmedia condition available to achieve the same thing without needing any HTML nor JS.The
scriptingmedia condition reached Baseline 2023 support so it is a little on the edge of broad support, however considering the drawbacks of the current approach and the entire principle of progressive enhancement that adjusting styles based on JS availability is built on I think it can begin to be adopted in new projects and H5BP can start directing developers towards adopting it as a new best practice compared to the previous class-based approach.I've added a mention of the new approach to the documentation including examples & references. If this proposal is accepted I can also open a PR in H5BP's
main.cssproject to add an example like the existing responsive media queries if the maintainers are interested.Types of changes
Checklist: