Summarizing conversations with @westonruter
It is common to have CSS rules to target js
vs no-js
. Certain components need to become hidden or presented differently in no-js
case.
Currently html:not([amp-version])
is one workaround to set specific no-js
CSS rules. This works because v0.js
adds that attribute but it is hacky and if SSR ever decides to add that attribute, it would break the workaround.
Maybe the proper approach is allowing style
in noscript
tag. I don't think it needs to fit the 50k limit either.
@westonruter @Gregable @cramforce
I'd be OK with that, but with a low KB limit. It would only ever be a little additional styling, and a large noscript-stylesheet would weigh heavily on the default case.
I thought content of noscript
don't get parsed with JS enabled. My understanding is that it becomes essentially a hidden text node. Limit is good regardless.
I think allowing noscript > style
is one solution, but it would be preferred from a WordPress context if the no-JS rules could be written in the style[amp-custom]
. In other words, the html:not([amp-version])
is easier to work with. As @sebastianbenz suggests in #17832, what if there is a runtime-ready
classname added to the html
element?
I think key would be to analyze the lifecycle including optimized AMP.
The document can be
Ideally, these can be distinguished and devs can target the earliest stage that works for them to avoid e.g. re-layout once JS eventually loads.
cc @alin04 since this may eventually intersect with the golang packager bug regarding noscript content parsing.
FWIW this is valid html
<head>
<noscript>
<style> ... </style>
<noscript>
</head>
<noscript>
can also contain <link>
. We could allow a link to a stylesheet and cache the sheet if we need to do so to preserve privacy (may not be needed if it's impossible to pre-render in a non JS environment anyway). Using a <link>
would minimize the performance impact on the JS case at the expense of the much less common <noscript>
case.
FWIW this is valid html
~Is it?~
I get validation errors when adding:
<noscript>
<style>body {color:red}</style>
</noscript>
Sorry. You said _HTML_, not _AMPHTML_. My mistake.
Is there still interest in this request? I don't see a resolution to determine a final implementation plan and interest has died off, so for now I'll just close it and we can re-implement.
Most helpful comment
I think key would be to analyze the lifecycle including optimized AMP.
The document can be
Ideally, these can be distinguished and devs can target the earliest stage that works for them to avoid e.g. re-layout once JS eventually loads.