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

No, you'd still have to scour the web for each individual library of tags. Since they require the .register() on the page, from what I understand.

Though your last part, with <require /> is fascinating and would greatly improve this.

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.

Understand now, that would still be very valuable.

Maybe I'm misunderstanding, doesn't this mean I can use x-foo without including its js if x-foo is in the marketplace? That would be amazing.

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.

I'm aware, I submitted an app already :-).

I'm confused about what he meant about the marketplace having a "bootstrap builder" for 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.

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!

While I considered this approach to be plausible at first glance, it isn't.

For the tags to work for your users, they would also have to visit the registry for that tag.

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.