Mur blanc - Tag - web

Patch

Gabriel Kerneis — Sat, 17 Mar 2007 17:57:00 +0100

Il y en a qui publient dans des revues scientifiques. Il y en a qui gagnent des jeux-concours. Il y en a qui réussissent leurs TP de réseau. Il y en a même qui arrêtent de fumer.

Chacun sa petite gloire personnelle. Moi, je viens de créer mon premier patch pour un projet libre. Ça marche, ça compile, je l'ai fait tout seul avec mes petites mimines. C'est beau, c'est fonctionnel, c'est magique. Et puis darcs est un vrai bonheur à utiliser.

Promis, je vous préviens quand il entre dans le répertoire officiel.

Mise à jour : C'est fait ! Et en plus, c'est utile (on peut à présent compiler le serveur en mode natif, grâce au travail d'Alain Frisch, ce qui nécessite la dernière version d'Ocaml, que mon patch permet d'utiliser - la boucle est bouclée).

Sat Mar 17 17:00:34 CET 2007 balat at pps.jussieu.fr
* Native code version
It is now possible to build Ocsigen in native code
IMPORTANT WARNING: You need a modified version of ocaml for now to use that!
(natdynlink branch in OCaml CVS, by Alain Frisch)

Wed Mar 14 18:34:37 CET 2007 Gabriel Kerneis <gabriel@XXX.info>
* Support for Ocaml 3.10 (EXPERIMENTAL)

Précision à l'intention des lecteurs perdus : ça veut dire que j'ai contribué à améliorer un logiciel, en l'occurrence le serveur web Ocsigen en lui ajoutant la possibilité d'être compilé avec la dernière version d'Ocaml (3.10 beta).

Je ne suis pas un héros...

Gabriel Kerneis — Sat, 24 Feb 2007 17:29:00 +0100

Un petit test bidon (une fois n'est pas coutume).

Quel héros de film es-tu ?


Néo (Matrix) : 79%
Hannibal Lecter : 74%
James Bond : 72%
Jim Levenstein (American Pie) : 72%
Indiana Jones : 70%
Batman / Bruce Wayne : 70%
Yoda (Star Wars) : 68%
Maximus (Gladiator) : 68%
Eric Draven (The Crow) : 66%
Tony Montana (Scarface) : 66%
Forrest Gump : 60%
Schrek : 57%

Ce que je trouve vraiment inquiétant, c'est le second de la liste...

Ego

Gabriel Kerneis — Tue, 20 Feb 2007 03:54:00 +0100

Je suis fier de moi. Et c'est un peu frustrant de ne pas pouvoir expliquer pourquoi sans rentrer dans des détails techniques incompréhensibles.

Disons pour simplifier qu'il y avait un problème. J'ai eu une idée pour le résoudre, quasi-instantanément. Puis j'ai creusé, creusé, creusé, jusqu'à ce que l'idée devienne réalité. Et ça a fonctionné.

Alors je sais que je me répète mais... je suis fier de moi.

Bullshit of the month

Gabriel Kerneis — Sat, 09 Dec 2006 01:57:00 +0100

You mean you're not even able to do a simple division by zero ? You idiot ! It's fairly obvious. How can you not know that ?

Have a glance (as quick as possible) to : http://www.bbc.co.uk/berkshire/cont....

It works indeed... or maybe not.

PS : don't hesitate to correct my English, or suggest better (more idiomatic) sentences.

Accords commerciaux

Gabriel Kerneis — Mon, 20 Nov 2006 00:23:00 +0100

Je voulais commander quelque chose^[1] sur un site étranger. Malheureusement, ils ne livrent pas en France. En revanche, ils semblent avoir des accords commerciaux pour le moins... surprenants. Jugez vous-même :

Bientôt en Iraq ?

Notes

[1] Non, vous ne saurez pas quoi, n'insistez pas.

Publicité discriminante

Gabriel Kerneis — Thu, 16 Nov 2006 10:44:00 +0100

Si vous prenez le métro parisien régulièrement, vous n'avez pas pu louper toutes ces affiches sur le rentring, le concept que les new-yorkais nous envient. Petit rappel des faits et analyse de la situation (un peu geek sur les bords).

Depuis quelques jours, on voit florir sur les panneaux d'affichages parisien (particulièrement dans le métro, mais pas seulement), des affiches vantant le rentring. A grand coups de messages chocs, assénés en lettres faites de néons oranges sur fond bleu, vous voilà définitivement has-been si vous ignorez ce que sait. Il y a ainsi des plans rentring, quand on sort en boîte, qu'il convient de chercher auprès de ses potes, car le plus important quand on sort en boîte, c'est de rentrer, etc. En petites lettres blanches, sous chaque message, une adresse web : www.lerentring.com^[1].

On est perplexe, forcément. Plusieurs idées me viennet à l'esprit : une campagne de la sécurité routière ? un nouveau service d'invitations pour rentrer en boîte ? une chaîne de taxis ? un site de covoiturage ? Je finis par avoir la curiosité de me pencher de plus près sur une des affiches. Dans le coin^[2], vous savez, là où il y a le nom de la société à l'origine de la publicité.

Orange SA. Forcément, ça explique la couleur des néons. Mais nom de Dieu, c'est quoi le rapport ? Je finis par me décider à aller sur le fameux site (et pourtant je n'avais pas envie, je n'aime pas céder à la publicité). Naturellement, un joyeux message me prévient qu'hors de Flash 8, point de salut. Je jette un oeil au code source, localise le bout de javascript qui me bloque^[3], saute ni une ni deux sur www.lerentring.com/flash.htm, encore bloqué je réactive javascript^[4], regarde la barre de progression. Et boum, ça ne fonctionne pas.

Forcément, j'ai Flash 7, et Flash 8 je ne suis pas près de le télécharger (pas de version Linux disponible). Bon, j'ai quand même des bouts d'animation, ça vole de partout, y'a des photos, c'est de la pseudo-3D, je ne comprends rien. Sans les textes, c'est un peu normal.

Toutefois, j'ai appris des choses en regardant le code source. D'abord la balise <html> est fermée mais pas ouverte. Ou alors, quand elle est présente, il y a un attribut xml:lang mais pas de DOCTYPE : vachement utile, ça pue le copier-coller de designer qui ne comprend rien à ce qu'il fait. Il y a des stats en javascript, et même une version <noscript> à base d'une image. Très utile de compter dans les stats les gens qui n'ont pas javascript et ne verront donc rien du site. Un petit texte descriptif à la place aurait été plus judicieux.

Il y a les mots-clef aussi :

rentring,le rentring,lerentring,nouvelle tendance,viral,les stroops,the stroops,internet sans ligne fixe,téléphone illimité,paris dernière,paris paris,orange,télévision numérique,net et mobile

Alors, qu'est-ce que ça veut dire ? Ça fait penser à leur pub récente pour Unik, le service de téléphone fixe & mobile combiné. A propos de mots-clef, je suis sûr que les robots d'indexation^[5] doivent beaucoup s'amuser à visiter leur site (ils ne doivent même pas passer la page d'accueil en fait). Par exemple, sur Google, on obtient :

Le Rentring
Le Rentring. TELECHARGER FLASH PLAYER 8.
www.lerentring.com/ - 3k - En cache - Pages similaires

Au moins, on est prévenu avant même d'aller sur le site...

Mais pourquoi je m'acharne sur ce nouveau buzz marketing ? Je ne sais même pas. Il doit concentrer tout ce que j'exècre : une campagne de pub multi-media aggressive à grand renfort de milliers euros, un site en Flash + javascript sans version alternative, un mépris des standards et de l'accessibilité et j'en passe.

Bon maintenant si vous voulez VRAIMENT savoir ce qu'est le rentring, allez voir le blog de Onesque.

Notes

[1] Le lien ne fonctionne pas, c'est volontaire.

[2] pan !

[3] if(flash.ver["8"]){location.replace("flash.htm");}

[4] Le flash est chargé par javascript himself.

[5] Google, Yahoo, Exalead et consorts

Réinventer le web

Gabriel Kerneis — Tue, 31 Oct 2006 00:56:00 +0100

Juste après mes atermoiements sur XHTML, un message de Tim Berners-Lee qui redonne un peu d'espoir. C'est long et un peu technique, mais passionnant si vous vous intéressez au sujet.

Si vous êtes pressés ou peu connaisseurs en la matière, allez plutôt lire le court commentaire de Bob Marcel qui résume bien la situation, de manière accessible au commun des mortels (enfin je pense).

Mise à jour : Vous pouvez également consulter ma dépêche Linuxfr sur le sujet.

Making standards is hard work. Its hard because it involves listening to other people and figuring out what they mean, which means figuring out where they are coming from, how they are using words, and so on.

There is the age-old tradeoff for any group as to whether to zoom along happily, in relative isolation, putting off the day when they ask for reviews, or whether to get lots of people involved early on, so a wider community gets on board earlier, with all the time that costs. That's a trade-off which won't go away.

The solutions tend to be different for each case, each working group. Some have lots of reviewers and some few, some have lots of time, some urgent deadlines.

A particular case is HTML. HTML has the potential interest of millions of people: anyone who has designed a web page may have useful views on new HTML features. It is the earliest spec of W3C, a battleground of the browser wars, and now the most widespread spec.

The perceived accountability of the HTML group has been an issue. Sometimes this was a departure from the W3C process, sometimes a sticking to it in principle, but not actually providing assurances to commenters. An issue was the formation of the breakaway WHAT WG, which attracted reviewers though it did not have a process or specific accountability measures itself.

There has been discussion in blogs where Daniel Glazman, Björn Hörmann, Molly Holzschlag, Eric Meyer, and Jeffrey Zeldman and others have shared concerns about W3C works particularly in the HTML area. The validator and other subjects cropped up too, but let's focus on HTML now. We had a W3C retreat in which we discussed what to do about these things.

Some things are very clear. It is really important to have real developers on the ground involved with the development of HTML. It is also really important to have browser makers intimately involved and committed. And also all the other stakeholders, including users and user companies and makers of related products.

Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work. The large HTML-generating public did not move, largely because the browsers didn't complain. Some large communities did shift and are enjoying the fruits of well-formed systems, but not all. It is important to maintain HTML incrementally, as well as continuing a transition to well-formed world, and developing more power in that world.

The plan is to charter a completely new HTML group. Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel xHTML. It will have a different chair and staff contact. It will work on HTML and xHTML together. We have strong support for this group, from many people we have talked to, including browser makers.

There will also be work on forms. This is a complex area, as existing HTML forms and XForms are both form languages. HTML forms are ubiquitously deployed, and there are many implementations and users of XForms. Meanwhile, the Webforms submission has suggested sensible extensions to HTML forms. The plan is, informed by Webforms, to extend HTML forms. At the same time, there is a work item to look at how HTML forms (existing and extended) can be thought of as XForm equivalents, to allow an easy escalation path. A goal would be to have an HTML forms language which is a superset of the existing HTML language, and a subset of a XForms language wit added HTML compatibility. We will see to what extend this is possible. There will be a new Forms group, and a common task force between it and the HTML group.

There is also a plan for a separate group to work on the XHTML2 work which the old "HTML working group" was working on. There will be no dependency of HTML work on the XHTML2 work.

As well as a new HTML work, there are other things want to change. The validator I think is a really valuable tool both for users and in helping standards deployment. I'd like it to check (even) more stuff, be (even) more helpful, and prioritize carefully its errors, warning and mild chidings. I'd like it to link to an explanations of why things should be a certain way. We have, by the way, just ordered some new server hardware, paid for by the Supporters program -- thank you!

This is going to be hard work. I'd like everyone to go into this realizing this. I'll be asking these groups to be very accountable, to have powerful issue tracking systems on the w3.org web site, and to be responsive in spirit as well as in letter to public comments. As always, we will be insisting on working implementations and test suites. Now we are going to be asking for things like talking with validator developers, maybe providing validator modules and validator test suites. (That's like a language test suite but backwards, in a way). I'm going to ask commenters to be respectful of the groups, as always. Try to check whether the comment has been made before, suggest alternative text, one item per message, etc, and add to technical perception social awareness.

This is going to be a very major collaboration on a very important spec, one of the crown jewels of web technology. Even though hundreds of people will be involved, we are evolving the technology which millions going on billions will use in the future. There won't seem like enough thankyous to go around some days. But we will be maintaining something very important and creating something even better.

Tim BL

(Texte sous licence creativecommons by-nc 2.5 - vous pouvez aussi consulter le texte original)

XHTML 1.1

Gabriel Kerneis — Sun, 29 Oct 2006 21:33:00 +0100

Dilemme de geek.

XHTML 1.1 c'est bien. Sauf que ça ne sert à rien. Enfin, moi, ça ne me sert à rien. Mais conceptuellement c'est beau. J'avais bien envie de mettre mon site en XHTML 1.1 moi. Sauf qu'Internet Explorer ne le supporte pas. Du tout.

Alors je fais quoi. Il faut qu'il soit lu, quand même, ce site. Même si, pour l'instant, il est plutôt vide. Un jour, il y aura des choses intéressantes dessus^[1]. Alors en attendant j'ai fait une version alternative en XHTML 1.0 servi en tant que text/html (ce qui est conforme aux recommandations W3C mais est philosophiquement une mauvais chose).

Je ne sais plus quoi penser, quoi faire. Au moins, si je sers la page en application/xhtml+xml, plus besoin de gérer les problèmes de CSS d'IE. Mais me couper d'un lectorat potentiel, quelle connerie !

Et si XHTML était mort ? Faut-il être plus royaliste que le roi ?

Pfff, c'est compliqué la technologie.

NB : si vous n'avez rien compris, c'est sans doute normal. Si vous êtes curieux, lisez les liens que j'ai éparpillé dans le billet, ils sont tous très instructifs. J'ai passé des heures sur le sujet, à en examiner tous les tenants et les aboutissants. Et je dois dire que j'en suis toujours au même point : vaut-il mieux utiliser html 4.1 proprement, être lisible par tous, ou jouer son geek avec xhtml et envoyer au diable tous les utilisateurs d'IE ? Pour une page à vocation professionnelle (à terme), ça la fout mal quand même. Surtout que je me coupe aussi des navigateurs en mode texte, etc.

Notes

[1] D'ici là, IE supportera peut-être XHTML 1.1 cela dit.

Reconnaissance de navigateur en pur (X)HTML

Gabriel Kerneis — Fri, 27 Oct 2006 00:42:00 +0200

Un billet pour les ~~geeks~~ webmasters soucieux des standards.

Vous avez un site web. Avec une jolie CSS. Mais ce merveilleux navigateur qu'est Internet Explorer ne la gère pas correctement. Sauf, peut-être, la version 7. Or vous n'avez pas envie d'utiliser des hacks ignobles pour corriger les bugs. Vous voulez rester conforme aux standards du W3C. Vous aimeriez juste pouvoir filer à IE une feuille de style dédiée, avec un design simplifié qu'il sache gérer.

La solution : les conditional comments (soit commentaires conditionnels, en français).

Qu'est-ce que c'est ? Ce sont des balises reconnues par IE (uniquement) qui permettent d'afficher ou de révéler du contenu selon la version du navigateur. Il y en a de deux types :

Les downlevel-hidden conditional comments, qui révèlent le contenu seulement à IE. Ce sont des commentaires au sens classique, ils sont valides (au sens du W3C). Un petit bout de code spécial indique juste à IE qu'il doit afficher le commentaire, et non pas l'ignorer. Concrètement, ça se présente comme ça :

Les downlevel-revealed conditional comments, qui cachent le contenu seulement à IE. Ce ne sont pas des commentaires au sens classique, ils ne sont pas valides (au sens du W3C). Ce sont des balises supplémentaires, non reconnues par le W3C :

<![if !IE]> Ce texte est affiché par tout le monde sauf IE. <![endif]>

Heureusement il y a une solution pour rendre de tels commentaires conditionnels révélés conformes. Ou plutôt, des solutions. Naturellement, la meilleure est tout à la fin (mais il y a de jolies choses à voir avant, qui valent la peine d'être lues).

Si vous voulez vous contenter d'une détection binaire IE / !IE, alors voilà une méthode simple et efficace :

 Caché pour IE. 

L'astuce : on utilise un commentaire du premier type (donc standard) et on dit à IE de l'ignorer totalement, quelle que soit sa version (!IE). Ensuite, IE va tout ignorer jusqu'au <![endif]-->. En particulier, nous pouvons à loisir fermer le commentaire initial, donc rendre la suite visible pour les autres navigateurs, puis le rouvrir pour mettre le <![endif]-->.

Si vous voulez affiner en fonction de la version d'IE, ça ne suffit plus. En effet, si l'on met if IE 7 à la place de if !IE par exemple, IE 7 va lire la suite et affichera donc : --> Caché pour IE.<!--. Il nous faut un moyen de lui dire d'ignorer ces bouts de balise ! Là encore, plusieurs solutions :

Une méthode de toute beauté (mais qui vous donnera un avertissement de la part du validateur du W3C, car elle est assez osée) :

 Caché pour IE<7, visible pour tous les autres. 

Si vous êtes curieux, voilà quelques détails sur la syntaxe des commentaires en sgml qui devraient vous permettre de comprendre le pourquoi du comment de cette méthode. À noter que si IE7 est vraiment strict (ce que je n'ai pas testé), il vous jettera violemment pour non respect de la syntaxe des commentaires^[1].

La même mais sans avertissement :

 Caché pour IE<7, visible pour tous les autres. 

L'usage de cette méthode est en fait déconseillé, elle pose exactement le même problème que celui qu'elle tente de résoudre : IE7 affichera le <--> indésirable.

Ma méthode à moi (en fait antérieurement trouvée par quelqu'un d'autre), qui consiste à cacher les commentaires révélés à l'intérieur de commentaires cachés (IE interprétant les commentaires conditionnels récursivement, même si cela n'est pas explicitement précisé dans la documentation) :

 Caché pour IE<7, visible pour tous les autres. 

C'est la méthode que je recommande : elle fonctionne et est valide en toutes circonstances (sauf si Microsoft décide que les commentaires conditionnels ne doivent plus être interprétés récursivement).

Un exemple d'application ? Tiré du lien précédent :

 <link rel="stylesheet" href="others.css" type="text/css" /> 

Ainsi, la feuille de style ie.css est lue par IE, others.css par les autres navigateurs. Si l'on veut distinguer selon IE7, c'est un peu plus touffu, mais toujours le même principe :

 <link rel="stylesheet" href="ie7-and-others.css" type="text/css" />  

Quelques ultimes détails :

Certains n'aiment pas rajouter du code dans leur page pour gérer l'apparence. C'est compréhensible, au nom de la séparation du fond et de la forme. Si vous en faites partie, vous serez peut-être intéressés par une solution en pur CSS (c'est un hack, mais plutôt résistant).
Les commentaires conditionnels ne sont pas forcément la panacée : un article à ce sujet.
Vous pouvez aussi mettre une feuille de style visible pour vraiment tout le monde et ensuite rajouter un commentaire caché juste pour IE, avec des directives supplémentaires, pour compléter/corriger ce qu'il interprète mal dans la première feuille. Ça évite la duplication de code entre vos deux feuilles de style.

Notes

[1] C'est en particulier possible si vous servez vos pages en tant que xml au niveau du serveur web, ce qui est rarement le cas.