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.

What you mean? I have never seen that. I have done in that way in hundreds of websites but never heard that. The sites are passed with w3 validator as well. Maybe I did not try to see anywhere. Can you please elaborate bit more about this issue?

What you mean? I have never seen that. I have done in that way in hundreds of websites but never heard that. The sites are passed with w3 validator as well. Maybe I did not try to see anywhere. Can you please elaborate bit more about this issue?

It's not defined by HTML specification thus it cannot be guaranteed that every browser will behave like this. Of course it may work but we should adhere to standards. As to why validator doesn't issue an error (or warning) -- that's a question for the W3C. I can only speculate that the reason is that the standard doesn't specifically require a URI, it only says that "behavior for a value other than an HTTP URI is undefined". In other words HTML specification doesn't say what the browser should do when the value isn't a URI.

A URI reference that does not contain a URI is a reference to the current document. In other words, an empty URI reference within a document is interpreted as a reference to the start of that document, and a reference containing only a fragment identifier is a reference to the identified fragment of that document. Traversal of such a reference should not result in an additional retrieval action. However, if the URI reference occurs in a context that is always intended to result in a new request, as in the case of HTML's FORM element, then an empty URI reference represents the base URI of the current document and should be replaced by that URI when transformed into a request.

It's clear that HTML4 specification does require action attribute to be a URI. It's too bad the specification is so ambiguous. Stating that "behavior for a value other than an HTTP URI is undefined" doesn't help at all. But it's been a long known fact that HTML specification is full of such ambiguous statements.

Me
I've never had a good reason to use an xhtml doctype. I don't parse my output as xml so...

Yeh, I've started using HTML strict again recently. XHTML isn't supported by IE, and I've been swayed by the arguments on here (I like the XHTML syntax, but HTML is more practical / correct until the problems with XHTML are sorted out.. and even then it won't be suitable for a lot of applications). I may convert some of my existing sites to HTML strict as well.