Hanblog

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

jeudi, août 12 2010

Désactiver snap.com

Encore une fois, cette société qui pullule et pollue internet m'a bien enquiquiné [1] ! Je ne vois vraiment pas à quoi sert le service, si ce n'est cacher le contenu que j'essaye de lire. Du coup, je le désactive. "Heureusement", la société permet de désactiver le service en plaçant un cookie sur votre ordinateur. Bon c'est bien mais pas top. Parce qu'un cookie ça ne vit pas ad vitam eternam, parce qu'un cookie ça ne vit que dans un seul navigateur (et j'en utilise plusieurs). Du coup, coupons l'herbe sous le pied de ce fléau.

Pour se faire, il faut ouvrir /etc/hosts et rajouter :

127.0.0.1 spa.snap.com

Ainsi, plus de problème, quel que soit le navigateur. Et le bonus, c'est que vous ne téléchargerez plus le JavaScript inutile. Yatoubon !

Notes

[1] pour rester poli, et j'ai du mal

lundi, juillet 19 2010

Résumé des épisodes précédents

Nouveau job

Début février, j'avais quitté Skyrock après 3 ans (depuis mon dernier stage). Le but était de trouver un poste à l'étranger pour découvrir une autre culture et avoir un emploi qui correspondait mieux à ce que j'avais envie de faire. Après quelques tentatives diverses, j'atterris finalement mi-juin chez Mozilla, en tant qu'évangéliste Web [1]. Le but est de promouvoir les nouveautés de Firefox 4, Firefox Mobile et des standards en général auprès des développeurs. Mais aussi, d'écouter les besoins des développeurs, ce qui marche bien, moins bien, ce qui manque et ainsi de suite afin d'améliorer Firefox et la plateforme Web.

Je suis très heureux de ce nouveau poste. En plus de travailler pour un mouvement que je trouve très responsable et de promouvoir ses produits, je peux promouvoir le web en entier. Bosser pour sa passion, dans un environnement qui correspond à ses valeurs personnelles, c'est plutôt cool je trouve. Le seul petit point noir, c'est que je reste basé à Paris pour le moment. Je ne peux donc pas cocher la case "vivre à l'étranger" sur mon tableau buts personnels. Mais comme je serais amené à voyager, c'est pas si mal.

Et puis évidemment, merci à Paul et Tristan pour la confiance.

MAOW, Drumbeat, WebWorkersCamp

En parlant de voyage, ça a commencé à Londres fin juin pour un MAOW. Le lendemain, c'était Drumbeat à la Cantine. Et le samedi, WebWorkersCamp à la Cantine aussi où j'ai pu faire ma première présentation et en anglais du coup.

Ayant appris la veille l’existence de cet évènement, je n'avais pas vraiment de présentation de prête. Heureusement, je travaille actuellement sur les WebSockets donc j'avais quelques choses à montrer. On a parlé de stockage côté client (localStorage, sessionStorage, mentionné IndexedDB), des évolutions de l'History API, de AppCache, de File API, des Forms HTML5.

Performance Web

Et pour la suite, je serais mercredi soir à la soirée performance organisée par Éric Daspet, le plus vocal des avocats des performances front-end en France. L'invité principal sera Stoyan Stefanov, travaillant pour Yahoo!, mainteneur entre autre de Yslow qui est une référence dans le domaine. À ne pas louper donc. Si vous n'êtes pas encore inscrit, dommage, c'est plein.

J'y parlerais de ce que font les navigateurs pour améliorer les performances. On évoquera rapidement les changements dans Firefox puis on s'attardera sur les nouveautés des standards.


PS : Je ne sais pas encore ce que je vais faire, mais il se peut que ce blog utilise un peu plus d'anglais, pour le travail. On verra.

Notes

[1] si vous avez une meilleure dénomination, ça m'intéresse, je trouve celle là dure à expliquer et connotée religieusement

vendredi, juillet 2 2010

Compte-rendu de @media 2010

Il y a déjà 3 semaines (comme ça passe vite), je me rendais à Londres pour @media. Plutôt que d'essayer de faire un résumé objectif, je vais donner mes impressions. Pour quelque chose de plus conséquent (parce qu'il a pris des notes pendant), allez voir chez Jérémie.

Brendan Eich - Grown-up JavaScript

L'inventeur de JavaScript, pour commencer, la grosse classe ! Il a résumé l'avancement actuel de ECMAScript, ce qui va bientôt arriver, ce qui est un peu plus éloigné et encore plus loin, le début de certaines discussions. Et pour conclure, quelques prédictions plus ou moins hasardeuses (de son propre aveu). Par exemple, Apple et Google vont forker WebKit.

Doug Scheppers - SVG today and tomorrow

Sans hésitation, la meilleure présentation des deux jours. Doug travaille au W3C et, comme je lui ai dit, c'est la première fois que je vois une présentation marrante (et donc accrocheuse) d'un membre du W3C (désolé Karl, Dominique et autres). Au final, ce n'était qu'une présentation de l'état de l'art mais le rythme, le sujet méconnu (à tort), et la sympathie qui transpire donne envie de faire du SVG partout.

John Resig - Testing mobile web apps

Le titre de la conférence est trompeur. Au final, il a beaucoup parlé des navigateurs que l'on devrait tester, à la manière des A-grade browser de Yahoo. Et à la fin, on parle un peu de ce que jQuery supportera côté mobile. J'ai été très déçu car je comptais apprendre des choses sur comment tester en général des web apps, plus particulièrement des mobile apps. À part mentionner brièvement TestSwarm, le sujet n'a pas du tout été abordé. Donc au final, c'était une présentation de graphiques, stats sur les parts de marché des navigateurs, une énumération des navigateurs et leurs capacités. Pas grand chose à en retirer.

Simon Willison - Building crowdsourcing applications

Avertissement : je suis ultra fan de ce touche-à-tout. Ayant travaillé pendant 3 ans sur un réseau social, cette présentation me parle beaucoup. Plutôt que d'aborder les problèmes techniques (scalabilité, disponibilité, etc.), il aborde les problématiques sociales, ergonomiques des services communautaires. À travers les exemples du Guardian et de projets persos, il donne des conseils pour réussir à faire participer les gens au maximum. Réduire au maximum les étapes avant pouvoir participer (0 étapes étant l'idéal), comprendre les mécanismes des jeux pour entretenir l'envie de participer, donner des récompenses, travailler énormément pour réduire la sensation de "et maintenant je fais quoi ?", etc. Beaucoup de choses à apprendre.

Mark Boulton - Designing grid systems

La grosse déception du premier jour. Il a passé beaucoup trop de temps à expliquer les mécanismes du cerveau, comment l'être humain réfléchit, comment il a résolu certains problèmes, etc. Au final, seulement 15 minutes sur les grilles. Évidemment, Il est important de donner du contexte à ce que l'on présente, mais pas trop. Au final, pas grand chose à ramener chez soi pour appliquer.

Jeremy Keith's hot topics

La pire table ronde jamais vue… 25 minutes de branlette (désolé pour le terme) sur qu'est-ce qu'un designer, un UX designer, un visual designer, j'en passe et des meilleures. On s'en cogne… Ensuite, "qu'est-ce que HTML5". Oui le marketing ne l'utilise pas comme les techniciens, mais franchement, on s'en cogne. Dernier sujet : les APIs. À peut-être un truc intéressant, et non ! On tombe sur des questions du genre "oh mais y a plein d'API différentes, comment je travaille avec ?", "XML est tellement bien, pourquoi y a plus rien en XML ?". Il y a tellement d'outils pour passer outre cela qu'on manque les questions intéressantes. En voyant cette table ronde et celles de Paris-Web, des fois je me demande si c'est vraiment utile.

Andy Clarke - Hardboiled web design

Très partagé sur cette présentation. J'aime l'idée générale d'oublier les plus vieux navigateurs et allez de l'avant. Mais il ne faut pas non plus faire n'importe quoi avec cette idée. Rajouter des petites touches subtiles (ombres, dégradés, bords arrondis) pas de souci, utiliser de nouvelles techniques et utiliser JavaScript pour combler sur les anciens navigateurs pas de souci, mais donner un look totalement différent selon le navigateur, non ! Son argument est qu'un utilisateur ne verra votre site qu'avec un seul navigateur donc ça ne le dérangera pas. J'objecte fortement. Nous utilisons de plus en plus d'ordinateurs. Il est très fréquent d'avoir, par exemple, un Mac avec Safari à la maison et un IE au travail, ou encore d'utiliser un site en vacances chez des amis. Sur mobile, l'utilisateur s'attend à une autre expérience donc on peut changer de design mais d'un ordinateur à un autre, non.

En plus du contenu de la présentation, j'ai une grosse aversion pour le personnage. Il a passé les deux jours en jean t-shirt mais est venu sur scène avec un costume. La présentation est remplie d'assertions fortes sans justifications. En gros, j'ai senti une grosse différence entre le style anglo-saxon — très confiant, sûr de ses idées, aisance à l'oral — et le style français — présente une idée, souhaite des retours, l'oral est un travail constant.

Matt Biddulph - Mobile social location

Un tour assez complet des interactions qu'apportent les mobiles, ces objets à la frontière du monde réel et virtuel. Ils connaissent beaucoup de choses sur le réel via des capteurs (emplacement, direction, son) qu'ils peuvent communiquer au très puissant virtuel et vice-versa. En tant qu'évangéliste Nokia, il souhaite évidemment que les développeurs trouvent des idées autour de cette liasion particulière. Ça rejoint la notion de "Very personal devices" de Jean-Louis Gassée

Pat Lauke pour Bruce Lawson - HTML5

Cette présentation devait être faite par Bruce mais ayant une extinction de voix, son collègue Pat Lauke s'en est chargé. Au passage, Bruce publie un livre via "Voices that matter", quelle ironie ;) Un tour d'horizon de HTML5, son histoire, ce qu'il apporte niveau compatibilité, niveau nouveaux éléments. J'ai du mal à résumer cette session vu que je connais bien le sujet. Mais je suppose que pour ceux qui souhaitaient apprendre, ce fut une bonne session, informative et fun.

Relly Annett-Baker - All the small things

Une conférence sur les formulations à utiliser et ne surtout pas oublier sur un site. Comment rassurer son utilisateur, ne pas le laisser dans le vide, toujours lui proposer un moyen de résoudre le problème qu'on rencontre. Même si je trouve le sujet important et les conseils donnés plutôt bon, il y a eu beaucoup de répétitions, d'exemples similaires. Dommage, mais c'était compensé par la pêche de Relly.

Steve Souders - Even faster web sites

Comme je connais assez bien le sujet, je n'ai finalement pas appris grand chose. Mais j'ai énormément apprécié la gentillesse et la disponibilité de Steve Souders. Bien qu'il soit l'orateur le plus connu de la discipline, il sait se mettre à niveau et répondre aux questions des débutants comme des confirmés.

Scott Berkun - The myths of innovation

Une dernière conférence très inspirée et inspirante. Pas de code, pas vraiment lié au web mais hautement intéressante. Comment réussir à innover ? Pas juste avoir une idée, parce que c'est la partie simple mais plutôt réussir à la réaliser et arriver à un produit fini. Quelques conseils sur la constitution d'une équipe pour la mettre dans les meilleures conditions, d'autres conseils pour que chacun soit innovant.

vendredi, janvier 15 2010

WebForms HTML5 et iPhone

Mark Pilgrim, génial auteur, vient juste de publier son chapitre sur les nouveautés qu'apporte HTML5 pour les formulaires. Évidemment, c'est une lecture indispensable. Je mettrais un petit bémol sur tout l'aspect validation de formulaires qu'il n'aborde pas et qui est pourtant une grande amélioration.

Un des intérêts immédiat est l'adaptation de l'iPhone aux nouveaux types de champs. Pour avoir un exemple plus concret, j'ai préparé un petit exemple et quelques captures d'écran. Apple propose aussi une documentation de ces changements de clavier.

Placeholder

<input type="text" placeholder="webforms roxor">
Une aide s'affiche lorsqu'aucun texte n'a été entré et disparait automatiquement.

Téléphone

<input type="tel">
Le clavier s'adapte à la saisie d'un numéro de téléphone. Il est dommage qu'un accès au répertoire ne soit pas proposé. Espérons dans une prochaine version.

Url

<input type="url">
Le clavier s'adapte à la saisie d'une URL. Un accès aux favoris aurait pu être intéressant.

Email

<input type="email">
Le clavier s'adapte à la saisie d'un email. Un accès au répertoire aurait aussi pu être intéressant.

Nombre

<input type="number">
Le clavier s'adapte à la saisie d'un nombre.

Nombre entier

<input type="text" pattern="[0-9]*">
Le clavier s'adapte à la saisie d'un nombre entier. Vous remarquerez la différence avec la saisie d'un nombre plus général. Par contre, on ne peut pas écrire <input type="number" pattern="[0-9]*"> car l'attribut pattern n'est pas disponible sur un champ number.

Utiliser ces quelques nouveaux types ne coute rien puisque les navigateurs ne comprenant pas les nouveaux types afficheront un simple champ texte. Mais quel bénéfice pour les utilisateurs de périphériques adaptés. Opera implémente une précédente version des Webforms et comprend donc une partie de ces champs. Je n'ai jamais vu comment Opera traitait ces champs sur un mobile par contre.

Connaissez-vous d'autres navigateurs ou périphériques comprenant déjà ces nouveautés ?

mercredi, décembre 23 2009

Abandonnons IE6, si possible

Ce sont les fêtes de fin d'année, une bonne période pour prendre du recul sur les choses. Par exemple, le fameux "j'en ai marre de IE6, ça me pourrit la vie". On va donc voir pourquoi on peut déjà l'abandonner, ce qu'on y gagne techniquement et peut-être financièrement.

Pourquoi c'est possible ?

La réflexion a commencé la semaine dernière sur Twitter (enfin sur Identi.ca). Ma réponse à ce cri de détresse était de faire un simple calcul que chaque société devrait faire :

Si l'argent que vous rapporte les utilisateurs de IE6 est inférieur à l'argent que vous investissez pour les avoir, alors oubliez IE6 et vous pourrez passer plus de temps à avoir un site plus agréable pour les autres utilisateurs.

Votre chiffre d'affaires sera inférieur, puisque vous perdez des clients (et encore, pas sur). Mais votre bénéfice augmentera. Bon, je ne vais pas vous expliquer comment calculer la rentabilité de votre entreprise, je n'en suis pas capable mais vous voyez l'idée.

Évidemment, je ne demande pas à tout le monde d'abandonner IE6 [1] , seulement si cela vous avantage. Mais réfléchissez, prenons un exemple vague : 20% du temps d'intégration consacré à IE6, 10% de visiteurs sous IE6 qui ne sont pas ceux ayant le meilleur taux de transformation en plus. Est-ce que ça ne vaudrait pas le coup de se passer de tout ça ?

Si vous décidez de passer le cap, n'expulsez pas les utilisateurs sous IE6. Les deux options à envisager sont :

  • Proposer une CSS très simplifiée pour IE6 afin d'avoir un style global portant vos couleurs, mais pas plus.
  • Fournir le même code mais en prévenant que vous n'avez pas tester et que ça peut péter à tout moment.

Et en complément, proposez d'autres navigateurs pour leur permettre d'avoir une expérience correcte.

Techniquement, qu'est-ce qu'on y gagne ?

Transparence alpha sur les PNG

IE6 ne supporte pas la transparence alpha sur les PNG. Il affiche un fond gris immonde pour les PNG24 ou considère tous les pixels avec un canal alpha comme transparents pour les PNG8. On a donc recours aux horribles filtres IE, immaintenables et lourds en performance. Et encore, ils ne sont utilisables que pour des backgrounds.

À partir de IE7, plus de problèmes, on utilise les PNG que l'on veut, où on veut, roulez jeunesse ! Et cette transparence est très utile pour des ombres, des dégradés, s'adapter à vos différentes couleurs, etc.

Une palette étendue de sélecteurs

Avec ces sélecteurs étendus, on évite beaucoup de trifouillages de HTML. Par exemple, plus besoin de classes spéciales pour sélectionner input[type=submit] ou html[dir=rtl] grâce aux sélecteurs d'attributs. Vous pouvez aussi cibler le premier enfant avec :first-child.

Plus de contrôle aussi grâce au sélecteur adjacent (h1+p) ou au sélecteur enfant (body>div). Pour illustrer une image avec légende, vous pourrez utiliser des sélecteurs simples tels .legend > img et .legend > img + p.

Et mon préféré, les classes multiples. Pouvoir identifier un élément grâce à .menu.active est très pratique. Pas besoin d'ajouter un élément englobant pour contourner cette absence de IE6.

Position fixe et background fixe

Peu de sites s'en servent mais ça peut-être bien utile. Pour avoir une interface toujours sous l'œil de l'utilisateur par exemple. Ou encore avoir une entête de liste toujours visible. C'est une possibilité de design sous utilisée, donc à vos claviers.

:hover partout

Avec IE6, :hover ne fonctionnait que sur les balises <a>. L'avoir sur tous les éléments vous permet de mettre en avant des parties de votre interface au fur et à mesure.

min- max-width et min- max-height

Des design un peu plus souples grâce à cela. Je me rappelle en avoir souvent eu besoin pour dimensionner correctement des images uploadées par les utilisateurs.

De meilleures performances

Vous êtes assurés d'avoir des visiteurs avec un navigateur plus performant. Du coup, vous pouvez utiliser des techniques plus lourdes sans que ça pose problème. Par exemple, IE7 ne passe plus par un ActiveX pour faire des XHR/Ajax.

Moins de bugs !

C'est certainement une des parties les plus intéressantes. Moins de temps à se prendre la tête, moins de temps en QA, moins de machines pour tester.

Avec cela, vous pouvez apporter un site de meilleure qualité, plus léger pour vos visiteurs, plus léger pour votre bande passante et beaucoup plus facile à faire évoluer pour vos développeurs.

Et en plus, on peut gagner plus !

Si vous abandonnez IE6, je vous conseille de communiquer sur cet abandon. Pourquoi ? Je suis persuadé que les technophiles tombant sur votre communication anti-IE6 la relaieront. Il y a une telle haine de IE6 chez les gens passionnés d'Internet que vous en ferez peut-être des clients ou alors juste des relais d'informations. En tout cas, c'est la communication la moins chère du monde, puisqu'en développant moins de code, vous augmenterez votre visibilité.

Le mot final : envisagez sérieusement de ne plus développer pour IE6 en vous appuyant sur des chiffres. Si votre contexte vous permet l'abandon de IE6, vous rendrez service à vous même, vos pairs et vos utilisateurs.

Notes

[1] même si ce serait sacrément le pied

mardi, novembre 3 2009

La semaine de WebKit - #10

Semaine du 25 au 7 juin (avant r44490). Pour tester ces nouveautés, vous aurez besoin d'une nightly WebKit.

Border-radius plus intelligent (44235)

Vous connaissez tous border-radius évidemment. Et vous adorez cette superbe propriété ? Avant ce changement, lorsque les rayons définis dépassaient certaines longueurs (par exemple la moitié de la largeur), le rayon était remis à zéro et il n'y avait pas de bord arrondi. Depuis, WebKit suit les règles de la spec et réduira le rayon si nécessaire.

Multiples adaptations aux specs (44293, 44298, 44301, 44302, 44360, 44475, 44481)

De nombreux événements n'étaient pas transmis à l'objet window, contrairement à ce que disent les specs. Hop, corrigé. De plus, les évènements storage doivent avoir un attribut storageArea retournant la zone de stockage qui a été modifiée. Corrections anodines mais utiles.

Bloquer le défilement lors du chargement d'une page avec ancre

Entre le moment où une page commence à s'afficher et celui où elle est complètement chargée, de nombreuses ressources peuvent modifier le rendu de cette page. Du coup, la position de l'ancre au moment où le navigateur s'est aligné a changé. Avant ce changement, le navigateur restait à la position où il était descendu la première fois. Là, s'il n'y a pas eu de défilement de l'utilisateur, l'ancre restera visible.

Activation des panneaux du Web Inspector

Les panneaux Resources, Network et Profiles bénéficient tous d'un panneau d'activation. Ce panneau d'activation permet de ne l'activer que pour cette session ou définitivement. Cela permet de ne pas ralentir les performances lorsque l'on n'a pas besoin de ces panneaux.


Voilà pour cette semaine. Évidemment, ce n'est qu'une sélection que j'ai faite. Si vous avez remarqué d'autres changements intéressants, n'hésitez pas à les mentionner. Idem si je me suis trompé dans une explication.

jeudi, octobre 22 2009

MUSIQUE POUR CAPS LOCK DAY

TRÈS BONNE IDÉE D'UN COLLÈGUE EN CE JOUR DE CAPS LOCK DAY. DES GROUPES DÉDIÉS À CE JOUR. LISTE NON EXHAUSTIVE.

  • AC/DC
  • REM
  • U2
  • IAM
  • M
  • NTM
  • TTC
  • N.E.R.D.
  • INXS

AVEC LA COLLABORATION DES FOUS DE #OPENWEB

jeudi, juillet 30 2009

Résumé du W3cafe

Il y a deux semaine, je présentais avec Aurélien Lévy.

Voici le résumé des points abordés pour ma partie avec quelques liens externes et de bonnes ressources. En gros, c'était mon bloc notes pour me rappeler toutes les nouveautés.

HTML5

  • Philosophie Design principles
  • Définition du parser, des nécessités user agent VS auteurs
  • Nouveaux éléments
    • doctype et charset : faciles à retenir
    • nav, header, footer, section, aside, article : pour mieux structurer le contenu
    • video, audio, canvas : pour rajouter des contenus dynamiques
    • web forms (url, mail, date, range, search, color), required, placeholder, autofocus : plus de contrôle sur les formulaires
  • Nouvelles API
    • localStorage, sessionStorage, sql storage : stockage côté client façon clef => valeur ou SQL
    • app cache (manifest) : permet de stocker l'appli offline, couplé au stockage permet de faire du offline complet
    • getElementsByClassName : une nouvelle collection pour traverser facilement le DOM
    • Drag & Drop : bah euh, glisser déposer quoi :)
    • postMessage : permet de communiquer entre deux applis tournant sur des domaines différents, permettant ainsi des "mashups" plus sécurisés.
  • Presque lié à HTML5 mais dans d'autres specs
    • XHR cross domain : permet de faire des requêtes Ajax sur d'autres domaines sans passer par un proxy côté serveur
    • Selectors API : permet de sélectionner des éléments à partir d'un sélecteur, comme le font les librairies JavaScript
    • Geolocation API : donne accès à la position géographique
    • Web Workers : lancer du JavaScript dans un autre thread pour faire des traitements lourds qui ne bloque pas l'interface
    • Ecmascript 5 (pdf) (JSON.parse) : plein de nouveautés mais surtout un moyen de parser du JSON nativement et en toute sécurité.
  • Ce qui Marche dans IE8
    • JSON.parse
    • Drag & Drop vu que la spec s'est inspirée de ce que IE avait déjà implémenté depuis IE5
    • localStorage, sessionStorage
    • postMessage
    • XDR, c'est XHR cross domain mais avec un objet nommé autrement (mais la même API)
    • Selectors API mais qui ne fonctionne qu'avec les sélecteurs CSS connus par IE8 évidemment.

CSS3

  • Petit rappel : CSS 2 n'est pas encore totalement exploité (display: table, inline-block, @font-face, text-shadow, sélecteurs, generated content) ni une spec finale
  • CSS 3 est découpé par modules qui sont plus ou moins finalisés et implémentés.
  • Candidate Recommandation
    • Media queries : écrire des règles qui ne sont exécutées que si l'appareil/navigateur a certaines propriétés (couleurs, taille, ratio, etc)
    • Marquee : oui oui, le défilement comme <marquee>, très utilisé dans les pays asiatiques visiblement.
    • Basic UI : indique de nouveaux pseudo-sélecteurs et propriétés pour enrichir l'interface utilisateur (::valid, ::required, etc)
  • Last Call
  • Working draft utilisables
    • Background et border Rajoute beaucoup de possibilités : bords arrondis, bordures avec images, plusieurs arrière plans, ombre
    • Couleurs : Transparence partielle avec RGBA, d'autres espaces de couleurs avec HSL et HSLA, opacity pour la transparence
  • Working draft en cours de rédaction
    • Template layout nouveau moyen de faire des layout avec une syntaxe orientée "ASCII art" : display: "aaaaa" "bccdd"
    • Grid positionning nouveau moyen de faire des layout basés sur une construction via des grilles, proche de l'impression papier
    • Transforms 2D/3D permet de modifier l'aspect d'un élément en le tournant, tordant, déplaçant dans un espace 2D ou 3D.
    • Transitions permet de passer d'un état à l'autre d'une propriété avec une transition plutôt que brutalement
    • Animations permet de définir des animations à effectuer.

Ressources externes

  • CSS3 info : beaucoup d'exemples de fonctionnalités très simples
  • Hacks Mozilla : des exemples plus avancés et concrets d'utilisations de CSS et HTML5
  • HTML5 doctor : articles et tutoriaux sur HTML5, les techniques, l'état de l'art, etc.

mardi, juillet 21 2009

La semaine de WebKit - #9

Semaine du 11 au 24 mai (avant r44117). Pour tester ces nouveautés, vous aurez besoin d'une nightly WebKit.

Support de nouveaux champs (43267)

4 nouveaux champs <input> sont désormais supportés : url, mail, number et tel (voir la spec HTML5). Pas de nouvelle fonctionnalité associée (comme une complétion avec le carnet d'adresses, les favoris, etc), juste un support simple. Mais on peut supposer que cela arrivera dans un second temps.

Rôle ARIA : grid(43669)

Bien que Safari 4 soit sorti avec un support élémentaire de WAI-ARIA, le travail n'est pas fini. De nouveaux rôles sont encore ajoutés.

Orientation et ratio disponible en CSS (43739)

Les media queries en CSS permettent d'avoir un contrôle plus fin sur vos CSS en se basant sur les propriétés de l'appareil qui fait le rendu. WebKit supporte déjà une partie des queries. Ce changement rajoute le support de l'orientation (portrait ou paysage) et du ratio (exact, minimal ou maximal) de la vue.

Support de displayName dans le débugueur (43774)

Les fonctions anonymes sont monnaie courante en JavaScript. Elles sont très pratiques pour le développement mais beaucoup moins lorsqu'il faut trouver à quel endroit il y a un problème. Du coup, Francisco Tolmasky de 280North a eu l'idée d'ajouter la propriété function.displayName. Ainsi, on peut choisir le nom qu'affichera le débugueur pour une fonction. Auparavant, il avait effectué un changement équivalent pour le profileur. Je vous conseille de lire l'article où il rentre dans les détails.


Voilà pour cette semaine. Évidemment, ce n'est qu'une sélection que j'ai faite. Si vous avez remarqué d'autres changements intéressants, n'hésitez pas à les mentionner. Idem si je me suis trompé dans une explication.

mercredi, juillet 8 2009

W3café de juillet, troll assuré ?

Petit relai pour le W3café du 17 juillet au soir. Détails et inscriptions.

Je m'occuperais plus des parties HTML5 et CSS3, n'étant pas du tout compétent sur WCAG2. Si vous avez des questions en avance, n'hésitez pas en commentaire, ça me permettra de réviser mes fiches avant l'oral la semaine prochaine.

jeudi, avril 23 2009

La semaine de WebKit - #8

Après une interruption de 4 mois, je vais essayer de reprendre mes petites nouvelles. J'ai changé d'organisation pour essayer d'être plus régulier.

Changements de la semaine

Tout ce qui est mentionné ci-dessous doit normalement fonctionner dans la dernière nightly disponible (42662).

6 connections parallèles (42457, 42559)

Avec ce changement, WebKit passe de 4 à 6 connections parallèles par domaine. Le nombre de connections par domaine est important pour télécharger au plus vite les ressources des pages web. WebKit s'aligne donc sur les dernières versions de IE, Firefox et Chrome. Opera utilise 8 connections par domaine. Il faudra juste attendre une prochaine version de la librairie CFNetwork pour voir le changement effectif dans Safari.

function.displayName (42478)

JavaScript permet de créer des fonctions anonymes. Elles sont très pratiques mais la contrepartie, c'est qu'elles sont aussi anonymes dans le profiler, ce qui rend difficile l'interprétation des résultats. Grâce à ce changement, on peut désormais donner un nom aux fonctions et il sera utilisé dans le profiler.

Yarr! (42481)

Yarr! (Yet Another Regex Runtime) est un nouveau moteur de RegExp. Il est désactivé par défaut pour l'instant mais semble plus rapide que l'ancien (encore heureux) mais pas encore suffisamment. Il est d'ailleurs encore incomplet. Des nouvelles lorsqu'il sera plus avancé.

XMLHttpRequest withCredentials (42483)

Nouvelle fonctionnalité faisant partie de la spec XMLHttpRequest Level 2, l'attribut withCredentials permet de choisir si l'on souhaite envoyer les cookies et les autorisations HTTP lors d'une requête XHR sur un autre domaine. Comme pour le nombre de connexions parallèles, il faudra attendre une prochaine version de CFNetwork.

Array.reduce et Array.reduceRight (42563, 42570)

Deux nouvelles méthodes définies par ECMAScript 5. Je vous invite à lire les explications sur le centre développeur Mozilla.

SQL en lecture seule en navigation privée (42616)

En mode navigation privée (aka porn mode), les écritures ne seront plus autorisées dans les bases de données web. Plus d'insertion, modification ou suppression possible. Ainsi aucune information durant une session privée ne pourra être enregistrée.

Implémentation de l'attribut played (42619)

La nouvelle balise video contient un attribut played permettant de savoir quelles parties de la vidéo ont déjà été visionnées. Cet attribut représente les intervalles de temps qui ont été lus.


Voilà pour cette semaine. Évidemment, ce n'est qu'une sélection que j'ai faite. Si vous avez remarqué d'autres changements intéressants, n'hésitez pas à les mentionner. Idem si je me suis trompé dans une explication.

mardi, avril 7 2009

À l'attaque !

Désolé pour l'intermède nombriliste. On ne va pas y aller par quatre chemins, j'entame à partir d'aujourd'hui un régime que j'espère concluant.

Départ : 103,5 kilos (oui, 3 chiffres...)

Objectif : 80 ou 75 kilos (si l'arrivée aux 80 kilos se fait "tranquillement", on envisagera les 75)

Ce régime Dukan ou régime protal risque de durer environ un an. C'est pour cela que j'en parle ici :

  • Pour avoir une trace écrite de mes engagements. Ça fait partie de la motivation.
  • Pour que mes proches, mes collègues ou autres puissent savoir qu'il ne faudra pas trop me forcer à aller au restaurant ou m'inviter à boire des verres.

Alors merci à Amaury (mon colocataire) et Géraldine qui ont déjà commencé ce régime. Merci pour la motivation initiale et l'entraide qu'on se donnera. Merci à ceux qui m'ont toujours un peu reproché, critiqué, embarrassé sur mon poids, ça fait partie des choses qui me motiveront. Merci aux escaliers qui me fatiguent. Merci à l'été qui arrive et qui me fait trop transpirer ou qui me gêne quand il faut se baigner.

Je mettrai certainement ce billet à jour avec mes progrès au fur et à mesure.

Temps de passage estimés :

DatePoidsPhase
7 avril 2009103,5 kilosGo !
17 avril 200996 kilosFin de la première phase
26 mai 200980 kilos
14 juin 200975 kilosFin de la deuxième phase
14 avril 201075 kilosFin de la troisième phase

Poids au fur et à mesure :

DatePoids
7 avril 2009103,5
8 avril 2009102,5
9 avril 2009102
10 avril 2009101
11 avril 2009101
12 avril 2009101
13 avril 2009100,5
14 avril 2009100
15 avril 200999,5
16 avril 200999
17 avril 200999
18 avril 200998
19 avril 200997,5
20 avril 200997
21 avril 200997
22 avril 200997
23 avril 200997,5
24 avril 200997
25 avril 200997
26 avril 200996,5
27 avril 200996,5
28 avril 200997
29 avril 200996,5
30 avril 200996
1 mai 200995
2 mai 200996
3 mai 200995,5
4 mai 200995
5 mai 200995,5
6 mai 200996
11 mai 200995
12 mai 200994,5
13 mai 200994
14 mai 200994
15 mai 200994,5
29 mai 200992,5

lundi, avril 6 2009

Compte rendu de mon atelier Paris Web 2008

WebKit ?

WebKit est souvent pris pour plusieurs choses à la fois. On pense que c'est un navigateur, on pense que ce sont les versions de développement de Safari ou tout autre idée répandue. En réalité, ce n'est qu'un moteur web. Tout ceci est bien résumé sur la page d'accueil du projet ou sur Back to the basics. Là où ça devient un peu plus confus, c'est que c'est aussi le nom d'un framework de Mac OS X. Ainsi, il est possible simplement d'afficher du contenu web dans son application en utilisant ce framework. On passe au niveau d'incompréhension supérieur : les nightlies. Régulièrement, des compilations nocturnes sont mises à jour. Il y a le source dans une archive tar.gz. Afin que de nombreuses personnes testent, il y a aussi des versions compilées pouvant tourner avec Safari Mac ou Safari Windows. Elles ne font que lancer le navigateur Safari installé sur votre machine avec une autre version du moteur.

Une autre particularité du projet est l'absence de versions à proprement parlé. Chaque éditeur souhaitant utiliser WebKit choisit ce qu'il souhaite intégrer.

Pourquoi Firebug et Web Inspector ?

Firebug est un très bon outil, pourquoi en apprendre un autre ? Tout simplement, les fonctionnalités, bugs et autres particularités des navigateurs nous obligent à avoir des outils pour analyser nos pages sous chaque navigateur. IE8 intégrera de nouveaux outils annoncés plus adaptés, Opera intègre déjà DragonFly. Et WebKit possède le Web Inspector depuis Safari 2. Une mise à jour a eu lieu avec Safari 3 puis avec Safari 3.1. Mais tout cela restait bien fade par rapport à ce qui arrivera dans la prochaine version majeure de Safari (Safari 4 en bêta depuis quelques jours). Il est intéressant de tester ses pages avec le Web Inspector dès aujourd'hui. Safari représente déjà près de 7% aux États-Unis, cela est appelé a augmenté naturellement par la part de marché croissante des Mac. L'iPhone représente une partie non négligeable du trafic provenant de mobiles. Chrome est désormais sorti de beta. Et il y a bien d'autres logiciels qui embarquent ou embarqueront WebKit.

Fonctionnalités

Pour les fonctionnalités, je vais avoir du mal à retranscrire la présentation, vu que c'était plutôt "hands-on" (et brouillon aussi). Je vous invite à consulter la documentation de Firebug et la présentation des dernières nouveautés du Web Inspector (et ma traduction).

Ce qu'il faut retenir, c'est qu'il n'y a pas que l'onglet HTML de Firebug. Il est bien utile mais l'onglet Réseau (ou Resources côté WI) peut vous aider à améliorer les performances de votre site. Par exemple, on peut regardez quelles ressources prennent vraiment du temps à être téléchargé, quels sont les headers envoyés, reçus. Abusez des profilers si vous utilisez JavaScript. Cela vous permettra de trouver les fonctions les plus lentes ou trop souvent appelées dans votre code. Sans oublier le Débugueur. Positionnez des points d'arrêt, regardez l'état des variables à cet instant, parcourir la suite du code, etc. Autant d'infos précieuses pour comprendre le fonctionnement réel de votre code (ou le code d'un autre site). Et bien entendu, la console permet d'essayer des morceaux de code, d'étudier la page, elle est également disponible lorsque le débugueur est utilisé.

La Console API est tout simplement géniale. Fini le débug avec alert(). Utilisez console.log, console.warn, console.group ou console.assert pour suivre le déroulement de votre application. Vous pourrez les enlever très facilement de votre application en environnement de production et cela vous fera gagner un temps précieux en développement. Contrairement à alert() qui est bloquant, les messages de l'API console ne vous gêneront pas dans vos tests. Abusez-en !

Dans les astuces peu documentées, je rappelle souvent le mot clef debugger; en JavaScript qui permet de mettre en pause l'exécution du script, comme un point d'arrêt classique.

Autre astuce : $0 dans la console permet d'accéder au dernier élément inspecté. On peut ainsi par exemple rapidement faire $0.style.display = 'none'; . $1 permet d'accéder à l'élément inspecté avant $0 et ainsi de suite. Cela n'est pour l'instant valable que dans Firebug.

Contribuez !

Hormis les outils de IE8, tous les autres sont libres, même DragonFly. Ce sont vos outils de tous les jours, ne les négligez pas. Si quelque chose vous gêne, n'hésitez pas à remonter l'info. Il y a bien entendu les bug trackers mais vous pouvez aussi me remonter l'info si vous préférez parler directement à quelqu'un (en tout cas pour le Web Inspector).

Un exemple concret de retours dont nous avons besoin : beaucoup de gens se plaignaient que les styles n'étaient pas éditables. Cela fait longtemps qu'ils le sont et nous ne comprenions pas pourquoi nous avions ces retours. Après quelques discussions, nous nous sommes rendus compte que les gens ne comprenaient pas ce qu'était les "Computed Styles", premier onglet de style ouvert. Depuis ces discussions, cet onglet est toujours présent mais replié. Nous ne pouvions pas découvrir ce problème sans retours.

En plus de cela, si vous souhaitez vous impliquer, sachez que le Web Inspector est intégralement réalisé en HTML/JS/CSS (tout comme DragonFly). Il est donc très facile pour un développeur Web de s'essayer au développement de ces outils.

Quelques URLs utiles :

lundi, mars 2 2009

Redesign du Web Inspector

Ci-dessous, une traduction du billet de Timothy Hatcher du blog Surfin' Safari. Quelques fautes et imperfections de traductions doivent s'être glissées, n'hésitez pas à me les signaler. Le billet original date du 30 septembre 2008 et ne parle pas encore de la beta de Safari 4.

Lire la suite...

samedi, décembre 27 2008

La semaine de WebKit - #7

Édition de Noël !

Changements de la semaine

Tout ce qui est mentionné ci-dessous doit normalement fonctionner dans la dernière nightly disponible (38826).

Web Workers (38150, 38567)

Une fois n'est pas coutume, nous allons parlons d'une nouvelle spécification. Les Web workers permettent de réaliser des actions complexes en JavaScript dans un autre thread et donc en tâche de fond. Cela permet de ne pas bloquer le navigateur mais aussi de mieux utiliser les multiples cœurs des processeurs récents. La spécification est actuellement en plein travail et change relativement souvent. Vous trouverez des explications plus détaillées sur le blog Web Tech de Mozilla (qui a aussi implémenté cette spécification qui est disponible dans Firefox 3.1β2). Certaines API sont disponibles dans un Worker mais l'API DOM n'en fait pas partie. Oliver Hunt a préparé une démo pour illustrer le gain en performance.

Support de WML (38541, Bug 20393)

Le WML est le langage destiné aux terminaux respectant le protocole WAP. WebKit ne supportait pas ce langage mais il est actuellement en cours d'implémentation. Ce support n'est pas activé par défaut dans les nightlies, ce qui vous empêchera de le tester sans compiler vous même.

HttpOnly Cookie (38566)

Une extension de Internet Explorer (depuis ajoutée à Firefox et Opera) sera bientôt fonctionnelle dans les navigateurs basés sur WebKit. Cela permet de restreindre l'accès à certains cookies. Ils ne sont disponibles que lors d'une requête HTTP et donc pas en JavaScript. C'est une fonctionnalité importante pour restreindre les dégâts de failles XSS. Ceci n'est pas testable dans les nightlies car cela demande d'avoir des librairies propriétaires d'Apple à jour (CFNetwork). Mise à jour (29 décembre) : Ceci est testable puisque CFNetwork a été mis à jour depuis.

Mise à jour de propositions (38717, 38737, 38760)

Les propositions de CSS Transforms, CSS Transitions et CSS Animations ont été mises à jour. Les CSS Transforms ont même étés séparées entre les transformations 2D et 3D. Il y a aussi une proposition d'extension des CSS Media Queries pour les étendre aux propositions précédentes. Une proposition d'extension des pointer-events au HTML a aussi été ajoutée. Toutes les propositions actuelles sont regroupées en une adresse unique.

Travail soutterain

En plus de tout cela, beaucoup de travail que je nommerai "souterrain" a été réalisé. De nombreux renommages, nettoyages ont été effectués, des corrections sur les fonctionnalités récemment introduites, une réduction de l'empreinte mémoire, des tests de conformité. Il y a beaucoup trop de changements pour que je les indique individuellement. Tout ce travail pas très visible mais bien utile me donne l'occasion de rappeler les buts du projet WebKit.


Voilà pour cette semaine. Évidemment, ce n'est qu'une sélection que j'ai faite. Si vous avez remarqué d'autres changements intéressants, n'hésitez pas à les mentionner. Idem si je me suis trompé dans une explication.

jeudi, novembre 27 2008

La semaine de WebKit - #6

Je n'arrive pas à tenir le rythme, voici donc une revue avec très peu d'explications pour rester à flot.

Changements de la semaine

Tout ce qui est mentionné ci-dessous doit normalement fonctionner dans la dernière nightly disponible (38100).

Input multi-lignes (35739)

Avant ce changement, WebKit n'envoyait que la première ligne d'un champ input. Maintenant, un copier coller d'un texte multilignes conservera tout le texte. Les retours chariots seront remplacés par des espaces. Cela harmonise le comportement avec les autres navigateurs.

Onglet Computed style replié (37523)

Après le billet sur le redesign du Web Inspector, de nombreuses personnes semblaient se demander pourquoi les styles n'étaient pas éditables. Ils se trouvaient tout simplement dans la partie Computed Style des styles. Comme son nom l'indique, elle représente les styles finaux après calcul et ne sont donc pas éditables. Pour éviter cette confusion mais garder un accès facile à cette information, cet onglet est désormais replié.

Débugger sans recharger la page (37622)

Envie de débugger du JavaScript. Il suffit d'activer le debugger et vous êtes parés. Pas de rechargement à attendre.

Temps et poids de chargements détaillés

Afin de faciliter l'interprétation de la cascade dans l'onglet Ressources, des temps et poids de chargement détaillés ont été ajoutés. Il suffit de survoler la resource pour obtenir les différents temps (temps d'attente et temps de téléchargement) ou le poids de la resource. Time details

Profiler à la demande (37730, 37933)

Avant ces changements, le profiler était toujours activé lorsque le menu développeur de Safari était activé. Cela dégradait les performances, même lorsqu'on ne souhaitait pas profiler du code. Avec ces changements, le profiler est maintenant désactivé par défaut. Un nouvel écran d'activation a donc fait son apparition. Un écran similaire a été ajouté pour le débugger. Profiler activation screen

Geolocation API (37854)

De nombreuses applications souhaitent obtenir la position de l'utilisateur pour rendre des services locaux. Une API est donc en cours de développement au W3C : Geolocation API. Nous voyons tout de suite l'intérêt que cela pourrait avoir sur un iPhone. Cela dit, cette fonctionnalité n'est pas testable dans les nightlies.

Upload de plusieurs fichiers (37863)

HTML5 introduit l'attribut multiple sur les champ de type file. Cela permet d'uploader plusieurs fichiers en une seule fois. Combiné avec XMLHttpRequest version 2, cela permet de faire des uploads avec une barre de progression sans utiliser de plugins.

Curseurs Mozilla (37902)

Deux nouvelles propriétés ont été ajoutées pour personnaliser les curseurs : -webkit-grab et -webkit-grabbing. Ils étaient déjà utilisées dans Mozilla. Démo de tous les curseurs actuels

Changement du raccourci accesskey (38211)

À l'origine, le raccourci pour les accesskey était Ctrl. Cela posait des problèmes avec les raccourcis type Emacs de Mac OS. Le raccourci a donc été changé pour Ctrl+Alt. Mais cela pose maintenant problème avec VoiceOver. D'où la solution intermédiaire : utiliser Ctrl+Alt sans VoiceOver et Ctrl avec Voiceover.


Julien Chaffraix et moi-même étions à Paris Web 2008. Entre autre bons moments, une jolie table ronde navigateurs avait lieu.


Voilà pour cette semaine. Évidemment, ce n'est qu'une sélection que j'ai faite. Si vous avez remarqué d'autres changements intéressants, n'hésitez pas à les mentionner. Idem si je me suis trompé dans une explication.

dimanche, octobre 19 2008

Paris Web, la conférence qu'elle est bien

Du 13 au 15 novembre prochains aura lieu la troisième édition de Paris Web. Bon j'aurais du vous en parler plus tôt vu que la période de tarifs réduits est terminée. Mais bonne nouvelle : ça reste plus que raisonnable même à plein tarif.

Au programme, un beau panel. On peut citer Chris Wilson, Daniel Glazman, François Yergeau, Nicole Sullivan, Christian Heilmann, Charles MacCathieNeville, Aaron Leventhal. Et je ne cite là que les noms connus internationnalement. Il reste encore plein de personnes plus intéressantes les unes que les autres.

De mon côté, j'animerais un atelier le samedi sur Firebug et Web Inspector :

Les documents que nous développons sont de moins en moins statiques. Une fois le code écrit, il faut comprendre l’interprétation qu’en font les navigateurs.

Quelles règles CSS s’appliquent à cet élément ?

Quel bug s’est glissé dans mon code JavaScript ?

Pourquoi cette action est lente ?

Nous découvrirons et utiliserons ces deux outils pour répondre à ce genre de questions et plus. Nous parlerons aussi de la Console API et des outils en ligne de commande.

J'aimerais aussi parler un petit peu des nouveautés de WebKit, on va voir sous quelle forme ce sera.

En plus des conférences et des ateliers, il y aura un petit pot libre.

Je vous attends donc tous en grand nombre à cette conférence atypique, organisée par des bénévoles mais de qualité professionnelle. Et si vous comptez passer, laissez un petit commentaire ici histoire de.

lundi, octobre 13 2008

La semaine de WebKit - #5

Un mois sans nouvelle, bouh, c'est pas bien. Du coup, on reprend avec seulement deux semaines.

Changements de la semaine

Tout ce qui est mentionné ci-dessous doit normalement fonctionner dans la dernière nightly disponible (37469).

Style du texte de remplacement (37123, 37217)

WebKit accepte un attribut placeholder sur les éléments de type input. Cet attribut permet d'afficher une aide dans le champ lorsque l'utilisateur n'a entré aucun contenu. Par défaut, ce texte d'aide est affiché légèrement grisé. On peut désormais jouer sur son style en utilisant le pseudo-element -webkit-input-placeholder. Voir cet exemple.

Débuguer avant la fin du chargement (37313)

Avant cette correction, il était impossible de débuguer une partie de code s'exécutant avant que la ressource ne soit finie d'être chargée. C'était un peu handicapant pour un outil comme le Web Inspector. Corrigé donc.

En-tête Origin pour les requêtes POST (37317)

Début d'implémentation de la spécification Access Control for Cross-Site Requests. Un en-tête Origin, ne contenant que le domaine de la page déclenchant la requête POST, est ajouté. Cela permet aux applications de vérifier que la requête provient bien d'un domaine autorisé. Contrairement à l'en-tête Referer, celui-ci ne révèle pas le chemin complet de la page d'origine.

Recherche de ligne précise (37389)

Comme Firebug, il est possible de rechercher une ligne précise d'un fichier dans le panneau Ressources. On peut utiliser #123 ou line:123 comme syntaxe. Il est même possible d'ajouter un mot pour ne trouver que les lignes contenant ce mot.

Correction du test SunSpider (37389)

Comme l'a mentionné David Mandelin sur son blog, le test regexp-dna de SunSpider était incorrect. Une option supportée uniquement par Gecko était présente et défavorisait donc ce moteur. Tout est rétabli, les moteurs font désormais le même test.

Nouvelles de la semaine

Pendant que je ne donnais pas de nouvelles, trois nouveaux billets sont apparus sur le blog Surfin' Safari :


Voilà pour cette semaine. Évidemment, ce n'est qu'une sélection que j'ai faite. Si vous avez remarqué d'autres changements intéressants, n'hésitez pas à les mentionner. Idem si je me suis trompé dans une explication.

lundi, septembre 8 2008

La semaine de WebKit - #4

On reprend le rythme doucement, après quelques semaines sans nouvelles. Au passage, les billets en anglais sont désormais recensés sur le Planet Webkit.

Changements de la semaine

Tout ce qui est mentionné ci-dessous doit normalement fonctionner dans la dernière nightly disponible (36135).

Édition des propriétés DOM et des variables locales (35835)

En double cliquant sur une des propriétés dans la barre latérale dans le panneau Elements ou Scripts, vous pouvez changer la valeur de la propriété associée. Vous pouvez entrer du javascript comme le montre la capture suivante DOM editing

Support de console.count (35842)

Toujours pour la compatibilité avec Firebug, une nouvelle méthode s'ajoute à la liste. Elle permet de compter le nombre de fois qu'une ligne a été appelée.

Onglet Metrics éditable (35876)

Tout comme Firebug, il est maintenant possible d'éditer les dimensions, padding, bordures, marges et position d'une boîte. Metrics editing

Support de Canvas Text (36060)

Canvas, l'élément qui permet de faire du dessin en 2D s'est vu ajouté une API pour dessiner directement du texte. Deux tests peuvent vous servir d'exemples.

Conséquences de Chrome

Évidemment, vous n'avez pas manqué l'annonce de Google cette semaine. Un nouveau navigateur utilisant WebKit. Et les deux projets s'entendent, j'en veux pour preuve ces quelques commits.

  • 36074 Nouvelles constantes pour Skia, V8 et Chromium.
  • 36095 Les benchmaks de V8 sont intégrés à WebKit.
  • 36097 Petite anecdote, certains développeurs de Google fournissaient des patchs sous des pseudonymes pour ne pas éveiller l'attention avant l'annonce.


Voilà pour cette semaine. Évidemment, ce n'est qu'une sélection que j'ai faite. Si vous avez remarqué d'autres changements intéressants, n'hésitez pas à les mentionner. Idem si je me suis trompé dans une explication.

mercredi, août 27 2008

Librairies JavaScript : Connaissez vos outils

Certes je n'aime pas les librairies JavaScript en général. Beaucoup de code téléchargé, parsé, exécuté pour n'utiliser la plupart du temps qu'un ensemble très réduit de fonctionnalités. Mais bon, mettons ça de côté aujourd'hui car il faut l'admettre, elles rendent tout de même de bons services.

On va quand même garder un point qui m'embête : ces librairies cachent souvent la complexité du code qu'elles exécutent. Pour démontrer cela, mettons nous en situation ! L'exemple sur la page suivante contient 1729 paragraphes de deux mots. Pour une raison évidente[1], nous voulons cacher le deuxième mot de chaque paragraphe. Pour cela, nous utilisons jQuery de deux manières différentes.

La méthode toggle

$('span').toggle();

Que fait réellement cette simple ligne ? Elle va récupérer tous les éléments <span> de la page puis leur appliquer la méthode toggle. Pour chaque élément trouvé (1729 je rappelle), elle va vérifier s'il est affiché ou non et lui appliqué un style en conséquence. C'est tellement long que votre navigateur risque de bloquer sur la page de test.

La méthode classe

$('div').eq(0).toggleClass('hidden');

Jeu de mot pas terrible mais qui résume bien la situation. Ce code récupère tous les éléments <div> de la page et ne travaille que sur le premier. Sur ce <div>, elle va regarder s'il a la classe hidden et en fonction, lui ajoutera ou enlèvera cette classe. Voilà, c'est tout ce qu'elle fait. Ensuite, c'est le navigateur qui travaille comme un grand grâce à la règle .hidden span {display:none;}. Évidemment, le moteur CSS de votre navigateur fera ça bien plus rapidement.

Conclusion

Évidemment, mon exemple avec autant d'éléments est grossier. Mais tout de même, la différence est fondamentale. Permettez-moi une analogie entre un accès DOM et un accès disque, c'est à dire les parties les plus lentes des deux algorithmes précédents. Dans le premier cas, un premier accès en lecture (récupérer tous les spans) puis 1729 accès en lecture (est-il affiché ?) et 1729 accès en écriture (réglons son affichage). Dans le deuxième cas, nous avons un premier accès en lecture (récupérons tous les divs) puis un accès en lecture (est-ce que la classe est présente ?) puis un accès en écriture (ajoutons ou enlevons la classe). Le calcul est vite fait...

De manière générale, rappelons qu'il faut le moins possible toucher au style d'un élément. Si vous devez accéder plus de deux fois à l'attribut style, il sera plus profitable de passer par une règle CSS. Le moteur CSS sera toujours plus rapide que vous. De plus, vous permettez aux intégrateurs de pouvoir styler votre page en ne changeant que quelques classes. Et votre code d'affichage reste cantonné aux fichiers CSS, merci la maintenabilité.

Notes

[1] parce qu'il faut bien un exemple à la con

- page 1 de 5