In a discussion elsewhere on SO, I was informed that "[m]ost browsers will not execute inline javascript... these days." This is news to me, and I have been researching to try to verify this statement, in order to understand if I need to adjust the code on some of the websites I maintain in order to make them patible with future browsers.

As far as I can tell, the menter is referring to Content Security Policy, a relatively new proposal that would, if implemented, restrict or totally disable inline scripting.

However, I note:

• This requires the use of a (currently optional) HTTP header or meta-tag equivalent, which I doubt any webserver will ever be able to send out by default.

• The browser support for it is currently limited to the latest & greatest, especially on mobile.

• Nothing in this indicates (to me) that 'most browsers' will not serve inline JavaScript at all, nor that they are planning to implement such a thing in the future.

My question is basically, am I wrong about #3? Is inline JavaScript support likely to be on the way out?

Incidentally, I ask this on SO because I think it might be a "practical, answerable problem that is unique to software development." If others believe this is too broad or belongs somewhere else on SE, I would like to hear your suggestions. Thanks in advance!

In a discussion elsewhere on SO, I was informed that "[m]ost browsers will not execute inline javascript... these days." This is news to me, and I have been researching to try to verify this statement, in order to understand if I need to adjust the code on some of the websites I maintain in order to make them patible with future browsers.

As far as I can tell, the menter is referring to Content Security Policy, a relatively new proposal that would, if implemented, restrict or totally disable inline scripting.

However, I note:

• This requires the use of a (currently optional) HTTP header or meta-tag equivalent, which I doubt any webserver will ever be able to send out by default.

• The browser support for it is currently limited to the latest & greatest, especially on mobile.

• Nothing in this indicates (to me) that 'most browsers' will not serve inline JavaScript at all, nor that they are planning to implement such a thing in the future.

My question is basically, am I wrong about #3? Is inline JavaScript support likely to be on the way out?

Incidentally, I ask this on SO because I think it might be a "practical, answerable problem that is unique to software development." If others believe this is too broad or belongs somewhere else on SE, I would like to hear your suggestions. Thanks in advance!

• javascript
• standards

• 8 Whomever told you that "most browsers won't execute inline javascript" was wrong. – zzzzBov Commented Mar 12, 2014 at 17:20
• CSP has nothing to do with inline JavaScript. On the contrary, it specifies from which domains the page is allowed to download and execute scripts. Or we have a different definition of "inline scripts". – Felix Kling Commented Mar 12, 2014 at 17:22
• @zzzzBov Agreed. Whoever is using one of these browsers would have an incredibly difficult time browsing the web. There are even some inline scripts on this SO page. – David Sherret Commented Mar 12, 2014 at 17:22
• While Inline is not bad, it can be a bit of a pain to read depending on how much you put inline. That's more-so just a coding etiquette though, to make it more readable. – Fallenreaper Commented Mar 12, 2014 at 17:23
• 5 I stand corrected! Anyways, the point is if you own the page, you can do whatever you want by setting the right policies. If you write a library instead, you can't use inline scripts anyways. "Additionally, some implementations will not respect unsafe-inline." Then they would break the web. Changes like this have to be backwards patible. If there are environments where this isn't respected, then you can assume that using inline scripts there isn't relevant anyways. The page you linked to is related to Chrome extensions. – Felix Kling Commented Mar 12, 2014 at 17:29

3 Answers 3

There are hundreds of millions of web pages out there that would stop working if inline javascript was disabled by default. A browser that does that would have to be very brave.

Backwards patibility in browsers is a good and a bad thing (just think about IE!). A bad thing, because they could be lighter and quicker if they didn't have to support legacy code, and a good thing, because, otherwise, hundreds of millions of useful webpages that no one maintains any longer would be almost lost.

Think that no browser, even when using HTML5, will enforce strict rules for HTML, so I doubt inline javascript will be disabled. And even if there is introduced a way to do it, you, as a developer, will have a way to disable that option (or even better, not to enable it).

That said, I'd be the first to enable it in my own websites, because I hate inline code. My advice: never use it except if strictly necessary.

Like the ment said, whoever said that is wrong.

However, you should still stop using inline JavaScript (exception, frameworks like Angular) because it's poor practice. Concerns should be separated. For instance:

<someElement onlick="func()">Derp</someElement> // this is bad.
someElement.addEventListener("click",func,false); //this is much better

It's easier to read, and in larger apps, it's much easier to maintain, especially in a separate file.

It will still act the same, yes, but in my experience I have encountered many more problems debugging inline js than I did external scripts.

Browsers will execute inline JavaScript

All browsers will execute inline JavaScript provided they have JavaScript enabled. Whoever told you this was wrong.

Browsers will likely continue to execute inline JavaScript by default.

Inlining JavaScript is the easiest way to make a piece of script occur at a particular point in the page. The internet is democratic. You don't need to be a puter scientist to hack together a renderable HTML page with some blinking text and a dancing penguin. This is how the web is supposed to be.

Also, sometimes it is useful to be able to pass through a content managed JSON object from the HTML to a static script. Any browser that removed this would bee instantly less useful, and people would migrate away.

Issues with inline JavaScript (why this is actually a good idea)

Allowing Inline JavaScript makes cross site scripting (XSS) attacks fairly easy. The attacker enters some JavaScript into a web form, perhaps a ments box, and the server then renders that script to the page. The script can then do things like steal login credentials or redirect to another page containing malware.

Currently XSS must be dealt with on a per server basis, and it's actually harder than you might think as there are many ways to execute script. Implementing a simple header element that turns off inline script would be a much easier way to guard against all XSS.

It's best practice not to use inline JavaScript if possible

You should think twice about using inline JavaScript. Separation of concerns (HTML5 for meaning, CSS3 for styling, JavaScript for behavior) remains good practice. It's tidier and easier to maintain. Also, by separating your JavaScript into a separate file, you gain the benefits of caching. The script will not need to be downloaded each time a page on your site is viewed.

Optimising for pure speed

The exception to this is if you are optimising for speed. Placing your script inline at the end of your file will ensure your content is visible as soon as possible. This is a technique that Google are fond of. I don't hold with it personally as it makes your code messy, but it will render the page content slightly faster.