meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Invented Elements

This 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.

14 Responses»

    • #1
    • Comment
    • Fri 23 Mar 2012
    • 1022
    Aaron Gustafson wrote in to say...

    Completely with you on this one. What do you think about the proposed picture element and its JS polyfill? Should it be x-picture for now?

    • #2
    • Comment
    • Fri 23 Mar 2012
    • 1031
    Ryan Benson wrote in to say...

    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?

    • #3
    • Comment
    • Fri 23 Mar 2012
    • 1057
    Eric Meyer wrote in to say...

    It turns out hyphens aren’t allowed in element names and you can only create custom elements using an element element to wrap stuff and an is attribute 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.

    • #4
    • Comment
    • Fri 23 Mar 2012
    • 1109
    Alex Russell wrote in to say...

    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*

    • #5
    • Comment
    • Fri 23 Mar 2012
    • 1129
    Eric Meyer wrote in to say...

    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.

    • #6
    • Comment
    • Fri 23 Mar 2012
    • 1137
    Jeremy wrote in to say...

    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?

    • #7
    • Comment
    • Fri 23 Mar 2012
    • 1235
    Eric Meyer wrote in to say...

    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-fancybutton in the example is really an attribute value, not a full element name. Yes, it’s very confusing.

    • #8
    • Comment
    • Fri 23 Mar 2012
    • 1257
    Dimitri Glazkov wrote in to say...

    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.

    • #9
    • Comment
    • Fri 23 Mar 2012
    • 1257
    Dimitri Glazkov wrote in to say...

    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/

    • #10
    • Comment
    • Fri 23 Mar 2012
    • 1327
    Alex Russell wrote in to say...

    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

    • #11
    • Comment
    • Fri 23 Mar 2012
    • 1533
    Eric Meyer wrote in to say...

    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 xkern elements (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 the element/is= approach is just too crufty to recommend. Is there a summary of the reasoning behind resisting local semantics, perchance?

    • #12
    • Comment
    • Fri 23 Mar 2012
    • 1616
    Dimitri Glazkov wrote in to say...

    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.

    • #13
    • Pingback
    • Mon 26 Mar 2012
    • 1529
    Received from Some links for light reading (27/3/12) | Max Design

    […] Invented Elements […]

    • #14
    • Comment
    • Mon 26 Mar 2012
    • 1950
    Rhys Burnie wrote in to say...

    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?

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


March 2012
SMTWTFS
February April
 123
45678910
11121314151617
18192021222324
25262728293031

Sidestep

Feeds

Extras