Brain Cracking

RPW 14/07/10: que supporte les mobiles, bénéfices de la performance Web, implémentation de la balise , inclure son JS de manière non obstrusive

Désolé pour le manque de revue de presse de ces derniers jours, mais une petite surcharge de taf s'est imposée à moi. La revue a pu continuer sur Twitter mais je n'ai pas eu le temps de la commenter. Rattrapage :

• Mobile : tableau comparatif du comportement des navigateurs mobiles (modernes), sur des éléments aussi variés que le support CSS3, l'API Selector, l'interprétation de la spec ECmascript, la sécurité et surtout l'utilisation du réseau : nombre de JS en parallèle, nombre de téléchargement en parallèle par nom de domaine... Bref, cela vous sera utile en particulier concernant les performances réseau qui sont encore plus essentielles sur mobiles que sur desktop.
• Perfs : résumé graphique et données chiffrées issues de la conférence Velocity sur la performance Web. Des chiffres toujours utiles à glaner pour estimer ce que vous rapporterait une amélioration de la performance. On y apprend par exemple qu'un temps de chargement de 3s augmente de 50% le temps de rebond, et baisse de 25% le nombre de pages vues, par rapport à la même page se chargeant en 1s.
• Audio : implémentation et tutoriel de la balise <audio> , avec fallback Flash. Comme sa cousine <video>, le support de la balise elle même n'est bien sur pas assuré chez les IE, et il n'y a pas non plus d'entente sur le format à utiliser (FF refuse de lire les fichiers MP3). Bref l'intérêt du tuto est d'utiliser la librairie jPlayer qui utilise un fallback Flash, par contre ils suggèrent d'encoder en MP3 et en OGG les fichiers audios, sans préciser si la librairie est suffisamment intelligente pour servir à FF la version Flash dans le cas où l'on n'utilise que la version MP3 par exemple. A tester donc.
• Perfs : inclure son JS de manière non-obstrusive, tout en préservant l'ordre d'inclusion des scripts et en faisant marcher les scripts inline. C'est un peu le Graal du moment dans le monde des performances Web. Ici l'implémentation utilise la librairie labJS (inclusion synchrone ou non de fichiers JS) et un trick JS façon Analytics pour les scripts inline, qui consiste à stocker dans un tableau le code JS à exécuter une fois que toutes les dépendances sont là. C'est plus propre que ma solution mute + eval, mais ça demande à modifier le JS inline. Et encore une fois document.write() n'est pas géré.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 07/07/10: étude de cas performances Mappy, Firefox 4b1, déclaration de fonctions en JS, tester simplement et automatiquement son interface

Revue de Presse Web de hier :

• Browser War : Firefox 4 beta 1 est de sortie, avec un énorme paquet d'améliorations que les webdevs attendaient. Je ne les liste pas ici, Mozilla l'a déjà très bien fait. Comme pour IE9, je recommande d'au moins vous l'installer sur une machine virtuelle pour tester votre site car le parser HTML a changé et les formulaires HTML5 sont (partiellement) supportés. Ne remplacez pas votre FF de travail, la plupart des addons dont firebug ne marchent pas. Update : la version alpha de Firebug marcherait avec cette beta
• JS : il y 2 manières de déclarer une fonction en JS et je n'avais jamais compris la différence, mais elle est piégeuse car elle touche au scope. Par expression ( var theExpressionWay = function() ) ou de manière déclarative ( function theDeclarativeWay() ). Je n'utilise pratiquement plus cette dernière car elle ne permet pas de gérer la portée de la fonction : elle se met directement dans le namespace global (window.), ce qui peut provoquer des conflits. Mais ce que je ne savais pas, c'est la fonction est déclarée quoi qu'il arrive, même si séquentiellement le parser n'est pas censé arriver jusqu'à la déclaration.
• Qualité : un outil OSX (fakeapp) pour automatiser des actions sur un site. De manière très visuelle il permet de programmer une navigation, à priori même sur des interfaces compliquées dépendant lourdement de JS, et de tester certaines valeurs. Utile pendant le développement ou avant de passer en production pour vérifier que l'on n'a rien cassé (login, signup, actions principales ou secondaires rarement testées ...). Sur le principe il se met en concurrence avec Selenium, en pratique Selenium est bien plus complet (plusieurs browsers, ne bloque pas le développeur, stockage des rapports sur serveur ...), et donc beaucoup plus lourd à mettre en place. A vous de voir si vous voulez doucement mettre le pied dans les tests automatisés avec une interface sympa ou passer directement au standard de facto. Par contre FakeApp est actuellement gratuit car en beta et finira payant.
• Perfs : Etude de cas d'optimisation sur Mappy.com. La principale méthode, hormis le nettoyage de code qui n'a pas apporté grand chose et la concaténation, a consisté à maîtriser l'ordre d'affichage des zones importantes (le formulaire et la carte) pour les faire afficher en premier, et donc jouer sur la perception plutôt que sur les temps de chargement total. Le logiciel WebPageTest est un outil à utiliser pour avoir un développé dans le temps du rendering d'une page, et il émule en plus différentes vitesses de connexion. Les commentaires valent aussi le coup d'être lus, ils sont un bon complément à l'article.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 06/07/10: ergonomie, 15% d'utilisateurs sans gzip, les performances de la home Yahoo

Revue de Presse Web de hier :

• Ergonomie : le comportement des utilisateurs, à la fois surprenant et frustrant pour les producteurs de sites. J'avais déjà partagé ce lien il y a 4 mois, mais ceci en est un résumé français, et cela ne fait pas de mal à relire tant les résultats sont édifiants. Pour résumer, les gens y vont franchement à l'instinct sur vos pages : scan visuel très rapide, sections entières inconsciemment ignorées, scan des mots, la moindre attente ou sentiment d'être perdu les fait partir, chaque élément doit réagir comme ils s'y attendent eux. Seul salut là encore : les tests utilisateur (via @guerrier)
• Perfs : la compression Gzip est la plus facile et la plus immédiate des optimisations à faire sur un site (réduction de 80% du poids des HTML/CSS/JS), mais 15% de vos utilisateurs n'en bénéficient jamais. En cause non pas les anciens navigateurs, mais les logiciels de sécurité comme les antivirus et les firewalls. La seule solution (PDF, page 12) pourrait consister à servir une page compressée dans une iframe cachée, qui définit un cookie en JS : si le navigateur supporte vraiment la compression, il va interpréter le JS et renvoyer le cookie à chaque requête. A partir de là, à vous d'intercepter la valeur du cookie en PHP ou via Apache (avec SetEnvIf Cookie) et de servir la page gzippée.
• Perfs : retour d'expérience de l'équipe qui travaille sur la nouvelle Homepage Yahoo, qui présente quelques challenges uniques : contenu inconnu à l'avance (sprite inutile), fort traffic (cache inutile) , personnalisation de listes de Widgets, Widgets très dépendants de JS. Les outils traditionnels montrent leurs limites pour mesurer ce qui compte pour l'utilisateur : le temps entre le moment où il demande la page et celui où il peut cliquer pour obtenir sa fonctionalité. Solutions :
  • Le "progressive enhancement" prend donc ici tout son sens, puisque même sans aucun JS, la page est utilisable. L'utilisateur n'a donc pas à attendre lorsqu'il sait déjà où cliquer
  • Ensuite vient la technique classique de l'insertion dynamique des JS, qui ne freeze pas l'UI par rapport à l'inclusion via <script>, sauf que celle ci se fait en 2 requêtes : un loader, puis le JS principal qui suffit à la plupart des interactions.
  • Pour chaque module requérant un JS spécifique celui ci est chargé à la demande. Après le body.onload, on pré-charge les JS/CSS des modules les plus susceptibles d'être utilisé
  • le HTML a été modifié pour suivre les "flush()", car certains navigateurs n'affichent pas les <div>s si elles ne sont pas fermées. Là je suis un peu surpris car c'est en contradiction avec ma propre expérience : je flush également par bloc, mais j'ai une div contenante qui fait toute la page, et je n'ai jamais constaté ce problème. Le <head> et la navigation chez moi sont rendu instantanément pendant que PHP continue à calculer le reste de la page
  • parser du JSON coûte cher en CPU (= coup de freeze), en particulier sur les anciens navigateurs, ils ont donc arretté d'envoyer du HTML via JSON, pour le mettre en texte plein à la suite de la réponse JSON
  Voilà, vous me direz que bien peu d'équipes ont les problématiques et le temps pour réaliser tous ces tests de performances et optimiser une page, mais il y a de bonnes leçons à prendre pour tous les sites, comme continuer à développer en progressive enhancement ou flusher dès que possible (via @edasfr)
• Emploi : quelques stats sur les postes pour freelance ouverts. En 4 mois, les recherches de poste HTML5 (quoi que ça veuille dire ...) ont été multipliés par 8 ! Un chiffre précis signifie pas grand chose, mais c'est juste représentatif du hype actuel autour d'HTML5 (merci Steve Jobs). Et c'est plus que jamais le moment de mettre à jour son CV, il suffit de changer un doctype pour affirmer qu'on a fait du HTML5 ...

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious.

RPW 05/07/10: Canvas pour les flasheurs, installation de Node.js et utilisation de WebSocket,

Revue de Presse Web de hier :

• Canvas : implémentation d'un algo hallucinant : le "content aware image resizing". L'algo original permet de redimensioner une image sans crop ou déformation, regardez cette démo vidéo ici. Pour le porter sur le Web, l'auteur manipule un Canvas en JS et a apporté de nombreuses améliorations de performances, car c'est très consommateur en CPU. Sa prochaine amélioration sera logiquement d'utiliser Web Workers pour générer l'image afin de ne pas gêner le thread principal.
• Canvas : librairie JS d'accès à Canvas, qui adopte la syntaxe et les méthodes d'ActionScript. Idéal donc pour le développeur 2D qui veut enrichir son CV ou pour ré-utiliser des compétences internes déjà existantes en Flash alors si votre application doit passer en Canvas (au hasard pour supporter les iDevices).
• Perfs : piqûre de rappel concernant les sprites CSS avec ce court exemple de son utilisation. Si vous ne les utilisez toujours pas (au moins pour les myriades d'icônes et leurs états qui composent un site Web), il va falloir penser sérieusement à s'y mettre car cela accélère grandement l'affichage des pages, en échange d'un peu de lisibilité du CSS. L'alternative aux sprites est d'encoder ses images dans le CSS mais cela demande un gros développement pour rester maintenable : voir cet article pour la méthode de base, et celui ci qui corrige ses défauts.
• Node.js : installation et utilisation de Node.js avec WebSocket, le tout chez un hébergeur payant (SliceHost, qui donne tout de même beaucoup de liberté, comme le choix de la distribution Linux et les accès root). L'installation sur une Ubuntu passe par :
  • l'installation de Git, le clone du repository Node.js
  • la compilation de Node.js, le choix de la bonne branche
  • l'installation d'un serveur WebSocket, ici spécialisé pour Twitter
  Le code côté client n'est pas plus compliqué que ce que l'on fait aujourd'hui avec XHR. Assez simple dans son cas puisqu'il a un client et un serveur WebSocket déjà écrits. Le seul problème des WebSocket reste le changement obligatoire de techno si votre server-side est en PHP.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious.

RPW 02/07/10: outils pour l'accessibilité, Flash est accessible, CSS orienté Object et l'exemple Facebook, listing des propriétés CSS3

Revue de Presse Web de ce vendredi :

• Accessibilité : liste de ressources pour aider à développer de manière accessible. Outre la formation, ce qui vous sera utile au quotidien seront sans doute les extensions FF comme Wave ou Ocawa. Je n'utilise que le premier ainsi qu'un Color Analyzer / rôle ARIA, très pratique pour discuter avec son designer du manque de contraste. Les validateurs en ligne ne sont pas pratique pour les environnements de développement qui est en principe invisible de l'extérieur (et si vous avez un site avec beaucoup d'interaction, c'est quasi inutile). Sur Alsa on est bien traités avec un menu à la carte, c'est suite à une question à propos de cet article (extensions Chrome pour faire face à certains handicaps) que M. Goetter m'a donné ces liens ma foi fort utiles.
• Accessibilité : formation "développer accessible avec Flash". C'est payant, mais si je partage ce lien, c'est surtout pour rappeler aux flasheurs qu'en théorie Flash peut être accessible, mais qu'il faut se démener pour aller chercher les bonnes options dans l'éditeur. C'était le thème d'une des conférences Paris Web, dont j'ai retrouvé les slides ici, mais pas la vidéo (si il y en avait). (via @okeul)
• CSS : réduire la taille de ses CSS en changeant sa manière de coder. L'inventeuse du concept d'OOCSS revient forte d'une expérience d'optimisation des CSS sur Facebook. CSS et l'intégration en général sont souvent le parent pauvre du Web, que l'on donne en général à des développeurs débutants voire à des graphistes. Pourtant si l'on veut éviter d'en arriver à une situation comme sur Facebook et ses 1.7Mo de CSS, et où toute évolution demande beaucoup de maintenance, il faut utiliser les mêmes principes que pour les languages de programmation : ré-utiliser le code, le penser en modules et limiter les spécificités, c'est tout le concept derrière le mot "OOCSS". Pas mal de pratiques à prendre en compte, je ne cite que les plus révolutionnaires :
  • ne pas utiliser les #id : utiliser des modules (groupes de règles réutilisables)
  • éviter width, height ou float : n'utiliser que des systèmes de grilles
  • découpler la sémantique de la présentation : exemple <h1 class="h3">
  • éviter la spécialisation : votre colonne de droite peut surement reprendre 90% des règles modulaires (taille des titres, disposition en utilisant les grilles, couleurs et taille de texte)
  • rajouter autant de classes que nécessaires dans le markup. Exemple extrait de mon Facebook : <a class="pvm uiUnifiedStory uiStreamStory uiListItem uiListLight uiListVerticalItemBorder"> soit 6 classes pour une news. Mais même en alourdissant le HTML de toutes ces classes, ils auraient au final gagné 50% de poids de HTML en le refactorisant !
  Franchement ces pratiques m'avaient fait tiquer il y a quelques années lorsqu'elle présentait les prémices de son concept en interne chez Yahoo!, mais à force de voir mes feuilles de style grossir (de mon fait ou pas), et en plongeant un peu dans sa logique, il y a beaucoup de ces techniques qui devraient être appliquées au quotidien pour garder des feuilles de style maintenables.
• CSS3 : démo live de toutes les nouvelles propriétés CSS3 et associées (les Webkit). Je me suis promis d'arretter les démos CSS3 si l'auteur n'assure pas une compatibilité IE, mais ce lien là est juste utile pour avoir un petit listing et donc s'auto-former.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious.

RPW 01/07/10: HTML5 sur mobile, IE reprend des parts de marché, sortie d'Opéra 10.6 avec WebM

Revue de Presse Web de hier :

• HTML5 : série d'articles démontrant l'utilisation d'HTML5 sur mobiles. C'est un peu indigeste à lire en une seule fois, mais pour s'auto-former à HTML5, c'est assez complet, tout en vous donnant les compatibilités par versions majeures de navigateur mobile. Y sont abordé Canvas, CSS3, la géolocalisation, l'offline avec un manifeste de cache, les Web Workers (j'ignorais qu'ils étaient implémentés sur Android et Fennec) et LocalStorage.
• Browser War : IE a arretté de perdre des parts de marché dans le monde, regagnant même ces 2 derniers mois +0.88% en Europe. Je n'ai pas le détail par version, mais j'ai du mal à imaginer un retour d'IE6-7, il faut donc au moins espérer que les gens reviennent sur IE8. Ce serait la publicité télé ? ou alors des installation de Seven où les gens oublieraient de ré-installer FF ?
• Browser War : Opéra 10.6 sort de beta sur tous les OS et rattrape donc les Webkits et FF avec les Web Workers, la géolocalisation, l'offline avec Cache manifest. IE est donc maintenant officiellement le seul à ne pas supporter ces apports d'HTML5, et IE9 n'a d'ailleurs rien promis sur ces 3 points particuliers. Et surtout il supporte WebM : un petit tour sur Youtube (après s'être enregistré ici) permet. Contrairement à ce que j'écrivais hier sur Twitter, le plein écran n'est disponible qu'à partir du menu contextuel. Opéra fait d'ailleurs mentir Youtube qui affirmait avant hier qu'il n'était pas possible de mettre une interface par dessus une vidéo fullscreen. Ici Opéra semble tricher un peu : en passant en plein écran, Opéra aggrandit en fait la zone de la vidéo pour qu'elle occupe tout l'écran, et l'interface du navigateur disparaît (comme lors d'un appui sur F11). Du coup les contrôles Youtube restent, mais il est difficile de savoir si ils ont fait quelque chose de spécifique à Youtube ou si cette technique pourra marcher partout par défaut. Et pour le site, il n'y a aucun moyen de savoir si il est en fullscreen ou pas. Concernant la qualité de la vidéo elle même, impossible de trouver une vidéo de bonne qualité, même en 720p, ce qui peut provenir du codec lui même ou des vidéos, ou des encodeurs Youtube ...

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious.

RPW 30/06/10: introduction à SVG, CSS display, bilan de Youtube HTML5 vidéo, poids moyen des sites, IE9 WebTiming

Revue de Presse Web de hier :

• SVG : introduction à SVG. Y sont abordés la syntaxe de base, les outils pour en générer et la compatibilité. L'avantage est de pouvoir générer des images qui ne sont jamais pixelisées (comme Flash) car SVG gère des formes, et de pouvoir manipuler ces formes depuis JS. Dans les futurs FF4 et IE9 (le reste des navigateurs suivra forcément), il sera possible d'embarquer du SVG directement dans une page HTML5. Il n'y a plus qu'à attendre la disparition d'IE8 ...
• CSS : petite démo de la propriété display en action, qui montre qu'il existe une palanquée de valeurs possibles en dehors de block et none. Le inline-block (permet de mettre padding et margin sur un élément inline) nous fait rêver depuis longtemps mais est mal supporté par IE6/7. La valeur table-cell (qui permet entre autre un ajustement automatique de la largeur) est également exactement ce que cherchent beaucoup d'intégrateurs, mais n'est pas du tout supporté par IE6/7. Bref, c'est en revoyant ces limites qu'on se souvient de pourquoi on n'utilise que block et none.
• Vidéo : bilan de l'expérimentation HTML5 <video> de Youtube. Commencée en janvier dernier, le résultat est plutôt négatif :
  • impossible d'aller à un point particulier de la vidéo si il n'est pas téléchargé (et il y aurait besoin pour cela d'un standard complémentaire ...)
  • pas de possibilité de sécuriser (pour l'auteur) un flux vidéo, donc Flash restera la techno obligatoire pour le streaming payant
  • le fullscreen (quand il est supporté) n'est pas actionnable via une interface custom (je sais qu'au moins FF travaille sur ce point), et pas de moyen à priori de mettre une interface par dessus une vidéo fullscreen. .
  ainsi que d'autres points plus spécifiques à Youtube. J'avais déjà dressé mon propre bilan négatif en tant qu'utilisateur dans cette news. En passant ils rappellent qu'ils supportent WebM qui a de bonnes chances d'être le remplaçant de h.264 dans plusieurs années (avant 2015 idéalement, année où des droits payants pourraient s'appliquer) et que Adobe prépare une version de Flash supportant ce codec, pour moi dernière étape avant d'envisager sérieusement de migrer vers WebM. L'implémentation actuelle de cette balise est encore jeune, reste à voir si ces limites sont gênantes sur votre site, sinon cela cantonne l'utilisation actuelle de <video> à combler l'absence de Flash (via @pobo)
• Perfs : IE9 preview 3 expose les vrais temps de chargement et autres métriques, telles que constatées par le browser, et non calculées par JS comme c'est le cas aujourd'hui, ce qui fausse les résultats. C'est pour le moment préfixé MS (window.MSPerformanceTiming) et cela correspond à la spec WebTiming, en cours d'écriture. Bonne nouvelle pour les développeurs qui voudront benchmarker leur code manuellement. Je ne sais pas comment font aujourd'hui des plugins comme Firebug ou Dynatrace AJAX : Firebug utilise du JS, donc les temps doivent être biaisés, mais la techno utilisée pour Dynatrace étant différente, peut être que les temps sont déjà réalistes ? (via ajaxian)
• Perfs : dans cette vidéo extraire des conférences Velocity, Google nous donne quelques chiffres précieux (sans doute récoltés grâce à la google toolbar ou avec leur DNS) : le site moyen a un poids de 320Ko, et est chargé en 4,9s, alors qu'au vu de la bande passante moyenne, il pourrait être chargé en 1.4s. La moyenne est de 44 ressources externes (CSS, JS, images ...) pour 7 recherches DNS (widgets, pubs, trackers, sous domaines ...). Cette même page est chargée avec FF3.6 2 secondes plus vite qu'avec un IE6. Le reste de la conférence se concentre sur les améliorations sur lesquelles Google travaille et qui touchent aux protocoles (TCP, HTTP, SSL, DNS), et qui sans toucher aux sites permettrait d'accélérer la navigation.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious.

RPW 29/06/10: HTML5 audio, bilan du cache des browsers mobile, performances web et chiffre d'affaire, sémantique HTML5

Revue de Presse Web de hier :

• Audio : technique pour inclure un .mp3 dans une page avec la balise <audio> et un fallback Flash. Cela utilise uniquement du markup (l'équivalent audio de Video for everybody) et plutôt que de mettre la balise <object> qui référence le flash à l'intérieur de <audio>, c'est le contraire qui est fait. FF qui ne lisant pas le MP3 en natif prendra donc en compte le flash (non fourni ici) plutôt que la balise <audio>. L'inconvénient de la technique, c'est qu'aucun navigateur qui supporte le flash ET <audio> n'utilisera cette dernière balise.
• Perfs : test assez complet sur les limites des caches des navigateurs mobiles, iDevices en tête. C'est une question que l'on ne se pose pratiquement pas sur desktop, mais sur mobile c'est assez problématique, surtout pour des navigateurs qui auraient justement bien besoin de meilleures performances. Résultats : les premiers iphones ne gèrent pas du tout le cache, et l'iPad et les 3GS non upgradés ne gèrent pas plus de 25ko par composant (200ko au total). Etant donné que l'on concatène de plus en plus nos CSS/JS, il est fort probable que vous dépassiez déjà cette limite. Si votre utilisateur est sur un réseau Edge ou un mauvais 3G, le site est pratiquement inutilisable. La situation s'améliore lorsqu'on l'on monte en gamme iOS ou que l'on sert des Androids et des Palm. La solution réside dans l'utilisation d'un manifeste de cache, en plus compatible avec FF et les Webkits desktop, mais qui demande un peu de gestion.
• Perfs : impact de la performance Web sur le Chiffre d'affaire. Passées les 12 premières diapos, on nous rappelle quelques chiffres connus
  • Google : -0.6% de recherches par utilisateur avec 400ms de plus
  • Google UK : doublement des clics sur les pubs en passant de 3s à 0.5s de temps de chargement
  • Bing : -4% de revenu par utilisateur avec 2s de chargement en plus
  • Shopzilla : 5-12% de CA en plus en passant de 6s à 1.6s
  et y ajoutent leurs propres constatations : 40% de visites en +, diminution du taux de rebond, amélioration de la fidélité des visiteurs, 25% de temps passé en plus sur le site et de pages vues. Bref vous avez de quoi parler le même langage avec ceux qui payent votre salaire et entamer un chantier performances :)
• Sémantique : schéma résumant le chemin de décision lorsque l'on se demande quelle balise HTML5 appliquer à son contenu. C'est un résumé des différents articles de HTML5 Doctor qui a fait un gros travail de débroussaillage sur cette nouvelle sémantique. L'utilisation de <article> (qui peut s'utiliser pour autre chose qu'un article et qui doit contenir un <Hx>) et <section> (qui peut être un chapitre) par exemple n'est pas aussi évidente qu'on le croit

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious.

RPW 28/06/10: Forms 2, Chrome dépasse Safari, IE9 excelle en CSS3, charger ses JS, la guerre des specs HTML5, la montée du Web mobile

Revue de Presse Web de hier :

• Forms2 : table de compatibilité des HTML5 Forms, par navigateur. Je rappelle que vous pouvez déjà utiliser les nouveaux types de champs (email, url ...) car ils "degrade gracefully" et sont déjà utilisés dans certains cas (le changement de clavier pour l'iPhone, des widgets Calendrier pour Opéra), en plus de rajouter un peu de compréhension au niveau code. Pour la partie comportementale (placeholder, validation ...), l'alternative sera forcément en JS et pour le moment je n'ai repéré qu'une seule librairie qui le fasse : webforms2.
• Browser War : aux US, Chrome et Safari sont maintenant à égalité de part de marché : 9% chacun, ce qui porte à 18% la part des webkits, au cas ou vous vous demandiez encore si il fallait tester ses sites avec les Webkits. Les chiffres français ne doivent pas être très éloignés, au moins proportionnellement. Heureusement supporter Webkit pose aujourd'hui rarement problème. (via techcrunch)
• Perfs : la conférence Velocity sur les performances Web est terminée, voici quelques conférences sélectionnées par Steve Souders. Il y a eu 89 présentations en tout et je n'ai pas encore commencé à les regarder (1h à chaque fois ...), donc ça va me prendre quelque temps avant de les dépiler, regarder les bonnes et vous faire part de ce qu'il y a d'intéressant.
• Browser War : IE9 semble avoir vraiment pris de l'avance sur le support CSS3, constate quirksmode dont le métier est de dresser des tables de compatibilité. Les sélecteurs seraient implémentés à 100% et les backgrounds seraient mieux implémentés que chez les autres (j'ajoute que l'implémentation de border-radius aussi a l'air plus consistante). L'impasse a été faite sur les prefixes Webkit. Mais vu le cycle de release d'IE (une version tous les 2-3 ans) et des autres navigateurs (dès que possible), il est clair que cette avance sera rattrapée en quelques mois, pour le plus grand bonheur des webdevs.
• Mobiles : étude sur des utilisateurs d'Internet sur Mobile : ils l'utilisent au quotidien, cela ne remplace pas complètement leur navigation sur desktop, et ils apprécient surtout la facilité d'utilisation et le côté pratique du Web Mobile. J'imagine que dans cette étude on n'a pas fait le distinguo entre application natives qui utilise le Web et vrais site Web accédé via mobile. Ce qui est sur c'est que les utilisateurs apprécient les interfaces simplifiées faites pour les mobiles, ce qui est sûrement une indication pour les version desktop : simplifier là aussi les interface plutôt que de tirer parti des grandes résolutions pour en mettre un maximum sur la même page ferait sûrement gagner en satisfaction utilisateur. (via @guerrier)
• HTML5 : résumé de la situation autour des specs HTML5. J'avoue que je ne prête que peu d'attention aux débats entre W3C et WHATWG, mais d'après l'auteur il y a pas mal de politique qui ralentit l'écriture et surtout la validation des specs HTML5. En tant que webdev, on ne s'intéresse qu'au résultat final, c'est à dire les différents moyens de contourner les implémentations divergentes ou le simple manque d'implémentation. Ce qui dans mon cas se traduit par ce blog de veille techno. Malheureusement lorsqu'on l'on veut s'attaquer à des fonctionalités HTML5 encore mal couvertes par les librairies, on peut se retrouver du côté des implémenteurs (codeurs de librairie et browsers) et là il faut se tenir au courant de ce qu'il se dit pour en tirer une probabilité plus ou moins forte que la spec sera respectée. Et c'est dommage car cela prend autant de temps que le code lui même.
• Perfs : comment charger ses JS. Une méthode parmi d'autres, qui consiste à définir un loader très simple en JS (l'auteur le met en script externe en bas de page mais il parait judicieux de le mettre inline) puis à grouper ses méthodes d'initialisation dans le loader du script unique, le script étant chargé de manière non bloquante. La contrainte est que cela demande une bonne maîtrise des modules JS inclus dans la page pour regrouper à un seul endroit à la fois les dépendances JS et les méthodes d'initialisation. Cela suppose également que votre HTML se charge très vite, ce qui peut ne pas être le cas pour des pages demandant un gros calcul server-side. (via @edasfr)

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious.

RPW 25/06/10: n'utilisez pas HTML5, javascript hijacking pattern, Google et la sémantique de vos sites, mesurer les performances perçues par vos utilisateurs, plugin accessibilité

Revue de Presse Web de vendredi :

• HTML5 : un post d'opinion, à contre-courant du hype autour d'HTML5, qui déclare basiquement qu'il ne faut pas utiliser HTML5. L'auteur y rappelle surtout le process normal du W3C, et que la spec HTML5 n'en est toujours qu'au Working Draft, phase de grosse modification de la spec par excellence. Et il relaie les mots d'un des éditeurs des specs qui avait dit qu'elle ne serait pas finalisée avant 2022 (j'ai vu cette date souvent, mais je n'en connais pas le contexte). Ces arguments sont irréfutables, mais je trouve sa conclusion sans nuances : je pense que les trois quarts d'HTML5 sont implémentables cross-browser dès aujourd'hui (à grand renforts de fallbacks en tout genre, Flash en tête) et je pense même que la maintenance et les temps de développement sont largement acceptables si l'on utilise de bonnes librairies. Lorsque j'avais écrit ce billet en janvier, je pensais qu'il faudrait une petite année pour que les librairies majeures donnent un accès complet à HTML5, sous peine de voir le marché envahi par des librairies payantes. 6 mois après, les majeures n'ont pas vraiment bougé, mais on voit sortir de l'ombre quelques payantes et (heureusement) beaucoup de gratuites, qui se concentrent sur une feature HTML5 en particulier.
• JavaScript : pouvoir modifier des librairies JS, sans toucher à leur code source : c'est le hijacking pattern. Par principe (maintenance, copyrights) on ne modifie pas le code source d'une librairie, mais parfois on souhaiterait modifier son comportement voir en corriger des bugs. Vous pouvez ouvrir un ticket au développeur de la librairie (la correction/modification peut prendre du temps) ou mieux écrire un wrapper autour de la librairie (mais on y pense rarement au début). Il existe une 3^ème option qui tire parti de la versatilité parfois traître de JS : on sauvegarde la fonction originelle dans la classe ou l'objet instancié, et on la remplace par notre propre code en faisant référence si nécessaire à l'ancienne fonction. En exemple, l'auteur améliore le support de l'event mousemove de YUI.
• Sémantique : Google rappelle qu'il a introduit les rich snippets dans ses pages de résultat, qui se basent sur RDFa, les microformats ou les microdata. Ils fournissent un outil qui permet d'analyser une page en contenant, et qui montre comment le résultat peut apparaître : sur cette page Kelkoo qui contient des microformats, on voit par exemple la notation du produit automatiquement représentée. Chiffre intéressant : seuls 4% des sites ont implémenté les microformats. En d'autres termes, vous avez un avantage concurrentiel immédiat à prendre en rajoutant de la sémantique dans vos pages (vous pouvez vous aider de ce petit tuto)
• Perfs : script pour connaître les temps de chargement réels perçus par vos utilisateurs. Jusqu'ici, on utilisait au pire son poste en local, parfois des services en ligne qui testent votre site depuis des sites à l'étranger. Ce script est un tracker que vous pouvez inclure dans vos JS vous permettant de collecter certaines métriques des navigateurs de vos vrais utilisateurs. C'est à vous de déterminer les évènement importants : disponiblité de telle section plutôt que simple onload, temps des XHR... En prime il arrive à calculer le ping et la bande passante réelle après un peu de configuration. Cela demande à monter un script côté serveur pour récupérer les données.
• Accessibilité : service en ligne ou plugin Firefox permettant de tester l'accessibilité d'un site, de manière assez visuelle, avec indications positives et négatives. Je ne connais pas trop ce secteur mais ce plugin m'a l'air très complet : en connaissez vous d'autres ? (via @geekarlier)

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious.