The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I think that comment puts it into perspective where JavaScript falls in the big picture. A big reason why JavaScript gets a bad rap is because people don't understand when and how to use it. That snippet (hopefully) shows beginners, whom this book is written for, that JavaScript is not the driving force of their website but rather just one small part of it.

Because of the paradigm shift from old style JavaScript embedded everywhere into the page to unobtrusive JavaScript that is entirely in a separate file with no code in the HTML at all such an introduction is necessary so as to set the stage for how to code JavaScript properly. Even beginners will have seen tons of web pages filled with old style JavaScript and it needs to be made clear from the start that such an approach is the wrong way to go about adding JavaScript.

The tags around the embedded JavaScript were a little overdone though unless you are trying to cater for IE2 and Netscape 1 as well as the more modern browsers that all understand what a script tag is.

Is this intro article and indication of the content proportions in the book?

"Simply javascript: The Three Layers of the Web"

60% HTML
30% CSS
10% JavaScript

Seems to be more about best practise rather than something specific to JavaScript.

No, mrsmiley, the rest of the book focuses on JavaScript. This is an introductory chapter showing how JavaScript fits into the grand scheme of things. You can download a PDF of the first three chapters (of 9 total) to get a better idea of the overall content in the book. You might also like to check out the Table of Contents.

I know the article is about Javascript but the intro part about the Html/CSS connection helped immensely in my understanding of how they should work. I am new at this but this article helped me more than the books I have. Thanks a bunch.

Well, this is where the CSS argument has been wrong while being right from the very start. The situation you play out is correct for a static web site. (HTML | CSS | JS) Yet, HTML is actually "content packaging". You see on a dynamic web server (.Net|PHP|ColdFusion|JSP) you will find the content is dynamically generated. In fact the content is what you find wrapped inside the HTML.

So, we should all agree with that. The reason we don't use tables in general is the CSS is not able to manipulate the content packaging.

What's wrong with calling HTML content you ask. (If you didn't ask, let me answer those who truly want to know.) Sometimes you want to do more than just "CSS" your content. Sometimes you may need a separate HTML container CSS mix if you want to truly "SKIN" your sites. Thus the same content becomes flexable beyond CSS because you aren't thinking inside the CSS Box Model! "Thinking Outside The BOX" :) can make your sites even more dynamic, but only if you make separation of content and presentation a server side issue beyond browser abilities. Now brace yourself for my winning argument... let's just look at Flex, AIR and other technologies like that. SOA technologies would be included in consideration. When we tie our content directly to HTML we make the "reuse" of our content extremely difficult. We should be able to let a Flex application consume the same content without having to write the same code twice.

Well, this is where the CSS argument has been wrong while being right from the very start. The situation you play out is correct for a static web site. (HTML | CSS | JS) Yet, HTML is actually "content packaging". You see on a dynamic web server (.Net|PHP|ColdFusion|JSP) you will find the content is dynamically generated. In fact the content is what you find wrapped inside the HTML.

So, we should all agree with that. The reason we don't use tables in general is the CSS is not able to manipulate the content packaging.

What's wrong with calling HTML content you ask. (If you didn't ask, let me answer those who truly want to know.) Sometimes you want to do more than just "CSS" your content. Sometimes you may need a separate HTML container CSS mix if you want to truly "SKIN" your sites. Thus the same content becomes flexable beyond CSS because you aren't thinking inside the CSS Box Model! "Thinking Outside The BOX" can make your sites even more dynamic, but only if you make separation of content and presentation a server side issue beyond browser abilities. Now brace yourself for my winning argument... let's just look at Flex, AIR and other technologies like that. SOA technologies would be included in consideration. When we tie our content directly to HTML we make the "reuse" of our content extremely difficult. We should be able to let a Flex application consume the same content without having to write the same code twice.