What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 131 Stack Exchange communities.

The question is not about how <noscript> works, and why it's used, I'm fully aware of that.

Knowing that:

  • <noscript> only works when JavaScript is disabled by something browser-related (the browser itself or an extension). It doesn't work when JS is disabled by a firewall, for example.
  • A one-line alternative to <noscript> exists (using, well, JS) and covers every aspect of it + the above-mentioned firewall-ish case.

After a few Google searches, the number of people talking about alternatives to <noscript> and those trying to find reasons not to use <noscript>, makes me think there might be something wrong with <noscript>.

How come awesome websites such as Stack Overflow and Twitter are using <noscript> tags instead of the well-known alternative everyone seems to prefer?


The alternative is along those lines:

<script>document.write('<style>.noscript { display: none; }</style>');</script>
<div class="noscript">Y U NO JS ACTIVATED?</div>
share|improve this question

migrated from stackoverflow.com Apr 26 '12 at 20:01

This question came from our site for professional and enthusiast programmers.

28  
Why would they use this alternative when there is a native HTML element for this? In my opinion, using this "alternative" requires justification, not the other way around. –  Oded Apr 26 '12 at 20:03
3  
@Oded: Because (as the question states), if JavaScript is blocked by a firewall or an extension (like NoScript), the <noscript> tag won't work. This is because JavaScript is enabled in the browser (so, the <noscript> tag is ignored), but the script itself is blocked (so, it doesn't run). –  Rocket Hazmat Apr 26 '12 at 20:05
16  
I'm guessing because Nick Craver simply has more interesting / important things to work on, and likely never considered this edge case. –  Adam Rackis Apr 26 '12 at 20:06
9  
@Rocket - Users behind such a firewall or those that use NoScript would be aware of the issue they have with JS in general. –  Oded Apr 26 '12 at 20:06
2  
Let's hope he does, @Adam. He's said numerous times that the team is not interesting in optimizing for the case of users who have JavaScript disabled. That is not a supported configuration, and you turn this off at your own peril. –  Cody Gray Apr 26 '12 at 20:07
5  
I used NoScript on Firefox for a long time. Whenever I ran across a page that didn't look right or something on it didn't work, I naturally assumed that JavaScript was needed for it and, in most cases, promptly closed the page. :) –  animuson Apr 26 '12 at 20:08
1  
Hey, thank you for helping, but please don't fight. I'm asking that because the noscript/JS alternative is a question that seems relevant to a lot of people, so I was wondering WHY websites like SO chose to use noscript. If it's because the firewall case is really an edge case, then ok (though using one line of JS instead of <noscript> isn't really time consuming) –  Pioul Apr 26 '12 at 20:15
2  
@animuson - I assume you stopped since, eventually, you found yourself closing most websites? –  Adam Rackis Apr 26 '12 at 22:46
2  
@AdamRackis: Nah, I started using Chrome. –  animuson Apr 26 '12 at 22:47
    
Edit because the question is getting downvoted like hell, so I guessed I expressed myself poorly and needed editing. As for the answer, agreed, it shouldn't be here, it's now removed. (About your explanation, I agree with you and understand what you meant, but I'm trying to stay as close to the original question as possible: "is noscript bad or not?") –  Pioul Apr 27 '12 at 11:21
    
(No sweat about downvotes on Meta. I still feel it should not have been migrated, but I guess the title caused that.) –  Arjan Apr 27 '12 at 11:44
    
Okay. I feel the same, since almost no other people than you have been of good help here ;) –  Pioul Apr 27 '12 at 12:11

4 Answers 4

up vote 5 down vote accepted

Stack Exchange is also warning one (using JavaScript) if it detects that jQuery has not been loaded from the googleapis.com CDN.

It seems to me that the combination of <noscript> and the jQuery detection covers most problems with corporate firewalls and browser settings/plugins. (And I even feel it is one better than just checking for JavaScript being blocked, as then still blocked downloads would go undetected.)

Sure, using the jQuery detection together with the proposed alternative would also cover situations where some software might somehow block JavaScript execution. But I wonder if the dynamically hidden text would then be indexed (and appear) in search engines.

But if that text is not a problem, then using the <div> might be a nice enhancement to detect if Stack Exchange's sstatic.net CDN is blocked. If that's blocked, the jQuery warning will not be given either. So with the <div> in the page source but the JavaScript that hides it in an external file downloaded from sstatic.net, one can easily detect any blocking. (Like Jukka explained in their answer it might then be better to not rely on styles either, but that's easily changed.)

(I fail to see how the alternative can detect JavaScript downloads being blocked in firewalls—which, in my limited understanding, block network traffic. But I assume that some security software running on workstations might indeed somehow make browsers stop executing JavaScript.)

share|improve this answer
    
About search engines, for all I know, <noscript> is indexed by SE too (though Google is doing it more scarcely now due to spammers). Anyway, putting the <div> at the end of the page makes it a lot less valuable from a SE point of view. –  Pioul Apr 26 '12 at 22:39
    
About firewalls blocking the download of .js files, I see your point, and agree. It's something I saw here and there, so I just thought some firewalls were meddling with browsers in a way that disabled JS... But from a network point of view, the alternative method can't detect blocked downloads either, that's true. –  Pioul Apr 26 '12 at 22:42
    
So, to sum that up, your point would be that 1/ There's not apparent use to that alternative method 2/ SO uses <noscript> + a jQuery detector and that's enough to be safe. Thank you! –  Pioul Apr 26 '12 at 22:44
    
Well, if there really are (many) cases where software is stopping browsers from running JavaScript, while that not being detected by <noscript>, then there surely might be a use case. I don't know. As an aside, the jQuery detection is loaded from sstatic.net, so if that is blocked, then the nice notifications fail too. But that has not been high priority either. –  Arjan Apr 26 '12 at 22:47
    
Okay then. For the case we're talking about, I just assumed it was happening at least to some people since that's what I kept reading, but if I'm asking this question here, it's because that's just an assumption. One that seems to be wrong so far... –  Pioul Apr 26 '12 at 22:53
2  
(Actually, I think the migration to Meta was wrong, but as the team is very knowledgeable, you might even get a better answer here!) –  Arjan Apr 26 '12 at 23:03
    
Okay! The migration surprised me too, but like you say, if they know about what motivated that decision, it might be even better! –  Pioul Apr 26 '12 at 23:16
    
Oh, I thought I got your point, but I didn't (your edit allowed me to). Clever thing it is, though that way it will flicker. But I like this answer, and it's answering my original non-meta question, so I'm accepting it. Thank you for your help! Now the question is, is it worth caring about people behind such firewalls or not? (knowing that they must be kind of aware of their problem) –  Pioul Apr 27 '12 at 12:18

One moment there:

only works when JavaScript is disabled by something browser-related (the browser itself or an extension). It doesn't work when JS is disabled by a firewall, for example

So you want us to defensively code our site because you suspect there are firewalls out there that strip out SCRIPT tags and neglect to blank out the NOSCRIPT tags?

We are going to need a much more definitive, proven, argument about a real problem before hacking up our site and abandoning the use of the NOSCRIPT tag.

share|improve this answer
    
Like i said to @Arjan, this use case was an assumption from what I read. And from what you (and @Arjan) say, it seems I misunderstood what I read: it happens that firewalls block JS files downloads, but they (hopefully) never strip <script> tags from documents. –  Pioul Apr 26 '12 at 23:31
2  
a firewall that "disables js" would have to strip script out of the document, otherwise you would end up with half working pages due to inlines –  waffles Apr 26 '12 at 23:32
    
Now about your answer, I feel kind of attacked here, but I in no way asked this question suggesting SO was doing something bad that needed fixing, that's why I asked it on SO instead of Meta, I wanted to know if there was a downside to using <noscript>, and if yes, what motivated SO's choice (among others). –  Pioul Apr 26 '12 at 23:34
    
So what you're saying is that my assumption about firewalls doing MORE than just blocking JS files from downloading was wrong. And thus there's no downside to using <noscript>? –  Pioul Apr 26 '12 at 23:36
4  
I think it is fairly safe to assume your assumption there is wrong, from basic googling I can not even find any documentation about js disabling firewalls or proxies –  waffles Apr 26 '12 at 23:42
1  
This guy talks about it here stackoverflow.com/a/993461/408173 and points to some links too, but I guess he misunderstood the issue too, firewalls blocking JS files from downloading but not disabling JS per-se. –  Pioul Apr 26 '12 at 23:52
1  
Still then: if @Pioul's alternative would be driven by code from an external JavaScript file, say http://cdn.sstatic.net/js/stub.js, then it could easily alert one if sstatic.net is blocked. The existing code that checks if jQuery is available is also in JavaScript resources from sstatic.net, hence if that domain is blocked one currently does not get any warning about jQuery either. (It should then not use <style> to hide the text, but that's another detail.) –  Arjan Apr 27 '12 at 8:28
    
That's true, and even if it goes beyond the goal of <noscript>, it could be of use for sure! –  Pioul Apr 27 '12 at 11:24

To answer the “why” question: because the noscript element is common legacy and often used routinely, typically just to show a message that tells the user to enable scripting. This can be useful enough in very special cases, like pages mostly used by developers and other people who actually switch scripting off and on.

Regarding your proposed alternative, it has the drawback of displaying “Y U NO JS ACTIVATED?” when scripting is enabled and stylesheets are disabled (or a special user stylesheet is in use, overriding the setting used). To replace noscript by JavaScript code, it is better to use code that actually removes the content of an element, or an element as a whole.

share|improve this answer
    
Thank you for your answer. About the alternative, what you're saying is true, but it would result in some flicker, the element being shown before being removed. This is the only reason I was using styles instead of removing the whole thing. –  Pioul Apr 27 '12 at 9:10
    
But, @Pioul, in your case the element is shown too before it's removed? –  Arjan Apr 27 '12 at 10:21
    
It's not, when JS is activated, the inline script is executed, providing the browser with .noscript { display: none }, and then it renders the div, automatically hidden because of its class –  Pioul Apr 27 '12 at 11:06
    
Ah, that might very well be true, @Pioul. (I am not 100% sure it works that way, but it might indeed. That said, a combination of your method and that of Jukka does no harm, I guess.) –  Arjan Apr 27 '12 at 11:17

The thing of beauty in <noscript> is simplicty and Its pretty obvious.

The question is whether this

<script>document.write('<style>.noscript { display: none; }</style>');</script>
<div class="noscript">Y U NO JS ACTIVATED?</div>

Or this

<noscript>Y U NO JS ACTIVATED?</noscript>
share|improve this answer
1  
Are you suggesting the result of both methods would always be the same? The above "is pretty obvious" is not proving that at all. (And I doubt they are always the same. And both are quite simple, I feel.) –  Arjan Apr 27 '12 at 8:06
    
@Arjan, Seriously?? The top is not that simple my friend. Use a profiler to see what I mean ;) –  Starx Nov 4 '12 at 3:49
    
Again, you're not proving anything! Like, now that you're mentioning profiling: how does the first affect the full execution time of a site that uses a lot of JavaScript? (As an aside, also your sentence "The question is whether this [...] or this [...]" is missing some text.) –  Arjan Nov 4 '12 at 7:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .