da scritch net works - Mot-clé - cssr07

CSS reboot 2013

Da Scritch — 2013-05-10T07:46:00+02:00

Ce blog méritait un sérieux coup de peinture
Ma vie est une sitcom

La précédente version de ce site a été “designée” en 2006. Oui oui, en 2006. Et j'étais parti d'un pari complètement stupide, moi qui n'y connaissais rien aux CSS, de passer dans un design liquide et que cela fonctionne sur MSIE6. J'étais même suffisament prétentieux pour avoir participé au concours cssr07 à l'époque.

Yep ! C'est dire si ces temps sont lointains…
MSIE7 n'était encore qu'en béta, l'iPhone un projet super-secret, Firefox faisait 5% de PDM et WebKit n'existant que dans l'environnement KDE sous Linux.Et oui, j'annonçais Ripolinizing ze ouèb car en même temps, je peignais mon appartement. Comme peut en témoigner mon ex-photo de bannière, prise au Nokia 5800.

Sauf que voilà, Sud Web 2013 approche à très grands pas. Et même si les cordonniers sont les plus mal chaussés, ce site était devenu une honte. Je ne parle pas que du bleu layette que j'utilisais.

Vous pouviez pas savoir combien je me faisais chambrer, rien que sur la couleur de fond, que pourtant je trouvais très reposante par rapport au blanc pur. J'ai cédé. Je suis faible.

Gloire à l'équipe Dotclear

Même si le moteur de blog avance très peu (et il en a très peu besoin : il est très bien conçu à la base), il y a eu un élément important qui m'a fait passer le pas, c'est le thème Ductile. Il se montre très paramétrable, souple, est vraiment désigné en responsive design, ce qui était le péché majeur de mon précédent style, qui ne pouvait s'afficher en-dessous de 540px de large. Le travail de Kozlika, Franck Paul et de tous les autres est une petite merveille.

Le fait aussi d'écrire directement en XHTML1 la mise en forme de mes billets m'a évité bien des déconvenues. Y'en a forcément, mais elles sont franchement peu visibles.

Mes petits travaux de finitions

La première des choses à été de transformer le balisage du thème en HTML5, et de mettre un breadcrumb. Malheureusement, j'ai copié et retordu le thème au lieu de l'étendre proprement, ce qui fait que je vais devoir refaire ces travaux si je souhaite les reverser.
J'ai mis mon datehumaine() qui permet d'afficher des dates relatives. Faudra que je le ré-écrive, cette version date de 2005. Il est même pas à jour par rapport à dAgence.
J'ai remonté les annexes/pièces-jointes toutes en haut, afin que le podcast soit le premier élément lisible d'un billet d'émission. De même, le mini-sommaire des billets est désormais en haut “TL;DR”, ré-écrit en parti.

Mais tout est loin d'être terminé, car j'ai passé ces deux jours de congés à être malade comme un chien. Notamment :
Si les effets d'apparitions sont toujours là, je compte les switcher à du css3, ce qui sera nettement mieux
J'aimerais à terme refaire la une dans le style de l'application Google Flux sur Android, qui est super agréable à regarder.
Et surtout, j'ai supprimé les étiquettes en haut à droite du thème original sans le vouloir. Le restaurer va être compliqué

En fait, je suis pas assez bon designer pour arriver à donner un look uniforme à ce blog, à mon site corporate dascritch.com, à mon compte twitter et mes bannières Google+ et LinkedIn. Bref, y'a du boulot.

Y'a eu des pertes

J'ai définitivement viré l'impressionnante liste de liens qui comportait 1200 références classés par type. Ça faisait super longtemps que je ne la tenais pas à jour.
J'ai aussi supprimé le lien vers mes archives. Tout ce qui a été écrit entre 1997 et 2004 est provisoirement caché. Il faut que je prenne le temps de conformer les 300 pages pour les rentrer dans Dotclear.
Il y a aussi toutes les chroniques qui comportent le logo du Supplément Week-End à légèrement remettre en ordre : réduire le logo de l'émission et échanger avec la couverture du livre, pour qu'elle soit lisible en mode listing.

Mais ça y est, ENFIN, mon site est consultable sur téléphone.

Les sites des codeurs sont les plus mals codés

Da Scritch — 2011-04-15T13:47:00+02:00

Oh mince... y'a un accroc dans mon plan.
Webdev

Contrairement à la dernière fois, cela s'appelle une transition à l'arrache.

Le serveur qui héberge mon blog est en fait co-loué avec une bande de comparses. Cela nous permet d'avoir du dédié à un prix très intéressant, et je remercie Zorel de s'occuper de la gestion administrative et technique. Zorel est aussi un fin négociateur, et il l'a obtenu un bon rabais auprès de notre salle blanche ~~suite à une nuit de beuv~~ pour un nouveau serveur. Je pensais qu'on restait dans la même Debian avec des numéros de versions anciens (mais avec les patches idoines de sécu), et donc on est parti faire des interviewes au TGS Ohanami innocemment ce week-end.

Ça fait le con en costard devant un cameraman en marcel alors que le codeur aurait mieux fait de vérifier avant la version de son nouveau serveur (photo : © Enflammée)

Ouch, les textes ont disparus !

Seulement, en début de semaine, il y a eu un hic au moment de changer effectivement de serveur : on est passé à PHP version 5.3. Le blog d'Enflammée était clean (comprenez que c'était un dotclear sans modifications) et donc est reparti sans un pet mais mon site perso s'est effondré. Il se trouve que dascritch.net était depuis un temps certain architecturé avec un dotclear 2.0 version béta (eh oui, c'est pas bien du tout) qui a été greffé de force dans du code qui date parfois de 2001… Tant que cela marchait (et vu que mon code possédait suffisamment de blindage, remis à jour), et comme j'avais vraiment d'autres priorités (entres autres, dAgence, écrit quasi de zéro), ça ne posait aucun problème. Et forcément, ça me pendant au nez. Le passage en PHP 5.3 a cassé bien des fonctions obsolètes (entres autres, les fonctions regex ereg, car oui, comme pour le javascript, les libs regex sont très différentes), ce qui a fait disparaitre les textes des billets (en fait, ils n'étaient plus affichés) et mis mon site en verrouillage par sécurité.

Il était franchement temps de remettre tout ça d'équerre.

Donc, je suis revenu au Dotclear vanilla (2.2.3), cette fois-ci intégrant les fonctions persos dans un plugin écrit dans les règles (qui reprend mes améliorations, notamment de sécurité). Ce qui permet de garder la souplesse des mises à jour, et aussi une unicité de gestion de l'aspect graphique. Mais cela m'a demandé deux jours, puisque je suis en pleine livraison entre deux clients, des demandes urgentes de devis, bref, j'ai pas franchement dormi ces deux dernières nuits.

Du coup, plein de modifications sont apparues au grand jour… qui étaient prêtes à être déployées ! Cela faisait aussi 4 ans (eh !) qu'en fait la version de mon blog vue à la maison n'utilisait plus la lib javascript mootools mais jquery (pour info, la version 1.0.3, chargée le 27 Octobre 2006... je sais, j'ai honte) Une partie du code tentait de gérer MsIE 5.5 (eh oui), et disposait d'un chargeur asynchrone maison de librairies javascript. Le truc plus vraiment nécessaire. La CSS avait aussi gagné un sacré nettoyage, pas forcément visible. Dans l'ensemble, pour moi, ça fait pas grand-chose de neuf. Pour vous, ça semblera nettement plus actuel que la précédente version dite “cssr07”. Mais je compte néanmoins retravailler “graphiquement” mon header.

Ça… on jette… ça… on jette…

La colonne à droite de navigation (sidebar) a aussi vécu un sacré nettoyage. Fini le double moteur de recherche (l'un envoyant les résultats Dotclear, l'autre ceux de Google). Fini aussi le lien vers Viadeo, je vous laisse deviner pourquoi. Le résumé de del.icio.us a provisoirement disparu. Il est toujours consultable sur le site d'origine Il risque de revenir, mais sous la forme d'une compilation mensuelle, tant que Yahoo le tue pas. Ce fut un crève-cœur car le développement de ce code m'avait permis de discuter avec Joshua Schachter, notamment de micro-formats embarqués dans le html dès.... 2004 !

Disparue aussi ma liste de liens. les raisons sont multiples :

elle n'était plus à jour depuis que le dernier plugin de Firefox capable d'exporter les bookmarks en format xml/XBel a disparu, lors de la sortie de Firefox 2.0. Le fichier master du site est toujours présent mais plus à jour depuis belle lurette.
impossible de s'occuper de gérer les liens morts et tout le reste, même DMOZ n'y arrivait pas manuellement
point de vue référencement, j'ai sacrément perdu en 6 mois, puisque cette rubrique me montrait comme un farmeur de liens...

Le plan d'adressage est en cours de simplification, puisque tout le rendu est un pur MVC de Dotclear, et pas un mix immonde entre deux blocs de librairies, dont un perso vraiment trop ancien. J'avais fait disparaitre la version mobile de mon site en 2009 (ça mérite un papier, car certaines choses y sont pleinement d'actu), je compte plutôt faire un style pour les téléphones et petites tablettes. Les vieux sites archivés vont rentrer dans Dotclear, quand j'aurais un peu de temps pour ça, ce qui justifiera la disparition de la recherche Google locale. Des pages statiques virent, notamment mon CV, intégralement chez LinkedIn.

L'aspect général du site ne bouge pas dans l'immédiat, mais ça viendra. Un premier jet concerne déjà les écrans mobiles.

Faut dire que je veux vous éviter le traumatisme de la perte de l'ancien style. Vous vous souveniez du look de mon blog entre 2003 et 2007 ?

Moralité : lire le titre.

Bookmark-moi cette page !

Da Scritch — 2008-05-29T19:18:00+02:00

Avec des badges partout, ça fait franchement sapin de Noël, et comme qui dirait, on est hors-saison. Alors sérieux, s'abstenir.
Webdev

Comme tous les sites persos, à mes débuts, j'avais une page avec mes liens favoris (même qu'en fait, péché de jeunesse, c'était plusieurs pages dans une frame). Cette section subsiste encore sous une autre incarnation [PS1]. Pour souligner que j'avais plein de liens que j'aimais bien et tous pleins d'amis virtuels que je kiffais trop, comme tous les blogs primitifs, j'avais mis des badges partout.

On était en 1997.

Depuis, y'a eu prescription.

Pour la version 6 de ce blog, mitonnée pendant deux ans et arrivée l'été dernier, à donfe sur la two-point-zero vibe, j'avais dans l'idée de mettre plein de liens vers des bookmarkeurs sociaux. Vous vous souvenez, toutes ces startups “e-web 2.0” [PS2] qui proposent du bookmarkage sociétal à tout-va : del.icio.us avec 2 “.”, digg avec 2 “g”, fuzz avec 2 “z” et un “RIP”, fesse-bouc, microsoft® favorites™ live©,...

La véritable intention était surtout de parodier tous ces sites qui collent partout les badges “borkmark this !!!!!!!!!” car leur idée (oui, ils en ont une), c'est que forcément l'internaute va te marque-pager, et que comme leur compte BM2.0-digglike est publique, ben tu vas gagner mécaniquement en page-ranking, et forcément mieux que via ton presta SEO-linkfarmer qui se fait régulièrement blacklister de Google. À condition de ne manquer aucun de ces sites qui ont tous exactement la même fonction.

Bref, ces gourous de l'andouillerie oueb confondaient business-model publicitaire et clicodrome. L'occasion d'en rire était trop belle... en faisait tout comme eux.
Le problème, c'est qu'à galoper après l'échalote (recenser tous lese-bookm@rkers-2.0) ça faisait plein d'étiquettes bariolées, beaucoup de code à calculer côté serveur (en fait, totalement négligeable, mais quel intérêt pour un téléphone portable ou un robot de moteur de recherche de s'en encombrer le HTML ?). On en avait même fait une private joke lors de la conception d'un site web aujourd'hui disparu.

Fingers in the multiprise

Puis j'ai découvert AddThis.

Et là, je me suis dit « Pas con l'idée du popup menu avec la liste de liens sociaux, j'aurais pas à m'emmerder à faire toute la liste, et ça sera plus propre ».
Fallait juste rentrer de force leur javascript bourré de document.write avec mon système d'insertion dynamique.

Mais peut-être qu'au lieu de donner une immense liste de sites web de marque-pages sociétaux, il suffit juste de proposer dynamiquement celui/ceux au/x/quel/s est inscrit le visiteur. Et qu'il peut accéder directement via son navigateur.

Ça tombe bien, un script a été proposé hier-matin sur la Planet Mozilla, l'aggrégateur des blogs des développeurs de la MoFo.
La merveille en question s'appelle SocialHistory.js.
Et là, l'esprit taquin se dit qu'il pourrait tout aussi bien utiliser cette bibliothèque pour se faire automatiquement tagger à l'insu du visiteur, mais ce serait une très très très mauvaise idée...

Pourtant, étonnement, je ne vais pas l'installer.

Goodbye and thank you for all the fish

Cherchez bien le lien “AddThis” dans mon template, il n'y est pas. Son code côté serveur est toujours présent mais sert dans l'immédiat à mettre un (tiens, encore un...) badge militant pour le record du monde de bande passante.
Eh oui, tant de boulot pour finalement pas grand chose.

La véritable raison de la suppression du lien "Bookmark this" dans mon site, c'est que personne ne s'en est servi en deux ans. Strictement personne : zéro clic. Je veux bien croire que c'est sa position qui faisait que personne n'allait dessus, mais les liens qui l'entouraient dans la sidebar sont très régulièrement cliqués, donc il y avait un désintérêt manifeste pour cette fonction bouffeuse de place et de ressource JS. Si des gens se servent d'un système de bookmark sociétal, en général, ils ont des bookmarks, des extensions de navigateurs, voire des favlets [PS3].
Et, pour être franc pour les e-web-eux-tiou-pouint-zero, je suis pas persuadé que mettre plein de badges “booste son PR” [PS4], j'ai plutôt l'impression que c'est le contenu qui prime.

C'est peut-être joli, mais ça sert à rien de mettre des badges partout.

Mais ça... On le savait depuis le début !

PS : Ne pas bookmarker ces liens : c'est des renvois dans la même page !

↑ une autre incarnation : Mais qui est menacée d'extinction quand je passerais à Firefox 3 : Le script la génère à partir de mes favoris exportés en XBEL, format XML ouvert et documenté toujours pas supporté par défaut par la MozFo. Dans la section blog, il y a une liste de favoris par catégorie. L'excellente extension Bookmark Synchro de Torisugari n'est plus maintenue depuis un bail
↑ e-web 2.0 : Qui a dit « bingo » dans l'assistance ? Qui ?
↑ favlets : des bookmarks entrainant une action javascript. Une URL qui commence par "javascript:". OK, c'est pas propre, mais dans le contexte navigateur client, ça se justifie
↑ “booste son PR” : Véridiquement entendu dans une conférence de web-entreprenautes. Et c'est tout récent.

Pardonnons à ce Flash qui nous agace tant

Da Scritch — 2007-10-19T16:50:00+02:00

Ne tirez plus sur l'ambulance ! Avant de crier que « Flash sapu saimal », apprenez à mieux l'intégrer dans votre HTML...
Webdev

L'usage d'un élément en Flash dans un site n'est pas toujours pertinent, les animations qu'on ne pourrait pas faire autrement sont relativement rares. Mais y'a des fois où on ne peut pas se passer d'un élément en Flash dans une page HTML : Pour y mettre de la vidéo, pouvoir lire un mp3 à coup sûr, ou tout simplement parce qu'un client veut du Flash, et là, ça se discute pas : « Le Client a toujours raison ».
Alors évidemment, le Flash™ « sapu saimal » parce que c'est un format propriétaire tenu par Macromedia puis par Adobe, même s'il le format de fichier est documenté et qu'il existe un plugin alternatif open-source qui peut lire les documents en .swf (Gnash, mais dont les fonctions sont quand même limitées), mais aussi la plupart du temps, c'est l'inclusion d'un élément en Flash dans le HTML qui fait hurler « cépa codex ! ».

Un des points très importants à noter, c'est que le Flash n'est pas indexé par Google, mais il se trouve que d'autres moteurs (dont Exalead) sont capable d'entrer dedans [NB1] et de suivre les liens accessibles d'entrée...

L'autre souci, c'est que le Flash est rendu indépendamment du navigateur web. Il interagit avec lui, avec l'arbre DOM du document HTML où il est inclu, mais ne tient absolument pas en compte les actions de navigation tels que avancer/reculer/marque-pager. Pour ce dernier, il serait possible d'utiliser dans l'~~URL~~ IRI [NB2] la position d'ancre (ce qui est après le #) pour indiquer une position dans l'animation Flash (méthode déjà utilisée dans certaines applications Ajax-like), mais dans la pratique, personne ne s'y est intéressé. D'où cette impression que le Flash n'a jamais été dans la partie du web, mais en-dehors de ses fonctions de base. Ce qui donne cette inimitable frustration totale que laissent les sites intégralement en Flash quand on veut en montrer une partie très particulière à un ami par mail : Au lieu de donner directement une ~~URL~~ IRI (Je m'y ferais jamais) d'une page web, éventuellement avec une ancre, on doit expliquer qu'à cette adresse, il faut attendre 4 secondes, cliquer sur le lapin bleu (celui qui galope de droite à gauche), puis aller sur le rectangle à droite et le déplacer de 183 pixels vers le bas [NB3]. Le visiteur doit perdre du temps à comprendre une interface qu'il ne retrouvera sûrement que pour ce site.
“Immersif” soit, mais totalement frustrant.

Utiliser du Flash pour un élément de navigation, pour faire une galerie photo, ou pour faire un effet supplémentaire est souvent une erreur, qui rend le site moins utile, trop lourd [NB4], moins facile à visiter. Souvent, les intros en Flash sont considérées comme interminables et pénalisent l'expérience du visiteur du site plutôt que lui plaire. Je déteste le site de l'ACBD (dont je suis membre) rien que pour ça.

À sa décharge, le plugin Flash est sans contestation possible le plus répandu et peut-être le plus universel. Il permet à coup sûr de lire un document sonore en chargement streamé, ainsi que la vidéo. Mais jusqu'à l'intégration toute récente du codec H264 (une version particulière du MPEG4), la qualité n'est pas franchement top, pour une consommation de ressources honnêtement peu justifiée.

Pourquoi l'extension Flashblock est si populaire

Si vous allez sur le site du journal Libération depuis plusieurs années, vous avez remarqué combien ils ont été très tolérants envers les pubs en Flash : celle qui font du bruit (mention spéciale à la campagne Wanadoo qui faisait Zdoing! Zdoing! avec la mention « cliquez ici pour arrêter ce bruit »), voire pire, celles qui font de la vidéo.
En général ce genre de pub est extrêmement agaçant par le bruit généré, par très work-safe, gourmant dans la puissance demandé à l'ordinateur. En ouvrant une dizaine d'onglets à partir de la une d'un site de news pour lire tranquillement des articles, il m'est souvent arrivé que ma machine soit complètement à genoux à cause des pubs en Flash, ou que je perde un temps monstre à chercher quel onglet je dois fermer pour arrêter ce p↯☭↹∞n de Zdoing! Zdoing!.

Dès que j'ai vu les prémices de l'extension Flashblock pour Firefox, je l'ai immédiatement installé. De suite, ce fut un soulagement. Pouvoir lire Libération sans les pubs sonores, CSO France sans les animations qui mettent à genoux ma petite machine (à l'époque un Pentium IV)... un bonheur.
Flashblock ne bloque pas le chargement du Flash. En fait, il ne fait qu'en geler l'exécution, et le masquer par un place-over.

Alors évidemment, ça fait râler les publicitaires, les annonceurs, les e-régies net-publicitaires.com, les web-@gency et autres flashmasters... Ceux-ci d'ailleurs vont pas tarder à trouver la méthode pour détecter que le plugin est installé pour vous interdire l'accès au site web support de leur pub si gainiale [NB5]

Mais très honnêtement, si la pub ne s'obligeait pas à venir squatter du temps de cerveau déjà occupé par des méthodes aussi irritantes, elle n'emploierait pas autant de pollueurs du web. Le fait qu'elle ne peut s'en empêcher a forcément rendu nécessaire ce genre d'application afin de lire tranquillement une page de texte sans être insupporté par des animations quelconques (les GIF clignotants sont déjà des plaies).

La cabale anti-Flash tient souvent de la réaction épidermique à des publicités trop ”pro-actives“.

Balises et balisons : La guéguerre entre Embed et Object

Historiquement, le langage HTML a été étendu par Netscape, puis « extend and embrance » par Microsoft. Chacun y allait de sa petite innovation. Par exemple, qui se souvient des balises <layer> ? c'était le pendant de chez Netscape aux <div> proposé par Microsoft. Idem pour <object>, qui fut la réponse du berger à la bergère aux <embed> de Netscape.
Mais væ victis, ni les layers, ni les embed ne furent retenus par le W3C. Ces deux propositions furent enterrés avec le reste du code de Netscape Navigator (qui venait de perdre la première guerre du web) par le projet Mozilla qui en hérita, pour justement être conforme W3C et tirer un trait sur les erreurs de programmation du passé.
Étonnement, la doc en ligne écrite à l'époque de Macromedia Flash n'a pas été mise à jour. On nous explique toujours qu'embarquer dans la balise <object> un élément <embed> est très utile pour rester compatible avec tous les navigateurs... Ahem... Non, sans rire, je doute qu'il reste suffisamment de Netscape Navigator version 3 ou 4 justifiant d'utiliser encore cette balise. Et pourtant, pratiquement 95% des appels de Flash se font avec du code redondant qui n'est jamais interprété.

On y notera une des propriétés très intéressantes de la balise <object> : le fallback, qu'on pourrait rapprocher de la « dégradation élégante » qui m'est si chère en manipulation DOM. Si jamais l'interprétation des attributs de la balise <object /> échoue, le navigateur client va prendre le contenu entre les deux balises <object> et </object> pour l'interpréter. Chaque balise <param /> est susceptible dans ses attributs d'apporter des précisions complémentaires pour le plugin et les autres balises sont exécutées telles quelles. Un comportement qu'on pourrait croire analogue à <noscript> ou <noframe>, sauf qu'on intégrerait le source du script (ou des frames) dans l'attribut de la balise, ce qui aurait été largement plus intelligent.

<Applet>us dinosaurus et <Iframe>us archeis ne sont pas dans un bateau...

Quitte à parler de fossiles pré-W3C...
En faisant de recherches pour ce billet, je suis tombé sur une vieille balise, cachée dans les strates de la préhistoire du W3C : <applet>. La balise <applet> a été introduite par Sun Microsystems pour l'usage exclusif d'inclusion d'un programme en Java dans une page HTML. Cette balise fut complètement oubliée, et pour cause : aucun mécanisme codebase n'a été prévu pour signaler où chercher le plugin si celui-ci n'est pas présent dans le navigateur client. Une clause réellement indispensable et pénalisante à l'époque où le Java et le Flash n'étaient pas installés par défauts dans les systèmes d'exploitations (non non, ni dans Microsoft Windows 98, ni ME, ni 2000). Il fallait prévoir le coup dans le mécanisme de fallback.

J'ai aussi déniché pour vous une autre balise potentiellement intéressante. <iframe> a un “avantage” : sortir l'élément Flash du reste du HTML, ce qui fait que MSIE n'est plus fautif vis-à-vis du brevet Eolas (lire plus bas). Néanmoins, cela génère plusieurs bugs :

l'absence de gestion de codebase et de fallout en cas de plugin défaillant (absence du plugin, ou, cas récemment rencontré, version “archaïque”)
l'absence de récupération de l'arbre DOM par le programme Flash (si ce dernier modifie la structure de l'ensemble de la page)

La balise <applet> est dépréciée dans HTML4, les frames étant dépréciés dans le XHTML, leur usage n'est donc pas recommandé dans l'optique d'un internet moderne.

La question Eolas

Les “solutions” Javascript par manipulation DOM pour inclure du Flash sont une fausse réponse à une question viciée : celle de la compatibilité avec MSIE suite, non pas à un bug, mais à un procès.
En 2004, Microsoft perd un procès qui met les bases mêmes du web en danger. Eolas, une officine patent-troll [NB6] arrive à faire croire qu'elle a le droit de taxer tout ceux qui osent mettre un contenu interactif dans une page web, le principe même du plugin devient problématique. Non seulement, il y a un prior-art avéré à ce brevet, mais qui plus est on est dans un cas de brevet logiciel lequel n'aurait jamais dû être autorisé. Et les conséquences sont telles que pour une fois, tout le monde a... défendu Microsoft et hurlé contre Eolas (oui, tout le monde : le W3C, Adobe, Mozilla Foundation, Apple, Opera,... dont pas mal de multinationales en faveur des brevets logiciels ! ) au point que l'EFF et d'autres organismes pro-open-source se sont lancé dans un vaste plan de recherche pour contrer le brevet Eolas, estimé comme totalement illégitime.

Peine et procès perdu : Microsoft est condamné à payer plus d'un demi-milliard de dollars au maître-chanteur, et à brider le fonctionnement des plugins (dits « ActiveX controls ») dans son navigateur.
C'est ainsi qu'une mise à jour majeure a fait en sorte que TOUT plugin dans une page HTML (Flash, mais aussi Windows Media, Quicktime, PDF, Microsoft Excel,...) dans les navigateurs de Microsoft doit désormais être “activé” par un clic. Soit un popup s'affiche à l'écran, soit une image prérendue figée doit être cliquée pour activer [NB7] le plugin.
Dans les deux cas, ce comportement est ajouté par l'exécution obligatoire d'un script (très probablement un JScript ou un VBScript) hébergé en local dans MSIE. Et il se trouve que ce petit bout peut faire bugguer de façon aléatoire pas mal d'applications Javascript (et Ajax), dont mon propre site. Microsoft a pallié par un pathétique cache-sexe le refus de l'USPTO de reconnaître ses erreurs.

Très personnellement, je reste étonné que ni Opera, ni la Mozilla Foundation, ni KDE (éditeur de Konqueror), ni Apple (éditeur de Safari) ne furent inquiétés. Seul Microsoft fut la cible de ce patent-troll, très probablement à cause de sa forte rentabilité devant des tribunaux.
Conséquence : MSIE est l'unique navigateur affligé de ce comportement [NB8].

Heureusement, toutes les tares ne sont pas éternelles : Il se trouve que le mois dernier Microsoft a signé en catimini un accord avec Eolas, tandis que l'USPTO se prend actuellement des volées de bois vert de partout, l'EFF déterrant tout plein de cadavres concernant les brevets logiciels. On peut raisonnablement imaginer que bientôt MSIE ne sera plus bridé par le problème, par le jeu d'une mise-à-jour.
Et que donc la solution Javascript est une réponse erronée à une question qui n'aurait jamais dû être posée.

La réponse Javascript, pourquoi pue-t-elle plus que le Flash

SWFobject.js n'a qu'un seul objectif : permettre à une animation en Flash de se lancer dès l'affichage de la page HTML dans MSIE. Sans l'infâme popup, ni clic d'activation.
Voici le code HTML+Javascript qu'on devrait mettre dans un site pour inclure du Flash avec :

<script type="text/javascript" src="swfobject.js"></script> <div id="contenuflash"> Ce texte est remplacé par l'animation flash.swf </div> <script type="text/javascript"> var so = new SWFObject("flash.swf", "IdDuBlocDuSwf", "LargeurEnPx", "HauteurEnPx", "version", "CouleurDeFond"); so.addParam("quality", "low"); so.addParam("wmode", "transparent"); so.write("contenuflash"); </script>

Attendez... il faut une balise <noscript>. Parce que ok, SWFobject gère l'absence du plugin Flash (et théoriquement des versions obsolètes), mais il faut aussi gérer l'absence de Javascript... On doit définir 2 fois (DEUX FOIS) la taille et l'aspect du document Flash. En plus, l'objet Flash devient invisible pour les moteurs de recherche comme Exalead. Et pour parfaire le massacre, on se retrouver à pénaliser ceux qui consultent les billets par un lecteur RSS. Ce dernier peut tout à fait être capable de gérer le Flash, mais à condition d'avoir la même référence que votre site, c'est à dire la bibliothèque JS et son insertion ésotérique. Car la méthode préconisée par l'auteur de SWFobject est standard, soit, mais vraiment pas la bonne si jamais on a plus de deux bibliothèques à charger. Quant à son insertion de code Javascript au sein d'un document HTML, il relève vraiment de la préhistoire...

En fait, on est à la fois dans un souci concernant la gestion du plugin Flash, mais aussi du fonctionnement correct de Javascript : Pour peu qu'un incident à l'interprétation d'un Javascript (notamment dans une exécution synchrone comme SWFobject l'impose à ses utilisateurs), qu'une sécurité quelconque dans les paramètres du navigateur (ou de l'antivirus ou du proxy de votre entreprise, voire carrément de votre FAI paranoïaque), ou que vous ayez fâché votre marabout regex, l'édifice s'effondre, et votre Flash n'est définitivement pas lancé [NB9]. Car SWFobject n'offre que le service minimum en terme de dégradation élégante, plombe de redondance le fallback, et doit alourdir sauvagemment son code pour résoudre les problèmes de fuites ~~urina~~ de mémoire de MSIE. SWFobject.js n'est qu'un bricolage de fortune, pas trop mal codé, certes, mais structurellement incomplet voire boiteux.

Tout ça pour éviter un clic (voir plusieurs, re-regardez la page de garde de nrj.fr) chez les gens utilisant MSIE. S'il plante, pas de Flash, même sur les navigateurs qui ne sont pas concernés par le procès Eolas. Soit une très grande partie des navigateurs... Au lieu d'avoir le comportement considéré comme “normal” depuis deux ans avec MSIE, on prend le risque de faire planter son site dans 100% des navigateurs modernes. Quel progrès !
Le problème a l'air d'empoisonner beaucoup de monde, puisque moi qui ne suis théoriquement même pas professionnel, j'ai déjà été sollicité six fois sur le sujet depuis début Août par des “amis” infographistes jouant aux script-kiddies. J'aurais dû leur facturer mes services.

Être propre dans le HTML, élégant dans sa structure

Alors, comment insérer proprement des éléments en Flash dans un site web, avec une dégradation élégante pour les moteurs de recherche et les personnes handicapés, dans un minimum de code, mais parfaitement valide W3C et susceptible d'être fonctionnel pour plusieurs années ?

La solution est idiote. Puisqu'à relire attentivement la spécification de la balise <object>, on s'aperçoit qu'on avait la solution depuis le début. Si, si ! relisez le chapitre plus haut. Eeeeeeh oui...

Donc nous devrions plutôt écrire :

<object data="src.swf"avec en paramètres la taille prévue de l'animation, son typemime...> <paramles paramètres propre à l'animation/> Texte de remplacement, description, éventuels liens internes qui doivent être suivis par les moteurs de recherche... voire une capture graphique pour respecter l'aspect du site</object>

MSIE vous cause réellement un souci ? Vous voulez vraiment faire l'économie d'un clic ? Il suffit de ne parler qu'à lui pour lui donner vos “solutions” sans polluer les autres. Les recettes existent sur le net (commentaires conditionnels, manip dom, le tout tient en une ligne), pas besoin que j'en usurpe la paternité.

Parce qu'il y a plein de [NB] dans mon billet qu'il faut bien les caser quelque part :

↑ entrer [dans le Flash] : Dans le cas d'Exalead, vu que ce site repose sur le navigateur Konqueror pour faire ses captures d'écrans (User-Agent : « Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.5 (like Gecko) (Exabot-Thumbnails) »), je parie qu'ils utilisent Gnash, mais qu'ils se limitent aux liens immédiatement accessibles pour des raisons évidentes de performance et de sécurité.
↑ ~~URL~~ IRI : Comme déjà expliqué ici-même, le terme IRI est recommandé à la place d'URL ou d'URI
↑ on doit expliquer [la navigation dans un Flash] : Je plaisante à peine : je me serais bien passé de devoir donner un modus operandi aussi compliqué dans mon billet « Ballet perpétuel » pour expliquer comment accéder à la section “cashmere knit”. Si un lien était faisable pour aller directement dans cette partie de l'animation, je serais mille fois plus content.
↑ [site] trop lourd : Et bien souvent, difficilement maintenable. Mon camarade Xylpho a fait le tour des sites de photographes avec des galeries en Flash. Ceux-ci sont très rarement mis à jour à cause de la lourdeur de maintenance uniquement pour ajouter quelques photos. Quant à laisser le programme Flash générer dynamiquement la liste des photos, on imagine d'ici la lourdeur côté client et les risques pour le serveur.
Le projet Lightbox.js et ses compatibles sont d'immenses progrès.
↑ interdire l'accès : Ça demandera du Javascript et de détecter qu'une image est bien présente à l'IRI chrome://flashblock/content/flash.png et [...]flashplay.png ... ou conforter des comportements comme « Why Firefox is blocked ». Politiquement, c'est une énorme erreur de communication.
↑ patent-troll : Un patent-troll est une entreprise de taille ridicule (souvent réduite à un homme de paille, voire une boîte postale dans les îles Caïman) qui gère un important portefeuille de brevets, ici de l'Université de Californie, dans l'unique but de “valoriser” ces brevets devant un tribunal. Ces derniers n'ont souvent même pas été proposés à des industriels. Il n'y a donc aucun intérêt industriel ou technique derrière, juste un cabinet d'avocat qui pose des collets et récolte d'indécents dommages et intérêts si jamais quelqu'un a eu le malheur de “reproduire” en toute innocence un brevet dont il ignorait tout.
↑ cliquer pour activer : Eh mais, attendez, c'est pas le comportement de base de FlashBlock ? Procès pour plagiat !
↑ l'unique navigateur : Si on compte les versions 6+ et 7 ainsi que tous les faux navigateurs qui recarrossent le moteur de MSIE comme AvantBrowser, AOL ou Maxthon.
↑ défintivement pas lancé : Par définitivement, je veux dire que même une interaction du surfeur est inactive. Il n'y a qu'un espace vide, sans rien, là où il suffisait juste d'un clic pour ceux qui gardent un navigateur obsolète.

L'icône IE4Linux a été proposée par JesusDA pour le set d'icônes Tango à la demande de FreeDesktop.

Les coulisses du site en Septembre

Da Scritch — 2007-10-05T23:33:00+02:00

Making of, réjouissance, collection de spammeurs Français et objectif débile du mois.
Webdev

Objectif débile du mois

Le site d'info satirique The Register avait posé la question « So, what's the first rule of Reg Club ? ». Et un lecteur a proposé :

Thou shalt not quote Wikipedia and expect to be taken seriously.

Putain, les mecs de El Reg placent vraiment la barre très haut... OK, même pour moi qui adore mettre des liens absolument partout, pari relevé : Je ne citerai pas la Wikipédia en ce mois d'Octobre.
Hard core. Gasp.

Making of de Septembre

Allongement de la une du site, On cite les titres de7 billets (au lieu de 5). Bizarrement, la longueur varie presque pas.
Ajout d'icône de catégorie, et explicitement des tags dans le flux RSS. répétition de la description dans le contenu. Indirectement, ça permet de voir dans les logs d'Apache qui lit les flux et d'où...
Différentiation de mes commentaires par dc2. M'en a fallu du temps.
Un seul flux RSS était censé être indexé, le but étant d'éviter que les RSS de commentaires apparaissent dans les résultats de requêtes. Mais rel="nofollow" ne suffit pas (alors est-ce utile ?), il a fallu filtrer aussi dans robots.txt.
Modification de la structure du champ commentaire, hélas en cassant la construction proposée par Vric. Extention automatique de la zone texte en fonction de l'écriture. Toujours pas de capcha (ouf !).
Modifications dans le balisage des Flash, suite à la rédaction d'un billet à ce sujet
Modifications des liens relatifs documentaires
Modifications des bulles d'infos concernant les contextes de page (plier/déplier, lightbox,...)

Les soupirs de soulagement

Le futur de Firefox 3 et de Javascript
Microsoft consent à installer MSIE7, même sur des Windows piratés. On peut considérer que MSIE6 a moins besoin de pourrir le code d'un site perso.
Microsoft prolonge la vie de XP. Vista a trop refroidi les pros. Hélas, mes amis qui ne jurent que par la Fenêtre (et Clippy) devront y passer un jour.

Spammeurs Français du mois

Ils m'ont écrit à une adresse qui n'était accessible que par une collecte strictement illégale, ce qui est techniquement un spam caractérisé. La désinscription semble aussi douteuse que l'inscription forcée. Les entreprises suivantes sont donc totalement hors-la-loi en France, et ne sont sûrement pas dignes de bonne foi :

Entreprise/Site	Origine du spam	Technique	Sites publiés, complices	Activité supposée
Skibed.com	mailflip7.edt02.net (82.138.77.199)	Edatis (spammeur avéré)	leadmailing3.com , 80.245.41.17	Location
"Karine SEBAG" (rout.lcp-prod@laposte.net)	9 telecom (86.71.129.183)	Mail édité dans Word (Office 2003 non enregistré), logiciel de spam maison, obfuscation de l'adresse d'origine	vualatele.biz , lcproduction.eu	Vidéos amateurs
Sexy-rencontres (champ-reduit.com)	smtp.cachet.fr (90.40.199.233)	Site suspect (c'est quoi ce formulaire ?) Obfuscation de l'adresse retour (@yahoo.com)	easyrencontre.com	Racolage
infos@cdmultimedia.fr	cdmultimedia.fr (62.161.36.106)	Eudora		Duplication (légale ?) de vidéo
"Adomos" (edouard@marketmail.eu)	mailflip9.edt02.net (82.138.77.201)	Edatis (spammeur avéré)		Manipulations financières douteuses
"Audrey PAGENEL" (stim.ventes@laposte.net)	9 télécom (86.67.224.253)	Adobe GoLive 9, obfuscation de l'adresse d'origine	cine-cheque.fr (récidiviste) , stop-mails.info , vualatele.biz	Achat de coupons
newsletter@lereso.fr	mail.ecipfinance.fr (62.193.248.100)	PHPMailer, phplist	lereso.fr , JC Berbach , ecipfinance.fr	Cosmétiques
Sexy-boutique (champ-reduit.com)	smtp.cachet.fr (90.40.6.54)	Site suspect, obfuscation de l'adresse retour (@yahoo.com)	sexy-megastore.com	Racolage
Unibet (champ-reduit.com)	smtp.cachet.fr (90.33.159.141)	Site suspect, obfuscation de l'adresse retour (@yahoo.com)
andrea-95@cegetel.net	Cegetel (86.75.23.183)	GOTO Software Sarbacane, obfuscation de l'adresse retour (@yahoo.fr)	les-plaisirs.com	Racolage
"FMC via Travelbed" (emilie@travelbed.fr)	mailflip25.edt02.net (82.138.77.217)	Edatis (spammeur avéré)	edt02.net	Prêts usuriers
"BOLLINI PARTNERS" (maila.bus@laposte.net)	9 telecom (86.67.224.106)	Obfuscation de l'adresse d'origine	exploragent.fr	Revente d'un fichier de mail probablement illégal

Honnêtement, je doute de l'efficacité de Signal Spam. Certains ont déjà été plusieurs fois signalé depuis l'ouverture de ce service, il n'y a eu aucun effet.

Javascript, l'accent d'la regex

Da Scritch — 2007-09-06T11:28:00+02:00

“Javascript comme un dialecte”, acte II. Entre le professeur Louis De Funès : « mmmmh les expressions régulières, mmmmmhhh... vous allez en bouffer... mmmmmhhhh »
Webdev

Dans un précédent article, j'avais glosé des difficultés à écrire des javascripts au comportement cohérent sur l'ensemble des “principaux” navigateurs web dans la gestion des arbres DOM. Cette fois-ci, c'est un autre souci qui a été pointé cet été par Bojan Zdrnja, information qui aura sûrement échappé à la plupart des webdev... à leurs tords.
Relevant de nouvelles méthodes d'infecter d'innocentes machines par des virus, ce chercheur en sécurité du SANS a isolé un specimen de Javascript infectieux découvert par Daniel Kluge et mis sous son microscope afin de comprendre pourquoi il est si méchant. Malgré qu'il soit écrit dans un langage théoriquement “ouvert” (car interprété) et même en ayant son code source sous les yeux, il est difficile à disséquer, obfusquant son ADN source afin de protéger ses patrons maffieux. Rapidement, notre expert remarque que ce malicieux code Javascript ne peut s'exécuter que dans Internet Explorer. Pourquoi ? Ce n'est pas la grammaire, ni l'arbre DOM, ni une extension propriétaire de Microsoft qui est en cause, mais... les expressions régulières.

Pour “simplifier”, ces expressions rationnelles correspondent aux théories de Kurt Gödel [NB1], mais appliqués à un alphabet. C'est ÀMHA la meilleure explication jamais trouvée pour pondre le code le plus imbitable pondu histoire de faire criser les collègues de l'openspace [NB2]. Pourtant, je m'en sers pas mal, comme on peut le voir dans mes marques-pages, section PHP. La lecture d'un regex tient à la fois du bénédictin décryptage de langue morte digne de Champollion mais aussi d'une pointe de mystère religieux dans la contemplation de l'arc-en-ciel de votre éditeur à coloration syntaxique, aux motifs ressemblants à une rosace romane [NB3].
Objectivement, le regex est l'ultime solution thermonucléaire pour un question que vous ne vous êtes jamais posée.

Pouf ! Pouf ! Je reprends...

Où le Javascript, c'est comme une Tour de Babel...

Donc, dans cette publication « Raising the bar: dynamic JavaScript obfuscation », Daniel Kluge et Bojan Zdrnja mettent en évidence plusieurs bugs, ou plutôt des différences comportementales dans les regex selon les navigateurs ! Le comportement peut se tester sur cette page. Le premier nombre de la popup d'alerte est à surveiller : S'il indique une valeur de “94”, c'est que l'interprétation de regex est correcte dans votre navigateur.

Ainsi, le moteur JScript de MSIE retourne “98”, indépendamment de MSIE6 et MSIE7. Il considère qu'il peut faire précéder un nombre de plusieurs 0 sans que cela prête à conséquences... ou presque puisque JScript peut considérer qu'un nombre précédé de zéro non significatifs est en fait une chaîne de caractères. C'est le cas dans certaines versions du langage de macro d'Excel.
Safari (versions 2 et antérieures) retourne “93”. En fait, il voit mal le commutateur « /g », signifiant de répéter plusieurs fois l'opération. Ce qui est un bug (corrigé dans Safari 3) et qui fout potentiellement en l'air mon soit-disant script universel déblatéré ici. Ce bug est propre au moteur d'Apple puisqu'aucune des versions de Konqueror que j'ai sous la main (KHTML est la base utilisée par Apple pour son WebKit) ne retourne cette valeur erronée.

Mais c'est surtout un élément très important : Qu'un code supposé être universel peut subir des différences d'interprétation. Quelque chose à ne pas négliger quand il s'agit de “compresser/obfusquer” sa bibliothèque JS. Et une des raisons pour laquelle je déconseille cette pratique.

Contrairement à ce que l'on pourrait croire, les auteurs de ce virus jouent intentionnellement sur ce bug : La suite de leur infection ne fonctionne que sur MSIE, et les débuggueurs Javascripts travaillant plutôt avec un moteur Gecko (donc Firefox), toute personne qui tentera de comprendre leur code (pour justement le bloquer), aura encore plus de mal à le comprendre.

Là où on ne s'en sort plus, c'est quand on se souvient que les regex furent créés à une époque où les ordinateurs avaient rarement des caractères accentués. De cette vénérable histoire, ils ont gardé l'héritage curieux de travailler parfaitement avec les 128 premières caractères de l'alphabet informatique. Et après ? Point de salut : ISO-Latin (16 versions), MS-Dos page, Mac, et pire... Unicode (en UCS-2, UCS-4, UTF-7, UTF-8,...). Vous avez bien peu de chances d'être sûr de votre résultat... L'article Wikipédia a une section qui résume bien le problème [NB4].

L'autre souci, et non le moindre, c'est que les regex sont extrêmement pratiques, souvent utilisés dans le cas de projets compliqués (import/export de xml, analyse de texte,...) et avec une syntaxe... vague. Car de leur très longue histoire, ils ont hérités d'une généalogie très compliquée. Personne n'a jamais normalisé le langage regex, mais chacun y est allé de sa petite touche. Donc un programme, une fonction, voire une formule en regex est susceptibles de différences subtiles suivant où il tourne.
Tout dépend qui a fourni la bibliothèque et qui s'en sert : TCL, Python, Perl, Grep,... Ainsi Microsoft utilise des dialectes très différents ; sa notation dans JScript du navigateur MSIE diffère sensiblement de celle de ses serveurs ASP.NET ou de C#. Certains sites (comme celui-ci) s'emploient à proposer des codes universels. Personnellement, la plupart du temps, j'utilise l'éditeur de remplacement de kwrite pour écrire et tester mes regex, mais ça ne fonctionne pas toujours. Arg.

Transition PHP ? Prépare-toi à des nervousses breakdownes

Quand j'ai refait le design de mon site dascritch.net, comme vous le savez, j'en ai profité pour changer complètement le code (moteur blog, mais aussi présentation de fichiers, de liens, planet, et le reste...) mais aussi de serveur. Et c'est ainsi que je suis passé de PHP4.3 à PHP5. Mais là... surprise ! Entre les deux versions majeures de PHP, le moteur regex a changé... subtilement.

Ainsi, dans ma planet, pour classer les flux rss en fonction de la date de chaque billet, je décodais la balise date, écrite dans un format très spécifique (l'écriture d'une date dans un document RSS mérite un billet tellement que c'est le bazar).
Le code (basé sur magpieRSS) se présentait ainsi :

$regex_de_date = "/(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{2})(:(\d{2}))?(?:([-+])(\d{2}):?(\d{2})|(Z))?/"; if ( preg_match( $regex_de_date, $date_str, $blocules ) ) { list( $annee, $mois, $jours, $heures, $minutes, $secondes) = array( $blocules[1], $blocules[2], $blocules[3], $blocules[4], $blocules[5], $blocules[6]);[...]}

Et ben, vous allez rire [NB5], mais entre PHP4 et PHP5, le singleton ([-+]) [NB6] est devenu “significatif”. Ce qui veut dire que dans mon tableau renvoyé par mon regex, les secondes n'étaient plus en $blocules[6] mais en $blocules[7] si mon code est interprété par PHP5.

Visiblement, cela me semble être un bug d'interprétation de la bibliothèque PCRE qui a été corrigé, mais ceux qui avaient été confrontés à lui s'étaient plus ou moins arrangé avec ce comportement irrationnel [NB7]. Et donc des milliers de scripts, de programmes, d'applicatifs, de sites métiers,... sont basés dessus et vont avoir un comportement “incohérent” lors de leur passage à une infrastructure PHP5. C'est justement pour éviter la fronde des développeurs que Microsoft a instauré la compatibilité des ~~bugs~~ features comme une religion sacro-sainte. Avec fanatisme, donc avec absurdité.

Pour en revenir avec la sale bête

Dernier élément intéressant de l'étude du SANS : la faille exploitée par le virus réside dans la méthode d'appel d'un logiciel tiers. Un problème qui a valu à Firefox deux version successives (les 2.0.0.5 et 2.0.0.6), en fait dû à une très mauvaise habitude de Microsoft Windows dans la gestion des URI. Ce qui ouvre la voie à de nouvelles méthodes d'attaques par document audio ou vidéo malformé. Ce que l'on appelle du “fuzzing”, c'est-à-dire qu'on fait ouvrir des documents mals foutus exprès à un logiciel pour voir s'il plante. Rien de neuf sous le soleil, Windows Media Player était déjà connu pour être sensible à ce genre d'attaques, alors que MS Word et MS Excel sont plutôt bien écrits et très très bien testés de ce côté-là. La nouveauté, c'est que la moindre de ces applications de “lecture” est potentiellement victime d'erreurs de programmations. Des petites failles où le script décrit plus haut pourrait se nicher. Ou tout simplement de très mauvaise méthodes de programmation comme dans le plugin Flash

À noter que l'équipe Firefox a justement développé un outil de fuzzing pour tester la solidité de leur moteur javascript. Présenté publiquement lors du même évènement (la Black Hat Convention à Las Vegas cet été), l'outil conçu à ces fins a été mis à la libre disposition de tous... les navigateurs. Et comme bien souvent l'interprétation d'un code source en Javascript est écrit en regex...

Une horreur de slash

Ce qui est grave, c'est que ce n'est plus une extension qui est attaquable, mais l'implémentation dans la syntaxe de base d'un autre langage supposé lui aussi être quasi-universel. Sauf que les deux erreurs pointées le sont sur des règles de base qui sont uniformes partout ailleurs, et dont l'interprétation fantaisiste étonne les rédacteurs de l'article du SANS.
Un tel oubli chez deux importants constructeurs de navigateur montre qu'il y a encore des choses très importantes à tester dans les moteurs Javascripts. Alors que, contrairement aux DOM, les regex sont décrits avec précision dans la norme ECMA 262. La norme dont tous les moteurs Javascripts se targuent d'être parfaitement compatibles.

Encore une pierre de plus dans le jardin de John Resig. Pas de quoi le démonter dans son inoxydable enthousiasme sur le Javascript, puisqu'il annonce l'arrivée les nouveaux moteurs ECMAScript. Enfin conformes ?

Notes de bas de pages.

↑Kurt Gödel : Malgré son patronyme, et le fait qu'Hitler aie changé la nationalité de ses compatriotes, tu noteras, chère Katell, que son nom se prononce avec une pointe d'accent Tchèque plutôt que Germanique. Ce que tu n'avais pas compris la première fois.
↑ : D'ailleurs, ce langage est tellement l33t que la doc web de la lib PCRE est sciemment présentée comme si elle sortait sur un vieux terminal texte avec la commande man. C'est vraiment du terrorisme social pour empêcher les petits jeunôts de se croire plus compétents que vous parce qu'ils sortent d'une formation quelconque... Hinhinhin...
↑ coloration syntaxique d'un regex : Très honnêtement, si vim ne me proposait pas la coloration syntaxique, jamais j'aurais compris que le code en perl proposé dans le roman « Le Cryptonomicon » pour décoder du cryptage Enigma était erroné suite à un oubli d'un “/” dans une règle de substitution. Pour les curieux, page 227 du tome II, « Le réseau Kinakuta » de la première édition Francophone chez Payot SF.
↑ référence Wikipédia : Pour ceux qui me liront plus tard, la version de l'article au moment de l'écriture de ce billet.
↑ « vous allez rire » : humour geek au 0xFE degré, forcément.
↑ ([-+]) : Ce bout de regex signifie qu'à cette position, il y a un caractère unique pouvant avoir la valeur “+” ou “-”. Et uniquement celles-ci. Si ça marche pas, la fonction regex est fausse, preg_match() retourne la valeur false et donc la partie suivante du script est ignorée. Ce bug me semble être lié à celui-ci
↑ « ceux qui [...] » : ou plus probablement, ces développeurs perçoivent les regex comme de la sorcellerie. Ils ont chacun dû bidouiller au pif un code pioché dans un “Grand Albert” quelconque, formule magique se trouvait être fonctionnelle, et faute d'expertise, n'ont même pas relevé un comportement incohérent. Après tout, les gens qui invoquent pour eux des regex en égorgeant un coq noir par une nuit de pleine lune autour de braises de VT100 n'ont pas d'explication à donner. D'ailleurs, la syntaxe des rituels sacrés regex n'accorde aucune facilité de commentaires, qui pourraient briser l'invocation. Généralement, on évite soigneusement de provoquer leur ire par une question qu'ils pourraient trouver offensante. D'abord ça brise la magie, et ensuite si le sorcier voudou vous jette un œil noir, ça pourrait vous faire partir en sucette votre config Apache... Ugh.

Dans les tréfonds du classement

Da Scritch — 2007-08-31T21:41:00+02:00

Plus exactement très très bas dans le CSSR07, quelque part à la 62ème place sur 72...
Webdev

Et pour cause ! Pour me motiver à mettre en ligne la nouvelle version de DaScritch.Net au plus vite après deux années de développement extensif et cahoteux, j'ai osé m'inscrire au redoutable Cascading Style Summer Refresh version 2007. Et j'étais, à quelques erreurs près de syntaxe, totalement valide HTML même pour les invalides, parfaitement CSS-aware, avec du JS:DOM à tous les étages qui font croire que mon site est en Flash et en AJAX (eh eh eh !).

Or, pour une fois chez Alsacréations, il ne s'agissait pas d'avoir forcément le site le plus conforme, le plus techniquement parfait mais.... le plus joli. Je vous laisse deviner comment je me suis fait ramasser ?

Couvert de ridicule le Da Scritch !

Mais bon, indépendamment de ma note calamiteuse, de la quasi absence de commentaires et de l'été pourri, j'ai eu du plaisir.

Celui en consultant les “concurrents” de retrouver quelques amis (dont Hadrien), de voir des sites absolument superbes (tels que DazoNet, la case de l'Oncle Tom, la galerie Its Art Ist ou encore du Studio Américain), d'avoir beaucoup appris en scrutant les codes servis (et de ne pas être seul à parier sur les CSS3) et enfin d'avoir découvert un outil de stat prometteur.
J'ai eu beaucoup de bonheur à découvrir, à échanger, et à bookmarker.

Alors oui, se prendre une telle note rend humble, mais je m'en fous, Ce concours m'a rapporté 1/30^ème de ma fréquentation en Août, période très très très maigre, qui, même s'ils furent rares à rester plus de 3 minutes pour voir au moins deux pages, m'ont valus quelques compliments sur le moteur plutôt que sur la carrosserie. De quoi être satisfait des nuits blanches pour rendre copie dans les temps, malgré les imprévus qui rendent votre machine inutilisable pendant deux semaines.
Il en restera de cette opération à marche forcée, des billets spécifiques au sujet dans lequel je documente mes écueils. Pas mal encore de polissage technique à faire et de choses à ajouter, régler, améliorer... Et pour confirmation, non, je ne suis pas infographiste de profession, juste développeur web en chambre.

Tassons les Javascripts

Da Scritch — 2007-08-30T18:43:00+02:00

au DocMartens™. Encore plus fort... Allez, encore ! Le gain est dérisoire, mais c'est si marrant ! Tassons ! Tassons ! Comme des gros bourrins...
Webdev

Dans le dernier épisode de mes aventures en Javascript, on m'a plusieurs fois fait remarquer qu'on pourrait réduire les appels à un seul programme javascript en copiant collant toutes les bibliothèques utilisées en un seul document.

Un constat qui part d'un calcul logique : Chaque appel d'url HTTP se fait en envoyant plusieurs paquets d'instantiation IP. Juste histoire de dire « youhou ! je suis làààààà ! ». Et c'est ce qui fait que 4 images de 200 octets seront plus longs à charger qu'un de 1200 [NB1].

Oui mais ...

Oui mais ce genre de comptes d'apothicaire prête à sourire quand on a un style avec une dizaine d'images minimum à charger. Et pour ce qui est des lags pour cause de cascade de bibliothèques JS, la meilleure méthode semble être celle du chargement désynchronisé. De n'avoir qu'une petite bibliothèque d'initialisation avec le minimum [NB2] qui en appelle de largement plus grosses.

Lesquelles peuvent à loisir être très lourdes. À titre d'exemple (en complément du précédent billet) et rien que pour rire, Apple envoie un gargantuesque 500 Ko pour les galeries photos de iWeb. Ça laggue un peu dans le tas :

À noter que dans ce tableau, les valeurs de temps indiquées correspondent pour un seul fichier. Le graph représente le cumul...

Notons qu'Apple utilise une méthode de chargement JS asynchrone, mais que ses bibliothèques sont complètes, le source est brut avec commentaires, indentation, etc... Vont-ils penser à réduire leur bande-passante ? Ou laisser cet excellent exercice pratique pour débuggage ?

L'autre inconvénient du programme unique tient dans les bugs à l'interprétation. Si jamais une seule erreur arrive, toute la suite du programme est ignorée. Et vu que le Javascript comporte une multitude de dialectes, ça augmente les chances de plantages.

Réfléchir à réduire...

Donc, revenons à l'idée d'une seule et très grosse bibliothèque unique, réunissant un voire plusieurs toolkits et ses extensions [NB3] (Pourquoi pas, puisque c'est ce mode de distribution qui est proposé par mootools)... plus des routines de pub AJAX ou de liens sociétaux...
Néanmoins, il faut correctement maîtriser l'ordre d'appels, éviter les conflits (dans les espaces de nommages de variables, de fonction, les ordres d'appels d'évènements, voire carrément les méthodes addevent).
L'autre souci, c'est que ce copier-coller rend difficile la gestion des versions (si une des bibliothèques vient de changer de version, il faut réinsérer manuellement dans le source la mise-à-jour). La meilleure méthode dans ce cas-là est de créer un script côté serveur (pourquoi pas en évènement de répertoire, via bash, pour éviter d'éventuel trou de sécurité si le script est en accès public), qui aura pour instruction de construire le programme à livrer aux visiteurs.

Purger les caractères inutiles.

On peut aussi enlever tout commentaires, les lignes vides inutiles... Cela n'accélérera pas de façon visible l'interprétation du script, mais pourrait fortement alléger le poids, donc le temps de chargement.
Évidemment, il faut garder une version originale, voire carrément mieux, utiliser un système de versionning, mais à ce stade, autant l'appliquer à l'ensemble de votre serveur web !

Et puis...
et puis on peut supprimer les espaces et tabulations inutiles, celles qui courbent et déhanchent si élégamment votre code source, ou peuplent de leur non-dit vos fins de lignes... quelle utilité sur un site web grand public ? Zou ! À la trappe...

Et puis... ces retours chariots, eux aussi ont peut les virer...
Et hop ! regex-ons comme à la Légion : s/[ ]/g
Sauf que contrairement au C, au Pascal, au Java, les retours chariot ont parfois signification : celle de séparer les instructions. Les “ ; ” en fin d'instruction ne sont pas obligatoires, et implicitement placées en fin de ligne après une instruction complète.

Et si on songeait à exterminer toutes ces fonctions inutiles ? Par là, je parle de toutes les instructions de débuggage (comme breakpoint) , voire de fonctions propres à votre dev. L'excellent compresseur de Dean Edwards, qui m'a été bien utile pour tous mes tests, supprime les lignes commençant par “ ;;; ”. Une méthode efficace, 100% compatible et pas prise de tête pour différencier dans le source le comportement de développement et celui d'exploitation.
Une bonne habitude à prendre.

Nom d'une lettre !

Les fonctions, les variables, les objets régulièrement appelés, plutôt que leur donner des noms explicites, certains se lancent dans une réduction de taille de nommage à un voire deux octets ! Bien du plaisir pour mettre en place, mais surtout pour redécoder si le logiciel de substitution fait son travail de manière trop automatisé...

J'ai aussi vu l'usage de caractères de jeu étendu (mais cette fois-ci dans une CSS). Or là, on nage en eaux troubles : la confusion du jeu de caractère selon les navigateurs. Car si le jeu par défaut du HTML a tendance à être de plus en plus souvent fixé en UTF-8 par les concepteurs de sites, les Javascripts (par défaut dans la norme) et les CSS (surtout avec Safari) ont tendance à revenir spontanément en jeu ISO-Latin.
Foutoir garanti.

Si vous vous amusez à ce petit jeu, la meilleure solution est d'à la fois indiquer au navigateur dans la balise HTML le jeu de caractères du script/style appelé dans la balise via l'attribut charset="", et de le repréciser à nouveau dans le header. En priant pour qu'un logiciel client (ai-je dit “MSIE ” ?) ne fasse par un charset-sniffing foireux sur vos appels JSON.

Jusqu'à quel point peut-on “compresser” un Javascript ?

Tout en revenant à l'excellent outil de compression en ligne de Dean Edwards, celui-ci propose une option “packer”. Une fonction qui permet de faire une compression sommaire par règles de substitution, qui peut aussi faire office d'obfuscation. Un cryptage sommaire qui rendra difficile pour le premier script-kiddie ou webdesigner débutant venu de repomper votre source. Promis, je ne vise personne...
Je ne crois pas me tromper en écrivant que l'outil est très populaire probablement pour cette dernière raison.

En fait, il est idiot de croire qu'en cryptant de la sorte son Javascript, on va accélérer le chargement. C'est faux : le navigateur perd du temps à décompresser le source originel puis à le ré-interpréter. Et ceci à chaque changement de page puisqu'il ne le garde pas en cache (un peu comme MSIE avec des Images appelés dynamiquement par JS ou CSS). Car bien évidemment, dans une navigation client, un programme JS n'est pas lié à un site, mais à un document HTML. Votre JS est donc susceptible de changer à chaque navigation, donc le navigateur va fort logiquement ne pas garder le runtime de votre bibliothèque, et en initier une nouvelle à chaque page.

Autre souci, ces règles de substitution peuvent être sujettes à des bugs ésotériques, comme celui concernant les moteurs regex. Mais rien que ça, y'a de quoi en faire un billet...

Conclusion

On peut :

stripper les commentaires
supprimer les indentations
supprimer les retours chariots
substituer les noms de variables, de fonction, les objets récurrents par des noms très courts

mais on peut éviter :

d'utiliser des noms (variable, fonction, objet) avec des caractères non US-ASCII
de compresser par substitution
de tout coller dans une seule bibliothèque extrêmement lourde

Le meilleur exemple à suivre est celui de Google : Il suit très exactement toutes ces méthodes. N'allez pas dire que j'ai copié sur eux, je m'en suis rendu-compte après coup.
Une tel coïncidence, c'est que mon raisonnement ne doit pas être si foireux...

Nota bene :

↑ En plus du problème de la taille minimale de trame IP, mais ça, c'est un autre problème... élégamment résolu par chiptune.com, un incroyable émulateur d'Amiga tout en Javascript et DOM !
Pour afficher les textes dans les polices du Workbench, il ne charge pas une image par lettre, mais tout un alphabet en une seule image, laquelle est dupliquée pour chaque lettre avec une fenêtre de visibilité soigneusement calculée. Seul inconvénient, cette méthode ne marche que si les images sont en positionnement CSS fixé, voire absolu.
↑ fonctions minimales : Dans ma boîte à outil basique, j'y mettrais le chargement par insertion DOM, la gestion des cookies, timeout, addevent et domready. Ces fonctions primitives sont très faciles à écrire.
↑ Parmi les pages intéressantes que j'ai trouvé, Alister Cameron propose le pack prototype.js + scriptaculous.js (avec quelles extensions ?) packé en un seul fichier. Notez sa solution sur la gestion de charset appelé.

Pas de livraison du Supplément Week-End aujourd'hui

Da Scritch — 2007-08-25T10:08:00+02:00

Mais une petite vidéo programmée à la place pour vous faire patienter en attendant notre retour à la radio....
Vu

Pas d'émission aujourd'hui pour cause de retransmission d'Universités d'Été d'Attac sur Radio <FMR>. Étant donné que dans cette radio on fait dans la gaudriole, j'ai proposé qu'on passe plutôt celles du PS, mais comme, par équité, il fallait aussi diffuser celles de l'UMP, là, tout de suite, ça a jeté un froid.

Mais pas de panique, la saison IV du Supplément Week-End est toute proche. On a même refait complètement le site, inclus deux sites de mes anciennes émissions, et inscrits au CSSR (votez pour nous !). Pour vous allécher, je vous propose une petite vidéo exhumée ce matin en rangeant mon répertoire “conneries reçues par mail”. Un palliatif qui va ravir les fans de super-héros, de films d'action, de soap-opera hindi et de musiques kitch. Bref, tout l'essence du mélange improbable qu'attendent les auditeurs de notre Supplément Week-End :

(source inconnue, auteur inconnu, D.R.)

Chérie, toi qui me lit dans le salon, faudrait quand même qu'on se dégage un moment dans nos emplois du temps de ministre pour regarder les trois DVD que nous a aimablement prétés Dusport... quand même...

Pour quelques Javascripts de plus

Da Scritch — 2007-08-22T18:27:00+02:00

C'est bien joli de mettre des effets partout... Mais si ça doit rendre un site très lent, la java en vaut-elle le lag ? Pendant la reconception de mon site, je me suis furieusement gratté la tête pour vous.
Webdev

Grâce à d'excellents toolkits Javascript [NB1] et à la maturité des navigateurs web, il est possible de donner à un site web en HTML des effets dignes de Flash. Des possibilités qui deviennent envisageables même pour un infographiste ou un intégrateur web, en en connaissant qu'un minimum.

Mais ces bibliothèques peuvent être très lourdes, et leur temps de chargement côté surfeur pénalisent les sites, rendant parfois les navigateurs comateux pendant quelques secondes. Si vous ajoutez les dépendances entre ces scripts, vous pouvez vite atteindre plus de 3 appels (par exemple, sur mon ancien site : prototype.js, scriptaculous.js, effects.js, nicetitle.js, lightbox2.js ,... hem hem)
Si vous ajoutez à la page un Javascript pour un site sociétal (genre Technorati), une bannière de pub (Adsense ou autre) voire plus simplement un bête outil d'analyse trafic par mouchard JS (WebTrends, Google Analytics, Xiti), voire même puisque c'est à la mode des appels Ajax en pagaille... le temps de chargement de votre page devient tributaire d'un serveur tiers. Ce qui veut dire que si ce serveur devient moins réactif parce qu'on est aux heures de pointes, votre site donne une impression sensible de ralentissement, avec un freeze très désagréable du navigateur. Le problème touche tout le monde, frustrant car il ne dépend pas du webdesign... ou plutôt si : Il est possible en reconcevant votre code de supprimer ce méchant lag.

Et je comptais bien le mettre en pratique en redesignant mon site.

Au début des Temps, le Javascript et le HTML étaient mélangés

C'est la méthode la plus ancestrale pour faire appeler un Javascript : En l'attachant à un lien <a href="javascript:code();">. L'avantage, c'est que la balise hyperlien donne une cohérence du GUI. Le problème, c'est que les navigateurs qui n'ont pas Javascript (et à l'époque, ils étaient légion) n'ont que faire de ce lien.

Alors fut introduit la possibilité d'attacher un évènement à une balise. Ainsi, il était possible de créer des boutons qui créent une action <button onclick="code();">. Mais ces actions n'avaient lieu que si une action utilisateur avait effectivement lieue...

Heureusement, fut introduit dans le langage HTML une balise où tout devint possible : <script>
Contrairement à ce que l'on pourrait croire, cette balise n'est pas à l'usage exclusif de Javascript : On peut y inclure du VBscript (pour IE), du Tcl, du Perl (sur moteur Mozilla), selon le code type-mime spécifié dans l'attribut type="" (par défaut, ça reste du Javascript).

Néanmoins, l'affichage de votre page web sera complètement paralysée tant que cette balise ne sera pas intégralement interprétée. Par exemple, sur cette (vieille) page, la fonction alert(); bloque le parser [NB2], qui attend que le petit script rende la main pour afficher le reste du document. Quand l'utilisateur a cliqué sur la boîte de dialogue, le navigateur voit la suite de la page, et donc la balise <style>. C'est très important : cela signifie que votre page n'est pas complètement visible (même complètement chargée dans l'ordinateur du visiteur), puisqu'il faut que le navigateur termine d'interpréter votre Javascript avant de finir l'interprétation de votre document HTML.
Et pourquoi un tel comportement ? Car vous pourriez très bien y faire une construction “dynamique” (plus exactement “brutasse”) de HTML dans votre script via la fonction document.write();. Vous verrez que cette dernière est infâmement fourbe.

Et le Verbe fut `<script src="`...

Cette méthode, qui est unanimement considérée comme la plus propre et la plus standard (j'ai déjà expliqué pourquoi), permet d'utiliser des scripts globaux à l'ensemble ou une partie importante d'un site web. Idéalement, il est placé dans la section <head> du document HTML.

Néanmoins, elle a exactement le même impact côté client qu'un script embarqué : Le navigateur arrêtera tout traitement de la page (et donc bloque son affichage), tant qu'il n'a pas intégralement reçu le programme Javascript et qu'il ai traité les fonctions appelées.
Alors qu'en temps normal la plupart des navigateurs modernes ouvrent 4 chargements en simultanée (en mode asynchrone), on passe dans un système digne de nos plus Vaillantes Administration où chacun attend son tour que le chiffre imprimé sur son ticket soit annoncé au haut-parleur : Dans le cas de mon ancien site, ce n'est qu'une fois prototype.js chargé et interprété en entier qu'on passe à effects.js... et ainsi de suite jusqu'à google-analytics.js, et enfin les images se chargent... mais par paquet de 4, sans s'attendre mutuellement.

À noter que l'attribut defer dans la balise permet d'éviter cette attente. Si évidemment votre navigateur la supporte [NB3], et à condition de bannir tout document.write(); et toute dépendance entre les scripts. Pour mon exemple, c'est loupé.

`<script src="` juste à la Fin du HTML

Durant sa période de béta-testing, Google Analytics fut victime d'une panne. Le serveur google-analytics.com hébergeant le programme urchin.js étant indisponible, l'ensemble des pages de leurs ~~clients~~ béta-testeurs furent inaccessibles pendant 24 heures. Le temps que le navigateur du visiteur attende le timeout (en général, une bonne minute), tous les sites qui utilisaient ce service ne furent que pages blanches... Car à ce moment-là, Saint Google avait décrété que son outil de confession devait être invoqué pieusement par le HTML dans la balise <head>
Conscients de ce souci, G.A. recommanda alors de ne plus appeler leur script entre les balises <head>, mais juste avant </body>.

Mais alors, se dit le lecteur, pourquoi pas entre </body> et </html> ? Parce que le code ne serait plus valide. Ça peut pas. Pas bien. Faut pas. Saimal. Sapu.

Sauf que...
Sauf que la position idéale, si on va dans l'idée de faire un appel à un .js unique, c'est à côté des CSS [NB4], c'est-à-dire dans la balise <head>...

Prenez mon `body` et `onload`ez-le

Revenons au principe d'attacher une fonction JS à une balise HTML.
Et là, on s'est dit qu'il suffisait d'invoquer les éléments lourds non pas dans la fonction principale du .js (équivalent au rôle de la section main(); en C), mais lors de l'évènement onload de la balise <body>. Ce qui veut dire que soit on l'appelle dans le HTML par <body onload=" (je rappelle que cette méthode, c'est caca.), soit en liant une fonction en javascript :
window.onload = function () {} [NB5]

Néanmoins, l'évènement onload est intrinsèquement lié au chargement complète de sa balise et de tous ses enfants. Ce qui veut dire que cet évènement l'a lieu qu'après que l'ensemble des éléments comme les images <img />, les images décrites dans la/les CSS, les <object />, <iframe /> et bien évidemment <script /> soient effectivement chargés.

Cette solution garanti qu'aucun blocage ne sera dû à l'absence quelconque de quoi que se soit, sinon.... du visiteur ! Car il est parfois utile de comptabiliser au plus vite votre visiteur : pour gonfler vos statistiques de trafic “naturellement”, pour imprimer plus de pages de publicités vues, etc... Si possible, avant les deux secondes où il va s'apercevoir qu'il n'est pas sur le site qu'il attendait.[NB6]

Time is money, et attendre onload pourrait en faire perdre pas mal

Un `<script src="" />` unique, avec le tentateur `document.write();`

En fait, le coup/coût idéal serait de n'avoir à faire appel qu'à une seule balise <script src="" /> dans son document HTML, laquelle appelle ses petites copines javascripteuses pour bricoler leurs petits effets. Lightbox, Nicetitle, Analytics, AdSense...
Ça simplifierait de plus le développement, puisqu'il suffit de modifier une unique adresse pour, par exemple, changer complètement de toolkit. Une approche qui ressemble à celle de la création de CSS sur un site en ligne.

Or voilà exactement ce que je déteste : du document.write(); en vrac.
D'après vous, que se passe-t-il quand cette fonction est utilisée ? Le nouveau HTML est parsé, chargeant un Javascript qui est interprété, ralentissant d'autant l'affichage de votre page. Si vous tentez de retarder (avec la méthode .onload ou un setTimeout();) une fonction qui utilisera document.write();, vous n'êtes absolument pas sûr du résultat... pouvant même parfois effacer complètement votre document HTML... En clair : c'est une MAUVAISE SOLUTION.

À noter que cette solution proposée par l'équipe IE était tellement bugguée (surtout que la bonne réponse était CDATA), qu'elle a mené à une suite intéressante de réponses dans le blog de Gervase Markham (de l'équipe Firefox). Ce qui m'a amené (et je suis pas le seul) à une solution évidente :

Un seul `src=` et sur ce script je construirais mon DOM

Or donc, appelé à deviser là-dessus, Alan Trick le biennommé propose dans les commentaires d'utiliser une construction via l'arbre DOM du document. Avantages : Le parser du navigateur n'a plus à attendre et continue pépèrement à montrer le HTML, le chargement du source externe se fait en asynchrone (et donc indépendemment des temps d'attente),... bref tout le monde il est content. Pour ceux qui ont besoin de dépendances, Dao/Design-Noir propose une chouette bibliothèque extrèmement légère (moins de 30 lignes ! pensez-donc !) qui gère les listes d'attente et l'exécution de fonctions une fois la bibliothèque chargée... D'ailleurs, c'est comme ça qu'il colorise son code source.

Une solution efficace, mais qui dans des cas rarissimes, vous vaudra de vous fritter avec la susceptibilité légendaire de MSIE. Rien que ce domaine vaut un autre chapitre, qui racontera comment j'ai appris plein de nouveaux gros-mots que blogguent ouvertement les développeurs de ASP.NET contre leurs collègues de IE.

Mais avant ça, il faudra que je vous cause comment encore optimiser votre Javascript : En tassant son code au DocMartens™ !

Petits textes explicatifs avant de fermer le </body>

↑ Toolkit : Bibliothèque de fonction agissant comme de véritables environnements de développement. Ils étendent le langage, comble des déficiences, installent des fonctions primitives rébarbatives à ré-écrire à chaque fois. La mort du Bénédictin.
↑ Parser : Logiciel qui analyse syntaxiquement un document texte afin d'exécuter le programme qu'il contient (Javascript, Basic,...), construire sa mise en forme (HTML, XML, OpenOffice,...), ou les macros d'aspect (CSS, les thèmes de Firefox, Word, OpenOffice,...). Généralement, c'est bourré de regex, voire écrit dans le plus incompréhensible des Perl parce que celui qui l'a écrit ne peut pas saquer son collègue en face...
↑ defer : Même si elle est décrite dans la norme HTML4 par le W3C, cet attribut ne semble supporté que par MSIE. Pour une fois que l'équipe de Microsoft est en avance sur les autres pour appliquer les normes et standards, elle a dû sabrer le champagne. Je me demande si c'est arrivé une autre fois depuis 1998...
↑ les CSS : Certains mécréants n'ont pas encore compris l'utilité de la CSS unique, choyée et bichonnée comme l'unique héritier mâle des nombreuses familles Chinoises... Faudrait que je parte en croisade aussi là-dessus.
↑ window.onload : On peut écrire indifféremment window.onload ou document.onload ... les différences entre les deux éléments sont relativement minimes, et àmha ne concernent que la présence de <frame /> dans votre code.
↑ mesure d'audience : À ce sujet, I télé diffuse parfois un “bumper” pour vanter leurs XX millions de télespectateurs mensuel... Un chiffre parfaitement juste car il s'agit de personnes restant au moins une seconde sur leur chaîne. Le temps d'éternuer en zappant...
Questions chiffres, Bertrand Renard arrive à retenir ses télespectateurs autrement...

Sortir le script des balises

Da Scritch — 2007-08-15T23:30:00+02:00

Pourquoi Javascript ne doit plus polluer le HTML et comment faire. Une méthode de création de site qui va changer les relations entrer développeurs et webdesigners...
Webdev

Javascript est un langage assez fabuleux : Il est interprété sur tous les navigateurs (avec de sérieuses nuances), il est relativement rapide à développer et à exécuter, et il permet des effets en manipulant le HTML, l'arbre DOM du document ou les CSS.

Dans mon précédent design (conçu en 2003... ahem...), j'insérais dans mon document HTML des commandes Javascript pour chaque balise fonctionnelle, or certaines étaient liés à des groupes. Genre toutes les balises class="masqueur" qui ont une action sur les balises "masquable" correspondantes.
Ça donnait ceci :

<dt class="masqueur" id="bloc" onclick="flipflop('bloc')" title="cliquez pour afficher">Quelque chose à écrire!</dt> <dd class="masquable" id="bloc_m">Texte caché</dd>

Ça devenait assez chiant à coder. Que faire ? Laisser le travail à PHP, en priant qu'on ne s'emmêle pas les pinceaux dans un code à étage multiple ? Une solution qui serait devenu difficile puisque mon CMS (Dotclear) introduisait un système de template, rendant les inclusions PHP difficiles à gérer.

Exemple pratique : Supposons que vous avez un blog de plus de 800 billets et 500 pages statiques, que dedans, vous utilisez des effets comme l'affichage de galerie d'images ou d'effets de cacher/décacher dynamiquement par javascript. Supposons que vous changez toute votre base, ou même plus simple, que vous changez tout simplement de bibliothèque d'effets Javascript. Vous vous voyez tout modifier puis revérifier ?

À la réflexion, ce genre de Javascript embarqué n'a rien à faire dans le balisage HTML : il le rend lourd, pénible à maintenir, et n'a aucune utilité pour les logiciels clients qui n'utilisent pas Javascript (le panel est large : des robots de moteurs de recherche, jusqu'aux lecteurs braille en passant par les téléphones mobiles qui en plus paient au kilo-octet). Sans compter qu'il génère des incompatibilités dans l'usage des comparateurs < et > ou de l'opérateur &&. Perso, je suis pas fan des <![CDATA[ ...]]> dont j'ai jamais été fichu de retenir la syntaxe.

L'un des premiers effets réellement simples et réussis que j'ai vu d'insertion d'effet dynamiques en fonction du code HTML, c'est Lightbox. Pour appeler Lightbox, il suffit d'entourer une balise <img /> affichant une image réduite, vers l'original de la même image. Sauf qu'on utilise l'attribut rel=. Si celui-ci comporte parmis ses paramètres le mot-clé "lightbox", le lien traditionnel est remplacé par le lancement du visionneur JS.

Brillant.

Parce qu'il supprime tout appel Javascript du HTML,
Que cet appel est construit par manipulation DOM du document HTML
Que si Lightbox n'arrive pas à faire son travail, les balises HTML restent fonctionnelles, c'est ce qu'on appelle de la dégradation élégante
Qu'il utilise un attribut de la balise <a /></a> conforme mais peu utilisé

Lightbox a vite eu un panel très large d'utilisateurs. Mais il avait aussi l'inconvénient d'utiliser Prototype.js, Effects.js et Scriptalicious.js. Ce qui rendait les appels de page très lourds, notamment sur les appels (j'en parlerais prochainement). Très vite, de nombreux clones sont apparus, améliorant ou étendant ses possibilités. Seuls ceux qui utilisent le même type d'appel simplifiés sont réellement utilisés, et à raison : Tout autre méthode rend trop dépendant d'une bibliothèque qu'on pourrait être amené à changer.

En en ayant compris le principe, il devenait très rapide de s'imposer de nouvelles techniques pour créer son site web. Puisque j'utilise des classes HTML de manière conjointe avec certaines fonctions Javascript, il suffisait de manipuler mes documents HTML par ma bibliothèque JS personnelle, à la volée par le navigateur du client. Faire en sorte que celle-ci s'initialise (une fois que le navigateur a complètement parsé le document, sinon ça peut péter), en lui faisant manipuler des classes d'éléments. Les paramètres des fonctions sont tout simplement lus par le nom de la balise. Ce qui nettoie radicalement mon HTML :

<dt class="masqueur" id="bloc">Quelque chose à écrire!</dt> <dd class="masquee" id="bloc_m">Texte caché</dd>

Et simplifie mes appels :

function flipflop() { var objet = document.getElementById( this.id+'_m' ); [etc...] }

Le gain de rapidité est évident. Puisque les “éléments superflus” d'animations sont produits si le navigateur client peut les lire. Et qu'on obtient à la fois une cohérence de développement, mais aussi d'aspect puisqu'une fonction hérite du coup de propriétés CSS, lui donnant un réel look&feel. Le comportement des navigateurs n'est pas encore suffisament uniforme sur l'arbre DOM en Javascript, mais on arrive à des résultats absolument bluffants.
Mais attention : Si une fonction Javascript n'est requise que par un seul document HTML, il vaut mieux l'y laisser pour ne pas alourdir sa propre bibliothèque JS, ce qui serait passer de Charybde en Scylla. Écrire un programme en Javascript avec ses multiples dialectes n'a rien à voir avec une définition CSS... Mais plus les sites le feront, plus Microsoft sera obligé d'y réfléchir.

Quelque chose qui rappelle exactement ce qui s'est passé quand on a séparé la forme du fond. Quand toute la présentation fut retirée du HTML (adieu color= de sinistre mémoire !) et réuni en un seul endroit, le CSS. C'est peut-être ce qui manque encore à maîtriser :
Sortir les comportement globaux d'effets du HTML pour que le Javascript s'en occupe tout seul.

Et voici les colonnes !

Da Scritch — 2007-08-07T13:19:00+00:00

Quitte à changer le design du site, testons une des nouveautés offertes par les navigateurs en pointe. Elles sont belles mes colonnes ! Elles sont du dernier chic Gréco-Romain, mes colonnes ! Qui en veut des colonnes ?

Webdev

Comme vous avez pu le remarquer, le redesign de dascritch.net n'a pas consisté qu'en un bête changement de couleurs ou d'éléments de navigations. Aujourd'hui : l'aménagement d'espace.

Historiquement, les pages web sont écrites dans un langage de balise, appelé HTML. Celui-ci dérive du SGML, qui est en fait un système de PréAO comme Microsoft Word, T_eX et le DVI. De cet héritage, et avec l'arrivée des CSS, la plupart des webdesigners ont inconsciemment retenu que la largeur de votre texte est considérée comme contrainte, mais que votre page s'allonge indéfiniment verticalement.
C'était sans compter sur l'arrivée des écrans larges dans la bureautique. Les ratios 16/9, 16/10 et autres “écrans cinémas” se sont popularisés par la lecture des DVD (ou des DivX, hein... soyons pas aveugles), et surtout l'impossibilité d'utiliser autrement Excel[1] sur des tableaux très larges.

Rien n'est plus agaçant que de lire des sites prévus pour des largeurs VGAesques[2] à l'heure des écrans de 1300 pixels de large, en format cinémascope... La moitié de votre écran est occupé par du VIDE. Car on est arrivé à un paradoxe : la plupart des sites web sont beaucoup plus long que large, alors que le rapport s'inverse pour les écrans.

Voici donc ce que donne un design élastique (contraint horizontalement, ce que j'appelle “corset”), celui de mon ancien site. Notez le magnifique espace vide des deux côtés.

C'est ce qui a en partie motivé mon redesign de site : j'ai décidé d'abandonner l'aspect “corset” du design élastique. Que diable ! Laissons le lecteur choisir la largeur qu'il veut ! Vive le design liquide !

Voici ce que donnait en design liquide la maquette de mon nouveau site (le texte est issu du même billet) :

Rapidement, je fut confronté à un problème inhérent au design liquide : selon l'étirement de la fenêtre du navigateur, les lignes de texte risquent d'atteindre des longueurs rendant leur lisibilité digne d'un marathon oculaire. Heureusement, en tant que lecteur très fervent des sites des développeurs des navigateurs, j'avais déjà apprécié les tests de mise en colonne.

Dans les discussions en cours autour de la norme CSS 3 a été proposé le concept de la mise en colonne. Une idée que je trouve largement plus intéressante et utile que le multi-background ou l'ombrage de texte, car celle-ci s'attaque directement à la lisibilité et à la mise-en-page, au lieu de se concentrer sur un aspect du décor. Sans toucher au HTML, le navigateur décide tout seul quand les colonnes doivent apparaître et où les césures doivent être faites. Il s'agit encore d'un brouillon de norme, mais les développeurs en pointe l'ont déjà intégré dans leurs navigateurs.

Qu'elles sont pratiques ces colonnes ! Même primitives dans leur implémentation (nous n'avons pas encore le choix entre le style Dorique, Ionique ou Corinthienne), elles évitent de rendre la lecture essoufflante pour les muscles longitudinaux des globes oculaires, harassés par une suite de courses de fond 1500 pixels-haies, au point que le regard se perd dans des colonnes de une à deux lignes...

J'avais le choix entre un nombre fixe de colonnes, ou un nombre variable. J'ai opté pour cette dernière possibilité, avec une largeur minimale, arbitrairement 540 pixels. Pourquoi 540px ? Tout simplement parce que c'était le gabarit largeur de mes articles dans mon précédent design, et la plus grande largeur des images incluses dans le texte de mes billets (je ne compte pas les images lightboxées).
Étant donné que j'ai fixé la largeur de ma sidebar à 220 pixels, la largeur minimale de mon site (pour laquelle il se comporte à nouveau comme design élastique) est de 760 pixels[3]. Et la largeur minimale du viewport où apparaissent les colonnes, de 220 (sidebar)+540×2(colonnes)+10=1310 pixels.

Mais à quoi correspondent ces 10 pixels ? À l'espace inter-colonnes (en anglais : gap), actuellement vide, voire occupée par un trait vertical (en anglais : ruler) dans les navigateurs supportant cette fonction. Car il faut bien évidemment penser à séparer suffisamment les colonnes pour éviter que le texte ne se mélange. Or, et on sent que l'on est encore dans un brouillon de norme, tout le monde n'est pas encore exactement d'accord sur les comportement des règles entre colonnes.

Si elles sont fichtrement bien pratique, ces colonnes ne sont pas encore la panacée. Parmi les inconvénients, je note :

L'impossibilité de faire couvrir plusieurs colonnes par un élément flottant ;
L'impossibilité de limiter la taille verticale au viewport. Le lecteur doit remonter en haut de page après avoir atteint le bas de colonne ;
L'impossibilité d'aligner un texte verticalement par CSS. Le seul moyen existant actuellement est de recourir aux tableaux, urk...
Et les liquides étant incompressibles, le volume de texte reste constant, une très grande largeur réduit la longueur occupée, ce qui peut créer un vide en bas d'écran.

Je reste jaloux de ce que fait l'International Herald Tribune sur ses articles de plusieurs pages [4], mais étant donné qu'on est dans de la manipulation DOM par Javascript (Ouïlle !) et qu'en plus il faut prévoir les césures dans le HTML, on va s'en passer...

En attendant que ces propriétés soient enfin fixées, les navigateurs les ayant implémentées (Firefox version 1.5+ et Safari 3+) n'utilisent pas la syntaxe préconisée, mais préfixées par leur balisage “expérimental”[5] . Donc toute propriété column doit être répétée deux fois : par -moz-column et -webkit-column. Et comme personne ne semble avoir implémenté le page-break, seule méthode CSS pour indiquer qu'un élément ne supporte pas d'être étalé entre plusieurs pages/colonnes, on a droit à quelques erreurs, surtout visibles dans les listes de billets.
Va falloir que je fasse du lobbying auprès de Daniel Glazman à ce sujet, puisqu'il fait partie du comité d'étude...

En résumé, oui, les colonnes ça fait très prétentieux comme façade de votre site pavillonnaire, mais comme ça rend jaloux le voisin, moi je m'en prive pas.

Ces captures d'écrans n'auraient été possibles sans l'assistance technique de Vric et son fantastique écran 1600×1200. Ne reproduisez pas ces cascades chez vous si vous n'avez pas un écran 25”...

Pour les webmestres qui ne jurent que par les maîtres : un article d'A List Apart, qui étonnement site exactement les mêmes références.

Notes de bas de page :

NB 1 : Ouvrez votre tableur payant favori, faites de très larges colonnes, puis faites glisser l'ascenseur de défilement horizontal... À noter que le tableur d'OpenOffice dans sa version 2.0 a lui aussi adopté l'impossibilité de ne voir qu'une portion de colonne à gauche, rendant la navigation dans un grand tableur très pénible si votre écran fait une taille “raisonnable” pour des travaux de secrétariat.

NB 2 : La norme d'affichage VGA a été créée en 1987. La Haute Résolution professionnelle de l'époque y autorisait un affichage de 640 pixels de large (comme le CGA, l'Atari ST et l'Amiga) pour 480 de haut, offrant enfin au PC des pixels carrés. Certains sites limitent encore leur largeur pour être intégralement affiché dans ces 640px. La plupart sont passés aux 800px voire au 1024, courant le risque d'avoir une barre de défilement horizontale sur des écrans de 800 pixels de large. Soit tout de même 1% des web-surfeurs, frange nettement plus significative que ceux qui vont sur les sites WAP si coûteux à développer.

NB 3 : Soit la largeur d'un écran 800 par 600 pixels. Actuellement la plus petite taille significative dans mes stats de visite, mais surtout la résolution de mon écran de secours quand mon PC est squatté !

NB 4 : Cliquer sur un des articles de l'International Herald Tribune, puis dans la boite de présentation, cliquer sur mode «3-Column Format».

NB 5 : Notez que ces andouilles de Microsoft oublient de mettre un “-” en préfixe de leur balises CSS “expérimentalement” propriétaires, commençant illico par “mso-”. De toutes façons, on s'en fout, ils ont le CSS2 à apprendre avant de passer aux colonnes du CSS3.. Encore du Microsoft-bashing, c'est le troisième dans ce billet... J'avoue que c'est pas très sain, mais depuis six mois, j'en bave tellement avec Internet Explorer que je n'ai pas trop envie d'être tendre.
IE7 ne connaît pas les colonnes. IE8 ne sera probablement pas CSS 3-aware ; et étant donné le taux moyen de mise-à-jour des navigateurs Microsoft par leurs utilisateurs (comparé aux Maqueux et aux Firefoxistes), on aura très longtemps des MSIE aveugles aux colonnes.

Ooops ! I switched again...

Da Scritch — 2007-07-25T23:46:00+02:00

Et le serveur fut... déplacé !
Webdev

Ayé...

Deux années de recherches, de code, de bidouillage intensifs...
Deux années de quadracapillicutation intensif, de report de bugs (normes mals implémentées), de noms d'oiseaux échangés sur les fora spécialisés...

Aujourd'hui est un grand jour... de déménagement. Mon cœur a reçu sa première lettre chez ouam, mais c'est pas ça l'info principale de ce billet (eh... eeeuh ... si).

J'ai le plaisir de vous annoncer par la présente que dascritch.net, mon site personnel, vient de passer à sa 6ème incarnation.

Parmi les nouveautés visibles pour vous :

un design mieux contrasté
une mise en page liquide
la taille des écritures zoomable à souhait (avec la barre du haut)
des colonnes surgissantes (where available)
la page de l'émission Supplément Week-End
l'inclusion de mes anciens sites (ceux d'In-Digest et de Zérø)
une page d'erreur plus explicite
un moteur de recherche âchement mieux (Google n'a qu'à bien se tenir)
des éléments dynamiques (css, javascript, dom, touça...)
mes suggestions web du jour dans mon rss

Et pour moi :

du code encore mieux fait
des barrières antispam gratinées
un backend au top de la technologie moderne
un vrai outil de statistique
des années d'expériences qui feront toujours la différence...

Normalement, toutes les anciennes adresses (même le flux rss/podcast) ne bougent pas. N'empêche que les transitions de serveur furent très chaotiques ce soir (les visiteurs ont parfois droit à l'ancien design, mais avec le contenu neuf). Pour les amateurs de technique, surveillez bien la catégorie Webdev et le tag CSSR 07, j'expliquerais les points qui m'ont tourmenté ces deux dernières années. Ça remplira ce blog en attendant la rentrée littéraire et passionnera mes futurs employeurs. Bon, reste à enlever les échafaudages et à préparer le vernissage...

Vous pouvez laissez en commentaires vos remarques, indications de bugs, suggestions et autres applaudissements...

Ooouuuuuuuuuuuééééééééééé !!

Mercis doivent aller aux équipes Mozilla/(WebDevTB+Firebug), JQuery, MooTools, DcTeam(), Quanta...
Et à mes amis Xylpho, Vric, ZeuBeuBeu, Pep, ChampDePub, Sveetch, Zorel,...

... sans oublier l'Enflammée de mon cœur

La fête à la nationale

Da Scritch — 2007-07-17T16:46:00+00:00

J'aurais bien aimé écrire que je suis parti en vacances, mais même pas...
Ma vie est une sitcom

Le chantier qu'on devait faire avec un copain a pris du retard, ma mère a débarqué, mon pc se fait squatter, le pique-nique du 14 s'est fait mode Sarkozy (pas d'alcool), ma mère est repartie, je croule sous les retards sur mon nouveau site dascritch.net, et franchement, j'en suis un peu à péter les plombs sur des problèmes de... hem... je me demande si c'est vraiment utile que je vous le dise,... “manipulations javascript DOM peu codex en toolkits” (vous êtes bien avancés, là).

Donc pas eu émission Samedi, pas eu de billet depuis près d'une semaine, mais pas de panique, je suis bien resté chez moi à préférer un radieux bronzage à la chaude et douce lumière ~~de mon écran lcd~~ d'un tube cathodique par rapport aux rayons agressifs du soleil qui veut notre mort à tous (selon les derniers rapports, la couche d'ozone n'est pas encore correctement patchée).

J'en ai dépoussiéré mes pc [PS]...
Si ça continue comme ça, je vais finir par le faire, ce ciment...

[PS] : Pensez à le faire avant qu'il fasse vraiment chaud... C'est que ça supporte mal les canicules, nos pétoires.

Javascript comme un dialecte

Da Scritch — 2007-07-05T10:23:00+00:00

Où il est question de la différence fondamentale entre le Bescherelle nouvelle édition et la collection complète des petits Littrés des langues régionales.
Webdev

J'ai lu hier un article du blog de John Resig, « Javascript as a language ». J'étais en plein dans des soucis de code Javacript sur la nouvelle version de dascritch.net, justement...

Alors oui, Javascript 2 amène des nouveautés alléchantes, notamment sur les boucles itératives, ou encore le JIT (la compilation à la volée) qui va permettre d'accélérer les applications web... mais JS2 n'est implémenté que dans Firefox...3.
Seulement, dans son article, John Resig ne parle que des fonctions de base de Javascript, en occultant ce qui fait (à la louche) 60% de son usage actuel : La manipulation d'un arbre DOM d'un document HTML pour le rendre “dynamique”, comme les applications AJAX (exemple ultime : Gmail) ou les XML enrichi (Firefox, Thunderbird,... ont leur interface en XML/XUL qui est programmée en javascript). Et c'est là que le bât blesse : là, rien n'est standard.

En fait, il y a tellement d'interprétations différentes du Javascript d'un arbre DOM qu'aujourd'hui je peux certifier ceci : Le Javascript est une collection de dialectes comme le fut à son époque de Basic. Et Microsoft dans les deux cas n'avait pas arrangé la situation.

John Resig est très actif dans l'intégration de Javascript 2 dans Mozilla (Firefox) et l'auteur de la bibliothèque Jquery.js ; il a beau être une pointure dans le domaine mais son enthousiasme ne peut nier la réalité, coder du Javascript reste un immonde foutoir. Firefox est le navigateur qui a le meilleur support Javascript et DOM, mais il est vrai que quand on a le créateur dans ses rangs, on peut difficilement être en-deça.
Safari ne peut en dire autant (quoique les bétas de la version 3 semblent enfin prometteurs), et à priori en codant dans KHTML, on est à 85% compatible à coup de sueurs froides.
Mais pour mettre à rude épreuve vos nerfs, MSIE est le pire de tous.

Par exemple, soit dans votre HTML une <balise title="" />, que vous associez en javascript à votre variable balise . Si vous appelez balise.title, vous vous attendez bien sûr que les navigateurs web répondent logiquement une chaîne de caractère vide.
Pourtant, si vous mettez if (balise.title=='') , la conditionnelle sera fausse dans MSIE. Car cet abruti vous dira que balise.title=='null' ! Au lieu de renvoyer une chaîne vide, cet incapable crée une chaîne non-vide pour dire qu'elle est vide. Résultat : pour faire proprement votre test, il faudra ruser avec le support de MSIE d'une fonction proprio, par exemple document.all :
if ((balise.title=='')||((balise.title=='null')&&(document.all)))
Je ne veux pas persifler, mais on a quand même fait mieux comme langage de programmation pour tester si une chaine de caractère est vide.

Maintenant, supposons que vous voulez récupérer le texte dans <balise>texte <em>embarqué</em></balise> sans le balisage. Vous avez la possibilité de récupérer comme suit (cliquez pour tester) :texte embarqué

fonction suffixiale javascript	résultat escompté	navigateurs supportés
`balise.innerHTML`	"texte <em>embarqué</em>"	Compatible chez tout le monde, mais hélas, comporte les balises HTML embarquées
`balise.innerText`	"texte embarqué"	MSIE, Konqueror, Safari, mais pas Firefox
`balise.outerHTML`	"<balise>texte <em>embarqué</em></balise>"	Exclusivement MSIE, avec tout le balisage dont on veux pas
`balise.textContent`	"texte embarqué"	Uniquement Firefox, mais Safari 3 va enfin le comprendre

Donc si vous voulez faire un code “efficace” marchant “à coup sûr”, il va falloir utiliser innerHTML, mais avec une regexp (« mmmmhhh les expressions régulières... mmmhhhh » comme dirait De Funès). Une soupe à la grimace genre ça (je garanti pas que ça marche... ah ben si, cliquez) : balise.innerHTML.replace(/<[^<>]+>/g,"")

Vous croyez en avoir fini ? Reste à trouver les versions de MSIE... car les comportements changent entre 5.5, 6, 6SP2 et 7 !
Si un if (document.all) permet de démasquer MSIE et sa bande, le User Agent sniffing ne marche pas sur des faux navigateurs (comme Avant Browser, PhaseOut ou Maxthon, une bonne liste ici). Impossible d'être exactement sûr de la version du moteur MSIE utilisée sans un commentaire conditionnel, genre  niché dans le HTML, rendant illusoire l'idée de dissocier le code de la structure comme on a pu le faire avec le style.

Pire que tout, MSIE 7 dans ses toutes premières bétas montrait des comportements très différents dans le Javascript et les manips DOM. Vous développez votre site aux petits oignons, mixant PHP5, sHTML, CSS, règles Apache, xHTML, DOM et Javascript. Votre site se charge, les Javascripts de votre page sont quasi complètement interprétées... jusqu'à ce qu'une fenêtre d'alerte arrive : « Internet Explorer ne peut afficher le site http://... ». Cliquer dessus efface votre page et mène à une page d'erreur.

Coup de poignard dans le dos, ajoutant l'insulte à l'injure, cette page indique vaguement que MSIE n'arrive pas à contacter le site, ce qui est totalement faux. La réponse de la base d'information MS est risible.
Cette manie d'afficher un message bloquant (pour débugger) et mensonger (sur votre travail) a été backporté dans les MSIE6 SP2. super agréable.

Un des exemples de comportement changeant radicalement, MSIE considère désormais que le SEUL endroit où l'on peut insérer dynamique une librairie javascript c'est dans le <HEAD> de votre HTML. C'est à la fois logique, mais pas trop. Ce souci sans aucune documentation existante m'a empêché d'avancer pendant un an, surtout sans MS-Windows sous la main.

Et là, j'ai encore un autre problème avec exactement les mes symptômes. Je peux délayer mes problèmes de programmation dans Dotclear2, mais que mon site ne soit pas lisible par 70% du marché alors que je cherche un emploi, ça non. Strictement impossible. Cela m'a tellement gâché la journée que je me suis passé les nerfs en ré-installant l'interphone. Si ça continue, je vais faire du ciment d'ici ce soir.

Pour en revenir à John Resig, il a presque raison. Mais hélas, en l'absence de standard DOM parfaitement appliqué, tout comme le CSS2 et les extensions Microsoft, on est actuellement dans la même situation que le Basic du début des années 1980s : la grammaire est identique pour tous, mais les mots varient suivant les dialectes.
Et rien que pour ça, j'en viens à regretter quand je faisais des pages WAP1.1, c'est dire !

Regrets éternels HTML 2.0

Da Scritch — 2007-06-27T12:22:00+00:00

Les bonnes habitudes de code sont pour la vie.
Webdev

Il fut un temps où tous les navigateurs utilisaient par défaut la police Times. Je parle d'un temps que les moins de 20 ans ne peuvent pas connaître. Donc rituellement, toutes les pages voulant être plus lisibles, agréables et accueillantes commençaient invariablement leur <BODies par <FONT FACE="Helvetica,Arial">

Et là, vous me direz « Hou ! » dans une longue exclamation sonore. Ce à quoi je m'insurgerai en hurlant « Que celui qui n'a jamais pissé du code mal fagotté comme un camionneur bourré me jette son pot de chambre ». À cette heure, le seul qui peut me pisser dessus, c'est bien le petit Jésus.

Oui, j'avoue, j'ai pêché, mon code forniquait avec ces pratiques impies. Et heureusement que j'y mettais les guillemets... mais je fermais pas cette prime balise... Pourquoi fermer la <FONT> initiatrice ? À cette héroïque époque, vous fermiez les balises <P>, vous ?
Résultat, pour un site compilant tous mes travaux, il faut que je refiltre encore mes pages pour les supprimer : Internet Explorer, dans la logique de l'époque, applique le style à tout le monde.

Car à ce moment-là où les hommes étaient des hommes et les langages balisés s'écrivaient à la main avec des enluminures (le plaisir du RTF et du TeX artisanal), les canevas et mises-en-pages se faisaient de grandes <TABLE> où festoyaient <TR>s et <TD>s dans un gigantesque banquet partouzard, il fallait définir les fond par des BGCOLOR=, voire un BACKGROUND= pour les grandes occasions, chaque changement de couleur par un <FONT COLOR= ... On changeait le bord des images embarquées dans un lien par un BORDER= tout en définissant systématiquement leur WIDTH= et leur HEIGHT= ... nos débits minitéliques nous faisait même fractionner les images dans des tableaux. Voire même les pages avec des FRAMESET car à cette époque, point de PHP pour faciliter son boulot. Tout ce faisait au TextEditor, à la pogne, sans coloration syntaxique, sur un Amiga et fallait que le site tienne sur une disquette de 720Ko.

Et maintenant ? Je m'en repends de mes pêchés originels de larmes de crocodiles en travaillant comme un bénédictin. J'essaie d'adapter mes anciens sites du millénaire passé pour qu'ils soient intégrés dans le nouveau. Leur style inséré dans celui de la navigation de mon nouveau design... Plus d'une centaine de pages à ré-adapter, nettoyer, rebaliser, relinker en tous sens, à grands renforts d'expressions régulières, d'éditeur et d'un peu de conversion à la volée (mais pas trop, vaut mieux tout effectuer à l'avance). Et toujours reprendre son courage à deux mains, parce qu'ils faut encore reprendre tous les sources pour corriger une inconsistance. Qu'à l'époque était le principe même d'écriture pour le web. Pauvre pêcheurs que nous étions.

Tiens, un exemple d'inconsistance : On trouvait normal que nos sites fassent des liens dans des ancres de page commençant par <A NAME= ... mais ces ancres ne se terminaient jamais pas un </A> . Alors pour aller vite j'ai tenté de faire des balises autofermantes, genre <A NAME="lien" />... ben non, ça marche pas, c'est le chaos total. Les navigateurs placeront à leur guise un </A> fermant où ils veulent. Il a fallut remodifier encore chaque structure, en utilisant des dénominations plus modernes comme <P ID=...

Vous croyez que ces pratiques barbares d'un autre âge ont disparues ? Que nenni ! Un “entrepreneur” a usurpé le nom d'OpenWeb, célèbre groupe d'étude sur la conformance des sites web, tout en codant son “site web institutionnel” avec des tableaux comme des gorets et avec une navigation en flash... ben... j'hurle... de rire en avance en pensant au pauvre hère qui va devoir tout remettre ça d'équerre...
10 ans de retard sur la technologie...
Une très bonne preuve de savoir-faire en 2.0 ... HTML 2.0

Très chers lecteurs, en cliquant sur ce lien, tu pourras admirer ma préhistoire du web (on savait pas encore vraiment écrire en HTML, moi je faisais juste de la radio). Si tu es automatiquement redirigé sur dascritch.net, soit gentil... tente pas de faire valider la page, ça ne marchera pas.

</AMEN>

Question de commentaire

Da Scritch — 2006-04-27T22:09:00+00:00

Teasing ! Et désormais, mes commentaires ne se cachent plus.
Webdev

Vous l'avez remarqué si vous me lisez ailleurs que sur le site web lui-même, depuis (tôt) ce matin, les commentaires ne sont plus masqués par défaut. Fallait savoir qu'il faut cliquer pour afficher le formulaire. L'idée de base, c'était de cacher dynamiquement le superflu (j'en parlerais prochainement car la technique y est intéressante). Une fausse bonne idée, car ceux qui survolent mon site ne voient jamais ces fonctions. Donc finalement, je le retire.

En fait, c'est le fruit d'une longue et intéressante réflexion de Vric (très bon pote qui officie actuellement sur cuk.ch), sur comment les commentaires doivent être architecturés. Car pour ça, non seulement vaut mieux avoir un power-user qui a bien compris des notions de base d'ergonomie, mais si en plus il est architecte, là, on s'incline avec respect...

En fait, cela fait parti d'un très vaste mail sur l'ensemble de l'ergonomie du prochain design de son site perso. Paraît que l'actuel est un poil trop bleu ^o^, et puis le fait qu'il soit en largeur fixe, donc même pas d'un design élastique ni même liquide n'est pas agréable sur les très grands écrans... Mais bon, place à la voix du Maître, le mail est particulièrement long, et concerne des détails du futur design qu'il a vu mais que je ne veux pas dévoiler trop tôt. Néanmoins, ses remarques sur le formulaire de commentaire est particulièrement utile, et pas qu'à moi :

De : Vric

Si je n'avais pas vu la zone concernée affichée par défaut dans iCab, j'aurais cru à un bug de design au lieu de deviner qu'il faut cliquer sur “Ajouter un commentaire”, car ça ne ressemble pas à un bouton mais au titre de l'article, qui lui n'est pas un bouton.

Soit on affiche par défaut, soit on met un bouton. Mais un bouton doit ressembler à un bouton, ou se trouver au même endroit que d'autres contrôles similaires, ou se repérer au 1er coup d'œil.

Or le rapport avec le fonctionnement de la colonne de navigation n'est pas évident quand la fenêtre est large et que les triangles de “Ajouter un commentaire” se trouvent donc super loin, ou plus simplement qu'on n'a pas encore essayé la colonne de navigation.

D'ailleurs, quelle est la pertinence de donner à la saisie de commentaire un statut que le reste de la maquette dédie à la navigation?

Ou alors, faire pareil avec le reste : par cohérence, permettre de replier trackbacks et commentaires, voire aussi l'article.

Ce qui dévoile le vrai problème: replier pourrait éventuellement, peut-être, va savoir, plaire à quelques geeks, mais ça augmente surtout le risque que d'autres ratent des trucs sans le savoir.

Donc la zone de saisie de commentaire :
soit on la voit par défaut (et on ne la masque que si on a compris qu'on pouvait),
soit le bouton qui la montre est évident,
soit TOUT est repliable, y compris le titre du blog et autres machins statiques, ce qui ne serait pas une si mauvaise idée sur un blog de geek.

Mais alors j'irais plus loin : si on laisse le lecteur choisir ce qu'il voit, alors on doit aussi optimiser vraiment la surface verticale pour ce qu'il veut voir, et donc virer tout ce qui est statique hors de la zone de lecture, soit en le repliant, soit ici vers la colonne statique :

les parties à lire, éventuellement repliables, sur toute la hauteur de la fenêtre (article, commentaires, trackbacks)
tout les trucs statiques, éventuellement repliables, dans la colonne de nav (titre du blog, nav, logo, options, copyright, etc.)
hybridations possibles: si tu veux garder la maquette avec des parties statiques haute et basse (ce qui me fait chier mais tout le monde le fait donc tu as bien le droit), leur repliage devrait se faire horizontalement vers la zone statique, ce qui est bêtement compliqué mais pas hors sujet sur ce site.

[...]

La disposition des champs de la zone commentaire est faible comme toujours. J'ai décrit il y a longtemps à Xylpho des dispositions à la fois plus intuitives et beaucoup plus optimales que ce que tout le monde fait.

Mais sympas les coins arrondis dans moz et le fond selon focus (tiens, encore une limitation d'iCab).

[...]

Remarques sur la zone “Ajouter un commentaire” :

Les 2-points aux noms des champs seraient superflus si la disposition était logique.

Le titre du champ commentaire est superflu si on le place mieux.

Le petit champ de commentaire est chiant sans Omniweb (note pour Xavier : Omniweb permet d'ouvrir tout champ de saisie comme fenêtre à taille et police libres, justement parce que la plupart des sites font chier).

Or les autres éléments gâchent plein de place verticale. Donc mettre le champ de commentaire à côté des autres éléments sur toute leur hauteur et l'élastiquer en largeur.

Mettre l'avertissement « Le code HTML dans le commentaire » en tout petit et/ou en gris pour éviter qu'on le lise plus d'une fois (réduire visiblité et lisibilité ; si on se demande on fait l'effort de lire, si on sait déjà on n'est pas agressé à chaque fois par du texte inutile).

--- plus intuitif et confortable (sens de lecture et position des boutons) --- (plus besoin d'aucun 2-points, idéal et optimal, je vais mettre un copyright dessus)

J'ai d'autres idées de fignolage, mais elles relèvent de l'implémentation, alors je vais pas faire cadeau de tout, hein ;-)

Pas de panique, Vric, j'ai pris de très bonnes notes, et après quelques tests, oui, ça marche laaaaargement.

Ah oui, je suis noyé de (tentative) de spams toutes les 10 secondes. Soit je bannis certains mots ou séquences qui pourraient être utilisés en commentaire de manière légitime, soit je coupe les trackbacks. J'ai choisi la dernière option, trop peu utilisée.

da scritch net works - Mot-clé - cssr07

CSS reboot 2013

Gloire à l'équipe Dotclear

Mes petits travaux de finitions

Y'a eu des pertes

Les sites des codeurs sont les plus mals codés

Ouch, les textes ont disparus !

Ça… on jette… ça… on jette…

Bookmark-moi cette page !

On était en 1997.

Fingers in the multiprise

Goodbye and thank you for all the fish

Pardonnons à ce Flash qui nous agace tant

Pourquoi l'extension Flashblock est si populaire

Balises et balisons : La guéguerre entre Embed et Object

<Applet>us dinosaurus et <Iframe>us archeis ne sont pas dans un bateau...

La question Eolas

La réponse Javascript, pourquoi pue-t-elle plus que le Flash

Être propre dans le HTML, élégant dans sa structure

Les coulisses du site en Septembre

Objectif débile du mois

Making of de Septembre

Les soupirs de soulagement

Spammeurs Français du mois

Javascript, l'accent d'la regex

Où le Javascript, c'est comme une Tour de Babel...

Transition PHP ? Prépare-toi à des nervousses breakdownes

Pour en revenir avec la sale bête

Une horreur de slash

Dans les tréfonds du classement

Tassons les Javascripts

Réfléchir à réduire...

Purger les caractères inutiles.

Nom d'une lettre !

Jusqu'à quel point peut-on “compresser” un Javascript ?

Conclusion

Pas de livraison du Supplément Week-End aujourd'hui

Pour quelques Javascripts de plus

Au début des Temps, le Javascript et le HTML étaient mélangés

Et le Verbe fut <script src​="...

<script src​=" juste à la Fin du HTML

Prenez mon body et onloadez-le

Un <script src​="" /> unique, avec le tentateur document.write();

Un seul src= et sur ce script je construirais mon DOM

Sortir le script des balises

Et voici les colonnes !

Ooops ! I switched again...

La fête à la nationale

Javascript comme un dialecte

Regrets éternels HTML 2.0

Question de commentaire

Et le Verbe fut `<script src="`...

`<script src="` juste à la Fin du HTML

Prenez mon `body` et `onload`ez-le

Un `<script src="" />` unique, avec le tentateur `document.write();`

Un seul `src=` et sur ce script je construirais mon DOM