Otherwise xmlns tho not sure if html5 can use xmlns since the move away from xhtml?

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.

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?

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

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.

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.

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?

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*