HTML5 is gaining steam with more and more browsers supporting more features (and IE9 really puffing hard to keep pace), and in the process, a lot of familiar tags are being re-defined.

For example, a newcomer would be forgiven if they thought <small> meant “make the text smaller,” or <b> meant “make it bold.” Under HTML5, these tags now have semantic definitions; that is, they describe what is inside the tags, not what it looks like. The definition of <small> explicitly states, “The small element represents so-called ‘fine print’ or ‘small print’, such as legal disclaimers and caveats.” Therefore small could be physically small, as it most likely will be, or it could be large or bold or red, if you wanted your legal disclaimer to carry a markedly different weight. (<b>, just so you know, means “a span of text offset from its surrounding content without conveying any extra emphasis or importance.” It could be bold, but it doesn’t have to be.)

The groups who have masterminded HTML5 have also obsoleted some elements (somewhat ironically, <big> makes a good example) because they have no semantic value. So while we get a lot of fancy new tags like <header> and <article>, we must also mourn the loss of the fallen. Alas, the notorious <big>, a true gangsta, shot down in his prime.

Which finally brings me around to my conundrum: which tag do I use for embeddable content? Under HTML4.x, <object> was the semantically correct tag, while <embed> was a proprietary tag invented by Netscape for purposes of evil and later adopted by Firefox for purposes of good. The trouble, at the time, was that <embed> was wrong, but easier to use, and all browsers supported the tag, while the confusing <object> was technically correct, but didn’t work in Firefox.

The commonly accepted solution was to wrap <embed> inside <object>, like so: <object>
  List of <params> that nobody really understood.

And that worked, but it was still technically invalid. Standardistas cringed and sucked it up. Other sites, like MySpace—known for just not giving a fuck—simply used embed and only embed. And who could blame them? It worked and it was easy.

With HTML5, the W3C decided to “pave this cowpath” and officially welcome the bastard child <embed> into the family, which is certainly good news, but my question now is, how are these elements to be used properly? Let’s look up their definitions:

  • <object>: generic external content—The object element represents external content.
  • <embed>: integration point for plugins—The embed element represents an integration point for external content.

Okay... so where does this leave us? <object> was once used to display Flash and Quicktime and other such plugins, so that might be considered generic external content, but <embed> is now explicitly specified for plugins. But! later on in the details is stated, “The object element represents external content, which, depending on the type of the content, will either be treated as an image, as a nested browsing context, or as external content to be processed by a plugin.”

For comparison, “the embed element represents an integration point for external content—typically, non-HTML content such as an application or some other type of interactive content which involves use of a third-party plugin as a handler (rather than being natively supported by the UA).”

Can we get an English major in here? Now I’ve got to start parsing the semantics of these words, before I can parse the semantics of the tag. From what I gather, an <embed> can only be content processed by a plugin, while an <object> can be an image, a nested browsing context, or content processed by a plugin.

In my opinion, <object> can therefore be obsoleted along with <big> and the rest simply because all of its functionality has been made redundant by <img> (for images), <iframe> (for nested browsing contexts), and our newest family member <embed>.