In the past, browsers have used various techniques to handle the script contents… and this has had a long lasting effect on the way we use this tag in our current projects. The most abused attribute remains in common use today (even though has been deprecated in HTML 4.01 and XHTML 1.0 Strict) – the language attribute. Instead of specifying the language, it is now standard to specify the MIME type through use of the type attribute – and it is important to note that this is the only required attribute for the script tag.

If you are including some Javascript in the document itself, then you would use a construct similar to this:

<script type="text/javascript">
alert("Hello world!");
</script>

If you are delivering this content in a document that is using an XHTML doctype, then you should comment the data between the script tags (if you are unable to include it as an external Javascript file – see below) so that it is not parsed client-side. In the past you would often see a similar technique in use to “hide the code from older browsers” (note that the following example shows the correct way to use comments in an XHTML document using CDATA):

<script type="text/javascript">
//<![CDATA[
alert("Hello world!");
//]]>
</script>

There is no point using the CDATA comments above in a non-XHTML page at all. Nor is there any value in using the following kind of comments (whether you are working on an HTML or an XHTML document). This commenting was widely used to prevent “old browsers” seeing the Javascript. Nobody uses these “old browsers” for regular web use (and if they did, most web sites that use Javascript would break anyway)… so there is absolutely no point in including the comments:

<script type="text/javascript">
//<!--
alert("Hello world!");
//-->
</script>

If you are including an external Javascript file in the document, then you would use a construct similar to this:

<script type="text/javascript" src="helloworld.js"></script>

The only difference between inline and linked Javascript is that the latter uses the src attribute to specify where the linked Javascript file resides.

When writing well formed documents, you should include information about the default scripting language. This can be done using a meta tag in the document:

<META http-equiv="Content-Script-Type" content="text/javascript">

This is good practice, but is not required – especially if the server is already serving linked Javascript files as “text/javascript” (or more correctly: “text/x-javascript”).

The doctype appears as the very first thing on the page that is delivered to the user, allowing the browser agent to make decisions about how to display the page. Whilst a document can still display within a web browser in the absence of a doctype, defining one implies the document is “well formed” and allows a browser to make assumptions that assist it in rendering correctly. It also prevents the browser from making the wrong assumptions and displaying the document in an unexpected “quirks” mode.

So how do you decide what doctype to use? Again, the W3C have provided a list of recommended DTDs for your document but they don’t offer a lot of guidance to the developer in choosing one. In my opinion it comes down to a question of whether you are creating an HTML or an XHTML document.

Unless you are going to be serving your documents as “text/xml” and loading them into an XML parser to allow your XML tools to manipulate the page, then there is no reason to develop your documents as XHTML. A majority of web pages on the internet are HTML – and this should be the default choice for developing your documents – especially if your web host is serving your pages as “text/html”.

If you are developing frameset documents, then the choice is already made for you – you will use a Frameset doctype. The rest of the time you should consider using a Strict doctype which is almost the same as the Transitional doctype, but with the presentation specific elements removed (deprecated).

The big difference between Transitional and Strict doctypes is the seperation of the presentation and content layers within the document. The idea is that you use CSS to define the layout of your document, and rely on well formed HTML to define the content of the document. This ensures that the different programs that may be used to view your document are able to read the content consistently, and apply the appropriate presentation layer (via CSS).

The Transitional doctype is appropriate if you are working on an existing HTML document that contains presentational elements (like the <center>, and <font> tags). These tags were totally acceptable for the older HTML 3.2 definition (where the presentation and content layers were freely combined) and many sites still contain documents that have not been “upgraded” to use the most current standards.

If you are starting a new site, then you should be using a Strict doctype rather than a Transitional one.

To summarise, I would suggest that you use the following doctype for each of the following “common” development scenarios:

• Frameset HTML 4.01 – when maintaining or updating a frameset HTML document
• Transitional HTML 4.01 – when maintaining or updating an old HTML document that contains deprecated tags
• Strict HTML 4.01 – when building a new site which seperates the presentation and content layers
• Frameset XHTML 1.0 – when maintaining or updating an HTML frameset XHTML document
• Transitional XHTML 1.0 – when building or updating a site that needs to support HTML presentation layer tags
• Strict XHTML – when building a new site that will be manipulated by an XML parser and served as “text/xml”

The decision of whether to use Strict XHTML 1.0 or XHTML 1.1 is left to the reader. If you are developing Strict XHTML documents and serving them to a wide audience, you should have already made this decision based on the audience and the technology being used to serve (and read/parse) the documents.

This isn’t really completely new – it has been in Microsoft’s Lifecycle Policy document since at least June 2003 (as seen in this CNet news article from June 2003).

When it was first released in March 2000, version 5.x of IE for the Mac was much more standards compliant than it’s Windows counterpart – and even though Microsoft ended development over 2 and a half years ago, the browser still performed better at rendering CSS in a consistent fashion than more modern Windows Internet Explorer builds. That’s not to say the Macintosh version wasn’t ready for retirement… and without anyone remaining to develop it… it’s loyal users have quietly migrated away.

We now have Apple’s flagship Safari as well as the latest Firefox, and Opera browsers available for MacOSX as well as a dedicated following of less well-known browsers (including iCab and Camino) that remain in development.

I don’t think the loss of IE is going to be a problem for Mac users and web developers going forward – it will be good to see it finally drop off the web logs, though.

JavaScript is an object-based scripting programming language based on the concept of prototypes. The language is best known for its use in websites, but is also used to enable scripting access to objects embedded in other applications.

It was originally developed by Brendan Eich of Netscape Communications Corporation under the name Mocha, then LiveScript, and finally renamed to JavaScript.

JavaScript has a C-like syntax.

Here is a short list of some things that Javascript is not: