BT
x Votre opinion compte ! Merci de bien vouloir répondre au sondage InfoQ concernant vos habitudes de lecture !

Mozilla Brick : une librairie "Polyfill" pour les Web Components

par Dio Synodinos , traduit par Philippe Charrière le 23 sept. 2013 |

Les Web Components sont une spécification du W3C dont le but est de permettre aux développeurs web de réaliser et composer facilement des widgets avec un haut degré de richesse visuelle et d'interactivité. En attendant que les Web Components soient supportés correctement dans les navigateurs, les développeurs peuvent utiliser la librairie Brick qui offre de nouvelles balises HTML (tags) personnalisées pour abstraire les patterns courants d'interface utilisateur.

Brick est basé sur la librairie polyfill X-Tag, aussi, pour pouvoir exécuter du code s'appuyant sur des balises de Brick, vous aurez besoin d'attendre que l'évènement DOMComponentsLoaded soit déclenché au lieu de simplement utiliser window.unload :

document.addEventListener('DOMComponentsLoaded', function(){   
    // run code here... 
});

Au moment de la rédaction de cet article, Brick consiste en 13 balises différentes (ou "bricks"), la plupart indépendantes les unes des autres, et pouvant même être téléchargées séparément plutôt qu'en un seul paquet :

  1. Appbar
  2. Calendar
  3. Datepicker
  4. Deck
  5. Flipbox
  6. Iconbutton
  7. Layout
  8. Slidebox
  9. Slider
  10. Tabbar
  11. Toggle
  12. Togglegroup
  13. Tooltip

Voici à quoi resemble la brique calendrier (calendar brick) :

<x-calendar></x-calendar>

Google, qui a une très grande confiance en l'avenir des Web Components, travaille également sur une librairie polyfill de Web Components appelée Polymer qui, tout en utilisant les navigateurs existants, essaye de pousser des technologies futures comme Shadow DOM, les Custom Elements (éléments personnalisés) et le "Model Driven Views" (spécifications déclaratives des interfaces par-dessus un modèle de données).

Il est important de noter que bien que les Web Components semblent avoir pris de la vitesse durant l'année passée, la spécification évolue vite et il y a encore des zones d'incertitude. Il ya quelques semaines Dimitri Glazkov de Google a proposé dans une liste de diffusion du W3C d'enlever l'élément <element> de la spécification. Le consensus sur ce sujet est que la syntaxe proposée pour <element> n'était pas assez bonne et que ce devrait être aux librairies d'explorer ce domaine avant que la normalisation soit définitive, comme Brian Kardell du groupe Apollo le mentionne :

Laissez un peu de champ libre à des projets comme x-tags et polymer, et même à des projets comme Ember et Angular, pour aider à se poser les bonnes questions et trouver des réponses potentiellement compétitives -- Il n'y a pas d'urgence à normaliser un niveau aussi élevé pour le moment, à mon avis (IMO).

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT