The Element as a Trap(hacktivis.me)
hacktivis.me
The Element as a Trap
https://hacktivis.me/articles/no-noscript-element
20 comments
> is fine as it is, but changing the page after scripts load can potentially mean seeing the no-script content briefly (FOUC - Flash of Unscripted Content). Putting the message in a <noscript> tag avoids that.
These days you can use CSS to only show the message after a short delay.
But the majority of websites have no business actually requiring JS so the W3C recommendation is the only one that matters.
These days you can use CSS to only show the message after a short delay.
But the majority of websites have no business actually requiring JS so the W3C recommendation is the only one that matters.
> These days you can use CSS to only show the message after a short delay.
This sounds bad for accessibility though. Wouldn't the issue stay the same for screen readers or (legitimate) scrapers?
This sounds bad for accessibility though. Wouldn't the issue stay the same for screen readers or (legitimate) scrapers?
I think the viewpoint in the article could be summarized as "noscript is not Turing complete and thus cannot solve all problems with javascript"
> Because the problem is, JavaScript can fail to load in several ways. Here's a non-exhaustive list of cases...
The author answered their own question. In even the best effort case, noscript is the fallback.
I'm not even sure what they expect the website maintainer to do for most of that list. If they knew themselves, they would have put it in the blog post. Is this instead a call to draft new w3c specs or revisions? What am I misunderstanding? For a site that has "hacktivism" in the domain name, whining like this is a bad look.
The author answered their own question. In even the best effort case, noscript is the fallback.
I'm not even sure what they expect the website maintainer to do for most of that list. If they knew themselves, they would have put it in the blog post. Is this instead a call to draft new w3c specs or revisions? What am I misunderstanding? For a site that has "hacktivism" in the domain name, whining like this is a bad look.
I think you're missing the part where they quote the recommendation from the HTML spec:
> 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
That seems perfectly reasonable for modern sites and browsers to be able to do. `noscript` is effectively a relic from older days where you just didn't have the same budgets, tools, and browsers as today, where you couldn't seamlessly enhance the site how you can now. We shouldn't continue to use it in the same way we shouldn't continue to use `marquee` or `blink`.
> 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
That seems perfectly reasonable for modern sites and browsers to be able to do. `noscript` is effectively a relic from older days where you just didn't have the same budgets, tools, and browsers as today, where you couldn't seamlessly enhance the site how you can now. We shouldn't continue to use it in the same way we shouldn't continue to use `marquee` or `blink`.
I feel like <noscript> does a fine job at what its meant to do. The article's complaint is that it isn't magic and can't solve all problems, but nothing can.
No, noscript doesn't do a fine job, because it will be handled incorrectly on browsers that fit any situation like the ones on the article's list of examples.
A tiny minority of people that disable javascript does that in a way that is handled correctly.
But writing a page that works by itself and modifying it by scripts will work almost everywhere as long as you add any external dependency in a way that invalidates your script on errors.
But writing a page that works by itself and modifying it by scripts will work almost everywhere as long as you add any external dependency in a way that invalidates your script on errors.
No, I didn't miss that part. It's irrelevant to my point.
The noscript tag is just a way to conditionally display some HTML. There's no reason to avoid using it unless you are deeply entrenched in a pseudoreligious fight against javascript.
It really is just whining.
> didn't have the same budgets, tools, and browsers as today, where you couldn't seamlessly enhance the site how you can now
I'm sorry, but... what?
The noscript tag is just a way to conditionally display some HTML. There's no reason to avoid using it unless you are deeply entrenched in a pseudoreligious fight against javascript.
It really is just whining.
> didn't have the same budgets, tools, and browsers as today, where you couldn't seamlessly enhance the site how you can now
I'm sorry, but... what?
noscript came before modern CSS, it came before XMLHttpRequest, it was around before a lot of things. It was before we had modern standards and practices around progressive enhancement. A lot of things that are commonplace and easy to do now would require hours and hours of hand-writing javascript, instead of using modern libraries and selectors to easily target and replace content.
I don't know if you were coding back in those days, but I definitely remember how much more work it was to do progressive enhancement back then if you wanted a really JS-enhanced site. We were all basically individually inventing it, because it hadn't be standardized and popularized yet.
I honestly don't understand the framing of best practices here as "whining." I also don't understand your refusal to read the article, because you say "no reason" but the article explicitly states the reason:
> The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail.
I dunno, I like having my page continue to reasonably work when unforeseen errors happen. (And they do happen. We've been at this business for decades, but errors have happened, can happen, and will continue to happen.) I generally prefer my users to have a good experience when possible. And if I can design my page intelligently, to progressively enhance, instead of displaying a blunt "WHAT ARE YOU, A JAVASCRIPT-HATER LOL" error message, well, I'd prefer that. =)
I don't know if you were coding back in those days, but I definitely remember how much more work it was to do progressive enhancement back then if you wanted a really JS-enhanced site. We were all basically individually inventing it, because it hadn't be standardized and popularized yet.
I honestly don't understand the framing of best practices here as "whining." I also don't understand your refusal to read the article, because you say "no reason" but the article explicitly states the reason:
> The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail.
I dunno, I like having my page continue to reasonably work when unforeseen errors happen. (And they do happen. We've been at this business for decades, but errors have happened, can happen, and will continue to happen.) I generally prefer my users to have a good experience when possible. And if I can design my page intelligently, to progressively enhance, instead of displaying a blunt "WHAT ARE YOU, A JAVASCRIPT-HATER LOL" error message, well, I'd prefer that. =)
I'd much rather have something that behaves like:
<if js is available>
...
<else>
...
<the closing tag i guess/>Is that really any simpler or clearer than:
<script>
...
</script>
<noscript>
...
</noscript>I think something like:
<script src="..." id="bla></script>
<noscript for="bla">Script not loaded</noscript>
Yes! That's what I meant. Wasn't able to express it clearly but you did :)
Indeed, <noscript> doesn't show just because the page didn't properly load the scripts in the page. It's not a fallback for errors, it's a fallback to serve users who deliberately disabled Javascript. This is a rare scenario these days, but it does get displayed when you disable JS in Tor Browser, use the disable Javascript button in uBlock Origin (I personally use this to whitelist javascript per-domain), or use various other extensions like NoScript. This is dependent on the implementation, though. In theory some crappy browser extension could provide JS disabling functionality otherwise identical to tor/ublock/noscript but forget to display <noscript>s, but I haven't heard of implementations that are like this.
Either way, make sure you have something sensible to display for all scenarios, even if it's just an error page. Mysterious blank pages are not fun.
Either way, make sure you have something sensible to display for all scenarios, even if it's just an error page. Mysterious blank pages are not fun.
> In theory some crappy browser extension could provide JS disabling functionality otherwise identical to tor/ublock/noscript but forget to display <noscript>s, but I haven't heard of implementations that are like this.
Any no-JS extension worths its salt should actually at least provide an option to ignore <noscript> as some websites that would otherwise work perfectly fine without JS use it maliciously.
Any no-JS extension worths its salt should actually at least provide an option to ignore <noscript> as some websites that would otherwise work perfectly fine without JS use it maliciously.
Not sure if uBlock Origin has a checkbox to turn off <noscript> globally, but since it is an ad blocker, you could just manually add a global filter on all <noscript> tags. Or you could rely on the community's filter lists to remove specific instances of bullshit found in popular websites.
You also have small browsers like Dillio that intentionally don't support javascript https://dillo-browser.github.io/
FTA:
> “One of the few traps of the web”
…for some large value of “few”
> “One of the few traps of the web”
…for some large value of “few”
As far as error handling goes, <noscript> is still far from the worst even with these limitations.
The most infuriating one is when the javascript deletes the entire page content to show an error message due to some exception. Doubly so when the failing functionality is only used for tracking or some other unwanted "feature".
The most infuriating one is when the javascript deletes the entire page content to show an error message due to some exception. Doubly so when the failing functionality is only used for tracking or some other unwanted "feature".
The WHATWG recommendation:
is fine as it is, but changing the page after scripts load can potentially mean seeing the no-script content briefly (FOUC - Flash of Unscripted Content). Putting the message in a <noscript> tag avoids that.