dandonkulous

IE9 support lands today, and we've decided against supporting earlier versions of IE - too much headache and code bloat/hackishness to justify addressing the ever shrinking < IE9 user base.

I actually think a spin on this idea could work, we're going to be working with Google on adding a tag library to their JS libraries CDN (that is tentative btw) and the spec already calls for multi-tag definition inclusion via link tag.

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 going to work on it this weekend!

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

Correct, Mozilla Marketplace is not putting X-Tags in all apps. The dev tooling side of Marketplace will offer a project builder that let's you pick which tags (if any) you'd like to include. It then bundles all the assets you pick into one compressed file and spits out a zip containing a skeletal project with all the script tag and asset references preset for you in the pages.

@MatthewPhillips - That's not what I meant. Mozilla will offer a bootstrap builder with which you can add as many of the stock tags/components as you want to your app's pages. It will output a skeleton of an app that is development-ready. We will be actively working on getting the stock set of components prominently offered in other app bootstraps and store dev areas.

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

If I can get it compatible with IE9, is that a big thing for people here? I don't think it would be too hard, thoughts?

Yeah the funny thing is I could actually even make it work in IE6 and 7 if I used Mutation for IE9 and then - ready your pitchforks and torches folks - proprietary CSS Behavior script ducks to avoid tomato. IE8 screwed the pooch in this regard - they removed CSS Behaviors but failed to implement anything that could be used to do the same sort of thing.

The prefix is added as a default, but can be changed or even removed - it's up to you, the developer.

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.

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 ;)

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

To change the style and behavior, you just use the DOM as you normally would. You can access the inner DOM elements of a component with regular ol' JS and style them normally with CSS if exposed - but even if they were created as Shadow DOM elements (in browsers that support Shadow DOM), you can still style them with CSS ;)

X-Tag was just added as an official Mozilla repo on Github - it's a small, JS-only polyfill that enables the Custom Element portion of the W3 Web Components spec (https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/...) and other convenient mechanisms to generate awesome components. X-Tag has broad support coverage for a huge percentage of browsers in active used today on both mobile and desktop - Firefox 5+ desktop/mobile, Chrome 4+ desktop/mobile, Safari 4+ desktop/mobile, IE10 desktop, Opera 12 desktop, and all Android 2.0+ stock browsers.

A couple quick, important clarifications:

The parse does not turn the custom tags into divs, there is no need to do that. These are fully capable, valid tags and exist in the source just the way you write them: <moz:sometag></moz:sometag>. Check out the demo linked to in the repo and you'll see ;)

Also, the way the code works is even a bit better than you described in the dynamic creation case. Let's take your example:

    var slider = document.createElement('slider');

you would actually receive a _fully inflated_ element that is already event-bound when it is returned out of document.createElement, pretty sweet right? The innerHTML value of slider would literally read:

    "<moz:sliderknob></moz:sliderknob>"

Yeah Greg, I must say, do you really think David's (or any web-savy developers) passwords are "password" or "root"? Highly unlikely bro. Anywho, CSS Tricks and a few others were jacked too, so there goes the simple password explanation eh?

I would look at MooTools, their approach to OO JS abstraction keeps your JS heavy web apps lean and mean!