Alsacreations.com - Actualités - Archives (février 2012)

Dans la grande lignée des tests Acid ou de HTML5test, il y a désormais le CSS3 test, qui permet de donner une idée du support des propriétés de CSS3.

Les résultats annoncés pour les principaux navigateurs sont les suivants, mais peuvent varier selon les configurations. Ils sont donc à prendre avec des pincettes :

• Chrome Canary, WebKit nightlies, Firefox Nightly : 64%
• Chrome, IE10PP4 : 63%
• Firefox 10 : 61%
• Safari 5.1, iOS5 Safari : 60%
• Opera 11.60 : 56%
• IE9 : 39%

Note : seules les propriétés reconnues par les navigateurs sont testées, cela n'implique pas qu'elles soient correctement implémentées. Seules les propriétés reconnues par le W3C sont testées, pas les propriétaires.

Chronophage, redondant et fastidieux... Coder vos formulaires à la main vous prend du temps, vous préféreriez prendre du repos, au soleil, un verre de jus de kiwi à la main ? Intégrez-les rapidement grâçe à cet outil en-ligne, exportez-les et sauvegardez-les.

Outil de Lea Verou très utile pour paramétrer les Transitions CSS. Un graphique permet de déformer la courbe d'accélération à la souris et de générer le code correspondant.

L'un des nombreux générateurs de propriétés CSS3 en ligne, qui regroupe plusieurs techniques pour s'en faciliter l'appropriation et l'écriture, tout en ayant l'aperçu en direct des réglages proposés.

Au choix : border-radius, box-shadow, text-shadow, RGBA, @font-face, multiple columns, box resize, box sizing, outline, transitions, transforms.

Daniel Glazman, coprésident du CSS Working Group (groupe de travail sur CSS du W3C), a écrit un appel à action important: THE OPEN WEB NEEDS YOU *NOW*. C’est une lecture fortement recommandée pour tous les développeurs et designers web. Voici un résumé une paraphrase en français du problème exposé, et quelques préconisations que vous trouverez peut-être utiles.

Ne pas refaire l’erreur d’IE6

Si vous avez un peu suivi l’histoire du Web, vous savez que les situations de monopole ne sont pas bénéfiques pour les standards: l’éditeur de navigateur qui a le monopole ou quasi-monopole peut être tenté de proposer des fonctionnalités sans les proposer comme standards, les créateurs de sites web utilisent du code non-standard qui ne fonctionne que sur le navigateur qui a le monopole, et les éditeurs minoritaires sont tentés d’imiter les comportements non standard du navigateur minoritaire. Un jeu très dangereux pour l’efficacité des standards, qui mène à renforcer les monopoles, diminuer la concurrence et donc l’innovation sur le Web. La stagnation du Web quand Microsoft a arrêté le développement d’Internet Explorer après IE6 et pendant plusieurs années en est une preuve suffisante.

Aujourd’hui, nous sommes devant un nouveau monopole: celui du moteur de rendu WebKit sur les plateformes mobiles (smartphones, tablettes) et au-delà (le nouveau navigateur embarqué de la PlayStation 3 utilise WebKit). Dans les faits, Opera Mini et Opera Mobile restent des concurrents non négligeables sur mobile, mais il est certain que WebKit détient un monopole d’attention chez les créateurs de sites web: nous avons tous commencé à nous intéresser au développement de sites mobiles avec l’arrivée de l’iPhone ou dans les années suivantes avec le succès de l’iPhone et en parallèle celui d’Android.

Pour beaucoup, le Web mobile c’est WebKit et puis c’est tout

C’est une vision à court terme particulièrement dangereuse. Certes, personne ne peut jurer que Windows Phone ne fera pas un flop, que Firefox et Opera arriveront à s’implanter fermement comme navigateurs alternatifs sur Android et d’autres plateformes, ou que de nouvelles plateformes pour mobiles ou tablettes viendront changer un peu la donne. Mais en 2002 beaucoup pensaient que la partie était finie, qu’Internet Explorer avait gagné la guerre et qu’on arrivait à une période de stabilité. En réalité on a eu droit à une période de stagnation (arrêt du développement d’Internet Explorer, entrainant un retard que Microsoft rattrappe à peine) et une redistribution des cartes quelques années plus tard notamment grâce à Firefox. De nombreuses entreprises se mordent encore les doigts d’avoir fait développer des logiciels de gestion dont les interfaces sont compatibles uniquement avec IE6.

En pratique, le problème c’est quoi?

Il y a deux erreurs qui sont commises régulièrement par les développeurs web, et pas uniquement les moins informés:

• Utilisation du browser sniffing (détection du navigateur via la chaine User-Agent ou d’autres informations) pour réserver une fonctionnalité aux navigateurs WebKit ou à l’iPhone, voire carrément un blocage de l’accès au site mobile pour les navigateurs non-WebKit.
• Utilisation de propriétés CSS expérimentales avec préfixe -webkit-*, sans doubler ces propriétés par les syntaxes équivalentes pour les autres navigateurs et sans se soucier de la compatibilité.

Ces problèmes sont déjà courants sur des sites destinés à tous les supports (sites développés avec les techniques désormais nommées Responsive Design). Ils sont extrêmement courants sur les sites dédiés aux périphériques mobiles.

Aujourd’hui, les éditeurs de navigateurs minoritaires veulent 1) se faire passer pour des navigateurs WebKit ou pour Safari Mobile en envoyant une chaine User-Agent frelatée (une technique vieille comme le monde, les premières versions d’Internet Explorer le faisaient déjà pour se faire passer pour Netscape!) et 2) lire certaines propriétés CSS  -webkit-*. Le but est d’être compatible avec les sites mobiles qui, pour beaucoup, les mettent à la porte parce que vous comprenez ce soir c’est pas possible c’est une soirée privée WebKit.

Si Mozilla, Opera et Microsoft se prêtent à ce jeu, on risque une spirale infernale bien connue: des fonctionnalités non-standard (jamais proposées comme standards à l’instar de -webkit-text-size-adjust, ou expérimentales et amenées à changer comme feu -webkit-gradient() proposé en 2008 et remplacé par une nouvelle syntaxe avec déjà deux itérations…) commencent à être reconnues par plusieurs navigateurs, deviennent des standards de fait sans que la communauté des éditeurs de navigateurs et des utilisateurs (nous!) ait l’occasion de soulever des problèmes et de proposer des solutions. Quand on veut les améliorer c’est déjà trop tard, la solution plus ou moins bancale est en place et la très grande majorité des développeurs web l’utilise sans sourciller (éventuellement en pestant parce que c’est pas terrible ou limité, mais tant pis).

Alors oui, arriver à un bon standard ça prend du temps, malheureusement ça prend parfois quelques années, et il y a sans doute des choses qui peuvent être améliorées pour arriver à des résultats un peu plus rapides. Mais si en quelques mois une nouvelle proposition expérimentale dans WebKit devient un standard de fait (plutôt qu’un vrai standard communautaire), on risque d’utiliser dans cinq, dix et vingt ans des fonctionnalités mal finies et être condamnés à s’en contenter. Gros problème de qualité en perspective! Vous vous imaginez utiliser aujourd’hui, dans tous les navigateurs, les filtres DirectX d’IE5-6 à la place des effets CSS3 modernes? Moi si on en arrive à ça je pars élever des chèvres dans le Larzac ou alors je m’en fous et je fais du Flash.

Bon, qu’est-ce qu’on peut faire?

Pour éviter que les éditeurs de navigateurs ne cassent les standards du Web, c’est à nous de faire attention à éviter la monoculture WebKit (et à l’avenir tout problème similaire). Il y a deux choses à faire:

1. Faire passer le message! N’hésitez pas à faire tourner cet article. Vous pouvez même le copier-coller et mettre votre nom à la place du mien, rien à fiche, faites juste tourner. :)

2. Dans votre propre travail, pensez à la compatibilité avec tous les navigateurs (au moins les versions récentes, pour le support des anciennes versions c’est un autre débat). Je donne quelques conseils ci-dessous, mais vous aurez peut-être plus efficace ou pertinent à proposer en commentaire, alors partagez vos méthodologies et vos idées.

Un peu de méthode

• Commencez par créer une base fonctionnelle solide avec des fonctionnalités HTML, CSS et JavaScript éprouvées par le temps. Faites simple.

• Dans le même ordre d’idée, exploitez à fond les fonctionnalités déjà stables: HTML 4 et CSS 2.1 bien sûr, mais aussi les parties de HTML5 et CSS3 qui sont stables et implémentées sans préfixe dans au moins une partie des navigateurs.

  Pour savoir si une fonctionnalité est stable ou non, le site When Can I Use… (caniuse.com) est une mine d’informations. Si une fonctionnalité n’est pas implémentée par la moitié des navigateurs, évitez-la. Si elle est largement implémentée mais que tous les navigateurs requièrent l’utilisation d’un préfixe, gardez à l’esprit que la fonctionnalité n’est sans doute pas stable et pourrait changer radicalement ou même être abandonnée! Enfin, si les navigateurs commencent à proposer la fonctionnalité sans préfixe, elle est probablement stabilisée.

• Lorsque vous avez décidé d’utiliser une fonctionnalité expérimentale, utilisez au maximum les préfixes des différents moteurs de rendu, et terminez par une version sans préfixe. Ce n’est pas une solution miracle, en partie parce que c’est vraiment pénible et en partie parce qu’il est toujours possible que la syntaxe de la propriété CSS évolue (on a bien dit que c’était expérimental hein), mais tant pis, il faut se retrousser les manches et faire sa part du boulot.

• Si vous pouvez l’éviter, ne faites pas reposer l’accès aux contenus ou aux fonctionnalités de base sur le support par le navigateur de certaines fonctionnalités expérimentales. Si votre mise en page est nickel dans IE10 avec CSS Grid Layout, mais complètement illisible dans tous les autres navigateurs, vous avez un problème. De même si la mise en page de votre application web mobile repose sur l’implémentation de CSS Flex Box dans WebKit, sachez que Flex Box a été réécrit depuis cette première implémentation, que la nouvelle syntaxe est plutôt différente, et qu’il est possible que votre interface web mobile soit cassée dans d’autres navigateurs… ou même dans de futures versions de WebKit! Par définition, une fonctionnalité expérimentale peut vous exploser à la figure, et les utiliser sur des sites dont vous n’assurez pas la maintenance au quotidien est sans doute une erreur.

À vous maintenant: Quelles méthodes utilisez-vous? Que pouvez-vous améliorer dans vos pratiques? Comment pouvez-vous faire passer le message?

Une version officielle de Google Chrome pour Android a été publiée. La plate-forme mobile était déjà équipée du "Navigateur" Android par défaut avec un moteur WebKit, ainsi que des applications Opera Mobile, Opera Mini et Firefox. Désormais, Google compte mettre un coup d'accélérateur pour promouvoir son navigateur phare, au-delà du simple moteur de rendu WebKit, et donc indirectement ses applications et services. Après avoir lancé des campagnes de publicité à la télévision, on comprend que Google est motivé par la possibilité d'avoir à disposition un public équipé des dernières fonctionnalités (notamment HTML5) pour proposer des services de plus en plus complets (et addictifs).

Pour le moment, Chrome n'est disponible que pour la version 4.0 de l'OS (Ice Cream Sandwich), celle qui équipe les dernières tablettes et certains smartphones récents, notamment le Galaxy Nexus avec lequel les captures d'écran ci-dessous ont été prises.

Une vidéo de présentation a été conçue pour l'occasion.

L'interface de navigation diffère quelque peu de ce que l'on avait l'habitude de rencontrer avec Android, et fait la part belle à la synchronisation : un compte Google et le tour est joué, les favoris sont synchronisés. L'accent a été mis sur la performance ainsi que la simplicité.

Les onglets peuvent être repris en l'état depuis la version desktop (Windows/Linux/Mac OS X) du navigateur pour continuer une session de navigation, ou bien dans le sens inverse être envoyés vers le mobile avec l'extension Chrome to Mobile.

Pour les développeurs

Du côté des fonctionnalités prises en charges, on retrouve la navigation privée, le support de l'orientation et tout une panoplie d'API gravitant autour de HTML5 :

• Canvas avec accélération matérielle (y compris requestAnimationFrame)
• Défilement des éléments en overflow et prise en compte du positionnement fixe
• La video HTML5
• Indexed DB
• Web Workers
• Web Sockets
• Media Capture
• Les types date/datetime pour <input>
• Application Cache et AppCache API
• localStorage/sessionStorage
• Géolocalisation
• WebSQL
• File API (dont FileList, FileReader, Blob)

La fonctionnalité de débogage à distance Remote Debugging permet de prendre le contrôle du développement du mobile avec un ordinateur de bureau.

Vous permet de générer un template HTML5 basé sur HTML5 Boilerplate. Il peut comprendre également Modernizr, jQuery, et Bootstrap, et des instructions de configuration pour plusieurs serveurs web afin d'adapter au mieux les en-têtes HTTP véhiculées. L'ensemble correspond à une arborescence de fichiers classés (HTML, CSS, JavaScript, etc) et préparés pour exploiter au mieux toutes les astuces courantes : Chrome Frame, LESS, Analytics, classes pour Internet Explorer, icônes, robots.txt, et ainsi de suite.

Modernizr est une bibliothèque JavaScript conçue pour détecter des fonctionnalités spécifiques de HTML et CSS dans les navigateurs. Puisqu'il est inutile d'embarquer un fichier complet de détection dans tous les sites web, un script sur mesure peut être construit en piochant parmi les fonctionnalités détectables. Il sera par exemple possible de savoir si le navigateur supporte les transformations CSS 3D, la vidéo HTML5, Canvas ou SVG, et de prévoir une alternative le cas échéant.

Son usage est très simple, il suffit de copier-coller les quelques lignes générées dans le code source de la page, ou bien dans un fichier externe, puis d'exploiter l'objet Modernizr et ses propriétés (par exemple Modernizr.canvas, Modernizr.fontface, Modernizr.geolocation etc), initialisées aux valeurs booléennes true ou false. La méthode Modernizr.load vise aussi à faciliter le chargement de scripts tiers. Enfin, la bibliothèque embarque une déclaration des éléments HTML5 pour les anciennes versions d'Internet Explorer afin de permettre l'emploi de styles sur ces derniers.

Attention : il ne s'agit pas de moderniser les navigateurs mais uniquement de procéder à une détection, pour éventuellement utiliser d'autres scripts en complément, apportant des fonctionnalités non supportées.

Ce script ajoute des préfixes avant les propriétés CSS de façon automatique, pour les navigateurs n'implémentant pas encore celles-ci officiellement. Vous aimez le goût du risque ? Utilisez -prefix-free et facilitez-vous la vie.

Flux (rss): http://www.alsacreations.com/rss/actualites.xml