HTML Import

Comment sont créées les pages HTML ?

Lors de la conception d'un site web, on utilise le langage HTML pour créer les pages. Dans les sites, il y a souvent de nombreuses pages similaires, avec des éléments graphiques identiques: une entête avec le logo, un menu, un pied de page avec les copyrights, etc.

Ces éléments graphiques peuvent être amenés à changer: nouveau design, nouvelles couleurs, texte différent. Toutes les pages devront alors être modifiées.

Si les pages sont hébergées sur un serveur web, ce n'est pas un gros problème car elles sont souvent générées dynamiquement (Common Gateway Interface); on modifie le code qui génère ces pages, à un seul endroit.

Mais dans le cas où on n'a pas de serveur web, on parle alors de pages statiques.

Dans ce cas, le développeur qui veut modifier un élément graphique commun à plusieurs pages, par exemple le texte d'un bas de page, doit corriger toutes les pages contenant cet élément. HTML prévoit des mécanismes d'inclusion de différents éléments (feuilles de styles, images, audio, vidéos, code javascript ou ASP), mais pas d'autres éléments HTML.

Web Components

W3C, le World Wide Web Consortium qui définit les normes propres au web, dont HTML, a bien proposé depuis 2011 un mécanisme d'inclusion de HTML appelé Web Components, mais la majorité des fureteurs refusent encore de s'y conformer !

Il est possible que la situation s'améliore, poussée par les nouveaux fureteurs, mais actuellement la situation est confuse pour le développeur.

Pourquoi tant de retard ?

Web Components est partie d'une initiative de Google. Et devinez quoi ? Si les autres vendeurs de fureteurs trainent des pieds pour s'y conformer, c'est qu'ils boudent pour ne pas avoir consultés. On en est là ! Si cette attitude peut s'expliquer de la part d'entreprises commerciales (suivez mon regard vers Microsoft et Apple), c'est plus incompréhensible de la part de Mozilla (Firefox).

Pour faciliter la transition, Google a proposé une série de fonctions en javascript (polyfills), webcomponents.js, supportés par la majorités des fureteurs. C'est mieux que rien, mais ce n'est pas la panacée non plus, parce que du code interprété sera toujours plus lourd et plus lent que du code natif intégré dans le moteur du fureteur.

Donc, tant que ces petites guéguerres ne seront pas calmées, les développeurs devront se contenter de patchs ou de construire les pages web par des outils externes, et les utilisateurs auront des pages qui s'afficheront plus lentements !

Comments

Popular Posts