Well I'm not completely behind the above statement (only a little), the only special thing HEAD currently has is the TITLE element. And maybe the PROFILE attribute is also a valuable one (being used by the XHTML Friends Network), but I think that the PROFILE attribute should be better defined than it is now.
Most types of META elements can be replaced using robots.txt or HTTP headers. However, there are examples where META elements must be used. You can approach such an example from different point of views. Either you think they have chosen the wrong type of indexing or you think it is a valid example for the use of the META element.
I do think that is an easy way of indexing. Often when I'm creating a version of a site not to be indexed yet I start using a META element, which stops Google from indexing. At the end, I create the appropriate robots.txt file, but I must say a META element now and then makes live easy. Another example might be that you want to validate your document, but your server isn't sending a default charset/content-type for your files (you might consider to configure Apache or add it into .htaccess). Most people add a simple META element in their document to fix this. Even the World Wide Web Consortium is using it, though I think they only do it for people who like to copy and paste stuff, instead of figuring it out themselves (and without those people, the web wasn't nearly as big as it is now, I believe).
The LINK element is becoming a more important part of the HEAD element these days (it was there in HTML2.0, so it's about time too), so why can/should we remove it? As it turns out, the LINK element is a 'HTML replacement for the HTTP link header'. The HTTP link header was obsoleted in HTTP1.1 because there where to few interoperable implementations. Although it was removed Mozilla has a bug for it (if there are more implementations, it will be added bakc into the specification): Link toolbar doesn't support HTTP links headers. Mozilla already supports this for style sheets.
Since the LINK is actually a 'HTTP header' you can also emulate one using META elements with the HTTP-EQUIV attribute.
What about SCRIPT elements? I never knew link was ever a header, it seems like that would be a pain to configure and change. Sets the barrier pretty high for people who can't modify any server settings (even through .htaccess) as well.
Anne: I hope I added the correct words :-)
Considering that script elements are supposed to provide the behavioral layer, why not use link for them as well?
We'd end up with something like:
<link type="text/javascript" rel="behavior" href="myscript.js" />
Of course, before this will be implemented - if it will be - it is the year 2006, so who cares?
How about using the link for document relationships and the following code for style sheets and scripts:
<?xml-stylesheet type="text/css" href="/screen" media="screen"?> <?xml-script type="application/x-javascript" href="/functions"?>
I like that better than my suggestion. I do have my doubts at using headers for relationships though. Aren't the relationships a part of the document as well? There has to be a way of storing these relationships along with the document. Headers don't provide that, link elements do.
How would you manage the link via server headers? They are page-dependent. If, say, you use 10 such elements in total on your site, which has, say, 1000 documents, then the probability that you will need different combinations of these 10 elements in any of your 1000 pages is close to one. Specifying fixed headers sitewide is then out of question.
Next, the same link has a different meaning on, potentially, every page. By that I mean the target of the link. One example of this is the index link, another is the contents, yet another is alternate. I don't see how a proliferation of page-specific or subfolder-specific .htaccess files (or whatever that's appropriate) would make anyone's life easier. Finally, most changes would have to be done manually, as I don't see any commercial tool giving us a hand in site management with respect to this.
M.
Moose: You can easily do it via server scripting - e.g. PHP. This of course does NOT changed the need for HTML page pushed to browser thus negating server headers issue.
There are several points of importance which I haven't seen here.
The first one is about robots.txt. If one reads the specification carefully it becomes clear that it can only be put in the root directory. For everyone who has no access to a first level domain - for whatever reason - this is a problem.
This point extends to headers. People that put their site on the server of their provider seldom have server side scripting possibilities. They simply would have no way of sending the data to the browser.
These two points show exactly what the head element is meant for. It is to provide an alternative to those who can't send the data in any other way. And since the web is an open medium I think this should be a possibility in the future as well...
Perhaps something like this:
<links> <stylesheet type="text/css" href="styles.css" title="Default" /> <script type="application/x-javascript" href="funcs.js" /> ... </links>