Etirez, réduisez, déplacez et empilez les blocs... >>> Retour page R&D
1er avril 2008
Les normes et recommandations W3C s'adressent aux auteurs de contenus web mais aussi aux fabricants de matériels et concepteurs de logiciels capables de restituer les contenus web (UA) ; c'est donc l'ensemble de la chaîne de production-restitution qui est concernée, et la "rupture de la chaîne de validité W3C" peut être sans risque comparée à la "rupture de la chaîne du froid" dans l'agro-alimentaire : c'est toujours le consommateur final qui trinque. Dans le monde merveilleux et enchanteur de la perfection réalisée, un contenu web normalisé transporté jusqu'à des machines normalisées est restitué de façon optimale par des systèmes logiciels normalisés. On peut dire ça parce que c'est le 1er avril aujourd'hui... dans la réalité non-merveilleuse et non-enchanteresse de la vie quotidienne, on est concrètement confronté à la question lancinante du "jusqu'à ce que..."
Sous cette courte proposition initiale, le W3C prévoit dans sa grande sagesse qu'il sera beaucoup plus difficile à un producteur d'UA de proposer des produits conformes qu'à un producteur de contenus ; il charge donc ce dernier de pallier momentanément à cette défaillance provisoire :
Directive 7, note : Tous les points à contrôler qui suivent engagent la responsabilité des développeurs de contenu jusqu'à ce que les agents-utilisateurs puissent fournir des mécanismes de contrôle du contenu adéquats.
Dans la plupart des points de contrôle, on demande aux développeurs de contenu de s'assurer que leurs pages et leurs sites sont accessibles. Cependant, certains besoins d'accessibilité seraient remplis de façon plus appropriée par des agents utilisateurs (en incluant des technologies d'assistance). Au moment de la publication de ce document, tous les agents utilisateurs ou les technologies d'assistance ne fournissent pas le contrôle sur l'accessibilité que demandent les utilisateurs (par exemple, certains agents utilisateurs ne permettent d'arrêter le clignotement des contenus clignotants, ou des lecteurs d'écran peuvent ne pas gérer correctement les tables). Les points de contrôle qui contiennent la phrase "jusqu'à ce que les agents utilisateurs..." nécessitent que les développeurs de contenu fournissent un support supplémentaire pour l'accessibilité jusqu'à ce que la plupart des agents utilisateurs disponibles pour leur audience intègrent les fonctionnalités nécessaires.
Le provisoire étant fait pour durer et la directive n'étant pas contraignante, les éditeurs et fabricants prennent quelques libertés.
Concernant Microsoft, sa stratégie concernant les standards W3C suit pas à pas celle de ses suites logicielles : les produits MS ne sont compatibles qu'avec eux-mêmes. La conséquence est paradoxale : alors qu'IE est le logiciel de consultation internet le plus utilisé (et que MS est membre du W3C...) il est aussi le moins respectueux des standards. La raison est qu'un IE "normalisé" n'assurerait plus une rétro-compatibilité intégrale avec d'autres outils MS. Et le second paradoxe est qu'alors que la série des IE actuellement en circulation représente 80% des navigateurs, nous développons nos sites pour les 20% restants (Firefox, Safari, Opera, Konqueror, etc.), qui eux tendent à les suivre au plus près ; une fois nos sites terminés, nous les affichons en test sur différentes versions d'IE et appliquons en conséquence un certain nombre filtres conditionnels, précisant version par version (IE5, 6, 7...) aux différents moteurs de rendu IE que dans tel ou tel cas de figure ils devront se comporter comme ceci ou comme cela. Après quoi on peut mettre le site en ligne avec une relative sécurité.
Conscient d'être sévèrement en retard sur la question (et de la piètre image qu'il a auprès des acteurs du web), MS a annoncé pour 2009 sortirait un IE8 dont la principale caractéristique sera d'être 100% W3C compliant (conforme aux standards W3C). Les premières beta-versions disponibles en test montrent qu'effectivement les ingénieurs MS ont "mis le paquet" et qu'IE8 sera probablement l'un des UA les plus performants. Sauf que... sauf que des rumeurs inquiétantes commencent à circuler.
Apparemment les équipes de développeurs IE8 commencent à se rendre compte que 95% des sites n'étant pas conformes W3C mais totalement conformes au mode "quirk" du rendu Trident d'IE (Trident est le nom du moteur de rendu IE pour PC, IE Mac - abandonné aujourd'hui - était autrement mieux constuit !), une part non-négligeable de ces 95% de sites pourraient ne pas s'afficher correctement sur un IE8 W3C compliant (voir également l'article "mode quirks") ! D'où le dilemme chez MS : doit-on s'en tenir aux standards et laisser penser que IE8 est un énooooooorme bug (ben oui, s'il n'est même pas capable d'afficher des sites web correctement...) avec tout ce qu'on imagine comme risque économique encouru, ou doit-on au contraire privilégier la "MS-stratégie" classique de rétro-compatibilité en se satisfaisant d'une amélioration d'un IE7 parfaitement éprouvé ? Vaste débat. Ça peut en inquiéter quelques-uns qui, le jour où un IE8 normalisé sortira sur le marché, recevront le soir même des appels angoissés de leurs clients : "Dites, que se passe-t-il, mon site ne s'affiche plus correctement ?". Et ça, c'est pour 2009.
(...quoique finalement à la réflexion, non, ce n'est pas inquiétant du tout, il suffira de leur répondre que tout le site est à refaire et qu'il faut de toute urgence prévoir un budget pour ça... tout compte fait, d'un point de vue purement économico-stratégique l'idéal est apparemment de ne pas tenir compte des standards :-)
Il n'a échappé à personne que l'événement de l'automne 2007 a été la sortie de l'iPhone d'Apple. Attendue avec impatience, toute la communauté des développeurs s'est jetée sur la bête pour lui faire subir les pires outrages : des batteries de tests. La politique d'Apple étant de ne jamais donner d'informations techniques avant la sortie de ses produits, les résultats étaient impossibles à prévoir. Mais maintenant ils sont là : alors qu'Apple se présentait avec Safari comme l'un des champions du W3C compliant (Safari est quand même le premier - et a été longtemps le seul - navigateur à passer l'acid-test, cette épreuve qui met les nerfs des développeurs d'UA à rude épreuve : tout ce qu'il y a de plus compliqué à rendre réuni sur une seule petite image de quelques centimètres...), voilà que l'iPhone n'accepte même pas de reconnaître la feuille de style handheld en charge d'indiquer aux UA mobiles de préférer telle présentation des contenus (mieux adaptée à leurs petits écrans/formats) et charge directement la CSS screen destinée aux grands écrans d'ordinateurs. On se dit que ce n'est finalement pas si grave et qu'il suffit d'appliquer une détection de taille d'écran pour basculer automatiquement en feuille handheld mais ça ne marche pas : contre toute attente l'iPhone refuse de se laisser traiter comme un mobile. Et puis à force d'investigations on finit par voir dans les specs que le viewport, la taille de ce qui est visible, a été volontairement bloqué par Apple à 980px... Pourquoi ?, personne ne sait. (...Ils n'imaginent tout de même pas chez Apple qu'un jour les mobiles auront des écrans ce cette taille ? ...on remarque aussi que le dispositif pour modifier le viewport s'active toutefois avec le zoom).
Du coup on apporte un correctif spécifique, perdant d'un côté ce qu'on s'attendait à gagner de l'autre : au moment où l'on espérait avec IE8 en avoir fini avec les lignes d'instructions spécifiques conditionnelles (si tu es untel fais ceci, si tu es untel fais cela...) on doit maintenant aussi en rajouter pour Apple... Bien sûr on n'est pas obligés de le faire et on peut laisser l'engin se comporter nativement, mais personnellement une screen sur mobile m'incommode fortement en terme d'utilisabilité (manip zoom pas-zoom incessantes, allers-retours "wrap & scroll" causant une perte fréquente de la ligne en cours de lecture, etc.), alors que handheld est faite pour ça. Tsss...
Le "jusqu'à ce que les agents-utilisateurs puissent fournir des mécanismes" finira bien par arriver un jour, mais quand ?
Au prochain 1er avril.