2

A few years ago I was employed to develop web front-ends for client applications to W3C/AA compliant standards. I was told that CSS, JS and other non-visual/non-presentational content should ALWAYS be kept in the head tag.

Example

<!DOCTYPE html>
<html>
<head>
    <link type="text/css" rel="stylesheet" href="site.css" />
    <script type="text/javascript" src="jquery.js"></script>
    <script type="text/javascript" src="site.js"></script>
    <script type="text/javascript">
        $(document).ready(function() {
            // Code here...
        });
    </script>
<head>
<body>
    <div class="container">
        ...
    </div>
</body>
</html>

This approach has always worked for me, but In my current role I've been asked to move the CSS and JS references all to the bottom of the document for performance/execution reasons

Example

<!DOCTYPE html>
<html>
<head>
    ...
<head>
<body>
    <div class="container">
        ...
    </div>
    <link type="text/css" rel="stylesheet" href="site.css" />
    <script type="text/javascript" src="jquery.js"></script>
    <script type="text/javascript" src="site.js"></script>
    <script type="text/javascript">
        $(document).ready(function() {
            // Code here...
        });
    </script>
</body>
</html>

I was told that doing this didn't break any compliance or acceptability standards and allowed the site to load faster in some cases, however this caused more problems than it fixed.

Therefore I would like to know if I should stick by my decision to keep these resources in the head tag, or, on the other hand if there is any compelling argument for having resource tags at the bottom, or scattered about the document?

Matthew Layton
  • 39,871
  • 52
  • 185
  • 313
  • What kind of problems did the second example caused? I usually put the `scripts` on bottom like the second example. And the `stylesheets` on the `header`. Though, I don't know what the best practices are. – azhpo Nov 11 '14 at 11:12
  • @azhpo, moving the script files to the bottom caused ALL of the functionality on the page to break. My understanding of jQuery's .ready() function was to allow the scripts to execute only once the DOM had completely loaded, thus allowing scripts to remain in the head. As for CSS styles, SVG elements glitch horribly when CSS is applied to the end of the document. – Matthew Layton Nov 11 '14 at 11:14
  • "any compliance or acceptability standards": Does this include or exclude formal/syntactical HTML5 rules (i.e., does it matter if the document would be invalid)? – unor Nov 11 '14 at 13:53
  • @unor include formal/syntactical HTML5 rules...I guess :-/ – Matthew Layton Nov 11 '14 at 13:54

1 Answers1

3

link elements can’t appear in the body element (unless they are used for Microdata or RDFa). So your <link type="text/css" rel="stylesheet" href="site.css" /> has to be a child of the head element.

script elements can appear in the body. It depends on the script and your document if it makes sense to place the script element as last child of the body. See, for example, the questions

If the script element has a src attribute (i.e., the script is imported from an external file), you could use the async and defer attributes to control its execution:

  • async:

    the script will be executed asynchronously, as soon as it is available

  • defer:

    the script is executed when the page has finished parsing

  • default (i.e., neither async nor defer):

    the script is fetched and executed immediately, before the user agent continues parsing the page

  • async + defer:

    cause legacy Web browsers that only support defer (and not async) to fall back to the defer behavior instead of the synchronous blocking behavior that is the default

Community
  • 1
  • 1
unor
  • 92,415
  • 26
  • 211
  • 360
  • Apparently although contrary to the current spec, browsers handle link elements as a child of body just fine. See [this recent discussion on the whatwg mailing list](http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/0265.html). – steveax Nov 11 '14 at 15:30
  • 1
    @steveax - Sure, but browsers handle tons of invalid stuff just fine. The advice not to do it is sound (see Simon Pieters's comments on that thread) so going against that advice is a slippery slope. – Alohci Nov 11 '14 at 16:45
  • Yes, I agree that if you're going to release code the doesn't follow the spec you need to be very careful, but thought the thread was relevant to the discussion given many of the browser implementers were involved. – steveax Nov 12 '14 at 02:47