Aller au contenu | Aller au menu | Aller à la recherche

lundi, avril 27 2009

Améliorations du serializer de Mozilla

Enfin ! Ça y est ! C'est arrivé dans le trunk samedi ! Mon super gros patch sur le serializer ! Il y a 10 mois j'avais commencé son développement. Je vous rassure, je n'ai pas travaillé pendant ces 10 mois régulièrement sur cette amélioration. Il y a eu beaucoup de temps morts (la faute à pas le temps), et beaucoup d'attente pour les reviews et super-review.

Qu'est ce que cela apporte ? Le support des mêmes flags de l'interface nsIDocumentEncoder pour XHTML/XML que pour HTML. Donc principalement, la possibilité d'avoir enfin du "pretty printing" (indentation, passage à la ligne au bout de X caractères etc..) lors de la serialisation d'un DOM XHTML et XML. Seul un document HTML profitait de cette possibilité. Bien sur, pour XHTML, le pretty printing tient compte de la spécificité de XHTML. Par exemple, pas de pretty printing dans les balises <pre> ou <script>.

Au passage, puisque maintenant le code du pretty printing est commun à HTML/XHTML/XML, j'ai amélioré le pretty printing du HTML. L'indentation n'est plus boguée, les sauts à la ligne se font au bon endroit etc... Ce patch corrige donc d'emblée deux bugs de longues dates, et va en permettre de fermer quelques autres assez rapidement, en espérant ne pas avoir introduit de régression (mais bien sûr j'ai ajouté plein de tests unitaires pour limiter les régressions potentielles).

Et concrètement, ce patch va permettre d'avoir un meilleur enregistrement des pages web éditée dans BlueGriffon, Kompozer, ou tout autre application qui sera basée sur XulRunner 1.9.2 minimum (dont Firefox 4)..

dimanche, novembre 6 2005

Faire de l'Ajax sans le savoir

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).

jeudi, septembre 29 2005

Ajax est déjà obsolète

À coté du buzz web 2.0 qui ne veut rien dire et ne sert à rien sinon à vendre du vent, il y a le buzz Ajax qui lui est un peu plus concret. Il fait fureur en ce moment, tout le monde veut faire de l'Ajax, et tout le monde trouve cette technologie révolutionnaire, malgré qu'elle soit vieille de plusieurs années. Mais personnellement, je trouve que cela ne va pas vraiment dans le bon sens, et qu'il serait préférable de s'orienter vers d'autres techniques plus efficace et simple pour avoir du contenu dynamique.

Lire la suite...

mercredi, août 18 2004

jsTemplateBuilder

Imagine you have some javascript data. And imagine you need to generate some xul tags from this data. The traditionnal way is to use DOM objects, with document.createElement, and setAttribute, appendChild method etc... If you have many data, the amount of code to write could be high. Very high. And it becomes difficult to debug it, to have a general view of your xml tree that you generate etc.

Another way is to use the jsTemplateBuilder object.

Lire la suite...

vendredi, mars 12 2004

Accessibilité pour tous !

Ça faisait un bout de temps qu'Eric Daspet n'avait pas blogué. Le voici de retour, mais sur un autre blog, celui de Denis Boudreau. (Il est ce qu'on pourrait appeler, un bloggeur itinérant, ou un SBF :-) ). Il nous livre, comme à son habitude, un excellent article : Oublions les handicapés.

Eric dénonce une tendance plutôt négative : celle de focaliser sur les handicapés visuels quand on parle d'accessibilité. Cela a pour conséquence d'oublier qu'il existe d'autres handicaps, d'autres raisons de faire un site accessible. Je suis tout à fait d'accord avec lui.

Être accessible, ce n'est pas qu'être accessible aux aveugles, c'est être accessible à tout le monde. Il ne suffit pas de mettre des attributs alt dans les balises img pour avoir un site accessible. Le meilleur moyen d'avoir un site accessible, c'est de respecter au minimum, tout simplement, la sémantique des balises. J'en suis intimement persuadé.

J'en profite pour jeter un plus gros pavé dans la marre (ça me démange depuis bien longtemps) : n'en déplaise à Braillenet ou à AccessiWeb, j'affirme que leurs sites ne sont pas accessibles contrairement à ce qu'ils prétendent : ils sont simplement optimisés pour les aveugles et mal-voyant. Quand on ne respecte pas la sémantique des balises, quand on utilise des tableaux de partout pour la mise en page, quand on fait un site "optimisé en 800*600", on ne peut pas prétendre avoir un site accessible. Loin de là.

Je ne saurais trop vous recommander la (re)lecture de l'excellent tutoriel Plongez dans l'accessibilité qui montre bien qu'avoir un vrai site accessible, cela profite à tout le monde, même aux personnes "normales".