HTML Overlays
Par Laurentj le lundi, août 30 2004, 13:19 - Projets - Lien permanent
Fin du teasing comme l'annonce Daniel : HTML Overlays. Un principe assez simple, déjà utilisé avec XUL :
- vous déclarez des éléments HTML dans une page web
- vous les définissez dans un fichier annexe (un "overlay")
- vous rajouter une balise
linkavec unrel="overlay"plus l'inclusion d'un script JavaScript.
Et vous avez ainsi un système qui permet d'économiser énormément de temps pour créer vos pages web (surtout à la main), et d'économiser énormément de bande passante.
Voici un petit exemple, repris de la documentation de HTML Overlays.
Voici un extrait du contenu d'une page XHTML :
<div id="navBar"/>
<div id="main">
<p>Facts about our company:
blah blah blah</p>
</div>
Vous remarquerez que navBar n'est pas définie, seulement déclarée. Voici maintenant un overlay (myoverlay.xml), qui définit le contenu d'une div ayant pour id navBar, ainsi que d'une div ayant pour id main :
<div id="navBar"> <a href="index.html">Home</a> <a href="products.html">Products</a> <a href="news.html">News</a> <a href="company.html">About us</a> </div> <div id="main"> <hr/> <h6>Copyright (c) OurCompany 2004.</h6> </div>
Le XHTML resultant dans le navigateur sera alors :
<div id="navBar">
<a href="index.html">Home</a>
<a href="products.html">Products</a>
<a href="news.html">News</a>
<a href="company.html">About us</a>
</div>
<div id="main">
<p>Facts about our company:
blah blah blah</p>
<hr/>
<h6>Copyright (c) OurCompany 2004.</h6>
</div>
Vous remarquerez donc que le contenu définit dans l'overlay est rajouté dans les éléments correspondants de la page XHTML originale, et ceci, en rajoutant simplement ces deux balises dans cette page :
<link rel="overlay" href="myoverlay.xml"> <script type="text/javascript" src="HTMLoverlay.js" />
On peut, comme en XUL, ajouter des indications pour spécifier si le contenu de l'overlay est ajouté à la suite, avant ou à tel position parmis le contenu existant de la balise conçernée.
Bref, avec ce système, vous pouvez mettre dans un unique fichier overlay vos menus, bandeaux, pieds de pages de votre site, et n'y avoir dans les pages HTML que le contenu principal de la page. Par rapport aux "Service Side Includes", cela à l'avantage d'économiser de la bande passante puisque le fichier overlay est mis en cache par le navigateur. Ça a l'avantage aussi de ne pas avoir à disposition un moteur de script coté serveur comme PHP, Perl... Les pages sont donc lisibles même en local.
Petit inconvénient : cela diminue l'accessibilité puisque le processus est en javascript (donc si par exemple les menus de navigations sont dans un overlay, on ne les a pas quand l'interpretation du javascript n'est pas disponible dans le navigateur) . Mais cela ne devrait pas être un gros problème pour les intranets ou applications web. On pourrait imaginer que ce mécanisme d'overlay soit implémenté directement dans les navigateurs (donc plus de javascript), surtout que le code est vraiment simple.
Autre petit inconvenient, . [Edit] En fait si, ça l'est.<link rel="overlay" /> ce n'est pas conforme au standard HTML. Oui, bon, là, on s'en fout hein ;-)
Commentaires
Cela peut effectivement etre utile, cependant comme cela est souligné dans le cas de menus contextuels, si javascript est désactivé ça ne le peut fait pas.
D'où ma préférence à des if () et du php pour la navigation :-)
Cela dit cela peut etre utile pour cacher des infos à d'autres applications clientes tel que les palms ?
Sinon pour gagner de la bande passante effectivement, de plus si le fichier xml est generé via une base donnée, on obtient quelque chose de trés interressant, pas mal d'applications peuvent en découler ... :-) Ca va etre sympa à utiliser !
En fait, c'est pas gagné pour le gain de bande passante. Pourquoi ? Parce que ça a beau être dans le cache du navigateur, le navigateur fait quand même des requêtes pour savoir si des fois le fichier aurait pas changer. Autrement dit, il va y avoir une requête GET pour chaque overlay plus le .js à chaque fois. Auquel on ajoute les entêtes de retour qui disent que ça a pas changé. Au final, y a pas mal de chances pour que ces entêtes dépassent la taille du code html qu'on économise à tout mettre dans un overlay. Au final, la même chose côté serveur fonctionnerait tout autant et ne consommerait pas forcément plus de BP...
Je pense que la taille du contenu des overlays est tout de même largement supérieur aux tailles des paquets échangés lorsque le navigateur vérifie la valitidité du cache. Il fait un GET, effectivement, mais suivant les paramètres de ce GET, le serveur ne renvoie pas forcément le contenu de la page. Voir les explications sur le mécanisme du cache HTTP 1.1
1591 octets. C'est la taille des entêtes requêtes + réponses juste pour dire que ça n'a pas changé. Il faut vraiment que le poids de ce qu'ajoute l'overlay soit énorme pour que ça vaille le coup.
Bon en fait, en vrai, c'est un peu moins que 1591... j'avais pas fait gaffe que la requête à l'overlay renvoyait un 200 et pas un 304 (les entêtes d'une 200 étant plus longs). Cela dit, c'est déjà 764 aller-retour pour HTMLoverlay.js. Et, *BUG*, la requête vers l'overlay n'utilise pas le cache. Pas d'If-Modified-Since ou d'ETags dans l'entête de la requête... on choppe donc un 200 à tous les coups.
Si on a un 200 à tous les coups, c'est effectivement pas cool
Et j'ai bien peur qu'il ne soit pas possible de faire autrement. Sauf modification du XMLHTTPReader... dans Mozilla. Ensuite, reste à voir si par miracle celui d'IE utilise le cache, mais j'ai peu d'espoir.
glandium< En plus j'ai l'impression qu'ils ne peuvent pas corriger ce bug. Dans le script il y a une simple requete GET faite avec XMLHttpRequest, on peut envoyer des header avec la methode setRequestHeader, mais dans ce cas ça ne va pas être très utile ;)
glandium<, si je ne me trompe pas, celui d'IE cache comme un gorait :o
techniques au demeurant qui rend le document innaccessible. Enfin c'est un détail semble-t-il...
Il est clair que le document ne sera plus lisible par aucun agent utilisateur ne possédant pas Javascript.
Mais je pense qu'il faut quand même souligner l'effort, même si cette technique n'est qu'une idée née sur un coin de table, elle n'en demeure pas moins une idée intéressante pour l'avenir du web.
Oserais-je ajouter que cette technique pourrait être intéressante pour enfin retrouver un attribut target utile en XHTML ?
<a href="overlayPlop.xhtml" target="#content">Afficher plop</a> <a href="overlayOnk.xhtml" target="#content">Afficher onk</a> <div id="content"/>
C'est le principe des ilôts de données, pas de quoi casser des briques (sans vouloir être désobligeant).
Mais ça, c'est bon pour les intranet, ou si l'on prend soin de prévoir une solution de repli en l'absence de javascript (e.g: un formulaire en plusieurs étapes pourrait se faire sans rechargement de la page si js activé, ou en passant par une page par étape si js désactivé; ou encore des listes déroulantes à remplir selon les choix effectués sur d'autres commandes).
Et ça ne fonctionnera pas dans Opera (début d'implémentation dans Opera 7.60 mais il manque beaucoup de choses). Il y a bien un patch en JavaScript (http://www.scss.com.au/family/andrew/webdesign/xmlhttprequest/) pour "l'avoir" dans Opera, mais ç'est un peu l'usine à gaz si on fait appel à chaque fois à ce genre de scripts pour toutes les carences des différents navigateurs, et le "patch" a besoin de java je crois.
L'inconvenient majeur, c'est surtout point de vue référencement. on retombe dans le même travers que les frames niveau réf si le dév décide de stocker la navigation dans l'overlay. ... enfin inconvenient d'un coté mais qui peut être un avantage aussi. on peu alors imaginer de sacrée dérive du system pour cacher du contenu aux moteurs, et ne lui servir qu'une page épurée.
au lieu de cacher au visiteur le texte optimisé (grâce à display par ex), ils vont pouvoir cacher au moteur le contenu "sans interet" (référencement parlant)
Ldo : tu oublie la balise Link. avec elle, tu peux indiquer quelle est le rapport de la page avec le reste du site. C'est à dire que tu peux y indiquer la page qui contient le sommaire, celles qui sont les têtes de rubrique etc. la balise link, ce n'est pas seulement pour indiquer la feuille de style. Donc en théorie, ne pas avoir de menu de navigation dans la page html n'est pas un problème d'accessibilité (voir Mozilla avec sa toolbar spécifique de navigation).
Je reste assez dubitatif sur la valeur ajoutée par rapport aux différentes solutions existantes, et sur le fait que cette valeur ajoutée soit assez importante pour que ça devienne une implémentation standard sur les navigateurs. Par contre, surtout : n'arrêtez pas de nous sortir des nouvelles idées comme celles là. C'est très important et c'est grace à des propositions comme ça que tout avance.
j'avais oublié Xinclude également.
Interessant et "pas con" ! Maintenant il serait bien de le mettre en pratique sur ce site ;-) ... et pourquoi pas, faire un plugin "dotclear" ;-) Sinon, il est vrai que celà vient un peu sur le terrain XML+XSLT côté client, ou le CSS3 qui permettrait de rajouter du contenu via css. Bref, que de nouvelles techniques ! Et on a toujours du bon vieux "html4 trans" ;-)
XInclude... Warf... Allez, soyons sérieux.
LaurentJ> le problème n'est pas l'accessibilité ici, je parle de référencement. imaginons une page index.htm et un fichier sommaire.xml contenant la navigation. le problème, c'est que le moteur ne va indexer que index.htm, sans y inclure la navigation.
pour la plupart des gens, cela posera problème car il ne sauront pas comment pallier cette erreur de conception (oui, comme avec les frames, on parle d'erreur de conception en référencement).
mais d'un autre coté, ceux qui maitrise les outils de recherche et connaissent bien leur fonctionnement vont se régaler avec Overlay. cela peut permettre des techniques de spam bien plus élaborée et performante qu'un simple display:none pour masquer un contenu optimisé.
Ironie, ironie :-)
J'avais encore au telephone la semaine derniere un ingenieur d'une des plus grandes boite de soft US qui me tannait sur l'accessibilite de nos produits... Je pense que ce genre de boites a un "checkbox" sur l'accessibilite dans sa liste de "requirements" et n'achetera jamais (plus :-) un produit non accessible...
Ldo: il faut VINGT secondes à Google pour se mettre à regarder les href pointés par rel="overlay"...
ok daniel, je me livrerai à de petits tests aussi ;)
par contre ton fichier demo.xml ne comporte aucun lien.
Que Google suive parfois les liens <link href ça on le sait depuis longtemps, mais rien ne dit qu'il lit le fichier attaché. et c'est justement la réponse que l'on cherche. il y a une différence entre connaitre une url et savoir ce qu'elle contient en tout cas, cela ouvre des portes c'est indéniable.
Complètement hors sujet mais je sais qu'il y a des fans ici :
Le dernier Björk est sorti aujourd'hui (presque entièrement vocal apparemment). Il ne semble pas "protégé", mais c'est un CD/SACD, je me demande si ça passe sur les autoradios ... ou ma chaine mp3.
Réponse demain matin :-)
Miracle, le CD passe bien, c'est un des seuls que j'ai acheté récemment sans protection (sinon je suis obligé de le convertir en mp3 pour les écouter sur ma chaine, un comble !)
Musicalement, la voix de Björk est toujours aussi incroyable, mais certaines chansons sont un peu déroutantes à la première écoute. En tout cas on ne peut pas lui reprocher de se répéter :-)
Mystérieux Pingouin Migrateur : chouette, je vais pouvoir me payer un cd pour une fois depuis longtemps.
Personnellement, ça me fait ça à chaque nouvel album :-) C'est pour ça que j'aime Bjork et c'est ce qui fait la richesse de son répertoire. Peu d'artistes auteur-compositeur sont capables d'une telle diversité.
Donc voila une liste de technologies possibles pour faire ce qui est proposé là. Ce qui serait c'est de voir les avantages et les bénéfices de chacune des techniques.
Un jour des commerciaux d'Akamaï étaient venu causer le bout de gras chez mon client. C'est une boite qui, pour résumer, a des serveurs partout (en france, en europe, dans le monde..) et qui propose de raccourcir les distances entre le serveur et le client, surtout pour la partie statique. Ils font du cache. C'est une solution pour "gros" site,(ce qui me fait penser q le site dont je m'occupe encore un peu est gros? C'est n'importe quoi!!) je crois me souvenir que cela coûte dans les 2000 (?) euro par mois. Mais bon, ça marche, pour les gros sites qui ont beaucoup besoin de bande passante (e.g. microsoft quand ils sortent un patch).
A cette occasion ils nous avaient montré une techno dont je ne me souviens plus le nom mais qui était assez proche de l'HtmlOverlay mais côté non plus client mais serveur et infrastructure. Tu mets dans ton html des tags pour définir que tu mets en cache des parties de ton html et que seules certaines demandent une requête au "vrai" serveur web. Ensuite, c'est l'infrastructure qui fait le travail: Pour les parties "html", qui ne bougent pas, en cache : pas d'appel au serveur. Pour les parties indiquées par des tags: appel au serveur. Par exemple, tu regardais le site de Darty : tout le html "normal" était renvoyé par akamai, et tout le dynamique par le serveur web. Il y avait aussi des systèmes de cache, pour tant de temps ... (e.g. Le Monde : la news centrale change toutes les 10 minutes, celle de côté toutes les heure...)
L'intéressant est que ce système était "ouvert", agréé par Oracle et qq autres, voire le w3c? je ne sais plus mais c'était assez intéressant. Mais demande un changement radical dans la façon de générer les vues html. Là ce système à la akamai est une sorte d'htmlOverlay fait côté serveur.
Ouf ça y ets j'ai retrouvé, c'est "Edge Side Includes" ESI. www.esi.org. Le gros pb c'est le changement dans les habitudes de devs.
Ils l'ont utilisé chez LeMonde Laurent maintenant que tu es leur nouvel ami ;-) tu peux demander ?