blog

no-noscript-element.xml (3592B)

<entry>
<title>The &lt;noscript&gt; element as a trap</title>
<link rel="alternate" type="text/html" href="https://hacktivis.me/articles/no-noscript-element"/>
<id>https://hacktivis.me/articles/no-noscript-element</id>
<published>2025-08-18T11:52:43Z</published>
<updated>2025-08-18T11:52:43Z</updated>
<!--
<link rel="external replies" type="application/activity+json" href="https://queer.hacktivis.me/objects/50be9d37-dee6-4c69-818e-013fa3b010d0" />
<link rel="external replies" type="text/html" href="https://queer.hacktivis.me/objects/50be9d37-dee6-4c69-818e-013fa3b010d0" />
-->
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" class="h-entry">
	<p>
		One of the few traps of the web is how the <code>&lt;noscript&gt;</code>
		element doesn't provides the right behavior.
	</p>
	<p>
		Definition: The <code>&lt;noscript&gt;</code> element provides alternate content when JavaScript is entirely toggled off or entirely unsupported.<br />
		Sources:
		<ul>
			<li><a href="https://www.w3.org/TR/html4/interact/scripts.html#h-18.3.1">HTML4 § 18.3.1 The NOSCRIPT element</a> with ignoring non-JavaScript in <code>&lt;script&gt;</code> (W3C gives Tcl as example, I'd more point to JScript and VBScript, both of which are thankfully gone)</li>
			<li><a href="https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element">WHATWG HTML (multipage) § The noscript element</a></li>
		</ul>
	</p>
	<p>
		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.
	</p>
	<p>
		And should be noted that WHATWG HTML contains a similar recommendation to the latter method:
		<blockquote>
			The <code>noscript</code> 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 <code>noscript</code>,
			and to instead design the script to change the page from being
			a scriptless page to a scripted page on the fly, […]
		</blockquote>
	</p>
	<p>
		Because the problem is, JavaScript can fail to load in several ways. Here's a non-exhaustive list of cases:
		<ul>
			<li>Blocked domains/URLs, think adblockers/anti-viruses or corporate firewalls</li>
			<li>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</li>
			<li>Basic connectivity issues, after all browsing using mobile data is usual, HTTPS configurations still routinely presents expired certificates, BGP/DNS/… still fails</li>
			<li>Unsupported APIs or even language syntax, either due to a browser not supporting bleeding edge features or non-portable features</li>
			<li>Badly restored website backup or incomplete one</li>
			<li>Badly deployed website update, think HTML updated before JavaScript or even an incomplete deployment</li>
			<li>Part of the hosting infrastructure being down or overloaded</li>
			<li>Limits from the hoster, like rate-limits or limits on total bandwidth</li>
		</ul>
		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.
	</p>
</div>
</content>
</entry>