Forum Moderators: open
1. Content-Type meta element.
<meta http-equiv="Something"> is a nasty hack: it makes the browser pretend an HTTP header was passed. As well as being inelegant, it can make Netscape 4 'flash' whilst loading the page as it switches to the new charset. Ideally you should simply pass the header in HTTP, by configuring your web server or server-side scripts to send:
Content-Type: text/html;charset=(whatever)
instead of simply 'text/html', for HTML files. (and yes, p1: that means for XHTML files there are three ways of specifying the encoding!)
However if you're not running your own server you might not have access to the config or scripts to do that, so you have to opt for the inferior solution of <meta>.
Note that you only need to do this if you are using any characters outside of the range ASCII 32-126. For plain US-ASCII text, you can ignore any validator warnings - you don't need to say what charset it is, as the lower range of characters are the same in all encodings.
(Well, not actually - there are other encodings, like UCS-16, which are not a superset of US-ASCII, but then if your document is in one of those encodings, the browser has no chance of reading the <meta> anyway, so including it won't do any good.)
2. Content-Language.
Not really needed as a <meta http-equiv>. Seems more sensible to use the built-in features of HTML instead: <html lang="xx"> (or xml:lang="xx", for people already playing with XHTML 1.1).
3. DOCTYPEs.
Yeah, full DOCTYPEs are good. Make sure you include the full system identifier, not the "DTD/xhtml1-strict.dtd" relative version you sometimes see in the source of the W3C's documents - that's only valid for documents stored in the right directory at www.w3.org!
Avoid using the <?xml version...> preamble for the moment. It's not necessary for XML 1.0 documents and it will cause IE6/Win not to see the Standards-Mode DOCTYPE. (Gah! Really stupid bug.)
4. type vs. language
type="text/javascript" is best. language="..." really only needs to be used when you are using a specific version of JavaScript where the syntax won't be understood by older JS interpreters, eg. language="JavaScript1.2". Even so, this isn't so reliable - eg. Opera's inability to read regexp literals. Usually best just to use the (standard) attribute 'type' and leave the rest to object-sniffing in the script.
type='text/css' should also be used for stylesheet links.
Using external files is normally better than embedding stylesheets/scripts in the file. Apart from the maintainance difficulties, it's very tricky to embed non-HTML content reliably across HTML, XHTML and tagsoup. Also, for XHTML, never use the '<script type="..." src="..." />' empty-element shorthand, or your page will disappear entirely in HTML parsers!
5. Positioning of scripts.
It depends entirely on the script. If the script needs to use document.write() it will have to be in a particular place - in the head if it needs to write head elements; in the body if it needs to write page content. Some scripts may deliberately be written to work in either place.
Order of execution of scripts is actually quite well-specified: a script must finish executing before the rest of the page below its tag (including any other scripts) will be looked at. It must happen this way as the script could use document.write() to add some code to the page, and it would be too late to do this if the parser had already gone on to the next bit. (You can use the 'defer' attribute to tell the browser you don't use document.write(), but I don't think any browsers actually support that.)
The timing issues come in when scripts get themselves called back using window.setTimeout or various event handlers. That can get complicated quickly.
2. Content-Language.
Not really needed as a <meta http-equiv>. Seems more sensible to use the built-in features of HTML instead
Well, it depends. If you for some reason need the HTTP headers it's nice to use the meta http-equiv tags - as long as they work.
I've noticed that some of the filtering software based on PICS act on HTTP headers only, and ignore meta http-equiv tags.
(Regarding the content language this issue may not be that important, but it may be useful to pay attention to the HTTP headers.)
2. Content-Language.
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<meta http-equiv="Content-Language" content="zh">
<meta name="language" content="zh">
<html lang="zh">
Is this overkill? Although I can't find the references now, I believe that each of these can play a role in helping various browsers choose the proper character set and encoding for the page.
