The <noscript> element as a trap

# The <noscript> element as a trap Source: [https://hacktivis.me/articles/no-noscript-element](https://hacktivis.me/articles/no-noscript-element) One of the few traps of the web is how the`<noscript\>`element doesn't provides the right behavior\. Definition: The`<noscript\>`element provides alternate content when JavaScript is entirely toggled off or entirely unsupported\. Sources: - [HTML4 § 18\.3\.1 The NOSCRIPT element](https://www.w3.org/TR/html4/interact/scripts.html#h-18.3.1)with ignoring non\-JavaScript in`<script\>`\(W3C gives Tcl as example, I'd more point to JScript and VBScript, both of which are thankfully gone\) - [WHATWG HTML \(multipage\) § The noscript element](https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element) While the way to obtain the right behavior is to have a generic textual element being updated/deleted by your own script using the DOM APIs\. You could also make the scripts so optional for you to not need to provide a failure message, but that's not the right method when the scripts are needed for actually using the webpage\. And should be noted that WHATWG HTML contains a similar recommendation to the latter method: > The`noscript`element is a blunt instrument\. Sometimes, scripts might be enabled, but for some reason the page's script might fail\. For this reason, it's generally better to avoid using`noscript`, and to instead design the script to change the page from being a scriptless page to a scripted page on the fly, \[…\] Because the problem is, JavaScript can fail to load in several ways\. Here's a non\-exhaustive list of cases: - Blocked domains/URLs, think adblockers/anti\-viruses or corporate firewalls - Blocked browsers/users, think hosting\-side firewall \(at any of the IP/TCP/HTTP/… level of encapsulation\) which can be legitimate, over\-zealous, or accidental - Basic connectivity issues, after all browsing using mobile data is usual, HTTPS configurations still routinely presents expired certificates, BGP/DNS/… still fails - Unsupported APIs or even language syntax, either due to a browser not supporting bleeding edge features or non\-portable features - Badly restored website backup or incomplete one - Badly deployed website update, think HTML updated before JavaScript or even an incomplete deployment - Part of the hosting infrastructure being down or overloaded - Limits from the hoster, like rate\-limits or limits on total bandwidth I see most of the above on a regular basis, about multiple times per week to few times a month, and I tend to browse simple websites\. And that's without counting the various ways scripts tend to fail at properly handling errors\.