Présentation

Un beau jour de mars 2002, un message anodin sur un forum parle d'un projet de site offrant à la fois un regard expert sur le web et des exemples concrets d'utilisation des normes du W3C. Un noyau dur se rassemble autour de cette idée, souhaitant combler par-là le manque cruel d'une telle réalisation en français. Aujourd'hui, ce projet est réalisé. Présentation complète.

Blogs

Dernières brèves

Appel à l’action : le web ouvert à besoin de vous maintenant

le 09/02/2012.

Le CSS Working Group, le W3C, les fabricants de navigateur et le Web ouvert en général ont besoin de vous… Très sérieusement, ils ont besoin de vous TOUS. Cet article a été à l’origine rédigé par Daniel Glazman, co-chairman du CSS Working Group au W3C (World Wide Web Consortium).

La première partie de cet article est également issue d’une discussion officielle du CSS Working Group qui a fait l’objet d’un consensus au sein du groupe. Les membres du groupe derrière cette décision incluent Adobe, Apple, Disruptive Innovations, Google, HP, Microsoft, Mozilla, Opera et le World Wide Web Consortium (W3C). La seconde partie de cette article (après « Cela ne doit pas arriver ») reflète uniquement l’avis de Daniel Glazman.

Il n’y a pas si longtemps, IE 6 était le navigateur dominant sur Internet. Techniquement parlant, le Web était plein de sites « optimisés-pour-IE6 ». Pour ce qui était des autres navigateurs… leurs utilisateurs n’avaient que leurs beaux yeux pour pleurer. IE 6 est mort à présent, cette époque est révolue, et tous les fabricants de navigateurs, y compris Microsoft, sont revenus dans le giron de la standardisation. Définitivement révolue, cette époque ? Pas vraiment… IE 6 a disparu, mais le problème est de retour.

WebKit, le moteur de rendu au cœur de Safari et de Chrome, installé dans les iPhones, iPads et les périphériques Android, est maintenant le navigateur ultra-dominant dans le Web mobile et techniquement, le Web mobile comporte de nombreux sites ne-fonctionnant-qu’avec-WebKit... Du coup, les autres navigateurs et leurs utilisateurs n’ont à nouveau que leurs yeux pour pleurer. De nombreux sites détectent l’Agent Utilisateur des navigateurs et filtrent les navigateurs non-WebKit. Tout comme par le passé avec IE 6, ce n’est pas une question d’innovation mais de monopole du marché par le matériel et les logiciels fournis avec celui-ci. Il y a cependant un aspect du problème que nous n’avions pas lors de l’ère IE 6 : ces sites Web sont également spécifiques à WebKit parce qu’ils utilisent des propriétés CSS expérimentales exclusivement préfixées par -webkit-* et sans utiliser leurs équivalents Mozilla, Microsoft ou Opera. Ainsi, même sans aucune détection du navigateur, ces sites Web apparaitront toujours cassés aux navigateurs ne reposant pas sur WebKit…

Dans beaucoup, voire dans la plupart des cas, les propriétés -webkit-* que ces sites spécifiques utilisent ont des équivalents -moz-*, -ms-* ou -o-*. Les dégradés, les transformations, les transitions, les animations, les coins arrondis sont tous et toutes suffisamment interopérables pour de pas dépendre du navigateur. Les créateurs de sites Web n’ont besoin que de quelques minutes pour rendre leurs sites compatibles avec Mozilla, Microsoft ou Opéra. Mais ils ne l’ont jamais fait.

Sans votre aide, sans une réaction forte, il n’y aura qu’une issue, dont nous sommes dangereusement proches : les autres navigateurs vont commencer à prendre en charge / implémenter eux-même le préfixe -webkit-*, en transformant une implémentation unique en un nouveau standard mondial. Cela transformera une part de marché en un standard de facto, une seule implémentation en un monopole mondial. À nouveau. Ça tuera notre processus de standardisation. La question n’est pas de savoir si ça va arriver, mais quand.

Laissez-moi être très clair : ce n’est PAS une situation hypothétique et je ne parle pas ici de quelque chose qui pourrait arriver. Tous les fabricants de navigateurs nous ont officiellement fait savoir que cela arrivera bien plus rapidement qu’on ne pourrait le croire parce qu’ils n’ont, je cite, « pas d’autre option ». Clarifions un autre point : ce n’est PAS un manque d’innovation de la part de ces fabricants de navigateurs, d’autant plus qu’ils supportent BIEN une propriété mais avec leur propre préfixe, suivant ainsi les règles du groupe de travail. Les préfixes constructeur n’ont pas échoué. Ils ne sont pas parfaits, mais ils préservent du chaos les auteurs de sites Web. Nous pouvons certainement les améliorer mais nous le pouvons uniquement si les préfixes constructeur restent des préfixes propres à chaque constructeur.

Cette situation s’est produite dans le passé avec IE 6, quand les navigateurs fonctionnaient uniquement sur les ordinateurs de bureau, et il a fallu dix longues années pour en sortir. Avec les milliards de navigateurs mobiles d’aujourd’hui, le Web pourrait ne jamais s’en remettre.

Cela ne doit pas arriver

Je demande à toute la communauté des créateurs de sites Web d’arrêter de faire des sites uniquement pour WebKit, en particulier lorsqu’ajouter le support des autres navigateurs se résume à écrire quelques propriétés CSS préfixées supplémentaires.

J’appelle toute la communauté des créateurs Web à enlever immédiatement et à arrêter d’implémenter la détection des navigateurs WebKit sur les sites Web. Vous avez un tel site ? Affichez votre soutien au Web ouvert et enlevez la détection des navigateurs immédiatement après avoir fini la lecture de cet appel.

J’appelle toute la communauté des créateurs Web à cesser de recommander des sites web qui nécessitent d’utiliser un seul type de navigateur, alors qu’ils pourraient être compatibles avec plusieurs. Ne faites pas de lien vers eux, ne les mentionnez que pour dire à la communauté qu’ils ne respectent pas le Web ouvert. Ne nourrissez pas les trolls, mettez-les sur liste noire, qu’importe l’utilité du service qu’ils fournissent.

J’appelle toute la communauté des créateurs Web à mettre à jour leurs services en ligne pour prendre en charge les autres navigateurs si ceux-ci offrent un niveau de support CSS qui n’existait pas par le passé. Faites-le maintenant ! Un petit effort, de grands effets.

J’appelle l’ensemble de la communauté du Web, tous les internautes, à contacter les auteurs de sites et à se plaindre si leur site ne fonctionne qu’avec un seul moteur de rendu alors qu’il pourrait le faire avec plusieurs. Aidez-nous à diffuser la bonne parole auprès de ces sites Web pour garantir que l’architecture du Web demeure sûre pour tous, qu’elle demeure basée sur des standards Web consensuels et ouverts. Parce que si des éditeurs de navigateurs implémentent les préfixes d’autres navigateurs, ça ne peut conduire qu’à un chaos de la magnitude de celui de l’époque d’IE 6. Nous l’avons fait par le passé pour les sites qui ne fonctionnaient que dans IE 6 et nous l’avons bien fait, il est à présent temps de le faire à nouveau pour les sites qui ne fonctionnent qu’avec WebKit.

Je demande aussi aux éditeurs de navigateurs qui sont derrière WebKit, c’est-à-dire Apple et Google, de soumettre aussi vite que possible au groupe de travail CSS, toutes leurs propositions techniques pour les propriétés CSS propriétaires qu’ils ont laissé utiliser par le monde entier sur les périphériques iOS et Android, et qui nuisent au Web ouvert.-webkit-text-size-adjust est un exemple d’une telle propriété. Remarquez que les représentants d’Apple au CSS WG ont affirmé qu’ils le feront, et je les en remercie. Si ces propriétés sont si bien implémentées et si utiles à la navigation Web sur mobile, elles deviennent de facto des standards ; transformons-les dès que possible en standards de jure au travers de la standardisation du W3C.

J’appelle également Apple et Google à supprimer le support des versions « expérimentales » d’une propriété lorsque sa version finale est implémentée et publiée. Nous, et ce nous représente l’ensemble des acteurs du Web, nous ne pouvons pas laisser l’architecture du Web devenir dangereuse et peu fiable en conservant indéfiniment les préfixes éditeurs qui ne devraient plus exister. Ceci est inquiétant, et c’est de votre responsabilité, car vous pourriez fournir des mises à jour obligatoires à vos utilisateurs. Le Web ouvert ne doit pas souffrir d’une telle décision.

Alors, s’il vous plait, exprimez votre opinion, aidez le Web ouvert, twittez, bloguez que vous refusez de voir tout cela arriver. Certains d’entre vous ont d’ores et déjà commencé, après avoir lu les minutes http://lists.w3.org/Archives/Public... de la réunion du groupe de travail CSS à Paris. Il ne faut pas s’arrêter là. Faisons savoir à Microsoft, Mozilla et Opera qu’ils empruntent un mauvais chemin, quand bien même nous comprenons parfaitement leur diagnostic et la solution qu’ils proposent. Si ce sont les éditeurs de navigateurs qui créent les standards du Web, celui-ci appartient en fait d’abord et avant tout aux utilisateurs et aux créateurs de sites Web. Il est temps de le leur rappeler. Votre voix compte.

Enfin, je vous demande de relayer cet appel à l’aide. C’est pour cette raison que les commentaires sont fermés pour cet article. Alors à vos blogs, vos comptes Twitter, Facebook, Google+, ou que sais-je encore. Choisissez le moyen que vous voulez, mais faites-le. Jeffrey, Eric, Molly, Lea… et vous tous, nos amis de la communauté des Web Designers, ou de la communauté des standards Internet : aidez-nous ! Maintenant.

Si vous êtes journaliste, Daniel est disponible pour des interviews sur le sujet (attention, il est basé en Europe). Merci.

Article original : http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW

Traduction collaborative effectuée à l’adresse suivante avec le logiciel Etherpad. https://frenchmoz.etherpad.mozilla.org/saintgermanoise?

Card sorting - Troisième partie - Résultats, analyse et (re)conception

le 02/02/2012.

Concevoir une interface homme-machine n’est pas qu’une question de surface, c’est aussi une question de profondeur et d’architecture. Gautier Barrère et Eric Mazzone nous livrent la troisième et dernière partie de la série sur le Card Sorting (tri par carte). Dans ce dernier article, les auteurs nous montrent comment exploiter les résultats des séances de tri par cartes, et la façon dont ces résultats peuvent vous aider à concevoir ou re-concevoir vos interfaces.

SVG ou Canvas ?

le 25/01/2012.

Jérémie Patonnier se penche sur une question que se posent de nombreux développeurs Web. Quelle technologie choisir entre le standard SVG et l’élément HTML5 Canvas ? La réponse n’est pas simple, et cet article vous présente les avantages et inconvénients des deux technologies. Vous pourrez alors choisir en connaissance de cause. Toute l’équipe du collectif Openweb vous souhaite une bonne lecture et une excellente année 2012.

Toutes les actualités

Derniers articles

Ne perdez plus vos internautes, faites du card sorting / tri de cartes - Troisième partie : Résultats, analyse et (re)conception par Eric Mazzone, Gautier Barrère, le 02/02/2012 pour Débutant, Qualité, Méthodes.

Vous savez désormais ce qu’est le tri de cartes et comment le mettre en place. Découvrez sans plus attendre comment analyser les résultats et préparer le terrain pour une reconception efficace.

SVG ou Canvas, que choisir ? par Jeremie Patonnier, le 25/01/2012 pour Expert, (X)HTML.

Depuis plusieurs années que je m’intéresse à SVG et aux nouvelles possibilités qu’offre HTML5, on me pose régulièrement cette même question : « Quel est le mieux entre SVG et Canvas ? ». Je réponds alors stoïquement et laconiquement : « Les deux mon capitaine, ça dépend ». En effet, ça dépend, voilà donc un petit guide pour vous aider à choisir entre ces deux technologies.

Sprites CSS : performance et maintenabilité par Nicolas Hoffmann, le 16/08/2011 pour Expert, Gourou, CSS, Études de cas, Mise en page, Qualité.

L’optimisation des performances des sites implique de diminuer le nombre de requêtes HTTP. Pour ce faire, il est possible de regrouper les images utilisées dans les CSS, cette technique s’appelle les sprites CSS.

Tous les articles

Page valide XHTML 1 Strict, CSS2 et accessible AA.
Ce site s'affiche mieux dans un navigateur conforme aux standards, voici pourquoi.
Site hébergé par yterium (depuis 2010) et par l'APINC (2002-2010) . Propulsé par SPIP.