Element Customization
Published 12 years, 2 weeks pastA couple of weeks back I wrote about customizing your markup, but I got an important bit wrong and while I’ve corrected the post, I wanted to clear up the error in detail.
I said that you wrap portions of your document (or the whole thing) in an element element and use the customized element inside. This is incorrect, and actually a very bad idea. In fact, you define your customized elements using an element element and then use the customized elements later in the document. Something like this:
<element extends="h1" name="x-superh1">
</element>
<h1 is="superh1">UltraMegaPower!!!</h1>
<h1>Regular Old Power</h1>
The line break inside the element element isn’t required — I just threw it in for clarity.
The element element can optionally contain template markup, but I honestly don’t understand that part of it yet. I get the general idea, but I haven’t crawled through the specifics long enough to have really internalized all the fiddly bits. And as we all know by know, the fiddly bits are where understanding lives and dies. (Also where the Devil hangs out, or so I’ve been told.)
I still firmly believe that all this papers over a much bigger problem, which is the arbitrary barrier to devising and using actual custom elements (as opposed to customized existing elements). HTML5 already allows you to make up your own bits of language: you can make up any attribute you want as long as your preface the name with data-. Okay, so that’s a little bit clumsy naming-wise, but the capability is there. You don’t have to register your attributes, or declare them in a list, or any of that other stuff. You just make up data-timing or data-proglang or data-sttngcharacter on the spot and off you go.
This is not possible for elements. You can’t even make up a prefixed element name, whether it’s data-kern or x-kern or even xkern (to avoid the limitation that hyphens aren’t allowed in element names). You just can’t devise your own elements. The best you can do is use the element element to sprinkle some semantic dust bunnies on top of elements that already exist.
Of course, all this “you can’t” and “not possible” applies to the specification. Browsers will let you feed them any old element name and style it, script it, whatever. Some say that’s more than enough. If the browser lets you do it, why let the specification hold you back? And of course, that’s how most people will approach the situation.
To someone like me, though, who spent years (literal years) explaining to web folk the world over that just because Internet Explorer for Windows let you write width: 12 px, actually writing it was still a bad idea — well, those habits die hard. Just doing stuff because the browser let you do it is not always a good idea. In fact, more often than not it’s a bad idea.
None of that really matters, as I say, because people are going to inject their own elements into their markup. They’ll do it because it’s easier than thinking about the proper element to use, or they’ll do it because no appropriate element yet exists, or for some other reason. That’s why the HTML5 specification ought to include the ability to do it, so that we have a paved path and defined best practices. The capability is useful, as the data- attribute feature demonstrates. If there’s a good, solid technical reason why extending that customization from attributes to elements is not desirable, I’d really like to know what it is.