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

Développement web

Fil des billets - Fil des commentaires

lundi 4 novembre 2013

PHP: détecter si l'encodage d'un fichier est en utf8

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;
}
Je délégais donc au shell la détection du charset, ça marche bien, mais ça a plusieurs inconvénients. Le premier est que ça ne marche pas sous Windows, même si j'avoue que c'est pas ma priorité, l'une des forces de PHP est tout de même sa compatibilité cross-plateforme. Le deuxième problème est que j'aime pas faire des exec, je trouve souvent ça un peu crade et c'est en général l'indice que j'ai pas réussi à le faire en PHP, le troisième problème et c'est le plus grave pour moi c'est que c'est très très lent. En local avec un disque SSD, un script qui mettait 3 secondes à s'éxécuter (et qui parsait déjà un petit millier de fichiers pour chercher des erreurs de variables python dans des chaînes) est passé à 18 secondes avec cette fonction et est interrompu sur le serveur qui n'a probablement pas de ssd pour dépasser les 30 secondes.

Ça marche donc, mais c'est trop lent pour mes besoins et je ne voyais pas comment l'améliorer.

J'ai cherché du côté de mb_detect_encoding() mais j'avais des faux négatifs avec un fichier en UTF8 que je savais corrompu et que php me détectait comme de l'UTF-8 alors que bash me le détectait en fichier binaire et que mon éditeur de texte me donnait en UTF16LE sans BOM. Comme c'est précisément ce genre de problèmes que je cherchais à détecter, après plusieurs heures de recherche du côté des fonctions mb_, j'ai l'aissé tomber.

Finalement ce matin j'ai trouvé une solution qui a des perfs correctes pour mon usage (je suis passé de 3 secondes à 6 secondes et j'ai des idées dans mon contexte précis pour faire baisser ça) en utilisant les fonctions finfo_* que je ne connaissais pas ! la voici :

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;
}

La fonction ci-dessus correspond bien à mon besoin: pouvoir détecter si l'encodage d'un fichier est en utf-8 ou compatible utf-8 pour une utilisation sur le Web. Si quelqu'un a une meilleure solution, je suis bien sûr preneur :)

vendredi 7 décembre 2012

Parser des fichiers properties en PHP, ma lib pour composer

En début de semaine, mes copains de Mozilla Hispano ont lancé un projet qu'ils préparaient depuis quelques temps déjà, une petite application d'assitance aux utilisateurs pour leur page Facebook. Cette application interroge l'API du site d'assistance officiel de Mozilla (alias SUMO, pour SUpport.MOzilla.org) pour afficher les articles les plus consultés et elle dispose d'un champ de recherche qui propose des articles dans sa langue. Simple, efficace.

Ils m'ont contacté pour que je leur file un coup de main pour la localisation, comme ça l'application est disponible pour les non-hispanophones (et si vous avez un navigateur en français, le lien dans le paragraphe ci-dessus a dû s'afficher en français), j'ai donc ajouté de la détection de langue, de la détection de direction rtl pour le template et un petit système de traducion basé sur des fichier .properties, les fichiers properties viennent de Java mais sont omniprésent aussi en Javascript et sont la base de la traduction des logiciels de Mozilla (Firefox, ou FirfoxOS /ex).

L'application étant en php, l'idée initiale de mes copains étaient d'utiliser parse_ini_file() car la syntaxe des fichiers ini est presque la même que celle des .properties, mais si on veut des properties sans guillemets, avec du support des chaînes multilignes et éventuellement des commentaires, il faudrait mieux que ça, donc je leur ai rapidement créé une librairie pour parser les properties.

Ce n'est pas la première fois que j'écris une fonction ou une classe pour parser des .properties et en fait, je crois que c'est la troisième ou quatrième fois et à chaque fois j'ai fait du code jetable parce que je ne trouvais pas de librairie fiable sur le net (il y en a sûrement, j'ai juste pas trouvé), donc cette fois-ci j'ai décidé que j'allais faire une librairie une bonne fois pour toute et que la prochaine fois que j'aurai à réutiliser des properties, je m'en resservirai, voire même, je l'améliorerai :)

J'ai donc créé ma librairie sur github, elle s'appelle très originalement PhpProperties, elle parse correctement un fichier .properties et peut même extraire et associer les commentaires dans le fichier source (l'idée à long terme c'est de fournir un convertisseur vers d'autres format type .lang, .po, dtd... et de ne pas perdre les commentaires dans le code), son usage est simple:

<?php
$source = new \xformat\Properties();
var_dump($source->getproperties('toto.properties'));
Mais ce n'est pas tout, j'ai ajouté cette librairie à Packagist.org, vous pouvez donc l'installer comme une dépendance dans vos projets en utilisant un fichier composer.json:

{
    "require": {
        "pascalc/php-properties": "1.0"
    }
}


Un simple composer install vous installera tout ça :)

Voilà, je ne prétends pas que c'est du beau code, mais il marche plutôt bien et je suis assez content d'avoir pu créer mon premier paquet installable via Composer, le nouveau gestionnaire de dépendances de PHP :)

jeudi 13 septembre 2012

Vidéo de démo du serveur intégré à PHP 5.4

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 :

dimanche 3 janvier 2010

Nouveau thème pour mon blog

Un nouveau thème pour mon blog, entièrement fait main, dans les tons sombres pour changer et beaucoup moins encombré que les thèmes précédents que j'utilisais, en plus, il s'affiche même correctement dans IE6 sans que j'ai rien eu à faire !

samedi 2 janvier 2010

CSS Gradients dans Webkit et Gecko

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.

mardi 16 octobre 2007

badges "Don't hurt the web"

On fera une distribution de ça sur le stand aux JDLL ;) :

samedi 23 décembre 2006

Astuce conception web : fusionner et compresser ses CSS

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();
?>

mardi 5 décembre 2006

Firebug 1.0 beta

Firebug 1.0 beta est sorti, je voulais en faire un billet détaillé mais Baptiste l'a très bien fait pour moi :) Donc voici le lien vers le billet de Baptiste :

FireBug 1.0 Beta : plus qu'une extension, un prodige !

lundi 4 décembre 2006

PlumeCMS 1.2 est sorti

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 :

vendredi 24 novembre 2006

Bien développer pour le Web 2.0

Bien développer pour le Web 2.0, sous ce titre se cache un bon bouquin très didactique sur les méthodes de création de sites et d'applications web modernes et respectant les standards, centré sur Ajax.

L'auteur est aussi prof et ça se ressent dans l'écriture (en bien), c'est très clair, bien expliqué et avec des exemples concrets.

Encore un bon bouquin d'Eyrolles qui devient décidemment l'éditeur qualitatif incontournable de l'informatique. Un seul petit regret, comme beaucoup je suis pas fan du terme "web 2.0" qui tient beaucoup de l'effet de mode.

dimanche 27 août 2006

Understanding localization traps

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

lundi 22 mai 2006

Servir du javascript rapidement

Un intéressant article de Cal Henderson (développeur de Flickr) :

Serving JavaScript Fast

Il y explique tout un tas de techniques côté serveur pour améliorer la rapidité d'un site dépendant beaucoup de javascript/css, rien de révolutionnaire mais la mise en pratique est intéressante je trouve et loin des réponses stéréotypées sur l'optimisation des sites (genre "gzipper ses pages ça prend trop de ressources") qui peuvent être vraies dans l'absolue mais qui sont souvent très relative dans la pratique à mon avis. Ca m'a donné envie de lire son bouquin (Building Scalable Web Sites).

mardi 24 janvier 2006

ping, pong

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 :

<a href="http://www.toto.fr/" ping="http://partenairepub1 http://partenairepub2">lien vers toto.fr</a>

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

dimanche 1 janvier 2006

Web developer toolbar 1.0

La web developer toolbar est sortie en version 1.0, plein de nouveautés dont un éditeur html dans le panneau latéral sur le modèle de l'actuel éditeur css.

mercredi 2 novembre 2005

OneTrueLayout et Firefox 1.5

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à :) ) !

mardi 1 novembre 2005

CSS Reboot

Aujourd'hui c'est le jour du CSS Reboot, des milliers de sites passent à un nouveau design entièrement CSS. Ce genre d'évènements est toujours intéressant car il permet de voir les toutes dernières techniques css appliquées sur des cas concrets, ça montre aussi les tendances et mode en cours.

Je note deux courants CSS :

  • les sites au design flexible, plutôt axés sur le contenu et utilisant au maximum l'espace disponible (c'est la tendance CSS "hardcore" ;) ), ex : The Watchmaker project
  • les sites faits par des graphistes : peu de contenu, designs fixes et léchés, contrôle maximal des zones textuelles, intégration d'éléments en flash. ex : virtualdreams

Si techniquement ces deux courants sont connus depuis longtemps, c'est du point de vue visuel que le changement est frappant. Du premier coup d'oeil on peut désormais dire à quel courant css le concepteur adhère. Personnellement je préfère les designs élastiques non pas pour des raisons idéologiques mais plutôt parceque les sites choisissant ce type de designs sont en général des sites à fort contenu.

Je note que les sites américains sont toujours aussi moches et en général super-chargés, c'est incroyable le nombre de sites des US qui utilisent des polices, des logos et des couleurs qui rappellent les années 50...

Chez les européens, le gris anthracite comme couleur de fond semble être de plus en plus à la mode (robakdesign, coredreams.invitro-studio, Artlantis).

lundi 31 octobre 2005

Joyeux halloween !!

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

dimanche 23 octobre 2005

Spécificité en CSS

Vous avez du mal à comprendre le calcul de la spécificité (le poids d'une règle) des règles css ? Voici une explication visuelle géniale utilisant les personnages de la Guerre des Etoiles :

CSS Specificity Wars

Gardez de côté le super pense-bête de l'Empire ! :

dimanche 18 septembre 2005

Console javascript améliorée

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²

samedi 17 septembre 2005

Web developer toolbar pour IE

Microsoft, via le IEBlog annonce la sortie de sa barre d'outils pour développeurs téléchargeable ici : web developer bar IE

Je l'ai testée, voici mes premières impressions :

  • Il faut redémarrer windows pour la faire marcher !!!
  • elle est très inspirée de la webdeveloper toolbar de Firefox, mais bien plus limitée en fonctions (même pas la possibilité de voir le code source de la page!), en particulier il n'y a aucune fonction permettant de manipuler les css, ce qui est quand le point le plus intéressant de la barre pour Firefox
  • elle inclue un Dom explorer, très inspiré visuellement de notre Dom inspector, mais sans aucune possibilité de couper/coller des noeuds, d'éditer les différentes propriétés (attributs html, ajout de styles css...) et pas de fenêtre permettant de voir la cascade des styles appliqués sur un élement par rapport aux styles calculés (styles par rapport à getComputedStyle). Ce n'est donc qu'un visualiseur du DOM, pas un manipulateur du DOM comme le DOMI, bof bof.
  • l'ergonomie est à revoir, le fonctionnement des menus est différent de celui des fenêtres windows, pas agréable du tout

Personnellement je ne pense pas que je m'en servirais, car j'ai déjà des favelets qui me font la même chose souvent en mieux (notamment ceux de Slayeroffice), mais je verrai à l'usage si je lui trouve des intérêts. On sent là que l'équipe d'IE cherche à reconquérir une population de créateurs de sites qui sont passés à Firefox à cause de ses extensions de développement, je ne pense pas que ça les séduise mais ça pourrait inciter certains développeurs à rester un peu plus longtemps sur IE plutôt que de passer à Firefox comme principale plateforme de test des pages, ce qui est finalement peut être le but recherché, gagner du temps.

- page 1 de 3