views:

102

answers:

5

I used to believe that you should not insert javascript blocks

<script language="javascript"> 
<!-- 
//--> 
</script> 

into the body part of a (what, HTML, XHTML?) document, but rather into the head.

But is that still true?

+2  A: 

But is that still true?

It is a matter of good/best practices. HTML and Javascript should be separate. This is even knows as unobtrusive javascript/code.

More info at wikipedia:

Unobtrusive JavaScript

Although this is a good practice, but you can still put javascript at any part of the page, however you should avoid this as much as possible.

Some advocate that javascript should only go at the end of the page, for example they seem to say that is is better in terms of SEO (Search Engine Optimization) as well as performance as denoted by @David Dorward in his comment.

Sarfraz
It's usually for reasons of performance, not SEO. script elements are blocking, and if they are in the head and a lot of time is spent downloading them, then the visitor is sat looking at a blank page for a while.
David Dorward
@David Dorward: Good point and agreed, that's it logically, should add in answer thanks
Sarfraz
+1  A: 

But is that still true?

I'm not sure it ever was. Are you thinking about <style> CSS elements? Because those are illegal in the body.

But it is usually the better choice to put Javascript code into the head or a separate script, and wrap it in a document.ready or onload event.

However, in-body Javascript can have its place, for example when embedding external JavaScripts that document.write() stuff into the document. Top-modern, bleeding-edge Google Analytics relies on a <script> segment being inserted into the very end of the body.

Unicron
may be `<style>` is illegal, but it also works just fine in all modern browsers.
zed_0xff
@zed it still is invalid, and can cause visual problems because styles may be applied after elements are rendered. It's not a good practice to use.
Unicron
A: 

According to Yahoo, for the best performance it's recommended to put any script tags at the end of your document just before the closing html tags:

http://developer.yahoo.com/performance/rules.html

Google suggests using a deferred method to load scripts:

http://code.google.com/speed/page-speed/docs/payload.html#DeferLoadingJS

But they should almost always be script calls to an external .js file. There are very few occasions where it's better to have the .js embedded on the page.

DHuntrods
+1  A: 

Script in the body (not links to external files) is like putting CSS in the head--people move toward separating it so that they can have the markup and logic separate for clarity and ease of maintenance.

I'm a big fan of the document ready feature of Jquery...but that's just personal preference. A dom loader is really the only way to guarantee loading is going to be identical between the various different browsers. Thanks, Microsoft!

I say use common sense...it's not worth doing another file for a single line of code...or even two. If we all went to the extremes that best practices sometimes ask us to go, we'd all be nuts.....or at least more nuts than we are now.

bpeterson76
And what happens if you use $(document).ready(function() inside the <body>? Note: I'm not concerned about inlining the script or outsourcing it to an external file. just about when to bring it up.The reason is quite trivial: sometimes you would like to use values you render in the process of creating a page in a script. Like, say an e-mail-encoder like http://hivelogic.com/enkoder. Or some form validation features. Then it could be hard to put it all into the <head>, as output may have started already.
Urs
Well, in my mind, both of those are good candidates for client side, pre-process type functions either via loader (best) or stand alone (works most of the time)I nearly always use the document ready inside my body tags, because my header and footer are dynamically generated before the browser gets to my code. In my specific case, I use this for validation: http://www.position-absolute.com/articles/jquery-form-validator-because-form-validation-is-a-mess/ I suspect you could easily fire something like enkoder using a value from getElementById onsubmit().
bpeterson76
A: 

It's not recommended because if you try to access elements in the body itself (i.e forms, fields, etc) since they may only become available once the entire body has rendered. However, it's a valid and actually very common practice.

Artilheiro