jy[B]log

Paris Web 2006 est une conférence sur les standards du web, les 21 et 22 septembre prochain. Vous devez y aller si vous voulez :

1. en savoir plus sur les standards, comment intégrer les problématiques de design, d'accessiblité et de qualité grâce aux standards, dans la réalisation de vos sites web, le tout expliqué par des experts dans ces domaines.
2. ne pas rater ce grand évènement, une première en France pour les standards.
3. serrer la pince ou avoir des autographes des gugusses d'Openweb et autres personnalités du web
4. voir Tristan Nitot en tutu rose, et Daniel Glazman en slip léopard
5. boire un coup avec les organisateurs

Et bien sûr, j'y serais, pour voir tout ça, encourager mes camarades d'openweb et les autres orateurs.

La syntaxe wiki a été inventé pour une chose : mettre en forme un texte de façon trés simple et la plus naturelle possible, sans avoir à apprendre ce "complexe" langage qu'est le HTML. Trés pratique donc pour les internautes qui veulent publier sur le web (au hasard, via un wiki :-) ) et qui n'y connaissent pas grand chose en techno web. Et c'est une alternative trés crédible face aux editeurs wywiwyg en ligne qui génèrent du code HTML immonde le plus souvent. Moi même j'apprecie la syntaxe wiki, dans dotclear par exemple : cela m'évite d'avoir à taper des balises html dans tous les sens.

update : parce que cela choquait certains, le titre de ce billet a été modifié et la dernière phrase de ce billet supprimé.

L'INRIA a sorti un nouveau langage/framework pour réaliser des applications "web 2.0", HOP. (Un nom bien web 2.0 tiens...).

À lire la documentation, ce langage ne m'enthousiasme pas vraiment. Il a l'air d'avoir des mécanismes qui facilite en effet la déclaration de l'attachement d'une action coté client au service web coté serveur. C'est pas mal, mais coté syntaxe, faut aimer. Mais bon, le débat n'est pas là. Il est ailleurs. Le site.

Le site en lui même est fait avec HOP bien sûr, et c'est là que l'on voit la débilité de l'usage inconsidéré d'Ajax. Le contenu de ce site est simplement de l'information, de la documentation. Rien qui ressemble de prés ou de loin à une application. Mais les auteurs semblent avoir oublié quelque chose. La simplicité, l'efficacité. Oublions les énormes avantages qu'apportent de bêtes pages html du web 0.1 dans le cadre d'un site informatif, et faisons tout en ajax.

Résultats :

• il m'est impossible de vous donner un quelconque lien vers l'une des "pages" de ce site. Même pas vers un exemple hello world, ou la page téléchargement. Rien. Nada.
• Il va être impossible pour les moteurs de recherches d'indexer son contenu. (pour un site de documentation, c'est tout de même fort...)
• Accessibilité : proche de 0 j'imagine.
• Pages lourdes (pour le contenu qui y est présenté...)
• En dehors d'un navigateur graphique avec javascript activé, point de salut.

Conclusion : Un site et une techno à oublier pour faire des sites normaux informatifs. (de toutes façons, peu de chance que les gens s'y intéressent, puisque le site ne peut être référencé correctement..).

Ça y est, le premier brouillon des spécifications de xmlHttpRequest vient de sortir.

Il n'y a pas de grand changement par rapport au xmlhttprequest que l'on trouve actuellement dans les navigateurs. Le but de cette démarche est surtout de mettre sur papier une bonne fois pour toute les spécifications de xmlHttpRequest, afin que tout le monde soit d'accord sur la façon de l'implémenter.

Par l'intermédiaire d'un billet de Fred Cavazza, je viens de découvrir le site d'un projet de blog-web-2.0-qui-déchire-sa-race. Je ne parlerais pas de cet outil de blog en lui même, pas encore terminé, et pour le moment ergonomiquement trés criticable à mon humble avis (idem en ce qui concerne l'accessibilité). Souhaitons que dans une version finale cela sera amélioré. Non, je ne parlerais que du site du projet. Je précise que je n'en veux pas particulièrement à l'auteur du site (jeune apparement). Je veux juste pointer du doigt une dérive que l'on trouve de plus en plus dans les sites web 15.0.

À la lecture de certains commentaires, j'ai l'impression que mes billets sur Ajax ne sont pas assez explicites sur ma position à propos de cette méthode, et qu'ils sont peut être assez confus, puisque j'y parle non seulement d'Ajax, mais aussi d'interface utilisateur. Voici donc quelques eclaircissements.

FasterFox est une extension pour Firefox qui, en mode turbo, charge automatiquement toutes les pages dont les liens se trouvent sur la page courante. Cela peut paraître utile pour l'utilisateur, car alors quand il clique sur un lien, la page s'affiche instantanément pusiqu'elle est déjà chargée dans le cache. Malheureusement, cela provoque une charge non négligeable sur les serveurs, voir même un DOS comme en témoigne Raphael sur le forum alsacréations. Charge d'ailleurs souvent inutile car l'internaute va rarement sur les dizaines de liens que peut contenir une page web.

En fait, FasterFox utilise (abusivement) une fonctionnalité de Firefox qui permet de faire ce prefetch. Google profite profitait également de cet fonctionnalité en y mettant la balise <link rel="prefetch" href="http://url/à/prefetcher/">, qui fait faire alors à Firefox un prefetch sur le premier résultat d'une recherche.

Heureusement, il y a une solution pour les webmestres pour empecher ce prefetch. En effet, Firefox envoi l'en-tête HTTP X-moz: prefetch lorsqu'il effectue un prefetch. Il est donc possible de détecter ce genre de requête coté serveur via des rêgles dans le fichier .htaccess ou dans vos pages PHP.

Exemple que l'on peut mettre dans le .htaccess :

RewriteEngine On
RewriteCond %{X-moz} ^prefetch
RewriteRule ^.* - [F]

En PHP, on peut faire aussi :

 if(strtoupper($_SERVER['HTTP_X_MOZ']) == 'PREFETCH';){
  ...
 }

Lire un billet de Padawan qui a fourni il y a quelques mois des exemples détaillés pour contrer Google et FasterFox (exemples de redirections etc..)

Dans un billet précédent, "Ajax est obsolète", j'expliquais que pour moi, Ajax n'est pas une solution d'avenir car trop complexe et trop bas niveau (le fameux xmlhttprequest).

J'avais alors émis l'idée d'avoir plutôt des balises spécialisées, interpretées directement par le navigateur, qui se chargeraient des opérations bas niveau et avec lesquelles on aurait juste à indiquer des informations minimales dans des attributs comme l'URL du service web à invoquer. Elles permettraient donc de faire de l'Ajax sans le savoir, sans avoir à taper des lignes de codes javascript complexes. Exactement en fait comme la balise HTML <a> ou <form>, qui utilisent finalement une forme d'Ajax sans que vous le sachiez : elles ont une url dans un attribut, elles envoient des données via xmlhttprequest à cette url, et elles modifient (ou plutôt remplacent) la page courante à partir du contenu de la réponse reçue.

J'avais donné alors l'exemple de la balise template en XUL qui est parfaitement dans cet esprit : on cache ce qui est bas niveau (xmlhttprequest), on permet d'éviter l'usage du javascript. Le résultat est alors une techno simple à utiliser pour développer, économe en temps de dev, de débuggage, et économe en bande passante ou en ressource système (il n'y a pas 50ko de scripts à executer puisque les balises sont directement interpretées par le navigateur).

Je voulais commencer à faire une bibliothèque JS qui permettrait de vous montrer concrétement mon idée. Mais en fait d'autres l'ont fait avant moi. Je suis en effet tombé, au hasard du surf, sur l'offre de backbase. Ce qui est intérressant sur ce site, c'est le code source de leur page. Que voit-on ? Des balises <include>, <event>, <buffer>, des attributs behavior, followstate etc.

On devine alors aisément à quoi elles servent : inclure des morceaux de pages à des endroits précis, qui sont éventuellement rechargés à l'apparition d'évènements particuliers, déclenchés par des actions spécifiques de l'utilisateur. En clair : vous avez le même résultat que ce que l'on fait en Ajax, mais sans avoir à écrire une seule ligne de code javascript. Quelques balises et quelques attributs bien placés, et vous voilà avec une interface utilisateur dynamique.

Exactement donc dans le même esprit que la balise html <a>, <form>, ou la balise XUL <template> : simplicité, efficacité. Bref, une techno accessible à tout développeur web, et pas seulement aux geeks.

Ce qu'a fait Backbase a toutefois un inconvénient : avoir une page utilisant leurs balises nécessite d'inclure leurs fichiers JS qui sont volumineux. Ce javascript sert à parser la page, et à interpreter les balises et attributs. On a donc une page lourde et longue à charger mais aussi longue à s'éxecuter.

Cependant, imaginez que le navigateur puisse interpreter nativement des balises du même style que celles de Backbase. Là je pense qu'on pourra vraiment parler de web 2.0 (ou 3.0 ?) ;-) (tout en résolvant une partie des problèmes d'accessibilité posés par Ajax).

De puis pas mal de temps, je suis avec attention l'évolution de l'implementation de XForms dans Mozilla Firefox. C'est en effet doublement intéressant car :

1. Firefox 1.5 sera le premier navigateur qui supportera en natif les formulaires XForms (ou quasi natif puisque xform sera livré sous forme d'extension). Ce que je veux dire par là, c'est que l'on pourra intégrer des formulaires xforms dans n'importe quel fichier XML (xhtml par exemple). Alors qu'aujourd'hui, avec les quelques implémentations qui existent, il faut soit un client spécifique, soit installer un plugin et fournir le formulaire dans un fichier séparé (bref, mettre une balise object dans son fichier xhtml).
2. Xforms apporte énormément d'améliorations par rapport aux formulaires HTML, surtout pour les développeurs.

Par exemple, XForms a des caractéristiques qui évitent le recours à des scripts additionnels dans nombre de cas, comme la validation automatique coté client. Il soulage ainsi le développeur de certaines tâches répétitives.

Une autre de ses caractéristiques qui me réjouit, c'est la possibilité de contrôler ce qui sera fait aprés envoi des données du formulaire. On peut ainsi préciser qu'il y ait un comportement comme un formulaire HTML classique (remplacement du document courant par le contenu de la réponse), mais aussi que le contenu de la réponse remplacera les données du formulaire, ou encore qu'il faille ignorer la réponse. Par exemple, on peut imaginer ce comportement : l'utilisateur cliquera sur le bouton d'envoi, les données saisies seront vérifiées puis envoyées, et c'est tout. La page ne bougera pas. Il est possible bien sûr de faire un script qui sera executé aprés envoi du formulaire pour modifier deux trois trucs dans la page par exemple. Ce qui laisse la porte ouverte à votre imagination (et donc plus de liberté dans vos applications web).

J'ai crée sur Xulfr une page dédiée à XForms. J'y ai mis entre autre une petite liste des avantages de XForms par rapport aux formulaires HTML (Si vous voulez compléter, n'hésitez pas).

Pour tester la Preview 2 de Xforms :

• Téléchargement et exemples
• La page du projet xforms dans mozilla
• La page de l'avancement de l'implementation