jy[B]log

Je suis en train de préparer un p'tit truc qui va plaire à pas mal de monde : une réference complète de CSS 1, CSS 2, CSS 2.1, CSS 3. Mais aussi une référence complète des styles spécifiques à Mozilla, qui sont indispensables dés lors que l'on fait du XUL (cette référence est en effet déstinée à l'origine au site xul-fr, mais après réflexion, elle pourrait aussi avoir sa place autre part..).

J'en suis pour l'instant à l'étape de rentrer en base de données les noms des propriétés et pour chacune d'elles, les mots clés possibles (ce qui va me faciliter la génération de la référence dans n'importe quel format). C'est long parce qu'il me faut lire en détails toutes les spécifications de CSS. Et j'ai du me faire un petit outil en PHP pour rentrer tout ça sans y passer l'année. Il ne me reste plus qu'à faire CSS3 (enfin, ce qui n'est pas encore à l'état de brouillon préliminaire dans les specs) et CSS-moz. Pour ce dernier, ça va être plus difficile : il n'y a aucune spec. Je vais devoir donc fouiller dans le code source de mozilla. Avoir la liste des propriétés et mots clés, c'est facile car c'est listé dans deux fichiers, mais avoir la correspondance entre les deux nécessite de plonger encore plus profond dans le code source.

Bien sûr, on pourra savoir si la propriété ou le mot clé est disponible dans Gecko 1.7 (Firefox/thunderbird 1.0), Gecko 1.8 (Firefox/Thunderbird 1.5) ou Gecko 1.9 (Firefox/Thunderbird 2.0). et si il fait parti de CSS1, CSS2 etc. Les pseudos classes et pseudo elements seront aussi référencés.

Une fois cette étape terminée, il me faudra ajouter une petite description pour chacune de ces propriétés, et à présenter cette référence dont la forme reste encore à définir. J'ai notamment en tête un espèce de wiki où chacun pourra compléter la description, commenter etc. Un peu comme ce que voulait le monsieur qui se plaignait du manque de documentation (mais dont il est inutile de rappeler son nom, et encore moins son blog vu qu'il n'assume absolument pas ses propos), un peu à la manière de http://www.php.net donc, car il est vrai que leur système de documentation est pas mal, même si un peu bordélique (les extensions sont classées par ordres alphabétiques, et non pas par domaine fonctionnel, et avec le temps ça devient le bazaaaare).

Bon, aller, j'y retourne..

Si on veut utiliser Ajax sur un site web, comme sur un blog, il faut faire attention à l'utiliser correctement. En effet, mal utilisé, un site peu devenir totalement inaccessible. Prenons donc l'exemple d'un blog ;-), affichant la liste des billets, avec pour chacun le chapô, et un lien "lire la suite" pour voir le contenu. Imaginons qu'en cliquant sur ce lien, cela ne n'affiche pas une nouvelle page, mais execute un script qui va aller chercher le texte sur le serveur, l'insérer à la suite du chapô, et l'afficher. Un exemple court et simple serait de faire :

<a href="#" onclick="afficheContenu(); return false;">Lire la suite</a>

Ça fonctionne trés bien et c'est trés agréable pour l'internaute "classique" que je suis. Mais pour les autres non. À cause du #. Pas de lien. Cela devient trés génant par exemple, pour ceux qui ont le javascript désactivé, ou qui n'ont pas du tout javascript comme ceux utilisant les navigateurs textes, ou les robots d'indexations. Et ceux utilisant par exemple des lecteurs vocaux d'écran, cela pose certainement problème. J'aimerais d'ailleurs savoir comme réagit un tel système face à une page qui est modifiée dynamiquement. Avertit-il l'internaute qu'elle a été modifiée ? prend-t-il en compte les éléments de la page ajoutés ou supprimés dynamiquement ?

Donc si on veut être sûr de pouvoir rendre accessible sa page web à tout le monde, il faut toujours renseigner les liens avec des vrais urls, faire toujours en sorte que l'internaute puisse accéder au contenu via le principe de base du web : le lien hypertexte.

<a href="/blog/2005/09/14/les-travers-d-ajax" onclick="afficheContenu(); return false;">Lire la suite</a>

Ainsi, ici, si le onclick n'est pas executé pour une raison ou une autre, le navigateur affichera la page indiquée par le lien, censée contenir donc le billet entier. Dans le cas contraire, le script sera executé, et le lien non suivi grâce au return false.

L'inconvénient de la technique, c'est qu'il faut avoir deux entrées ou page sur son site : une qui affiche le contenu du billet (/blog/2005/09/14/les-travers-d-ajax), l'autre qui propose le service web permettant de récupérer le contenu via un script javascript. Mais en ayant sur le serveur une API simple et efficace comme dans dotclear, c'est un inconvénient tout relatif ;-)

Hier, dans mon billet sur des tests dans deerpark alpha2, j'écrivais que les compteurs CSS étaient buggés. En fait, c'est moi qui avait mal fait ma feuille de style et donc mon test était faux.

Pour rappel, counter-increment permet d'incrémenter un compteur, et counter-reset permet de remettre à zéro un compteur. En fait, c'est une mauvaise interprétation de ma part. Ce n'est pas à proprement parlé d'une remise à zéro. Selon la spécification, il s'agit de la création d'une nouvelle instance d'un compteur. Ce compteur est visible au niveau des balises indiquées par le sélecteur, et de leurs balises filles, mais pas dans le reste du document. Ainsi dans l'exemple :

h2:before { 
   content: counter(chapter) ".";
   counter-increment: chapter;
}
h2 {    counter-reset: section; }
h3:before { 
   content: counter(chapter) "." counter(section) ".";
   counter-increment: section;
}

Je n'ai pas indiqué de counter-reset pour le compteur chapter. Du coup il est crée implicitement à chaque fois que j'y fais appel, donc dans chaque H2. Du coup la numérotation de mes H2 ne se fait pas, et j'ai toujours 1. Pour régler ce problème, il a fallu que je fasse un reset du compteur sur la balise mère de mes h2, qui est dans mon exemple body :

 body { counter-reset: chapter; }

Ainsi le compteur chapter est crée au niveau de la balise body. Il est donc disponible dans les balises filles, et sera donc incrémenté à chaque fois qu'un counter-increment sera indiqué dans les styles des balises filles. Mon exemple s'affiche alors parfaitement dans DeerPark. À noter aussi qu'apparement le reset ne peut être fait dans un selecteur :before, :after etc..

On pourra conclure par :

1. l'exemple donnée dans les specs du w3c est faux, il manque le reset du compteur chapter
2. Opera 8 est buggé puisque dans ce navigateur, on n'a pas besoin de faire un reset du compteur chapter alors que c'est contraire à la spec.

Aprés trois semaines de vacances (oui c'était bien et c'était dans mon salon qui est maintenant tout beau tout neuf, et en Bretagne dans le Finistère Nord), et quelques jours de réadaptation à la vie quotidienne trépidente en région parisienne, je peux reprendre mes activités normales.

Comme parler des standards par exemple, et plus particulièrement aujourd'hui du style position:fixed. Certains en abusent un peu trop. Comme par exemple mettre ce style sur un menu latérale. Soyez en 800*600, ou avec des troubles de la vue qui vous oblige à zoomer, et le bas du menu vous sera inaccessible... Vous aurez beau scroller, vous n'arriverez pas à le lire en entier.

Le position:fixed est à utiliser avec modération, et pas sur n'importe quoi. Un bandeau horizontal à la limite. Et encore, en diminuant la largeur de la fenêtre, il peut se mettre à augmenter en hauteur (surtout si il est conséquent à la base), jusqu'à rendre inaccessible le contenu qu'il y a en dessous.

Le célèbre livre "Designing With Web Standards" du non moins célébre Jeffrey Zeldman dans le domaine des standards, sortira traduit en Français, Jeudi prochain, aux éditions Eyrolles. Cette traduction, relue par le célébre Olivier Meunier, est accompagnée d'une préface rédigée par dautres célébrités, à savoir Tristan Nitot (oui, encore lui !) et Laurent Denis.

Bref, que du people autour de cette publication :-) (Sauf la traductrice/traducteur apparement, car personne n'en parle; va falloir que je l'achete pour savoir qui c'est :-) ).

Si vous êtes développeur web, un livre à lire assurement.

Mise à jour 08/04/2005 : le traducteur est Sébastien Blondeel, d'aprés Tristan Nitot.

Le printemps est synonyme de reveil, renouveau, renaissance. Il en va de même pour le deuxième anniversaire d'Openweb.eu.org cette année. Grâce à de nouveaux arrivants dans l'équipe de contributeurs, le site n'est plus à l'abandon. Vous pouvez lire d'ailleurs le billet qu'à écrit Laurent Denis à propos de cet anniversaire, et puis bien sûr, aller lire les nouveaux articles sortis aujourd'hui.

Quant à moi, je vais aussi refaire un come-back puisque j'envisage d'écrire un article sur Ecmascript (donc JavaScript). C'est un sujet peu développé sur openweb, et surtout sur lequel il y a beaucoup d'a priori. Je le vois en lisant les remarques de ceux qui découvrent XUL & cie sur http://xul-fr.org. En effet, javascript est l'un des piliers principaux d'une application XUL, et provoque trés souvent une méfiance : Quoi, javascript ? Bof ! On ne peut pas utiliser autre chose ?.

Cette méfiance est due bien souvent à une méconnaissance du langage, à sa mauvaise réputation (conséquence de sa mauvaise utilisation dans les pages web en général) et au mélange entre le langage en lui même et les objets fournis par les navigateurs (c'est trés souvent ce dernier point qui provoquent des incompatibilités, ce n'est pas JavaScript).

Bref, Javascript a mauvaise presse. Je tenterais donc, dans la limite de mon temps libre (comme toujours), de corriger le tir et de montrer que Javascript n'est pas un langage de script plus mauvais qu'un autre, et que l'on peut faire des choses trés évolués avec. D'ailleurs, Google, dans ses applications (de mail, de cartographie et autre) en fait un usage important, et je m'amuse de la réaction de beaucoup de personne étonnées que l'on puisse faire des choses pareils avec du JavaScript (preuve que peu de développeur web le connaisse vraiment).

Il y a un truc qui me fait halluciner parmis les habitués des forums, c'est l'engouement de certains pour le bbcode. Ils trouvent cela génial. Je vous avoue que je ne les comprends pas. Comment peut-on apprécier ce genre de balisage pour mettre en forme un texte ?

Lu sur Blogzinet et sur le blog de Laurent d'embruns.net :

Google, soutenu par les acteurs du blogage et ses principaux concurrents, propose une méthode de codage des liens hypertextes pour tenter de limiter le spamming des commentaires de blog.

En résumé : mettre rel="nofollow" dans des balises a ou link indiquera à Google et à d'autres moteurs de recherche de ne pas suivre le lien, ce qui empêchera la prise en compte de ce lien dans le calcul du pagerank du site concerné.

Ça m'a tout l'air d'être une idée géniale :-) Bye bye les spammeurs de blog !!

Edit : La méthode est soutenue aussi par yahoo et msn search

Tiens, vnunet.fr affiche aujourd'hui un nouveau design, basé sur CSS et s'appuyant sur une structure XHTML sémantiquement correcte. Un site grand public de plus en CSS ! Bon par contre, ça ne valide pas, à cause de ces scripts javascript de pub à la c** ,qui ne sont pas encadrés par des commentaires html (pubs qui ne s'affichent d'ailleurs pas chez moi, grâce à l'extension Adblock ;-) ).

J'allais quand même pas finir cette fin d'année sans un teaser ! Donc en voilà un (eh eh, je vous sens interrogatif là..).

Aprés des dizaines d'heures de boulot (oui là je sais, vous vous dites, ppffff qu'est qu'il nous a fait encore), sans que moi-même ait fait quelque chose ( qu'est ce qu'il nous raconte là ? ) , ça va bientôt sortir au grand jour (ah ? on devient perplexe je sens), trés bientôt même (attention, votre rythme cardiaque s'accelère). Ça sera plus beau, plus haut, plus fort, plus plus plus plus plus ( oui, c'est là que vous commencez à être impatient). D'ailleurs en voici un tout petit aperçu minuscule :

(à ce moment là, vous devriez ne plus tenir en place)

Bon, malheureusement, il faut que je me sauve, je ne vous en direz donc pas plus ! (ouuuuuh une envie de m'étriper vous prend, vite vite je sors..)