<noscript> is a blunt instrument that isn’t anywhere near as useful as you think it is.
<noscript> is pretty much a feature of the HTML parser. It disappears. The DOM representation doesn’t include a <noscript> element, so you can’t style it. (This is also why you can’t use <noscript> in the XML syntax of HTML. If you don’t know about the XML syntax, I’ll simplify and say it roughly means what was commonly called XHTML.)
What makes it even less useful is that the absence of the <noscript> content doesn’t mean that your scripts are being executed. If you use something like uMatrix or uBlock Origin to block certain types of scripts, for example, you might find that none of the scripts execute, but that the <noscript> content is also not loaded, because it could have executed some scripts, if the right URLs had been requested. Or perhaps the browser was happy to execute JavaScript, it’s just that it failed to fetch the JavaScript, for whatever reason. (Perhaps you put your JS on a CDN, on a different origin, and it’s down.)
In the end, the .no-js approach is far superior to the use of <noscript>.
Apps break even without browser extensions. A huge number of websites try to use localStorage, and do not check for errors. (localStorage will raise if the cookie settings for the UA do not permit storing data.)
I read that as “you can apply CSS to a <noscript> tag”, which is false. Stuff within it, sure. But the <noscript> tag itself vanishes during document parsing.
I maintain my position: <noscript> is nowhere near as useful as it first appears, and should seldom be used.
I would even suggest that, excluding spiders, user agents that don’t run some or all JavaScript will normally be due to browser extensions. This is a fairly niche area overall, and various extensions are the main factor.
To be clear, the noscript tag "disappears" when javascript is enabled in the browser. When javascript is disabled it behaves like any other tag and can be styled accordingly.
Extension can disable scripts selectively but in that case javascript is still considered enabled for the purposes of the noscript tag.
I was indeed wrong about this. I’d grown used to uMatrix’s spoofing, where it does get changed, and misrecollected things. I have now refreshed my understanding from the spec: it’s still a parser feature in that that iff scripting is enabled, it parses its children as raw text (like <script> or the old <xmp>). (And then there’s the user-agent style on it, `display: none !important`, so that you can’t get it to appear whatever you do, unlike most normally-hidden tags like head, title and script.)
<noscript> is pretty much a feature of the HTML parser. It disappears. The DOM representation doesn’t include a <noscript> element, so you can’t style it. (This is also why you can’t use <noscript> in the XML syntax of HTML. If you don’t know about the XML syntax, I’ll simplify and say it roughly means what was commonly called XHTML.)
What makes it even less useful is that the absence of the <noscript> content doesn’t mean that your scripts are being executed. If you use something like uMatrix or uBlock Origin to block certain types of scripts, for example, you might find that none of the scripts execute, but that the <noscript> content is also not loaded, because it could have executed some scripts, if the right URLs had been requested. Or perhaps the browser was happy to execute JavaScript, it’s just that it failed to fetch the JavaScript, for whatever reason. (Perhaps you put your JS on a CDN, on a different origin, and it’s down.)
In the end, the .no-js approach is far superior to the use of <noscript>.