Invented Elements
Published 12 years, 7 months pastThis morning I caught a pointer to TypeButter, which is a jQuery library that does “optical kerning” in an attempt to improve the appearance of type. I’m not going to get into its design utility because I’m not qualified; I only notice kerning either when it’s set insanely wide or when it crosses over into keming. I suppose I’ve been looking at web type for so many years, it looks normal to me now. (Well, almost normal, but I’m not going to get into my personal typographic idiosyncrasies now.)
My reason to bring this up is that I’m very interested by how TypeButter accomplishes its kerning: it inserts kern elements with inline style attributes that bear letter-spacing values. Not span elements, kern elements. No, you didn’t miss an HTML5 news bite; there is no kern element, nor am I aware of a plan for one. TypeButter basically invents a specific-purpose element.
I believe I understand the reasoning. Had they used span, they would’ve likely tripped over existing author styles that apply to span. Browsers these days don’t really have a problem accepting and styling arbitrary elements, and any that do would simply render type their usual way. Because the markup is script-generated, markup validation services don’t throw conniption fits. There might well be browser performance problems, particularly if you optically kern all the things, but used in moderation (say, on headings) I wouldn’t expect too much of a hit.
The one potential drawback I can see, as articulated by Jake Archibald, is the possibility of a future kern element that might have different effects, or at least be styled by future author CSS and thus get picked up by TypeButter’s kerns. The currently accepted way to avoid that sort of problem is to prefix with x-, as in x-kern. Personally, I find it deeply unlikely that there will ever be an official kern element; it’s too presentationally focused. But, of course, one never knows.
If TypeButter shifted to generating x-kern before reaching v1.0 final, I doubt it would degrade the TypeButter experience at all, and it would indeed be more future-proof. It’s likely worth doing, if only to set a good example for libraries to follow, unless of course there’s downside I haven’t thought of yet. It’s definitely worth discussing, because as more browser enhancements are written, this sort of issue will come up more and more. Settling on some community best practices could save us some trouble down the road.
Update 23 Mar 12: it turns out custom elements are not as simple as we might prefer; see the comment below for details. That throws a fairly large wrench into the gears, and requires further contemplation.
Comments (14)
Completely with you on this one. What do you think about the proposed
pictureelement and its JS polyfill? Should it bex-picturefor now?The first thought comes to mind is XHTML. I cannot access the site at the moment, but if their documentation clearly states to use the library you have to use their DTD that they wrote, wouldn’t that fix it?
It turns out hyphens aren’t allowed in element names and you can only create custom elements using an
elementelement to wrap stuff and anisattribute in other places: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#custom-element-section. That puts a huge wrinkle in all this.Browsers handle parsing of elements with hyphens in their names just fine. Try it!
The “is” thing is a complete hack and, frankly, only there because Hixie doesn’t like the idea that someone might go around plugging into the parser and creating new element type subclasses without first asking for permission. It’s entirely sane for us to want to do this, but he doesn’t seem to agree for some reason which, despite trying, I really can’t fathom. It’s entirely possible to maintain all of the Element invariants from script.
*sigh*
Alex: certainly it’s crystal-clear that browsers handle arbitrary elements without any problem. That’s how TypeButter works now! And I definitely agree that the extension mechanism in HTML5 is an ugly, ugly hack. I’m still reading through the text to formulate my reaction.
I don’t see how that throws any kind of wrench at all in. What the W3 says has never mattered; what’s matters is what the browsers actually do. The W3 has only ever mattered to the extent that they influence browsers, and I highly doubt browsers are going to suddenly stop supporting custom elements (breaking pages and making their users switch to other browsers) just on the W3′s say so.
And just to be clear, browsers have pretty much always supported custom elements, although maybe not perfectly. No one wants to make their browser fail on http://www.example.com just because the author of example.com accidentally made a DIVX tag instead of a DIV, so browsers have always been very lenient in what markup they accept. Stuff like XHTML and namespaced elements (or this new element tag) may have been a more structured response to the desire, but I’ll expect browsers to stop supporting the “old” way (of just creating random elements) about when they stop supporting the B tag.
Now sometimes we might wish the word of the W3 trumped the browser makers’ (*cough* IE6), but in this case we have a perfectly useful (in limited contexts) technique which as far as I know works perfectly well in every major browser … and we’re supposed to not use it because the W3 says so? Sorry, but that’s just silly.
Oh, and I didn’t see anything on hyphens being bad in that link; to the contrary, they use the example custom element “x-fancybutton”. Could someone please clarify?
Aaron: in general I’d say yes, it should be
x-picture(or some equivalent) until an element is standardized.Jeremy: the prohibition on hyphens in elements names is elsewhere in the spec. Also,
x-fancybuttonin the example is really an attribute value, not a full element name. Yes, it’s very confusing.Hi Eric and friends!
I don’t normally comment on posts, but when I do, I put them on Eric Meyer’s blog.
Yes, there’s a strange and murky road ahead with the notion of local semantics in HTML. I made a few attempts to present and defend this idea (http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html), but ultimately had to back off and go with the “is” workaround. So… it’s <span is=”x-kern”> today in the proposal.
Obviously, <x-kern> is less clumsy and more intuitive. However, there’s a few hurdles to clear out before we can get there:
1) Modify HTML parser to level the ground for these elements. As much as I like custom tags, they require changes to the tree construction algorithm (http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#tree-construction), and that’s a bit tricky, since we’ve just gotten a consistent parsing behavior across all modern browsers. Making changes requires a lot of convincing.
2) Speaking of convincing. There’s a large group of people, including Hixie and other Web luminaries, who find the notion of local semantics repugnant. This is a steep climb. I tried and I so far hadn’t had much luck.
So, as you can see, lots of work in this area — both happening and still to do.
Another thought. With Shadow DOM, a whole new dimension opens up. For example, TypeButter no longer needs to even add anything to page markup – just stuff the kerned content into Shadow DOM: http://jsfiddle.net/LkXDA/
I can’t leave Dimitri’s Alex-bait un-addressed: anyone who finds local semantics repugnant isn’t paying attention. If they were, they’d see that instead of making the web *more* semantic, most HTML5 apps and sites are predicated on enormous piles of JavaScript which *just so happen* to include MOST of the semantics of the page/app. That means the only thing they’re holding their nose at is the idea of this sort of ad-hockery bleeding though into HTML…but wait!? What’s this!? MicroFormats? RDFa? schema.org? HOW DARE THEy….er…I mean, it’s all good ’cause they’re not inventing new tags, right? AMIRITE?
Seriously, if the entire thing falls apart because we suddenly are able to say what we mean (behind a prefix like “x-“, no less) while waiting for the browser to get off it’s ass and give us the elements we really need anyway, I tremble in fear at our impending doom. Simply assuming that ad-hoc semantics don’t exist because they aren’t showing up at parse-time on *your* end of the pool simply doesn’t pass the smell test. Local meaning is already here, hidden away in the Turing-tarpit of JS, and the thing that’s keeping us from making headway on evidence-based HTML is the ability to catalog and correlate local meaning, turning it into global mean with dirty, dirty probability distribution functions. That’s a *good* thing, BTW. How does anyone think Hixie came up with those lovely HTML5 tags anyway?
http://devfiles.myopera.com/articles/572/classlist-url.htm
Hey Dimitri, thanks for commenting! Very much appreciated.
I’m unclear why adding arbitrary elements requires changes to the tree construction algorithm—could you give some details? I would think, while admittedly not knowing the details of browser DOM innards, that it would be like adding any element to the tree. Only the name would be different, and I would think would be covered under 12.2.5.5 (as a “foreign” token). Is it that 12.2.5.5 would need to be updated?
As for the reluctance to allow local semantics, I agree with Alex’s underlying points: browsers (tacitly?) allow it, it’s desirable, it will happen, and authors won’t bother to jump through flaming hoops to make it happen. My advice to the TypeButter guys as this point would be to create
xkernelements (since hyphens aren’t permitted in element names) and leave it at that. I’m sure you did the best you could given the constraints you faced, but theelement/is=approach is just too crufty to recommend. Is there a summary of the reasoning behind resisting local semantics, perchance?The tree construction is rather unforgiving in some corners of markup, like tables and select element children. In fact, I already went through this exercise with the HTML Templates spec, and you can see the modifications here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#parsing
And this is all just to allow a <template> tag anywhere. Luckily, once this exercise is done, we could just extend this to any element that starts with a certain prefix—like
x-.As for the local semantics discussion, I do not know of any existing source of truth that I can point you to. However, I encourage you to restart this discussion on public-webapps or whatwg mailing lists. Perhaps your calm reasoning and one giant heck-of-a-karma would help facilitate discussion.
Pingback ::
Some links for light reading (27/3/12) | Max Design
[…] Invented Elements […]
Ooo Shadow DOM for the win! http://meyerweb.com/eric/thoughts/2012/03/23/invented-elements/?#comment-653427
Otherwise xmlns tho not sure if html5 can use xmlns since the move away from xhtml?