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.
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.
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 ;)
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.
I'm not sure IE9 is such a huge win. This already supports IE10, and every Windows 7 computer will be auto-updated to IE10 (if Microsoft holds to it's decision to automatically update from now on).
XP users will never get IE9 or IE10, and IE8 can't be supported unfortunately. So I guess Chrome Frame will be necessary to target IE8 users.
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.
The steps seem pretty dishonest to me. Correct me if i'm wrong, but these are the real X-Tag steps:
1. Scour the web for a plugin
2. Add the plugin script include to your page
3. Copy/Type the new HTML tag
4. Customise the plugin with your own behavior
5. Wash, Rinse, & Repeat
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
@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.
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.
The Marketplace is just the "app store" -- it's where you buy apps. You can run the apps on any supported HTML5 device after buying them. So the supported device would not provide anything more than a browser rendering engine (and some navigator.* JS methods). It won't include x-tags.
We're working on a bootstrap that you can download to quickly start developing app, and it will include x-tags (with all components). There will also be a "builder" where you can customize your version of x-tags to only include the components you want.
So the bootstrap gets you up and running quickly, and the builder is a web-based tool that lets you optimize your build of x-tags when it goes into production.
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.
So, how does this impact Web Components? It seems to fill pretty much the exact same role, but with a rather different implementation. Should I expect to see this become the new standard because there's a polyfill for it so people will start using it already, or am I gonna end up with a bunch of legacy code when something else becomes standardized? And, again like Web Components, it's duplicating functionality that's been in Internet Explorer of all places since IE5.0 with DHTML Behaviors.
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.
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.
This is really amazing. After being used to custom XML tags in Android, I so wanted to build custom HTML tags for web apps. This is exactly what I wanted!
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 ;)
This really makes me sad. Mutation events gets you to IE9 but not 8, which means this cannot be used for enterprise apps. I'll start using it in personal projects though. Love the work.
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.
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.
