It seems like for years they’ve just been given default styling and inline display. Is there a spec somewhere that has dictated this? I’ve looked over the RFC’s but I’m not particularly good with RFC-ese, and I didn’t notice anything anywhere.
For example
<body>
Some content <mycustomtag>something else</mycustomtag> more content.
</body>
I can still style it with CSS, and the browser doesn’t outright vomit… so it seems like there is some sort of expected behavior. Was that dictated by a specification?
1
HTML 2.0 (RFC 1866) says, in Undeclared Markup Error Handling: “To facilitate experimentation and interoperability between implementations of various versions of HTML, the installed base of HTML user agents supports a superset of the HTML 2.0 language by reducing it to HTML 2.0: markup in the form of a start-tag or end-tag, whose generic identifier is not declared is mapped to nothing during tokenization. – – Information providers are warned that this convention is not binding: unspecified behavior may result, as such markup does not conform to this specification.”
This means that unknown tags are ignored. Any data between them is processed normally. That is, the tags are skipped, the (purported) element is not: its content is handled as if the tags were not there. So instead of being treated as inline elements, the constructs were treated as content.
HTML 2.0 is a great improvement over its successors in clarity and exactness. But what happened in practice is that browsers started recognizing elements with undefined tags, creating element nodes in the DOM and making them available to styling and client-side scripting. IE is the last one to follow suit here (as so often), and in Quirks Mode, even IE 9 ignores unknown tags (does not create styleable elements), unless you use document.createElement() to “define” them.
In XHTML, things are different in principle. Though the XHTML specs are obscure, it’s apparently the idea that XHTML is just XML with tags bound to “HTML namespace”. That is, you can use any tags in XHTML, and those declared to be in HTML namespace will be interpreted using HTML semantics, other elements are either from other namespaces known to the implementation (say, MathML or SVG namespace) or without any namespace, being just XML tags – which still create (styleable) nodes in the DOM.
3
Jukka’s answer covers the existing specs nicely, just for completeness sake I’d like to mention that the very recent “Introduction to Web Components” W3C draft includes custom HTML elements (the proper name is elements, “tag” refers to the opening and closing tag).
From the draft:
2 Introduction
The component model for the Web (also known as Web Components) consists of four pieces designed to be used together to let web application authors define widgets with a level of visual richness not possible with CSS alone, and ease of composition and reuse not possible with script libraries today.
These pieces are:
- templates, which define chunks of markup that are inert but can be activated for use later;
- decorators, which apply templates to let CSS affect rich visual and behavioral changes to documents;
- custom elements, which let authors define their own elements, including new presentation and API, that can be used in HTML documents; and
- shadow DOM which defines how presentation and behavior of decorators and custom elements fit together in the DOM tree.
…
5 Custom Elements
Custom elements are new types of DOM elements that can be defined by authors.
Custom elements can define presentation aspects like decorators. Unlike a decorator, which can be applied or unapplied to a given element, the element’s type is fixed. So custom elements can also define new state and behavior, which decorators can’t do because of their ephemeral nature.
The element element defines a custom element. It specifies the type of element it’s a refinement of using the extends attribute:
<element extends="button" name="x-fancybutton"> … </element>
You can monitor the draft’s status here. The project is spearheaded by the Google Chrome development team:
The Web Components project , led largely by the Google Chrome development team, aims to help solve a simple problem: Building Web applications is more complicated than it used to be. Worse, it’s more complicated than it should be.
Modern Web apps have rich, interactive UIs, driven largely by client-side code. Today we generally build such UIs using JavaScript frameworks and UI toolkits, such as Dojo/Dijit, jQuery UI, and YUI. That’s both good and bad. It’s good because it means it’s now easier to build rich Web UIs than ever before. It’s bad because it needlessly shifts the balance of control over Web development from designers to programmers.
1