X-Tag - a cross-browser web components library (opens in new tab)

Ah, but these are the X-Tag steps for 10 different tag types.

1. Scour the web for 1 plugin

2. Add 1 plugin script include to your page

3. Copy/type 10 new HTML tags (which you'd need to do anyways)

4. Add attributes, for which someone will release a Light Table plugin (eventually) to fetch standardized documentation.

5. Only repeat steps 3 and 4.

I'm very excited to see something like NPM for tag handlers. We might even see something like <require lib="jquery" source="google"> tags that transform into <script> tags that pull things like jQuery from CDNs. And if they use either the NPM model (unilateral publishing) or the Homebrew model (pull requests), and if they are half-decent moderators (to avoid squatting on common tags if they use the NPM model), I can see this transforming the way we write websites (although I'll always be a browserify fan myself).

1) Mozilla is generating a stock set of components that you wont have to "scour" for. 2) The components can be easily included using an app bootstrap builder that the Mozilla Marketplace dev hub will feature 3) You write the tags like you would any other in HTML, there is not complex copy or paste operation... 4) You can use components without modifying them, #4 is a red herring

Another huge benefit: the polyfill is 2k compressed composed of pure, library-independent JS

X-Tags could be made self-hosting with a name registry and a simple "missing x-tag" tag. In other words,

  1. Visit the registry for a tag.
  2. Start using it in your markup.

Assuming the registry's CDN is available, of course!

Ideally, IE8 should be your minimum. There's a large contingent of web users still on Windows XP and IE9+ is not available for it. XP is in extended support until 2014-08-14 & yes, I'm counting down the days.

I, for one, would never use this while it remains incompatible with a large segment of the web-browsing public.

So, yes, I think it would be a big deal. IE8 would be even better. But with IE9 compatibility, at least it would be feasible to start using this when IE8 fades away.

New tags are given an "x-" prefix by default, so that's not an issue. That said, you can opt out of the prefixing by changing the namespace string - but even if you remove it and there is a tag created down the road of that name, it doesn't mean your stuff is sure to break.

It looks like you have to prefix the tag names you register with an x- in your html.

Really neat. I must be living under a rock, but I never had heard of this before. It seems to bring a lot of the advantages of component-oriented development with it - just declare and go and the implementers will have taken care of the necessary wiring behind the scenes to make the components work. What I don't have a feel for though is what disadvantages it might bring from component oriented development - how easy for example would it be to change the style and/or behavior of the expanded component dom objects, in a way that the original developers never thought of, if need be? In any case, very cool and thanks for posting.

Actually I have been meeting with the W3 Web Components spec author for about 2 months while we readied this. The document.register method that was recently added to the spec was in large part a byproduct of X-Tag and when browsers implement it (Firefox soon) X-Tag will use it internally in browsers that support it, as a polyfill always does. Once one browser implements the JS mentod, X-Tag will truly polyfill the method on document as well.

I'm not sure, but I think this is 'Web Components'. The Mozilla page says so https://wiki.mozilla.org/Apps/x-tag

You should be able to use this as a standard soon, X-Tag has helped inform the W3 spec. I've been working with Dimitri Glazkov (the W3 draft author) over the last 2 months. We reached initial agreement as a group that the standard, imperative JS DOM API should be "document.register" in the style of X-Tag's "xtag.register" (specs can change though, of course).

Because it doesn't support CSS Animations, which I use for insertion detection. I might be able to finagle it for IE9 with Mutation events, but in their DOM Level 3 state, they destroy performance.

IE10 supports CSS Animations and will also be the first IE version to support HTML5 Windows apps, those are the two most significant reasons it is the current minimum version for IE. If IE9 is the thing people really need, I can try to work it in, we'll see what folks say ;)

Surely sir! http://github.com/mozilla/x-tag/

Can you file a bug (at bugzilla.mozilla.org) and CC me (":khuey")? I'd like to figure out what Arch is doing here.

Browsers were always able to implement their own tags. x-tag allows the developer of a website to write their own tags (and share them with others, etc.), which is huge.