Développement web

Dans mon boulot on travaille uniquement avec des fichiers source en UTF8, notre site principal est en python mais j'ai des outils de maintenance extérieurs au site qui sont en PHP, étant donné que l'on travaille avec une bonne centaine de bénévoles qui ont accès au svn où nous stockons les fichiers de traduction et que nous avons des milliers de fichiers, il arrive qu'un bénévole envoie un fichier dans le mauvais encodage (genre Latin 1 pour certains europeéns et UTF16 pour certains asiatiques) et là, pour Django, c'est le drame :)

En bash on peut lister tous ces fichiers assez facilement et se créer un alias pour ça :

find . -type f -name "*.lang" -exec file --mime {} + | grep -viE "utf-8|us-ascii"

(via mon collègue italien Francesco Lodolo bien meilleur que moi en bash :) )

Ça marche bien mais je préfèrerais pouvoir afficher cette information dans mes tableaux de bords que je consulte en permanence, j'avais donc besoin d'une fonction pour détecter l'encodage des fichiers et j'ai pas mal sué pour trouver quelque chose qui marche correctement.

Ma première solution qui marchait a été celle là :

function isUTF8($file) 
{
    return in_array(exec('file --mime-encoding -b ' . $file), ['utf-8', 'us-ascii']) ? true : false;
}

function isUTF8($filename)
{
    $info = finfo_open(FILEINFO_MIME_ENCODING);
    $type = finfo_buffer($info, file_get_contents($filename));
    finfo_close($info);

    return ($type == 'utf-8' || $type == 'us-ascii') ? true : false;
}

J'ai fait une petite vidéo de démo de l'utilisation du serveur web intégré dans PHP 5.4, vous la trouverez ici :

Je me suis pas mal amusé ces derniers temps avec les nouvelles possibilité des CSS (angles arrondis, ombres de boîtes et de texte, dégradés de couleur) pour voir ce qu'il était possible de faire avec ces nouveaux outils. L'intérêt de ces règles CSS c'est qu'elles permettent très souvent d'améliorer facilement un site web existant à peu de frais sans pour autant casser le site pour des navigateurs plus anciens (et par anciens navigateurs, j'inclus Firefox 3, Opera 10, Safari 3, les versions de Chrome vieilles de plus de 6 mois... ;) )

Ces règles sont parmi les règles CSS les plus intéressantes car le dégradé est un effet courant sur le web et les faire par css permettra de remplacer de coûteuses requêtes http pour des images. Sur la page des labs du projet Kompozer, j'ai combiné plusieurs de ces effets pour voir ce qu'on pourrait faire, notez par exemple le titre KompoZer Labs qui ne contient aucune image mais est une combinaison de dégradé, arrondis et d'ombrages sur une balise <h1>.

Pour ceux qui n'auraient pas un navigateur très récent, voici une capture d'écran montrant cette page dans les dernières versions de Firefox Trunk et Chromium sous Linux :

On peut noter que Chromium bien que supportant les dégradés CSS depuis plus longtemps que Mozilla a des bugs de rendus assez importants avec un très fort effet d'escalier dans le dégradé d'arrière-plan et beaucoup de mal avec les dégradés progressifs sur le h1, ça donne vraiment l'impression que le dégradé est calculé sur 256 couleurs seulement. Ça m'a un peu surpris car il me semblait que Webkit malgré un support imparfait des dégradés ferait mieux que gecko puisqu'ils avaient implémenté le draft CSS bien avant nous (ce qui explique leur syntaxe CSS assez compliquée pour le moment, elle a été simplifiée depuis et c'est ce que nous utilisons). En plus Paul me disait qu'il était sûr que sous Windows il n'y avait pas d'effet d'escalier sous Webkit,  j'ai donc lancé Virtualbox pour vérifier et voici la capture d'écran avec Safari 4, Chrome 3 et Firefox 3.6b5 :

Là on peut voir en fait que Webkit sait bien gérer les dégradés mais que c'est dans le fork Chrome de leur moteur de rendu qu'il y a un problème puisque Safari a un rendu correct. On notera aussi sur la capture de Chromium sous Ubuntu plus haut que le support des bords arrondis avec ombrage qui les suit devient enfin correct (il y a deux mois c'était pété de chez pété). Le rendu des polices avec ombrage diffère aussi entre Safari et Chrome, la version Safari est strictement identique à celle de Gecko alors que Chrome a un rendu trop léger à mon avis, on voit à peine les passages en gras.

À surveiller donc dans les mois à venir, ça pose la question du support correct des technologies dans les navigateurs, je me demande aussi comment se font les arbitrages dans le projet Webkit qui est maintenant bicéphale, le gros du développement du moteur de rendu étant assuré par Apple alors que Google a le gros des utilisateurs Webkit avec Chrome.

Je vais mettre sur le carnet de temps en temps des astuces que j'utilise pour la conception web, donc essentiellement du php/mysql/css/js/html...

Rien de révolutionnaire, le développement web ce n'est finalement pas mon métier, mais ça peut servir à d'autres personnes qui cherchent des astuces simples leur facillitant la vie.

Aujourd'hui donc, voici une astuce permettant d'organiser et d'optimiser le chargement de ses feuilles de styles. La problématique consiste à diminuer le temps de chargement d'une page en diminuant la taille de la feuille de style d'une part et en combiant les feuilles de styles multiples d'autre part.

Si on a une mise en page en feuilles de styles un peu complexe, on modularise en général ses règles, ce qui donne quelque chose de ce genre :

<link rel="stylesheet" href="/theme/miseenpage.css" type="text/css" media="screen">
<link rel="stylesheet" href="/theme/formulaires.css" type="text/css" media="screen">
<link rel="stylesheet" href="/theme/pageaccueil.css" type="text/css" media="screen">
...

Ma solution pour améliorer le rendement est de combiner ces fichiers via php et de les renvoyer compressées par gzip, ainsi on économise à la fois sur le nombre de connexions pour obtenir plusieurs petits fichiers et on envoie un seul fichier compressé :

<link rel="stylesheet" href="/theme/" type="text/css" media="screen">

Dans le dossier theme je mets un index.php avec le code suivant :

<?php
header("Content-type: text/css; charset=UTF-8");
ob_start('ob_gzhandler');
include "miseenpage.css";
include "formulaires.css";
include "pageaccueil.css";
ob_end_flush();
?>

Le SGC (système de gestion de contenu, CMS en anglais) PlumeCMS vient de sortir en version 1.2 et c'est la première mise à jour majeure de ce programme depuis un an.

Je joue avec depuis hier et ça m'a décidé à migrer un de mes sites avec lui car il a les avantages suivants :

• il est léger
• il a un système de cache simple et flexible
• il produit du XHTML propre
• il a une interface d'administration inspirée de Dotclear, claire et facile d'emploi
• il produit automatiquement un flux RSS des nouvelles et un plan de site (plan que j'édite actuellement à la main)
• il a un système de gabarits (templates) plutôt clair et pas compliqué
• il a un éditeur de texte interne visuel (wysiwyg)
• il produit des URL signifiantes avec ou sans url-rewriting
• il a un système de thèmes et de plugins qui devrait assurer l'évolutivité
• ce n'est pas une usine à gaz qui recquiert 3 semaines d'apprentissage pour afficher 4 pauvres pages

Il devrait donc remplacer avantageusement mon système de template/cache maison tout en m'offrant des fonctionnalités dont je ne disposais pas (moteur de recherche interne, plan de site mis à jour automatiquement, rédaction des news en visuel par quelqu'un qui ne comprend pas le html...).

Je suis clairement séduit par cette nouvelle version de plume, qui plus est, le thème par défaut est tellement chouette que je le garderai presque sans modification. Bien sûr il y a quelques petites bricoles à améliorer, en particulier il manque une documentation récente, je ne sais même pas où trouver la liste des fonctionnalités, heureusement que l'interface est claire et qu'on découvre tout facilement!

Voilà, PlumeCMS c'est bien et il mérite d'être plus connu, d'où ce billet.

Quelques sites faits avec Plume :

• Aozeo
• Ferme Auberge de la Faye
• Alsacreations

My English-speaking readers may think that localization is just a step you have to think about when you make software, like burning the CDs, having promotional T-shirts printed or visuals for the press and trade-shows. That's actually a big mistake and a mistake that many projects experienced the hard way. For any big software project, localization is not one of the final steps of the software production process, localization has to be part of the whole process.

That's true for software and that's true for web content. Actually, I would compare it with designing standards-compliant web pages. Many web-designers make web pages using old crappy html hacks dating back to the late 90s and when the project is nearing completion they decide to make it standards compliant. The result is that they spend way more time twiddling with their code to make it pass the HTML validator than they would have spent learning how to directly produce well structured html.

Of course you always think that your framework is well designed, that your page template is flexible and that the text is pretty simple and therefore shouldn't be difficult to translate... Self-confidence is the biggest mistake, that's forgetting Murphy's laws: if things can go wrong, they will go wrong. Things that look simple and straight-forward to you are likely to be considered way more complex with somebody's else eyes, especially if he is from a different culture.

A few common traps we had to deal with in Mozilla Europe :

• Translations are usually 30% longer than the original text, not only because English has a less verbose syntax but also (and probably mostly) because you have to transpose an English way of explaining things into your own language. That's usually not a problem, except when you have to make the text fit in a small little graphics box like the download box or a menu item, "Free Download" or "Press area" can be a long sentence in some languages.


• What happens if there is no version of the software in the language of the visitor because it hasn't been released yet? We chose to propose both the newer English version and the last version of the software that is available in the visitor's language. But wait, wouldn't a Czech be more happy with a newer Slovak version than an English one? Isn't a Catalan or Galician more likely to prefer a Spanish version of Firefox or Thunderbird if it is not available in their language rather than an English version? That's the kind of problems that impact not only the visual design but also the script logic behind the scene, something you have to discuss with localizers because they know best.


• Screenshots. Supporting 22 languages means supporting 22 different sets of screenshots, it means using as neutral as possible webpages pictures, without references to a specific culture. The Mozilla.com Firefox screenshots on the right column are examples of something we can't really use since they are US-centric, a "way to san jose" text in the search bar or the New York Times - CNN tab titles don't really cut it in Cyrillic language...


• Text as images are usually a bad practice as they can't be re-used in other languages and are simply more difficult to update, see for example the Firefox has been updated page. This page isn't localized yet but one thing is sure, either we remove these text-based images or we automatically generate them server-side which can prove tricky. (Actually, there is a third solution which is to use SVG or Canvas, which would I think make sense for a Firefox only page).


• The original text may simply be irrelevant in the target language or need a total rewrite to make sense. Here is an example taken from mozilla.com current download page that is not really relevant outside of the US : Firefox 1.5 (Windows version) is also the first browser to meet US federal government requirements that software be easily accessible to users with physical impairments.. If you want to reuse this point, you need to know what the current situation is with your own regional laws, but most of all, it poses the problem of geography targeting vs. language targeting. This point is valid for a US citizen, who may speak Spanish as his first language, but not for an English native speaker living in Belfast. The fact that translations are planned may impact the very content of your original text.

The above points are just a few examples to show that the devil is in the details, and once you deal with many languages you have to deal with many details related to culture, fonts, visual design and even unexpected Gecko bugs in Right To Left languages for instance. Of course, if it were as easy as it looks at first sight, all big projects would have multilingual websites.

In this article, I just talked about a few technical traps to underline what kind of problems you are likely to meet when working on content meant to be internationalised, but let's not forget the human factor in a project where web content localization means dozens more people involved in the project living in different countries and timezones. We certainly have to work on making this collaborative work easier for web content just as we did in the last two years product-wise. The English-section of this blog is one of the tools I will use to get feedback from the community but more things are coming.

If you want to follow the English articles only from the blog, use this RSS feed: http://chevrel.org/fr/carnet/rss.php?lang=en

Récemment, Darin Fisher a introduit dans mozilla le support de l'attribut ping pour les liens en html. L'attribut ping est une des propositions du groupe de travail WHAT dont l'objectif est de moderniser le HTML actuel afin d'arriver à un HTML5, tout en restant totalement compatible avec le HTML4.01 actuel. Ce groupe s'est créé pour pallier au fait que le W3C n'est plus intéressé par une évolution du HTML depuis plusieurs années, les membres de ce groupe sont essentiellement des développeurs Mozilla, Opera et Apple.

Ping, de quoi s'agit-'il ?

Le principe de fonctionnement de ce nouvel attribut pour les balises a est que si l'on clique sur un lien ayant un attribut ping, le navigateur effectuera une requête http vers les urls présentes dans cet attribut. Il s'agit donc d'un moyen d'informer des serveurs que le lien a été cliqué, serveurs pouvant être le serveur d'origine ou (surtout en fait) des serveurs externes qui collectent ces informations pour les étudier (liens les plus populaires, comptabilité des clics pour la rémunération des bannières publicitaires...). Il s'agit donc d'un procédé supplémentaire de pistage des clics des utilisateurs sur une page.

L'idée derrière l'ajout de l'attribut ping est de fournir une solution aux publicitaires pour comptabiliser les clics de leurs partenaires et récupérer des informations sur l'agent utilisateur utilisé sans avoir à effectuer une redirection sur le serveur et donc mettre une page intermédiaire à cet effet, concrètement, il s'agit de remplacer des liens du type : <a href="http://serveurpub.com/redirect.php?id=123">lien vers toto.fr</a>

par des liens comme celui ci :

Pour être clair, actuellement les sites comptabilisant les clics actuellement travaillent de la manière suivante :

1. clic sur un lien du type <a href="http://serveurpub.com/redirect.php?id=123">lien vers toto.fr</a>
2. le navigateur fait un passage par la page http://serveurpub.com/redirect.php?id=123 qui s'occupe de comptabiliser le clic dans une base de données avec les entêtes http classiques envoyés par le navigateur (je viens de telle page, je suis tel navigateur, ma langue par défaut est le français...)
3. la page ci-dessus vous redirige vers la page que vous voulez vraiment visiter, c'est à dire toto.fr

L'idée est donc de demander au navigateur de contacter directement le site, ce qui offre théoriquement les avantages suivants (avantages essentiellement mis en avant par Darin et Ian Hickson qui a eu l'idée de ping au départ) :

• le chargement de page est plus rapide puisqu'on va directement sur la page de destination (les pings sont faits en arrière-plan en asynchrone)
• il y a une plus grande transparence puisque l'on voit dans le code html quels sont les pages contactées et on peut donc prévoir un mécanisme pour l'afficher dans le navigateur. Dans le cas de la redirection côté serveur on ne sait pas quels sites collectent ces infos.
• l'utilisateur pourra désactiver la fonction dans les préférences de firefox

Voici le message ayant lancé la création de l'attribut ping : <a href="" ping="">.

Pourquoi je pense que c'est une fausse bonne idée

Le principal problème de cette proposition de nouvel attribut est que les avantages pour l'utilisateur n'apparaîtront que dans un seul cas : si cette méthode remplace la méthode actuelle de redirection côté serveur. C'est une énorme hypothèse qui personnellement me semble tout à fait irréalisable pour les raisons suivantes :

• la méthode actuelle fonctionne pour tous les navigateurs, 100% de réussite, puisqu'elle ne dépend pas de la configuration et des possibilités des différents navigateur mais uniquement du serveur publicitaire. Pourquoi un site commercial abandonnerait-il un système qui fonctionne parfaitement pour tous les navigateurs pour le remplacer par un système qui ne marchera que pour 10, 20 ou 30% des visiteurs ?
• les utilisateurs pouvant désactiver les pings, pourquoi les annonceurs remplacerait une méthode qui permet de comptabiliser tout le monde à coup sûr par une méthode où le client final peut ne pas être comptabilisé?
• même si firefox, opera et safari (tous membres du whatwg) intègrent cette fonctionnalité, Internet explorer ne l'intègre pas et la majorité des utilisateurs seraient donc invisibles pour tout annonceur sauf si... il conserve son système actuel de redirection serveur. Même dans le cas improbable ou le futur IE7 intégrerait l'attribut ping (sience-fiction), IE6 ne l'intègre pas, IE6 est encore là pour un bon bout de temps, ce n'est pas demain que l'on vera un IE6 à un taux inférieur à 5% de part de marché...

Est-il raisonnable de penser que les entreprises dont les revenus dépendent entièrement de la comptabilité des liens cliqués vont abandonner un système parfaitement fiable, dont personne ne se plaint vraiment, pour un système ne fonctionnant que chez très peu de gens et qu'ils ne pourront pas contrôler ? je ne pense pas.

Pourtant, ce sont les publicitaires eux mêmes qui ont demandé si un tel système pourrait être intégré à HTML5 :

> - Nobody would really make use of it.

The suggestion for this originally came to me from Web advertisers, so I'm not sure this is necessarily true.

(Ian Hickson répondant à une critique sur la liste de discussion)

Il est clair que des boîtes de pub sont intéressés par l'intégration d'un tel système, et comme commercial et codeur amateur je peux comprendre pourquoi. Ce n'est pas dans le remplacement de leur technique actuelle côté serveur que je vois un intérêt marketing, c'est en complément de celui-ci pour des usages nouveaux. Avoir la possibilité de comptabiliser les clics sans passer par une redirection serveur permettra de proposer des accords commerciaux avec des gens refusant de voir leur site promu par une direction passant par un serveur externe car cela nuit à leur stratégie de référencement. On peut aussi imaginer sans difficulté que faire effectuer le boulot côté client permettra de profiter des avantages d'un navigateur, à savoir la possibilité de manipuler ces liens avec attributs ping par javascript et de changer leur apparence par css. Il sera ainsi possible de proposer de nouvelles formes de partenariat pubicitaires à des sites à base uniquement de javascript et de css, un simple include d'un fichier javascript et d'une feuille de style dans les entêtes d'un portail et il sera possible de modifier tous les liens pointant vers le site partenaire du jour sans avoir à toucher au contenu (ajout des attributs ping sur les liens déjà existants par parcours du DOM) et en plus de les styler de manière "promotionnelle". Il ne faudra pas longtemps pour voir des feuilles de style insérées par les agences de pub dans leurs sites partenaite contenant des trucs du genre a[ping="alcatel.google.com"]:after {content:" (nouveau site!)"}.

En fait, c'est même assez génial comme technique puisque ça permettrait à un site d'ajouter un système de comptage des liens pour une opération commerciale et de les styler de manière à les distinguer des autres sans avoir à toucher à son contenu (très important quand le contenu est syndiqué et produit par une autre équipe). On peut imaginer de nouveaux types de liens promotionnels destinés à une nouvelle clientèle de gens qui trouvent les système d'affiliation à des programmes publicitaires trop lourds car soit trop intrusif dans leur site (bannières, google ads...), soit trop complexes à mettre en place (liens avec redirections nécessitant une modification du html+langage serveur). Un nouveau système de comptabilisation des liens, plus réactif, plus facile à mettre en place, liens stylables à distance sans intervention aucune sur le corps HTML, visant une cible de geeks (les utilisateurs de Firefox) c'est tout simplement toute une gamme de nouveaux services publicitaires à proposer.

Dans tout cela, les avantages pour l'utilisateur final sont minimes (s'ils existent) et dans le meilleur des cas, on aura des internautes beaucoup mieux informés certes mais aussi beaucoup plus pistés à mon avis.

Les autres problèmes possibles

Outre le problème central de la simple utilité de ce nouvel attribut html, il y a à moins avis plusieurs autres problèmes posés par cette nouveauté. Il est tard donc je les listerai rapidement :

• Les attaques de sites pas deni de service (DoS). Darin a écarté assez rapidement cette possibilité dès le départ avec comme argument qu'il est déjà possible d'utiliser d'autres balises pour le faire (img, object et iframe en particulier) et donc que ce n'est pas une nouveauté. Oui mais... Le lien est la base du web, en fait le web ce sont les liens, il ne s'agit pas d'une balise quelquonque. La base de la plupart des outils de publication est la possibilité d'insérer des liens (blogs, commentaires, sites de nouvelles type digg, forums...), quand je lui ai signalé que si j'arrive à pousser un lien dans une série d'attributs ping en première page de slashdot je pourrais attaquer un site, il m'a dit que c'était de la responsabilité de slashdot de nettoyer la balise de lien avant publication; je veux bien mais ça veut dire que tous les systèmes de publication dans le monde vont devoir ajouter un système de nettoyage des liens insérés dans leurs pages parce que cet attribut n'existait lorsque leur CMS a été conçu? Et qu'est-ce qui se passe si un ver se propage et modifie les liens de milliers de sites en ajoutant des attributs pings sur tous les liens qu'il trouve ? Je veux bien croire que les attaques par DoS soit un fantasme mais alors pourquoi ça a été évoqué dans la discussion du WHAT lors de la création de l'attribut sans que personne ne démente formellement la possibilité ?
• L'interface utilisateur. Ce nouvel attribut veut dire que d'une part il va falloir informer l'utilisateur sur les liens pingés (sinon ce n'est pas la pein de parler de transparence) et que d'autre part il faut rajouter la possibilité de le désactiver facilement, sans oublier que le minimum serait de pouvoir mettre certains sites sur liste noire. Pour la désactivation j'ose espérer que ce sera faisable depuis les préférences et pas depuis about:config, pour l'interface utilisateurs je n'ai aucune réponse claire à ce sujet. Comment informer l'utilisateur des liens pingués sans que ce soit pénible ? Si je dois voir une infobulle à chaque lien me présentant les liens pingués, à ce moment mon interface est moins agréable que mon Firefox actuel puisque pollué par des liens pseudo-informatifs (les annonceurs annoncent les pings qu'ils veulent après tout, rien n'empèche de pinger directement sur le site client d'autres sites différents...). Comment alourdir l'interface de Firefox pour rien...
• Des implications légales ? Actuellement c'est le serveur de redirection qui se charge de pinger les sites, si c'est le client, ça veut dire que c'est la responsabilité du surfeur. Tous les utilisateurs de firefox ne vivent pas dans des démocraties après tout, je ne suis pas sûr que ça simplifiera la vie du surfeur qui vit dans une dictature si il doit se demander si sa machine ne va pas établir des requêtes avec des sites interdits dans son pays à chaque clic sur une page (genre des liens dans les pings vers des moteurs de recherche interdits en Chine). Si une attaque par déni de service utilisant ce nouvel attribut ping a lieu, est-ce que le projet mozilla ne pourrait pas avoir des problèmes et présenté comme seul responsable ? Finalement, on est en train d'implémenter quelque chose qui n'est pas encore standard, depuis une spécification d'un groupe de travail sans existence légale.
• les dommages en termes d'image. Quoi qu'on en dise, même si les intentions sont bonnes, ce n'est qu'un système de tracking supplémentaire et si c'est implémenté dans Firefox, on verra rapidement les firewalls intégrer la possibilité de bloquer ping comme ils bloquent activex pour IE, ne serait-ce que pour ajouter un argument commercial ("nous bloquons les nouvelles menaces contre votre vie privée"). Ce n'est pour l'instant que dans des versions de travail de firefox et déjà on a eu droit à des articles extrèmement négatifs dans la presse technique à ce sujet et parmi les utilisateurs habituels de Firefox. Je n'ai aucun doute que la presse plus généraliste n'essaiera même pas d'analyser la fonction et criera au spyware, ça sera faux bien sûr, mais ça fait vendre et ça nous fait mal. Je vois déjà les titres du style "Firefox finance son développement par l'intégration d'outil destinés au publicitaires".

Finalement, la question est de savoir pour qui on fait un navigateur. Traditionnellement nous avons fait un navigateur pour deux cibles, les développeurs web et l'utilisateur final exigeant. Maintenant il faudrait aussi supporter les developpeurs web spécialisés dans la pub? On ne peut pas à mon avis courrir tous les lièvres à la fois, surtout quand les lièvres se battent pour la même carotte. Peut être aussi faut il reconnaître que les objectifs de nettoyage et de simplification du HTML sont peut être intéressants à long terme, mais qu'à court et moyen terme les redirections ne sont pas près de disparaître, ce n'est pas parce que c'est créé par le WHATWG qui a des projets d'amélioration du HTML à très long terme que c'est forcément bénéfique à Firefox qui a son propre ordre dui jour et des objectifs à court et moyen terme.

Personnellement, ping ne m'intéresse pas, je n'en vois vraiment pas l'intérêt comme utilisateur donc si un jour c'est intégré ma première réaction sera de le désactiver, c'est pas comme les cookies et javascript, ils peuvent être utilisés pour me pister mais ils ont aussi mille usages qui me sont bénéfiques. Pour ping je ne vois pas à quoi ça va me servir et d'ailleurs si c'était désactivé par défaut, personne ne s'en plaindrait ce qui prouve bien l'utilité de la chose... Je n'ai pas de désir particulier d'aider des gros portails et des boîtes de pub à enrichir leur offre commerciale en faisant le boulot depuis mon navigateur à la place de leurs serveurs, ou alors qu'ils me payent pour ça :).

Excellente nouvelle pour les designs CSS, la nouvelle méthode géniale de marges négatives sur les floats pour des designs multicolonnes récemment présentée sur PostionIsEverything, One True Layout, qui n'est pas compatible avec Firefox 1.5RC1 sera résolue pour la version finale de Firefox 1.5 (on leur a tous mis la pression sur ce coup là :) ) !

Eh oui, c'est halloween, l'occasion de faire des redesigns temporaires de sites. J'ai bien aimé celui de poui-poui design (et de manière générale j'aime bien son blog même si elle ne poste pas souvent), et comme vous l'a signalé Tristan, vous avez échappé de peu à un redesign Halloween de Mozilla Europe mais vu qu'on a pas mal de changements en cours qui pourraient interférer, on a préféré ne pas risquer le coup. J'ai donc mis la page de ce que ça aurait pu être là : Moz-Eu Halloween

Console², une extension améliorant la console javascript vient de sortir.

Cette extension permet de filtrer les erreurs par langage (JS, CSS, XML), contexte (Content ou Chrome) et par type (avertissement, erreur, message):

Présentation et téléchargement ici : Console²