The <noscript> element as a trap
6 points by runxiyu
6 points by runxiyu
I don't really understand this post. What should <noscript> do instead? What's the trap?
I think the argument it's making is that you shouldn't depend on <noscript>, and instead use JavaScript to insert JavaScript-reliant content such that it doesn't display if the JavaScript fails to load for some reason. I'd call that "progressive enhancement". It's a great idea! I don't think you need to frame it as "The <noscript> element is a trap" though.
This post is a bit confusing to me. The author doesn't explicitly state what they deem correct behavior.
It sounds as if the author expects <noscript> to be displayed when there's an error in the JavaScript code or if fetching it fails, even though the spec is quite clear about <noscript> only firing when JavaScript is toggled off or unsupported. These are different scenarios that call for different solutions.
It's a warning that <noscript> isn't as reasonable and versatile as e.g. <img alt>.
It's not a useful fallback, but one of the many half-assed hacks left over from the browser wars.
Parsing of <noscript> is shockingly awful. It's not even behaving like an HTML element. <noscript><a href="</noscript> changes the meaning of the entire page's markup depending on whether the JS or non-JS flavor of HTML is being parsed.
I think there's a semantic role for <noscript> if browsers were inclined to treat it differently. I read this article as saying functionally you might as well have a <div> that the script strips out as soon as it starts running. And, well, I see a lot of sites that do that and they are practically indistinguishable from <noscript>.
There is a pretty old HTML issue Should "script-src 'none'" CSP in HTTP headers count as scripting being disabled? that doesn't feel unreasonable to me. Especially because that is the most obvious way to disable JS for a specific site on any browser from my point of view.