Brain Cracking

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.

RPW 24/06/10: enrichissement progressif, HTML5 drop, métriques performance Web, sortie d'IE9

Revue de Presse Web de hier :

• CSS et bonnes pratiques : bel exemple d'enrichissement progressif : au détour d'un exemple sur l'utilisation du pseudo-élément :after, de sélecteur d'attribut (a[target="_blank"]) et de quelques propriétés CSS3 (border-radius), l'auteur démontre que dans certains cas il n'est pas besoin d'attendre que tous les navigateurs supportent la même chose pour utiliser une techno : IE6 et 7 n'affichent rien, et le rendu n'est clairement pas pixel-perfect pour les autres, mais la fonctionnalité est le plus souvent là. A négocier au cas par cas avec son designer bien sur, et cela demande un peu plus de travail, ne serait ce que pour visualiser le rendu sur chaque navigateur à chaque modif, mais bien maîtrisée cette pratique permet d'améliorer l'expérience de la majorité de vos utilisateurs.
• HTML5 drag&drop : exemple d'implémentation en production d'un drop de fichiers depuis le bureau, avec barre d'upload. Dispo depuis FF3.6 (voir la première démo Mozilla), leur implémentation utilisait dans une première version la FileAPI et l'event onprogress de XHR (en théorie compatible avec la prochaine version de Chrome donc). Etre précurseur a un prix et ils ont ainsi pu découvrir que charger des fichiers de plus de 25Mo n'était pas raisonnable. Ils vont donc utiliser une autre méthode recommandée par Mozilla (mais je n'arrive pas à savoir si elle est standard), qui les obligera à faire des modifications côté serveur, en attendant FF4 et FormData (et là non plus je ne sais pas quels browsers vont assurer ce standard). Leur métier principal est de charger des fichiers, on peut donc comprendre qu'ils modifient autant de code pour une minorité d'utilisateurs, d'autant qu'ils ont eu des retombées presse, mais je doute que beaucoup d'entre nous les suivent. Rappelons que la seule alternative actuelle pour faire du drop de fichier depuis le bureau dans un browser est ... les applets Java ou ActiveX
• JS : module YUI3 pour exécuter du code JS qui n'est pas encore là. Un peu sur le même principe que Facebook, un listener est posé sur toute la page, qui capture tous les évènements, les annule et les stocke. Lorsque le JS concerné arrive et que les listeners sont posés, tous les évènements sont joués, appelant ainsi les callbacks. L'avantage par rapport à FB, c'est que cette complexité est cachée par la librairie, il n'y a donc pas de modification majeure de code à faire. Par contre le fait d'annuler tous les clics d'une page par exemple, signifie que vous empêchez votre utilisateur de naviguer tant que le JS n'est pas là, comportement acceptable seulement sur de vraies applications Web (Gmail, FB, ...).
• Perfs : les principales métriques à surveiller pour évaluer l'impression de performance d'un site. La plus importante à mon sens est le délai avant la première apparition d'un bout du site. Si vous suivez déjà la directive "Flush early", vous faîte au moins apparaître le header de votre site le plus tôt possible alors que la page continue d'être calculée, ce qui demande déjà à ce que navigateur ait téléchargé CSS+JS du header. Ce qui est plus difficilement mesurable, c'est le délai avant l'apparition d'un morceau utile du site, ce qui varie selon la page : formulaire de login pour une homepage, corps d'article pour un journal / blog ... Les autres métriques sont plus classiques (temps total passé en DNS, poids total, temps d'attente ...) et sont mesurables par le logiciel Dynatrace AJAX Edition. Si vous le couplez avec Selenium, vous serez en mesure d'avoir un historique de ces métriques et de les vérifier à chaque montée de version.
• Browser War : sortie de la preview 3 d'IE9. Support surprise de Canvas, ainsi que <video> et <audio>, des polices WOFF le tout boosté par l'accélération matérielle (ils n'ont pas la problèmatique de Mozilla d'être cross-platform). Les démos sont effectivement impressionnantes de fluidité sur des machines qui ont une carte graphique valable (sur mes machines virtuelles, on ne voit pas la différence avec FF). EcmaScript 5 a l'air complètement supporté, le DOM est plus conforme (mais pas encore assez selon la 2nde partie de ce post), CSS2.1 est complètement supporté, CSS3 arrive doucement, ainsi que WebTiming (mesures véritables des perfs JS/rendering) arrive aussi. Continuez à tester votre site avec IE9 pour signaler des bugs : ils m'en ont fixé un, mais la nouvelle version m'en a apporté 2 autres ... C'est pénible à faire, mais ça sera pire si la version finale sort avec ces bugs sur votre site :)
• Browser War : les ventes de Seven se portent bien, merci pour eux, mais pour les webdevs ça signifie surtout une diminution directe du nombre d'IE6 qui vont passer directement à IE8, surtout que ce sont les réseaux d'entreprise qui commencent à s'y mettre, principaux fournisseurs d'IE6 en Europe / US.

Articles et liens partagés via RSS, Twitter, identi.ca ou Delicious

RPW 23/06/10: évènement performances Web à Paris, localStorage sur tous les navigateurs, drag&drop sur un touchscreen, site d'autoformation à HTML5

Revue de Presse Web de hier :

• Evénement : soirée performances Web à Paris le mercredi 21 juillet. C'est gratuit et il y aura un orateur fameux (Stoyan Stefanov) qui fera une présentation formelle (en anglais). Ensuite, ça sera entre le BarCamp et les mini-conférences, le but avoué étant d'essayer de faire participer les gens. Et votre serviteur se lance et s'essaiera à une mini conférence-discussion de 20mn sur les techniques d'inclusion de JS just-in-time, sujet qui me travaille en ce moment et qui peut aller de la simple inclusion en bas de page à un système plus élaboré façon Facebook. Organisé par Eric Daspet, déjà co-responsable des premiers Paris Web.
• localStorage : petite librairie d'accès au stockage sur le navigateur, du nom de jstorage. Elle permet d'uniformiser l'accès au stockage clé/valeur côté navigateur, ce qui peut vous permettre d'afficher très rapidement une grosse quantité d'info à un utilisateur, si celui ci est déjà venu. Sa principale limite est que sur IE6/7, on n'a droit qu'à 128k d'espace, et que l'auteur n'a pas prévu de remonter une erreur si l'on remplit l'espace alloué, ce qui permettrait au webdev de vider le cache par exemple. Cette solution est de toute façon à encapsuler dans votre une classe JS pour rajouter votre propre logique (invalider les données lors d'une montée de version de votre appli par exemple, pour éviter les bugs) et surtout pour pouvoir changer facilement : je pense que beaucoup de petites librairies comme cela vont sortir jusqu'à ce qu'il y en ait une qui soit vraiment meilleure que les autres. Pour ma part, je reste sur celle, plus mature de YUI2 qui utilise Flash en fallback IE6/7. Flash ne donne que 100k d'espace, mais au moins vous pouvez demander à l'utilisateur d'en accorder beaucoup plus. (via @gilles_66)
• CSS : cela fait 10 ans qu'on parle des variables dans CSS2, qui devraient permettre à un intégrateur de modifier un seul endroit par exemple pour des jeux de couleurs. J'ai appris qu'il y avait en fait 3 propositions différentes de specs... Autant dire que ça n'est pas prêt d'arriver. Sinon il reste les solutions server-side qui consistent à générer vos CSS, et qui incluent du coup des variables : la solution la plus connue est SASS. (via @stubbornella)
• Drag&Drop : librairie de gestion du drag&drop d'éléments DOM. Nommée dragdealer, celle ci a l'avantage sur ses nombreux concurrent d'être compatible de manière transparente avec les touchscreens style iDevices et de gérer les transitions douces, façon iOS. (via Ajaxian)
• HTML5 vs native : argument pour alimenter le débat applications HTML5 vs applications natives, trouvé dans cette interview d'un développeur iPhone. Les application Web ne requièrent pas d'installation, et dans son cas (version d'essai d'un jeu), cela s'est traduit par 10 fois plus de joueurs sur la version HTML que pour la version application native, qui requiert de passer par l'appstore.
• HTML5 : nouvelle ressource d'auto-formation à HTML5 (au sens large), édité par Google. Pas mal de contenu intéressant dans les tutos avec beaucoup d'auteurs différents dont certains connus (comme Paul Irish), il y a également un grand slide résumant les nouveautés HTML5/CSS3 et de quoi tester chaque feature HTML5 indépendamment. Dommage qu'il n'y ait pas de RSS ...
• CSS : bug IE à connaître pour certains cas extrêmes : tous les IE y compris la dernière preview du 9 sont limités à 31 feuilles de style par page. Au delà elles sont ignorées. Plus grave en ces temps où l'on commence à concaténer ses CSS, IE limite le nombre de règles par fichier CSS à 4095. Si vous avez la patience de vous enregistrer chez MS, vous pouvez augmenter l'importance de ces bugs en allant voter sur ces tickets : ici et là. Cela dit, on est dans l'extrême : mon Chrome plante la page de démo des 4095+ règles !

Articles et liens partagés via RSS, Twitter, identi.ca ou Delicious

RPW 22/06/10: démos HTML5 Web Socket et Web Workers, font répandues, HTML5 microdata, dégradé CSS3 et IE

Revue de Presse Web de hier :

• Web Socket : Démo de Web Socket (connection TCP bidirectionnelle permanente à un serveur) montrant une lecture synchronisée de vidéo entre plusieurs clients. Ca change un peu du classique exemple de chat qu'on associe toujours à Web Socket. La techno utilisée côté serveur est une librairie utilisant Node.js, côté client il utilise directement l'API native du browser, ce qui fait que cette démo ne marche que pour les Webkit. Le code est extrêment simple, ce qui confirme mon opinion sur HTML5 : accéder aux features est facile (pour les autres navigateurs on pourrait utiliser une librairie Flash), construire une vraie appli Web autour de Web Socket est autrement plus compliqué, en particulier côté serveur.
• Web Workers : Démo de Web Workers (exécution de JS dans un thread séparé du browser, idéalement sur un second CPU). Seul le dernier FF est supporté (les webkits ayant implémenté une ancienne version de la spec) et j'ai pu d'ailleurs apprendre que la spec avait évolué et supporte maintenant le passage d'autre choses que des String entre les threads JS. Ici l'auteur anime beaucoup d'objets dans la fenêtre principale, et fait de gros calculs de positions dans un thread séparé, illustrant parfaitement la raison d'être de cette feature : je vois l'utilisation CPU de FF monter à plus de 110% (dual core Mac Book Pro) sans perte de fluidité. J'aurais bien aimé voir la différence sans Web Workers. A signaler que l'auteur utilise très intelligemment JS pour faire communiquer ses 2 threads avec seulement des tableaux et des chaînes de caractères.
• Perfs : les sites Web ne sont pas les seuls à galérer pour donner l'impression de rapidité et de fluidité, Mozilla a conduit une étude sur son propre browser, en le comparant avec Chrome. La particularité de l'étude est qu'elle s'est concentrée sur la perception de lenteur, et non sur la performance pure. En conséquence les recommandations (spinner + petit, modification affichage de la fenêtre ...) pourraient faire sourire si l'on n'essayait pas nous Webdevs de faire la même chose sur nos sites : afficher le contenu principal le plus rapidement possible et le reste après (JS, images, pubs, widgets ...), lancer de courtes animations pendant les XHR, pré-chargement ... (via Ajaxian.com)
• Fonts : feuille résumant les fonts les plus répandues et leur font-stack (chiffres probablement obtenus grâce au service FontStack), et leur rendu sous 2 configurations (alors qu'il en existe 4 selon le type de font). Arial for Life. (via @guerrier)
• Sémantique : tutoriel sur HTML5 Microdata, dont le concurrent le plus direct est Microformat. Ce tuto est bien fait car il montre des exemples concrets de sémantique, reconnu et utilisé par Google (et pour cause, ce sont les principaux contributeurs à la définition du vocabulaire). Sont pris comme exemples Person, Product and Review et Events. Comme pour Microformat, je ne connais pas d'autre robot que Google ou Yahoo! qui exploitent cette sémantique, hormis quelques plugins FF très peu utilisé du grand public. Il n'empêche que du point de vue SEO, l'intérêt est immédiat pour enrichir ses résultats Google, voir remonter dans les classements car les infos importantes sont mieux cernées. (via @formeolibre)
• Outils : encore un autre générateur de propriété CSS3, cette fois les dégradés. Si je le signale malgré tout, c'est que celui-ci est allé plus loin en proposant la compatibilité avec Opéra et IE en fournissant le dégradé sous forme d'image de background ou en utilisant le filtre IE équivalent, qui marche depuis IE6, mais dont le principal défaut est de ne pas supporter les color-stop.

Articles et liens partagés via RSS, Twitter, identi.ca ou Delicious

RPW 21/06/10: performances des data: uri, CSS2 position, players video HTML5, automatiser les tests de performance,

Revue de Presse Web de hier :

• Perfs : solution de contournement des gros problèmes de l'utilisation de data:uri dans le CSS. Pour rappel la méthode consiste à encoder ses images en base64 à l'intérieur du fichier CSS et donc de gagner en perfs sur les requêtes HTTP (accrochez vous : Plus de détails ici). Cette technique a 2 problèmes notoires :
  • une image référencée plusieurs fois est encodée à plusieurs endroits (browsers hors IE) donc le poids total CSS + images devenait plus important qu'avant.
  • le poids total du CSS augmentant, le téléchargement prend donc plus de temps, bloquant l'affichage de la page pendant plus longtemps
  La solution ici passe par la génération d'un fichier CSS à part qui ne contiendrait que les règles CSS référençant des images. On inclue ensuite ce CSS en bas de page ou via JS, on a ainsi tous les bénéfices de la technique standard (CSS léger, affichage rapide du HTML) et de data:uri (très peu de requêtes HTTP). Et on peut même se passer des sprites qui sont gérés à la main. Il reste encore un défaut majeur : on télécharge des images même si elles ne sont pas utilisées sur la page. Et tout cela demande à mettre en place un process de génération des CSS en béton, la partie la plus difficile étant le parsing des CSS originales pour retrouver les règles référençant les images. (via @edasfr)
• CSS : retour aux basiques : explications théoriques sur la propriété position. Bon petit rappel, mais j'aurais bien aimé y voir des fixs de certains comportements IE, comme être obligé de mettre une div en position:relative, autour d'un élément en position:absolute pour fixer certains problèmes de positionnement.
• Vidéo : listing de players HTML5, le plus souvent avec fallback Flash. On aurait préféré un tableau comparatif, notamment pour savoir quel est le player flash utilisé lorsqu'il y a fallback, les possibilités de personnalisation CSS et d'interaction JS, ou le support du fullscreen VS full view port. Mais cela fait déjà une bonne base pour vous lancer vous même dans une telle étude (faites tourner vos liens si vous en connaissez une) (via @guerrier)
• Perfs : pour tester les performances de votre site de manière régulière et automatisée, voici un tutorial utilisant Dynatrace AJAX Edition (test de perfs sous IE) et Selenium (tests automatisés et scriptables d'interface). Côté serveur les 2 demandent une installation de java pour enregistrer et visionner les résultats et l'auteur ne précise pas si l'on peut tester autre chose que des sites Java (à priori oui). En tout cas l'utilisation conjointe des 2 vous permet de surveiller régulièrement votre site ou même tous les sites de vos clients, et avec un peu de scripting de vous alerter en cas de problème.
• Forms : démo rapide et en vidéo de l'utilité des nouveaux types de champs HTML5 et de certaines propriétés comme placeholder et autofocus. On y voit l'utilisation qu'en font le peu de browsers qui se sont lancé dans l'implémentation (iDevices, Webkit, Opéra ... les autres arrivent). Rappellons que vous pouvez passer dès aujourd'hui et sans dommage aux nouveaux types de champs (email, url, date ...). Pour les propriétés de type comportementale (placeholder, autofocus, validation), ça ne coûte pas cher de les introduire en espérant qu'une librairie JS s'occupe un jour de les supporter.

Articles et liens partagés via RSS, Twitter, identi.ca ou Delicious

RPW 20/06/10: outils pour WebM, tester ses performances, hack mobile webkit, autocompletion façon T9, les performances mesurées par google

Revue de Presse Web de ce week-end :

• Vidéo : petite collection d'outils pour éditer des vidéos au format WebM, pour ceux qui voudraient au moins tester ce format. Rappelons que d'après le seul vrai comparatif que je connaisse, VP8 a l'air de moindre qualité que h.264 (mais est ce visible pour l'utilisateur ?), donc connaître ces outils vous permettront de tester par vous même. (via @formeolibre)
• Librairie : petit script en JS pour faire un peu de saisie intuitive, mot à mot (comme le T9 des mobiles). Ca manque de documentation, mais je n'ai pas l'impression que ça supporte d'aller chercher de manière asynchrone les données. Mais le plus dur est fait, c'est à dire l'UI, vous pouvez toujours l'étendre.
• Perfs : outil très intéressant (présentation en vidéo) car très complet : il permet de tester les performances d'un site, de plusieurs endroits dans le monde, et d'afficher les mêmes infos que Firebug, ySlow ou PageSpeed, mais pour IE (comme dynatrace et webpagetest.org). Il permet  en plus d'enregistrer une série d'actions (façon Sélénium), et de faire jouer ces actions depuis plusieurs endroits dans le monde. Bref un outil à considérer si vous êtes sous windows
• Perfs : que mesure Google ? en lisant entre les lignes, l'auteur de ce billet en est arrivé aux conclusions suivantes :
  • toutes les ressources (HTML + CSS + JS + images) comptent dans le temps de chargement
  • les mesures sont effectuées automatiquement par de vrais utilisateurs, grâce à la google toolbar
• iDevices : hack JS + CSS pour donner à certains éléments d'interface (des boutons d'action par exemple) toujours la même taille quel que soit le niveau de zoom du visiteur. Si l'on enlève la détection un peu hasardeuse de l'iPhone, la technique pourrait même marcher sur tous les webkits mobile (ce qui inclut Android et quelques concurrents). J'en profite pour rajouter cette astuce à ma collection de liens iDevices.

Articles et liens partagés via RSS, Twitter, identi.ca ou Delicious

RPW 18/06/10: Accessibilité et rôles ARIA, HTML5 vs progressive enhancement, gestion d'équipe, Chrome incluera un lecteur PDF

Revue de Presse Web vendredi dernier :

• Méthode de travail : une technique de division du travail : avoir 2 équipes séparées, l'une sur le travail de fond (longs développements) et l'autre sur ce qui peut et doit être fait rapidement : bug fixing et petites améliorations. Le fait est que lorsqu'un projet grossit, des développements qui auraient pris quelques jours au tout début mettent beaucoup plus de temps à sortir : test de qualité plus poussés, effets de bord, complexité du code, communication dans une équipe grossissante, niveau de priorité par rapport à la roadmap globale ... Bref votre client (interne ou externe) a l'impression que tout est devenu plus lent. Et les développeurs accumulent les frustrations car ils ont beau travaillé toute la journée, de l'extérieur ils sentent bien qu'ils donnent l'impression d'être lents. L'idée d'avoir une partie de l'équipe dédiée aux petits devs me semble bonne car elle donne l'impression de réactivité, ce qui met moins de pression sur l'équipe, et permet de sortir plus rapidement des fixs de bug, sans perturber la roadmap globale. Reste à veiller à ce que ça ne soit pas toujours les mêmes qui s'y collent. (via @nicolas_leroy)
• HTML5 : post d'opinion, où l'auteur voit une opposition entre les techniques de "progressive enhancement" et les applications Web, notamment offline. En gros, même dans des applications Web un peu avancées (sans aller jusqu'à Gmail), on se base toujours sur le server-side pour les tâche de rendering, que l'on a pas envie de re-coder en JS. Hors l'auteur fait remarquer que si l'on pense offline, on est obligé de coder tout cela en JS, dès lors pourquoi coder le rendering server-side ? De fait, sans même aller jusqu'à l'offline, c'est un choix technique que j'ai du faire pour certaines parties de mes projets (un gestionnaire de fichiers, recherche billets d'avion...), l'affichage des objets représentant beaucoup trop de variations possibles pour s'offrir de coder 2 fois la même chose. Notez que cela n'enlève rien à la sémantique et l'accessibilité du markup final et que les données pures sont elles toujours accessibles via des APIs. Ajaxian termine en disant qu'il est temps de se lâcher un peu dans ces cas là si l'on veut espérer être compétitif avec les applications natives, ce à quoi je rajouterais ma propre conclusion : l'accès aux APIs HTML5, même sur d'anciens navigateurs via des fallbacks, est facile, développer une application Web "HTML5" est autrement plus compliqué car c'est un changement d'architecture plus que de technique.
• Fonts : tuto sur un script permettant d'avoir n'importe quelle font sur son site, la technique consistant à générer server-side des images... Cela reste moins pire que les solutions basées sur Flash qui peuvent mettre un PC sur les genoux (incluez 20 bouts de flash sur une page et vous comprendrez), et je suis positivement étonné que les retours à la ligne soient gérés. L'accessibilité est certes gérée, et le scripts est suffisamment intelligent pour afficher le texte tant que l'image n'est pas là. En échange vous sacrifiez certains principes de coding (class="nom_de_la_police") et probablement de la performance : côté serveur, on peut mettre du cache, mais côté client on fait pas mal de requêtes DOM coûteuses (getElementByClassName n'est pas natif sur la majorité du marché des navigateurs) et pas mal de requêtes HTTP (non bloquantes) pour aller chercher les images. En somme c'est une alternative plus facile que les techniques actuelles utilisant @font-face, mais je vous conseille plutôt de négocier de ne pas mettre de police custom du tout :)
• Browser War : le prochain Chrome incluera un lecteur de PDF (via @alsacreations)
• Accessibilité : 2 bons articles sur l'utilisation d'ARIA et son implémentation. Après un petit rappel sur pourquoi est ce que les webdevs devraient se préoccuper d'accessibilité, vous pouvez directement aller à la section consacrée à l'explication des rôles ARIA et la comparaison avec les nouvelles balises HTML5. Le second article est intéressant car c'est le premier que je vois qui montre l'implémentation d'un screen reader des rôles ARIA (via @formeolibre)

Articles et liens partagés via RSS, Twitter, identi.ca ou Delicious

RPW 17/06/10: présentations en HTML, service gratuit de test de design

Revue de Presse Web de hier :

• Outils : une librairie pour faire des présentations en HTML, façon powerpoint. Proposé par le W3C lui même, il devrait permettre aux développeurs de faire des présentation techniques. Il m'a l'air assez complet, et est extensible, si l'on veut par exemple y rajouter des transitions. Les technos Web prennent ici tout leur sens : les éditeurs existants (powerpoint, open office, keynote) pourraient très bien exporter des présentations simples en HTML, les slides sont lisibles partout y compris sur mobile et n'importe quel type de contenu est insérable (vidéo, son, images). (via @formeolibre)
• Utilisabilité : un service web pour faire tester ses designs par de vraies personnes. Le service lui même est très bien fait et vous permet de poser une question à l'utilisateur, ou le mettre dans le contexte, de définir des zones cliquables sur votre screenshot / wireframe qui sont considérées comme positives, et même d'enchaîner plusieurs screenshots pour simuler une navigation. Ensuite vous attendez que d'autres utilisateurs du service tombent sur votre design pour avoir des stats sur le taux de réussite, d'abandon, le temps, etc... Evidemment c'est biaisé car la population est plutôt professionnelle, un screenshot n'est pas un site dynamique etc... C'est un peu l'outil du pauvre et ça ne vaudra jamais de vrais tests utilisateurs, mais il permet de se faire une idée rapide de la bonne lisibilité de vos Call To Action comme on dit. Et quand on teste les designs des autres, on se rend vite compte que c'est un vrai métier :) (via @okeul)

Articles et liens partagés via RSS, Twitter, identi.ca ou Delicious