@Costa: HTML is useful because it's a set of agreed meanings for tags. For example, browsers make links clickable because we've agreed (via the HTML spec) that the <a> tag is a link to another page. You can create your own markup salad, but it won't have meaning to anyone else except yourself. For a given purpose, that might be fine, but you're not really using HTML any more.
Also of interest here: librador.com/2009/10/20/Styling-undefined-tag-names-in-HTML "You can use any tag name in HTML, and it will be part of the DOM and can be styled."
I mean, he doesnt back up his statement with anything. Just because Douglas Crockford said it, it doesnt mean its true.
I'm not so sure about these answers. As I've just read:
"CUSTOM TAGS HAVE ALWAYS BEEN ALLOWED IN HTML."
So while using it made your html page "official unapproved", it didn't break the page either. um, try styling your invented elements in Internet Explorer. It wont work. You might not consider that broken, but the fact that custom tags are invalid and dont work in Internet Explorer, I dont see how you can argue theyre allowed.
So, while you shouldn't invent a whole custom unspecified markup salad of your own, it's not exactly forbidden to have custom tags in HTML. That is however, unless you want to send it with an +xml Content-Type or embed other XML namespaces, like SVG or MathML. This applies only to SGML-confined HTML.
The point here being, that HTML was based on SGML. Unlike XML with its doctypes and schemas, HTML does not become invalid if a browser doesn't know a tag or two. Think of <marquee>. This has not been in the official standard. So while using it made your HTML page "officially unapproved", it didn't break the page either.
Then there is <keygen>, which was Netscape-specific, forgotten in HTML4 and rediscovered and now specified in HTML5.
And also we have custom tag attributes now, like data-XyZzz="..." allowed on all HTML5 tags.
This is what the specs say: "This specification does not define how conforming user agents handle ... elements ... not specified in this document. [...] we recommend the following behavior: If a user agent encounters an element it does not recognize, it should try to render the element's content. [...] authors and users must not rely on specific error recovery behavior" - IMHO this means that Crockfor is wrong, for once.