Element Customization
Published 12 years, 1 week 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.
Comments (9)
I agree that there should be a way to safely use custom elements. To give an illustration of why you shouldn’t create your own elements at this point:
Say you are site with user-driven content and you think it would be appropriately semantic to wrap avatar images in an
avatarelement. The W3C then comes up with an idea (maybe based on your usage!) to create anavatarelement. They might reason that it would allow machines to differentiate between avatars and other images. That might be cool that they liked your idea, but what if the W3C’savatarelement has asrcattribute and behaves like animgelement? Now you may have nasty results!I like your idea for a convention of an
xprefix. So in my example, you would use axavatarelement. It is visually quick to see the intent is to have content related to an avatar. And if you want more clarity, you can even write itxAvatar.Having written an HTML5 (at the time it was still “Web Applications”) parser before I can suggest that attributes are easier because with only one trivial exception (minimization) attributes are all the same from a syntactic and tree-building point of view. This is not the case for elements, as I’m certain you’re aware. Some elements can have start tags or end tags omitted; others will act differently or be styled differently depending on various factors; some elements push out any children which are not among a small, rigidly-defined class; and so on.
These rules are well-defined now, but they’re quite complex, and further complicating things willy-nilly is an invitation for bugs and implementation deviations. I’m sure the real, hard technical reasons are quite arcane, but I expect it boils down to things being difficult enough as they are.
To tell you the truth what concerns me about this is not the technological aspect of whether you can or can’t add custom elements to HTML markup, but whether you should.
The success of HTML was primarily down to its simplicity.
The XHTML proponents forget that and XHTML failed.
If HTML5 advocates forget this, HTML5 will also fail.
The less different types of HTML markup the better. This should be a mantra repeated by everybody before a WHATWG meeting.
Hi Eric. HTML5 does acknowledge that elements can be defined by extension specifications. Which means it’s OK to invent an element such as
<kern>so long as you bother to document it somewhere.Conversely, the
<element>stuff you’ve been looking at isn’t actually part of HTML anyway; it has no more status than a self-published<kern>specification would. The page you linked to is a guide to ‘Web Components’, which is not part of the HTML specification. It’s labelled ‘extremely early draft’ and is quite possibly something which its authors would like to become part of standard HTML. But it certainly isn’t at the moment, and quite possibly will never be.So it isn’t accurate to bill this weird
<element>thing (which I hadn’t heard of till you mentioned it) as how anybody is supposed to do anything.Now, on to what the HTML spec actually does say.
First, it isn’t just the case that minting your own elements happens to work in browsers; the specification actually requires that browsers parse them sanely:
Then look at what the spec says in terms of allowing extension elements:
In other words, it is acceptable for authors to use elements that are defined in an applicable specification. What’s one of those? Follow the hyperlink and you get to the definition:
So if somebody (not necessarily a recognized standards body) writes a specification for extending HTML with a
<kern>element, and you write webpages which meet the combined requirements of the HTML spec and the new Kern spec, then your document will be conforming to anybody who recognizes those specifications.That of course leaves open the matter of how would such a Kern spec become ‘recognized’ … but that’s a social matter, not a technical one. If the web developer community (or a particular subset of it that you’re part of, or the client that you’re developing a website for) recognizes it, then it’s recognized. Yes, I realize that’s a tautology, but that’s cos really there’s no magic involved — and nothing a standards body can do to either force a particular specification on to a public that isn’t interested (see also XHTML2), nor to prevent the will of the people from collectively buying into a particular extension specification.
There’s still the matter of automated conformance checkers, though. Obviously if you are following a particular extension specification it would be irritating if the validator you use doesn’t also use it, throwing up ‘errors’ for things actually allowed. If a community takes to a particular extension, hopefully somebody in that community will be sufficiently motivated to set up a validator which covers it.
Henri Sivonen, who runs Validator.nu has said that he would consider adding support for an extension specification which has “real user demand from validator users”.
Hope that’s of interest.
Smylers: we (the team driving Web Components in WebKit and writing the spec) are absolutely going to extend HTML with the
elementelement. That it’s not in the draft of a living spec right this second is neither here nor there.We have also, in various places, proposed requiring that authors use some form of enforced prefix for these things, with my current favorite being
x-.In any case, the question of standardization for custom extensions puts the cart before the horse. HTML’s core semantics should continue to grow as we see more use of (non-standardized) extensions. What Web Components do is to open up the space for creating and using custom extensions in the first place, enabling authors to vote with their feet and their code. Over time, what is common should feed back into the *standard* HTML. The entire idea of blessing side-contracts just so we don’t have to extend HTML is a time whose idea has passed.
Regards
Hi Alex. Thanks for your response.
When you say “absolutely” do you mean that Web Components will definitely become part of the HTML spec (and that it’s already been approved in principle by the relevant working groups and editor), or just that it’s absolutely your intention that it will become part of it?
I agree completely that any extensions to HTML which garner widespread adoption should then be incorporated into the HTML standard.
However, if somebody wants to add an element to HTML, the ‘other applicable specifications’ clause provides a way for her to do so. As will the
<element>if that is adopted, giving authors a choice. Given that choice it sounds as though Eric would prefer to simply create a named element than to add an attribute on to an existing element, but perhaps other developers would prefer the<element>approach.As someone that has to maintain a custom CMS for clients I must say I’m not really keen on on element customization. Tools like TinyMCE and HTML Tidy do allow you to add custom elements and custom attributes, but they have to know about them in advance. In the past everyone wanted to strip out made up (can’t say invalid anymore) HTML elements (e.g. MS Word converted pages). I see a lot support issues with non-prefixed element customization.
That isn’t saying that this stuff is bad. Any extension that is widely adopted should be incorporated into any editor tool as part of the standard update process that should happen.
I guess what I fail to see with the element element as it stands is how it is functionally different than simply using a class. What is practical difference between Eric’s example above and simply declaring <h1 class=”superh1″>?
What should be the implications of custom elements on JavaScript? Is part of the appeal of a new element the ability to extend its prototype? For example
HTMLKernElement.prototype.setSpacing = function() {...}. Right nowon OSX I get mixed results:
document.createElement('kern').toString()returns[object HTMLUnknownElement]in Firefox 11 and Chrome 18 but returns[object HTMLElement]in Safari 5.1.5.