Aller au contenu

Ouvrir le Web un bug à la fois

Par Karl Dubost

Mini-conf (15 mn) :
Langue :
Français
CC Télécharger la vidéo

Liens connexes

Le sujet

Nous nous plaignons souvent du comportement des navigateurs Web. Bien que les implémentations soient parfois bancales, les développeurs de navigateurs doivent faire des choix pas toujours faciles. Entre part de marché et bugs distribués, la marge de manœuvres est fine. Avec un ou deux exemples, vous découvrirez comment ensemble nous pouvons garder simplement le Web ouvert et interopérable.

Présenté par

Transcription

- Je pense que tout le monde connaît Karl. Pour ceux qui ne le connaissent pas, pour le moment, il fait *. C’est * en anglais. Ce n’est pas la première fois qu’il vient, on est content à chaque fois.

- Karl Dubost : bonjour et bienvenue, mon nom est Karl, j’ai travaillé dans des agences Web, actuellement, je travaille pour Opéra, un peu comme plombier, on va comprendre un peu pourquoi je dis ça.

Le but de la présentation qui va être assez rapide, c’est ouvrir le Web.

Cela veut dire que je vais venir avec un sabre pendant la présentation...

Je veux rétablir l’équilibre.

Notre perception du navigateur Web, c’est que c’est un monstre, qu’il y a des choses qui buguent, il y a des choses qui fonctionnent mal, il y a plein de bugs. C’est vrai.

C’est une réalité, il y en a qui vous ennuient plus que d’autres mais ça s’arrange. Microsoft est revenu dans la bataille. Il y a vraiment une volonté de la part de tous les navigateurs d’enfin donner un outil qui soit intéressant pour les développeurs, de développer des technologies plus réalistes et plus proches de vos problèmes. Cependant, ça ne se passe pas toujours très bien et notamment, il n’y a pas tout à fait un équilibre social parmi les navigateurs Web, on a peu de parts de marché dans certains domaines ou pays.

Cette fois-ci, ce n’est pas une interopérabilité, c’est dû au développement sur les sites Web, c’est un gros problème.

A été lancée une initiative : open the Web, qui consiste à faire de la plomberie sur les sites que vous développez. Un utilisateur arrive sur un site et ça ne fonctionne pas sur Opéra. Le premier problème, pourquoi on a développé ces activités ? Parce que la première opinion qu’a l’utilisateur sur un site cassé, c’est que c’est le navigateur qui est cassé. Donc la perception est mauvaise pour le navigateur et ça pose un problème parce qu’on va perdre des parts de marché et l’entreprise ne pourra pas vivre. L’équipe, pour ceux qui étaient là ce matin pendant la présentation d’Andreas, il a présenté une équipe qui s’est répartie la charge, moi, c’est un peu plus la plomberie http et je vais passer à travers un ou deux bugs, on n’a pas beaucoup de temps, pour vous montrer la difficulté à laquelle on est confronté quand on est implémenteur de navigateur Web. Opéra est passé à la version 10 il y a très longtemps, beaucoup plus longtemps que la plupart des autres navigateurs, ça ne veut pas dire qu’on était en avance, mais on est un navigateur plus ancien et les versions ont avancé plus rapidement. Depuis, Chrome et Firefox ont rattrapé le retard.

Nous étions à la version 9.81, tout allait bien, et à un moment, on est passé à la version 10.0 et la plupart des sites se sont cassés. Beaucoup de librairies faisaient * sur le * du navigateur.

Pourquoi le numéro devrait changer ? Parce que les développeurs pensaient qu’une version a un chiffre avant la virgule. Je passe à 10.0. Opéra 1, c’est un vieil opérateur, ça renvoie à un site de merde. Opéra, je quitte et je vais chez un concurrent. Pour la petite histoire, Firefox qui est en train de passer à 10, a les mêmes problèmes. Ils sont en train d’avoir des problèmes de fonctionnalités sur certains sites comme Figaro, Bloger, etc.

Donc, ce n’est pas un problème unique chez nous, c’est un problème courant dans la plupart des développements. Quand vous faites un développement, ne pensez pas en termes de bug de l’an 2000, c’est la même chose... Surtout, petite technique à penser, c’est les foldbacks. Ce qui se passe souvent, c’est que vous avez l’identification du navigateur et non, ça ne marche pas. Le foldback c’est : ah ben non, je ne sers pas la page. Si vous ne pouvez pas identifier le navigateur, identifiez quelque chose qui est correct. C’est une histoire qui continue, c’est moi qui la traite en ce moment chez Opéra, c’est une belle histoire d’interopérabilité, de http qui rassemble toutes les conditions pour montrer comment c’est compliqué. Ça a commencé, je crois, en 2007, j’ai vu le bug antécédent à mon arrivée, il était là. Il y avait un pattern, sur certains sites, quand l’utilisateur arrivait, il y avait une erreur XML *. Quand vous arrivez sur une page où il y a un document XML, le navigateur l’identifie, je dois le traiter avec un * XML, s’il y a une erreur dans le document, je ne continue pas, j’affiche un message d’erreur. C’est à peu près comme ça sur tous les navigateurs. Mais là, avec Safari et d’autres navigateurs, ça fonctionnait bien.

Nous, ça ne marche pas, bizarre.

Je rencontre AFD Domet*.

Ce n’est pas encore tout à fait déterminé l’origine exacte, soit une librairie Microsoft, soit une librairie mobile qui n’est plus maintenue qui fait que quand je vois Opéra, je renvoie du XML. Sauf que le développeur ne le sait pas, renvoie du HTML avec du XML, le serveur crache parce que ce n’est pas un document XML. Comment on règle ça ? On peut contacter tous les sites, les développeurs et essayer de leur faire changer le site. C’est ce que je fais à longueur de journée, j’essaie de trouve la bonne personne pour faire évoluer le site, la librairie, une mauvaise pratique de développement, etc.

La chose que l’on va faire, c’est qu’on va être obligé de créer un FAQ pour servir les utilisateurs qui ne sont pas techniciens.

Le développement a des conséquences catastrophiques, vous faites l’amour avec la mort. Soyez très prudents quand vous faites des déplacements, le agency* *, c’est mal. Quand vous faites du snifing, une page Web meurt. Ne faites pas ça ou sinon, vous devez être un expert. Si vous êtes un expert et que vous faites une erreur, au Japon, on s’ouvre le ventre. C’est très problématique pour les développeurs de navigateurs, on est obligé de faire des Hack, des choses pas tout à fait normales. Pour corriger une erreur, on fait du reparting* dynamique.

La prochaine personne qui vient derrière et qui fait une erreur dans son document, le développeur ne va pas forcément la voir puisque la page ne va plus être en erreur. Donc, on va voir comment renvoyer un message d’erreur dans l’outil développeur, mais ce n’est pas cool, ça nous oblige à faire des hack, ce n’est pas bien parce que ça se déploie et à partir de ce moment-là, elles sont copiées, les erreurs sont archivées, elles restent. Ne faites pas de hack.

Autre chose : quand je viens à contacter les sites Web, une des premières réponses que j’ai dans les pays occidentaux avec une faible part de marché Opéra, c’est : on ne vous a pas dans les statistiques, pourquoi on devrait le supporter ?

Mais vous avez essayé d’y aller ?

Non.

En effet, votre site est inutilisable, interdit à l’entrée. Donc ça ne marche pas. On rentre dans un combat qui est un peu nul, un combat entre les implémenteurs et les développeurs, vous, ce n’est pas cool, on devrait être ensemble à essayer de développer le Web, de faire un Web ouvert. Ce n’est pas parce que vous utilisez des technologies standards que vous faites un Web ouvert.

Il faut que le Web soit accessible quelle que soit la plate-forme. Dans le thème de la conférence KISS, c’est vraiment un principe, évitez d’utiliser des librairies trop funky, des choses qui ne sont pas maintenues. Un jour, ça pourrait ne plus être maintenu. Vous savez comme moi qu’une fois que le projet est livré, il est livré, que quand il faut le maintenir, il n’y a plus d’argent et ça va coûter de l’argent de fixer cette ligne de Javascript, faites-le en amont.

Soyez fainéants...

Il faut qu’on passe à travers toutes les pages pour voir si tout fonctionne. Il y a Selenium pour ça, vous pouvez programmer le passage, tester les formulaires.

Après, il ne reste que des interfaces, des problèmes de Lay out*. Aidez-nous à corriger.

Chaque navigateur a un système de rapport de bug. Il y en a un pour Opéra, Mozilla, Microsoft, je ne sais pas... Aidez-nous, rapportez les bugs, soyez descriptifs. On a du plaisir à recevoir les bugs, ça nous aide à corriger les bugs du navigateur ou les bugs de vos sites Web ou des sites dont vous êtes les utilisateurs. Surtout vous qui êtes développeurs, allez-y. Vous pouvez essayer de contacter le site Web, mais ne prenez pas trop d’initiatives. Si vous pensez que vous allez péter une coche, faites un rapport chez nous.

J’ai présenté à peu près l’état de mon métier de plombier, les difficultés que l’on a en tant que navigateur. Des questions ?

Une question.

- Bonjour, une question sur les bug tracker. Microsoft en a un aussi, ils l’ont inauguré avec *.

Concernant Opéra, ce n’est pas un bug tracker, c’est une interface de saisie d’un bug et une fois qu’il est ouvert, on vous dit que vous n’aurez aucune nouvelle sur votre bug.

Est-ce qu’il y a des plans ?

- Sur le bug tracker, il y a une fonction Feature, toute l’équipe de développeurs de contact avec les développeurs d’Opéra est pour l’ouverture du bug tracker, donc, allez-y. Le sujet progresse. Au sein d’Opéra, la volonté d’ouvrir le bug tracker est maintenant là, le problème, c’est le passage d’un système fermé à un système ouvert, ça crée certaines contraintes, donc, allez-y, continuez à pousser, je pousse avec vous.