Best IT Recipes

Is it a bad practice to embed JavaScript in the body of HTML?

The team I'm working on is used to using <script> tags in random places in the body of our HTML pages. For example:

 <html> <head></head> <body> <div id="some-div"> <script type="text/javascript">//some javascript here</script> </div> </body> </html>

I have not seen this before. It seems to work in several browsers that I tested. But as far as I know, it is not valid to put script tags in such places.

Am I really wrong? How bad is it that we put script tags in div tags like that? Are there any browser compatibility issues that I should be aware of?

+74
javascript html
May 14 '10 at 22:04
source share
17 answers

This is absolutely true.

You would not want to put large large blocks of code in the markup there (it is better to use external scripts), but this can be useful for:

  • add additional binding information for progressive improvement (where this data is difficult to fit into the class name or another approach to hiding extended information in attributes); or

  • where it is necessary to start script improvement as soon as possible (and not wait for the window / document to load). An example of this is autofocus, which can be annoying if it is too late to trigger.

You might be thinking of <style> elements that are not allowed in <body> (although most browsers still allow it).

+75
May 14 '10 at 22:11
source share

Actually, this is quite common. For example, the Google Analytics tracking code uses only this syntax:

 <script type="text/javascript"> var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); </script>

If it will be enough for Google ...

+11
May 14, '10 at 22:09
source share

This is true and, depending on your server structure and the nature of the code, it is sometimes very difficult to avoid.

+4
May 14 '10 at 10:09 p.m.
source share

really!

you can use:

 <script type="text/javascript"> //<![CDATA[ // some javascrpt code that perfectly validates in the w3c validator //]]> </script>

I don’t think you can tell if this is bad practice in general. You have to say in this case. But I'm sure it's good to have all your JS in one place. This is a little messy if you have small pieces of JS throughout your html file.

+3
May 14 '10 at 22:12
source share

I prefer to put links to external scripts in my head and scripts that launch things and initialize widgets and something else in the body.

A problem that is very easy to work with is that the script element in the body cannot access the elements that appear after it. In addition, the unpleasant browser compatibility issue associated with this is that IE does not allow script elements to modify the element in which they reside. Therefore, if you have this:

 <div id="foo"> <script type="text/javascript"> document.getElementById("foo")... // do something to it </script> </div>

IE will not like your page. Older versions of IE used very cryptic error messages for this or even an empty whole page, but IE8 seems to give a descriptive error message.

As long as you make sure that your scripts have access only to the DOM, which is safe to access, I do not think that it is evil to place script elements in the body. In fact, IMHO, placing scripts that initialize widgets after related items can be more readable than putting them in just one place (and I believe that it can also make them work earlier, which makes things roll less as the page loads).

+3
May 14, '10 at 22:14
source share

As several people have already mentioned, its action really works, and it is widely used.

Semantics guidelines recommend (or at least recommend) placing script tags inside the header.

More advanced best practices that take performance into account recommend placing script tags (external and built-in) in the lower right of the body tag to allow the markup to fully display before any javascript is executed.

To simplify the understanding and maintenance of the code, it is recommended to use "unobtrusive javascript", where the code is in an external file and binds events to the DOM. (Google unobtrusive javascript)

In one case, when it is useful to have built-in javascript, you need to initialize variables with values ​​that exist only on the server side, which will then be used by external JavaScript code.

+3
May 15 '10 at 12:17 a.m.
source share

see yahoo ui for best practice: http://developer.yahoo.com/performance/rules.html (javascript at bottom of page)

+2
May 14 '10 at 10:10
source share

I have not seen this before. It seems to work in several browsers that I tested. But as far as I know, this is not valid for placing script tags in such places.

This is a valid, but not good (or recommended) practice.

Am I really wrong? How bad is it that we put script tags in div tags such as? Are there any browser compatibility issues that I should know?

There is no problem placing <script> under any other elements (but it should be inside <head> or <body> ). There are also no problems in terms of browser compatibility, however, the introduction of JS scripts on web pages presents serious flaws (how / why they are considered bad):

  • Adds page weight.
  • Difficulty (or possibly impossible) to minimize
  • Cannot be transferred or used for other pages.
  • Cannot be cached (must be loaded every time the page loads)
  • Lack of separation of problems (more difficult to maintain)
+2
Aug 21 2018-12-12T00:
source share

This, of course, is legal, I saw it on several pages here, for example, on Exforsys .

Now this is a training site that shows the basics of HTML and Javascript, so in this context it is completely understandable. However, I would not want to see this in production code for anything more than a simple statement or two. Not seeing that you replaced with //some javascipt here , I would not want to comment.

In this case, there should be no problems with the browser.

+1
May 14 '10 at 22:08
source share

However, it’s also good that you know that the JS needed for the HTML section will be for them. Instead of claiming and creating some inclusions at the top of the file.

So, instead of "if you are going to use this HTML code, make sure you import xyz.js", you can just include the HTML code and do with it.

So this is not necessarily a terrible evil. It may not be impressively awesome, but not entirely awful. The view depends on the intention.

+1
May 14, '10 at 22:10
source share

This is perfectly true, although it can damage maintainability. See Also. Where should I put <script> tags in HTML markup? and Why does calling this jQuery function not work in Firefox?

+1
May 14 '10 at 22:11
source share

this is one of many, many best practices that increase productivity to a greater extent, namely, improve your programming approach. ultimately in web development to get the product the most!

+1
May 15 '10 at
source share

I assume that your team does this either because they want to dynamically insert a script, or write a script that will fire when the page loads.

I would not say that there is nothing wrong with it when it is ABSOLUTELY NECESSARY (while it is in the CDATA block), but outside this, I would recommend that your team use a script library such as a prototype or jQuery and save external scripts on the page. This is usually cleaner, and libraries sometimes lead to clean code that, as I would say, is not currently happening.

I will also not run any time-consuming functions in the built-in script tags, as this happens when the page loads, and, as Jason said above, can slow down the page loading. All script libraries have neat features that allow you to do something when the page loads, and give you the ability to load pages when the page loads, for example, after loading dom.

+1
May 15 '10 at 2:04 a.m.
source share

It is permissible to add a body, but IE really does not like it. therefore, to be on the safer side, make sure you have your own scripts inside the tag.

which really created chaos (especially for IE) in the project we are working on

+1
Jul 21 '11 at 7:08
source share

A few things:

  • This is completely correct code.
  • This is completely discouraged.

This greatly slows down the loading of your page, as Javascript must be executed before any other part of the page can render. If you do a lot of work in this Javascript, your browser may freeze. You should try (whenever possible) to load your Javascript dynamically and at the end of your page (preferably before the </body> )

Buy and read High Performance Javascript . This will change the way you write JS.

0
May 14, '10 at 22:11
source share

The indicated recommendation that scripts should be stored in the header is to load the script before it is called. This is only a problem for some event handlers. For other types of script, this does not matter, and for some types (e.g. document.write) this makes no sense.

0
May 14, '10 at 22:13
source share

If you have an editor that can handle both html and javascript at the same time. And if you like to read a few html lines first and then javascript .. sure. go for it.

0
May 18 '10 at 11:51
source share


More articles:


All Articles