7

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?

Improve this question
1
  • 2
    I've seen them used as placeholders for various front end frameworks. Most notably Google's AngularJS.
    – blesh
    Oct 30, 2012 at 18:36

2 Answers 2

Reset to default
6

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.

Improve this answer
3
  • So here's my takeaway from your answer and tell me if this is your understanding as well: HTML will have undetermined behavior because the spec says to ignore but the implementations don't always, so you get no guarantee of how it will be treated. XHTML however makes guarantees that the elements should and will be members of the DOM and thus by XHTML spec should have determinable guarantees of behavior such that the browser treats them as non-HTML but still DOM elements receiving the benefits of DOM through CSS/JS.
    – Jimmy Hoffa
    Oct 30, 2012 at 19:41
  • @JimmyHoffa - I believe that's a reasonable understanding. With the new HTML5 spec, browsers are required to make the best of elements they don't understand which is why the OP is able to find it in the DOM and style his custom tag. In the past, they may or may not handle them at all. HTML5 has defined elements for each type of content. If one wants to create their own, they need to do it in its own namespace and XHTML is ideal for that.
    – Rob
    Oct 30, 2012 at 19:53
  • @JimmyHoffa, I’m afraid it’s more complicated. Any future HTML version, or browser, may start treating <mycustomtag> as a defined tag, with specific semantic (different from yours) and default formatting. And HTML5 drafts look really obscure to me in this respect. They sort-of frown upon namespaces.
    – Jukka K. Korpela
    Oct 30, 2012 at 21:02
4

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.

Improve this answer
1
  • 1
    Custom Elements now has a spec, currently at the Editor's Draft stage (which means: early) and some parts work in the Chrome "dev channel" if you turn on Experimental WebKit Features in about:flags.
    – Dominic Cooney
    Apr 28, 2013 at 1:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.