Mozilla publie Brick

Actuellement (dans les navigateurs ne gérant pas encore les Custom Elements), les balises qui n'existent pas héritent de l'interface HTMLUnknownElement. Elle n'a donc aucune propriété, méthode, et hérite de la mère : HTMLElement. (comme tous les autres éléments HTML).

Pour les navigateurs qui gèrent les Custom Elements (aucun nativement encore si je ne m'abuse ! Chrome 31 sera un des premiers à être en accord avec la spéc.), une balise "non enregistrée" au format "Custom elements" héritera de l'interface HTMLElement directement et sera affublée d'une sorte de tag "unresolved" (accessible via le sélecteur :unresolved) (comprendre : le navigateur se dit que la balise a le potentiel d'en être une, mais qu'elle n'est pas encore implémentée).

Les balises "customs" devront comporter un "-".
Les "unresolved element" héritent de HTMLElement si le navigateur supporte l'API (exemple : <x-calendrier>, <mon-element>
Les "unknown element" (non enregistrés, ne peuvent pas être des custom elements) héritent de HTMLUnknownElement (exemple : <x_calendrier>, <mon_element>

Source

------

x-tag de Mozilla (sur quoi est basé Brick) et Polymer de Google sont des polyfill qui permettent donc de supporter déjà les Web Components dans nos navigateurs. N'importe qui peut créer déjà ses propres éléments.

Il faut voir ces éléments comme des trucs qui encapsulent tout un tas de balises, de styles, de scripts qui seront propres à la balise et n'entreront pas en conflit avec les autres styles de la page

voila tout ce qu'on aimerait voir intégré dans HTML6 ... avec juste 20 ans de retard sur le développement natif

A propos de l'auteur, Leon Zhang :
En gros, c'est un stagiaire qui a pondu ça Chapeau, à première vue ça a l'air d'être un bon POC des, tout chaud, Composants Web.

Source

Ca me fait penser a BootStrap, sauf que ca a l'air plus compliqué et nécessite une nouvelle montoure d'HTML.

C'est pas une "nouvelle mouture" de HTML, puisque n'importe quel navigateur qui supporte HTML5 peut le comprendre... c'est juste des éléments "custom". Perso je vois pas trop en quoi ça pose un problème... avec bootstrap, il faut connaitre les noms des classes CSS, avec Brick il faut connaitre les noms des éléments. Finalement ça revient un peu au même...

(corrigez moi si je dis n'importe quoi, le dev web n'est pas du tout mon domaine...)

Je pense que cela va dans le bon sens, une sorte de standardisation de composants "évolués". Comme il y en a eu pour la programmation native (Windows / Linux ou autre).

Comme le dit Kaamo, chapeau bas au stagiaire à l'origine du projet.

Et comme le dit Paul TOTH, une intégration au standard HTML6 serait encore mieux.

Les Custom Elements vont sans doute remplacer à l'avenir les traditionnels plug-ins UI jQuery/MooTools et autre. Le composant est isolé du reste du site, qu'il s'agisse du DOM, du style CSS ou du scope Javascript. Cela facilite l'implémentation et supprime a priori tout risque de conflit.

Par contre si l'on externalise tous les composants UI des sites, j'espère qu'on aura trouvé d'ici là une meilleure solution pour que le client puisse les télécharger en parallèle ou pour générer des bundles comme propose Brick.

Aussi, entre les X-tags, les Shadow-DOM et les templates/imports HTML, ça devient difficile de s'y retrouver. Espérons qu'on arrive à un peu plus d'homogénéité dans les prochaines années.

A priori on pourra importer un composant via un HTML import (un peu comme on importe une feuille de style aujourd'hui).
Il y aura sûrement des sortes de CDN qui délivreront les composants.

Bref, faut attendre de voir ce que ça va donner.

Concernant les ressources, voici ce que j'ai pour suivre ça de près :
- y'a de bons tuto sur HTML5Rocks,
- l'avancement dans le support (caniuse, html5please)
- Suivre E. Bidelman (G+, Twitter) qui tient une feuille complète concernant les ressources utiles

Des composants tout chaud, prêts à être importés et être utilisés :
- Polymer elements
- customelements.io
- x-tags