Faire du web moderne à destination de tous

Par Julien Wajsberg

Conférence (50 mn) :

Langue :

Français

CSS

HTML

JavaScript

Liens connexes

• Diaporama (PDF)

Le sujet

Les navigateurs modernes ont des possibilités décuplées par rapport à seulement quelques années auparavant : graphiques bien sûr avec CSS3, du balisage dans HTML5, des APIs, des fonctionnalités Javascript. Une certaine monoculture dans le web mobile amène aussi certains développeurs à ne garder qu'une compatibilité envers quelques moteurs récents.

Dans cette présentation, Julien Wajsberg vous montrera qu'il est réellement facile de rester compatible dans une certaine mesure, et vouss présentera ses différentes astuces pour pouvoir utiliser les nouvelles fonctions tout en gardant le site ou l'application web utilisable sur des navigateurs plus anciens : duplication de fonctions (ou pas), mode dégradé ou rehaussé, Modernizr, et d'autres choses. Et si on pouvait non seulement obtenir un web plus compatible, mais aussi mieux préparé pour le futur ?

Présenté par

Transcription

Faire du web moderne à destination de tous
Par Julien Wajsberg

Aujourd'hui je vais essayer d'expliquer comment on fait pour développer à la fois avec les trucs que vous avez vus ce matin, par Daniel, par Luz, et mais tout en faisant des sites qui fonctionnent toujours avec peut-être des navigateurs anciens. Ça c'est le premier point.

Et le second point que je vais essayer d'expliquer c'est comment on fait pour... Éviter en tout cas de se focaliser sur un seul moteur. Ce qu'on voit un peu trop souvent dans le monde mobile.

Voilà. Donc moi je suis Julien Wajsberg, Je travaille chez Orange depuis huit ans, et pour encore deux semaines. [rires]

Ça fait environ deux ans qu'on travaille sur un gros projet de bureau en Web. Donc on a mis en place pas mal de choses, on a mis en application pas mal de trucs comme ça, parce qu'on veut supporter Internet Explorer 7. Et je voudrais essayer de partager tout ça avec vous.
Après c'est juste une expérience personnelle et je suis très preneur de trucs que vous pouvez avoir dans la salle.

Donc, d'abord je vais essayer de poser le problème.
Dire un petit peu quels sont tous les défis qu'on a à développer pour du multi-device, sur du multi-écran. Et ensuite, voilà, vous expliquez un petit peu du point de vue technique ce que moi j'ai pu mettre en place. Alors ça vous avez peut-être déjà dû voir, bon la qualité est pourrie mais on voit quand même le principe.

C'est une boîte qui s'appelle Animoca là qui montre un petit peu tous les devices qu'ils utilisent pour tester. Je vais trop vite ? C'est ça ? Ça sature ? Faut mettre moins fort alors ! C'est moi qui parle fort.

On voit qu'il y a vraiment beaucoup beaucoup de devices. C'est un des premiers problèmes en fait.
Beaucoup de devices, beaucoup de résolutions. On sait que sur PC par exemple ça peut aller du 1024 par 768 au 1600 fois je sais plus combien, voire plus pour ceux qui ont des gros iMacs. Il y a des problèmes de densité avec tout ce qui est écran haute résolution type Retina. Dans le monde des tablettes c'est similaire. On part des tablettes 7 pouces, on peut peut-être même mettre le note 5 pouces là-dedans, donc des résolutions de type 800X600. Et ça monte jusqu'à 1024, et sans doute plus à l'avenir.

Et dans le monde mobile, on a quelque chose d'à peu près standard, on va dire, chez Apple. Un peu moins chez Androïd, et puis je parle pas des autres.

C'est un premier problème que l'on peut résoudre avec responsive design comme on l'a vu un peu plus tôt dans une conférence déjà. C'est pas le but d'aujourd'hui. Je ne vais pas parler de ça. Parce que je sais pas trop, en fait.

Deuxième problème : un problème lié aux entrées utilisateurs.
Il y a vraiment une multiplicité de moyens d'entrer les informations. Sur les PC de bureau on a les classiques clavier/souris, et on commence à voir arriver des écrans touch. Sur les tablettes évidemment touch. Du stylet sur certaines tablettes. Le clavier virtuel que l'on aime pas trop. Et enfin sur les mobiles on a un peu plein de trucs. Alors sur les anciens mobiles on avait le stylet. On commence à le revoir aujourd'hui. On a la molette sur certains, c'est plutôt sympa aussi. Enfin voilà. Je vais pas en parler non plus.

Troisième défi qu'on peut avoir c'est tout ce qui concerne les contextes. Les contextes au pluriel.
Alors là je vous en ai mis... Il y a deux types de contexte, je dirais.

Il y a le contexte lié à la localisation. Chez soi, on est tranquillement installé sur son canapé.
On regarde la télé. On regarde la télé et en même temps pianote sur son mobile ou sur sa tablette.
Il y a peut-être un problème d'attention peut-être ?
Quand on est au bureau, chez soi, sur son ordi normal tout va très bien on est très concentré.

On peut être dans un magasin, on peut avoir des infos sur un produit. Dans ce cas là on va être au fin fond du magasin, on va avoir un problème de connectivité. Ça va aller très doucement. On risque de ne pas avoir toutes les ressources d’ailleurs, on peut avoir qu'une partie de la page s'afficher.

Dans le métro, dans le train, alors dans le train en a des problèmes de vitesse. On sait que dans un TGV, vous avez dû faire l'expérience, ça marche très très mal le mobile. Dans le métro à Paris, pour ceux qui sont pas parisiens, il faut savoir qu'il y a pas de 3G. Il y a que du Edge. Je sais pas si il y a quelqu'un de la RATP ici ?

Ouais, il y en a quelques-uns. [Rires]
Ah, je l’ai repéré, il y en a 1.

Voilà donc en fait il y a quand même quelques millions de personnes qui voyagent dans le métro chaque jour et ces millions de personnes ben utilisent quand même Internet. Ils essayent, et ça marche pas forcément très bien sur des sites qui sont lourds. Voilà.

Après, il peut y avoir des problèmes d'environnement. Dans un parc avec du soleil on a sa tablette avec ces supers écrans brillants qui semblent si jolis dans le magasin. Mais qui sont si peu pratiques une fois qu'on est en extérieur.

Enfin il y a tous ces problèmes de contextes.
Mais je vais pas en parler non plus aujourd'hui.

Ah oui c’est un point que j'allais oublier Luke Wroblewski c’est quelqu'un que j'aime beaucoup avec un site génial sur lukew.com. Qui a écrit Mobile First chez Bookapart, bref lui il a un peu synthétisé une étude qui dit en gros : les tablettes c'est chez soi. Chez soi ça peut vouloir dire en vacances.
Et les Smartphones c'est plutôt partout en mobilité, on a toujours sur soi.

Bon, c'est un peu une parenthèse. Je trouvais intéressant.

Et enfin, ce qui nous intéresse aujourd'hui c'est les différences dans les OS et dans les navigateurs. Alors, sur iOS c'est assez simple. Il y a ça sur les mobiles. Il y a quand même Opera Mini. C'est peut-être pas si simple que ça finalement. Ouais, c'est pas un vrai Chrome. C'est un Chrome avec le moteur Webkit de Safari et avec je crois un JavaScript qui est pas optimisé donc… Bon c'est un faux Chrome quoi ! Chrome, on peut accéder à ses données, sur son cloud Google. Voilà, c'est bien pour Google.
Sur Android, on a un peu plus de choix aujourd'hui. Bon on retrouve Androïd Browser évidemment.
Là on a le vrai Chrome qui arrive.

On a les deux Opera : Opera mobile et Mini qui sont complètement différents. Firefox qui arrive évidemment. Voilà. Et puis sur la plate-forme Windows on a IE, IE puis IE.
Même si je pense qu'il y aura du Opera Mini aussi.
Je crois qu'il y a un Firefox qui est en train d'arriver sur Windows 8 aussi.
Donc en fait voilà les 5 gros défis auxquels on est confronté.
Aujourd’hui on va parler surtout du dernier.
Donc alors rappelons-nous un petit peu, rappelons-nous en 2001 Internet Explorer 6.
En 2004 Firefox 1.
Alors il avait déjà des trucs avant mais ça n'avait pas beaucoup de succès.
2005, IE7 arrive.
Et en 2006, il sort vraiment.
Coïncidence, 2006, première édition de Paris Web. [Rires]
En fait, on a appris qu'en fait, en développant pour une seule plateforme, en fait, on la fait stagner.
C’est lié à la faute des développeurs avant tout.
Ils ont pas développé pour tout.
Bon ça c'est quelque chose que l'on ressasse depuis assez souvent.
Mais c'est quelque chose qu'il faut évidemment qu'il faut remettre en regard aujourd'hui, en 2012.
Alors en 2012, on des navigateurs modernes partout.
Ils nous entourent.
Je les ai tous mis, j'ai même mis IE10.
Il sort que ce mois-ci mais…
Par contre, sur mobile, on a du Webkit.
C'est omniprésent.
Alors WebKit c'est évidemment Android, Chrome, Safari mobile, c'est le Kindle.
Mais la vérité est un peu plus subtile, puisqu'on a Opera Mini, on a Firefox qui commence à arriver, on n'a pas surtout la plate-forme Windows dont j'ai parlée.
Donc Windows phone Seven depuis un an, et puis Windows 8 qui arrive ce mois-ci.
On peut imaginer que c'est Noël cette année, il y aura peut-être des Windows dans la nature.
Donc faudra s'en occuper.
Tous les sites qu'on a faits depuis quelques années et qui marchent pour iPhone, donc iOS, et que pour iPhone, on va mettre que du Webkit.
Ben, ils vont être pétés.
Voilà ! C'est juste la vérité quoi.
On a quand même des navigateurs encore anciens justement.
Suivant un petit peu les stats, on voit qu'il y a de 15 à 30 % finalement de parts de marché pour IE7 et 8.
IE6 dans certains pays, la Chine par exemple, il y a, on m'a dit 40 % hier, d'IE6.
Ça va être important de cibler, ben de cibler justement ses utilisateurs pour choisir quel navigateur on veut supporter.
C'est vraiment la base.
Faut pas dire : je fais que ça parce que c'est plus facile.
Faut dire je fais que ça parce que j'ai réfléchi un petit peu.
Donc là j'ai piqué un peu ça façon Courrier International.
Nous devons nous assurer de conserver la diversité.
La diversité est bénéfique pour le Web.
Voilà donc pour poser le problème un petit peu. Alors maintenant je voudrais essayer d'expliquer qu'est-ce qu'on a de nouveau.
En gros, on a plein de trucs nouveaux depuis je dirais 4, 5 ans.
On a des nouveautés en HTML5, on a des nouveautés en CSS3, on a des nouveautés en JavaScript.
Alors tout d'abord en HTML5 :
Oui, je vous ai pas dit, le début de cette présentation c'est la partie jolie.
Là j’ai la partie avec mode texte maintenant.
Mais j'ai quand même mis du orange.
D'abord HTML5, il y a des nouvelles balises.
Donc ça c'est quelque chose je pense qu'on a déjà pas mal entendu.

J'ai une opinion assez tranchée là-dessus :
Je trouve qu'elles servent pas à grand-chose.
Donc, il y a plusieurs possibilités pour les utiliser. On peut utiliser un script.
Avec les dangers…
Qui fonctionne bien, mais avec les dangers qu'on a qui font que si on arrive pas à télécharger ça marchera pas.
Il y a une technique un peu Sioux et qui consiste à utiliser les préfixes XML.
A réserver aux Daniel Glazman.
On peut utiliser à la fois ces nouvelles balises section, articles etc. et des div qui ont le même nom.
Moi je vois pas l'intérêt.
Je trouve qu'il vaut mieux du coup utiliser directement les divs avec des classes particulières.
Alors par contre on peut quand même préparer l'avenir.
On peut dire que dans notre CSS, quand on va styler, on va styler à la fois le div .article par exemple, et article.
Comme ça, dans le futur, imaginons que dans un futur plus ou moins proche, il n'y ait plus d'IE7 et IE8,
Qui sont à moins de 1 % de parts de marché,
Voilà, on peut reprendre le site.
Tout ce qui était div.article, on le remplace par article.
Pas besoin de toucher au CSS.
Parce qu'on l’a prévu pour l'avenir.
C'est pas difficile à faire, je pense.
Donc c'est juste mon opinion.
Je suis prêt à entendre les opinions contraires.
D'un point de vue multimédia, il y a pas mal de choses aussi, donc audio, vidéo, canvas.
Là j'ai un peu expliqué comment on peut les utiliser de manière multi-navigateur.
Donc, vidéo et audio on peut utiliser un fallback Flash.
Alors, il y a des choses qui existent, des librairie qui permet de s'occuper de tout ça pour nous en fait.
C'est ce que je vais voir après.
C'est ce qu'on appelle un wrapper en gros.
Et on va les utiliser.
On va utiliser audio ou video si c'est là.
Et pour fallbacker on va faire du flash autrement.
Canvas, c'est un peu similaire, il y a un fallback en JavaScript qui existe, qui marche pour Internet Explorer.
Attention ! C'est très lent ceci dit !
Donc faut pas juste dire : c'est bon je fais du canvas super top,
et je mettrai ça, et puis de toute façon ça va marcher.
Non ! Ça rame vraiment.
Je vais en parler de ça aussi après.
Il faut pas oublier de mettre le fallback texte aussi entre canvas et /canvas.
Souvent il y a un texte pourri qui est :
Votre navigateur supporte pas canvas.
Ça fait une belle jambe pour ceux qui… Pour les lecteurs d'écran.
Et les revues d'écran récentes, de 2012, savent le lire.
C'était pas le cas auparavant.
On a également de nouveaux attributs notamment sur formulaire.
"Tel", "number", "url", c'est super intéressant,
C’est à utiliser puisque les navigateurs qui supportent pas mettront un champ texte,
Et les navigateurs qui le supportent, notamment sur mobile, mettront un clavier adapté.
Je sais pas, qui connaît déjà ça en fait ?
Ouais, pas mal de monde en fait !
Ce que vous savez peut-être pas c’est que les inputs de type color et date, même si c'est implémenté, ça pose des gros problèmes d'accessibilité, et notamment en navigation clavier.
C'est le monsieur là, qui a fait des tests, j'ai pas testé moi.
Mais vous pouvez aller le voir si vous voulez.
Ça pose des gros problèmes d'accessibilité en navigation clavier.
Ça pose des gros problèmes aussi je pense en revue d'écran.
Même si ça s'améliore encore une fois, tout le monde n'a pas la technologie la plus récente, parce que ça coûte très cher.
Attributs de validation, bon, je vais passer, je pense que c'est assez facile.
Et les attributs data, c'est enfin une manière standard de spécifier les attributs.
Auparavant on n'en mettait déjà, mais on mettait des trucs propriétaires, on va dire.
Avec ça, on peut l'utiliser dès maintenant.
Ensuite sur les APIs :
Il y a beaucoup d'API très récentes : Web Socket, Poke Message etc.
Bien sûr c'est pas présent dans les vieux navigateurs.
Ensuite, c’est présent pas sur tous les navigateurs modernes,
Et des fois quand c'est présent, c'est pas compatible.
Un exemple très clair c'est IndexDB.
Vous connaissez peut-être ?
C'est une manière de… IndexDB, base de données, voilà.
Ça permet de faire une base de données côté navigateur.
Il y a des choses qui existaient avant, comme Web SQL database. Ça a été rendu obsolète.
IndexDB, la manière standard de faire aujourd'hui.
Mais voilà, c'est pas implémenté partout.
Le standard il vient juste d'être terminé.
Chrome implémente la version d'avant du standard dans sa version stable.
La version actuelle dans la version non stable pour l'instant.
Firefox le supporte.
Opera le supporte aussi. IE va le supporter.
Enfin bref ! C'est un peu la panade !
Mais il faut, à mon sens, si on utilise comme ça des fonctions qui sont nouvelles,

Il faut vraiment faire le boulot supplémentaire pour que ça fonctionne partout.
Pour moi c'est le prix à payer pour utiliser des choses qui sont nouvelles et qui sont pas finies justement.
On a envie de les utiliser, et c'est normal.
C'est des fonctions qui sont passionnantes.
On l'a vu ce matin.
Il faut pas oublier qu'il y a des personnes qui ont des navigateurs pas à jour, qui ont pas le choix de leur navigateur.

Sur JavaScript maintenant et tout ce qui est API toujours,
Je pense que toutes ces nouvelles API rendent le code plus amusant.
Par exemple, en JavaScript il y a des méthodes dans l'Array qui permettent de faire du traitement sur tous les éléments d'un tableau.
Il y a des choses dans le DOM qui permet d'aller récupérer très facilement des trucs, en se passant complètement de jQuery.
Donc, vous avez peut-être vu des exemples déjà ?
Et pour moi il y a deux manières de gérer ça.
Donc j'ai un peu essayé de dissocier.
Il y a d'une part ce qu'on va appeler les polyfills et d'autre part les wrappers.
Je vais expliquer ça un peu après ce que c'est.
Le mode wrapper est peut-être plus populaire, mais ça va induire une dépendance comme on va le voir.
Alors tout d'abord les polyfills ça peut être une manière d'éviter du code spaghetti.
Ce qu'on voit en fait souvent dans des exemples tout simples c'est :
Si la fonction est là, alors je fais quelque chose, sinon je fais autre chose.
Ça c'est pas maintenable du tout !
Et sur le long terme ça fonctionne pas et pourtant ce sont des exemples très simples.
Dans la vraie vie on va vouloir avoir du code un peu plus maintenable, et un peu plus structuré.
Donc, là, les polyfills c'est une manière de faire.
On va ré-implémenter l'API standard à partir…
La même API standard dans les navigateurs qui supportent pas.
Et ce qui est très important, pour un bon fonctionnement, c'est d'avoir exactement la même API, pour pas avoir d'effet de bord dans le futur.
Et ça, c'est ça qui peut être assez difficile.
Si je reprends l'exemple d'IndexDB,
On a quand même une API assez complexe qui gère l'upgrade de base de données,
Qui gère la suppression de database,
La création de bases de données.
Enfin qui gère une manière de naviguer dans une base, par exemple en utilisant des curseurs.
Donc c'est quelque chose d'assez compliqué.
Si on veut l'implémenter correctement dans un navigateur qui le supporte pas, qui supporte Web SQL database, par exemple,
Voilà, c'est du boulot !
Donc je pense qu'il faut vraiment essayer de faire la part des choses entre :
J’ai besoin de cette fonction de manière complète et, j'ai besoin de 300 kilo de scripts pour pouvoir l'implémenter.
Alors il y a une petite liste sur le site de Modernizer qui est un peu perfectible justement.
Il y a pas mal de polyfills qui suivent ça justement, qui suivent pas cette logique.
Ils disent pas qu'il faut que ça implémente exactement pareil.
Il y a par exemple un autre exemple par exemple :
Dans la librairie Underscore je crois, ils gèrent différemment des tableaux qui ont des trous dedans par rapport aux tableaux qui ont pas de trous.
Enfin, quelque chose comme ça.
Et suivant le navigateur, il va pas y avoir le même comportement.
Justement parce qu'ils l’implémentent pas de la même manière dans les navigateurs qui supportent quelque chose et les navigateurs qui le supportent pas.
Ça ça pose des problèmes, puisque nous on teste dans quelques navigateurs généralement.
On va tester dans tous les navigateurs, mais pas tout le temps, mais plutôt à la fin.
Et on va se retrouver à la fin de notre développement à tester tout, et voir que ça marche pas.
Et c'est un peu tard.
Donc voilà pour ce qui est des polyfills.
J'ai pas d'exemple en fait, c'est un peu bête !
Et après, l'autre manière de gérer ces différences c'est les wrappers.
Donc, un wrapper en fait c'est une bibliothèque qui va implémenter une certaine fonction en utilisant plusieurs manières.
Donc, un exemple qu'on connaît bien c'est jQuery.
jQuery ré-expose une certaine API par-dessus les APIs du navigateur.
Pour ceux qui supportent des choses rapides il va les utiliser,
Pour ceux qui supportent pas il va faire du parcours d'arbre un peu plus lent.
Donc il y a des bibliothèques comme Underscore qui permettent de faire la même chose pour la programmation fonctionnelle.
Donc ce qui est pas mal, c'est qu'on pourrait implémenter qu'une sous-partie d'un standard. C'est pas grave puisqu'en fait notre application métier, en JavaScript, va uniquement s'appuyer sur l'API, l'API qu'on expose.
Si derrière ça change, ça sera facile de changer juste cette librairie-là, et pas le code métier.
Donc en gros, voici une petite manière de décider ce qu'il vaut mieux utiliser.
Pour moi les polyfills, faut les utiliser lorsque la spec est finalisée.
Évidemment, vu qu'il faut que ça adhère à la spec,
Si jamais la spec est pas finalisée et qu'elle bouge, on peut avoir des problèmes.
On peut avoir besoin de ré-implémenter le truc.
Et ça doit être conforme à la spécification, et du coup ça ça peut être difficile à faire.
Par contre, pour des choses assez faciles je pense à requestAnimationFrame par exemple où le polyfill il tient en une ligne, enfin un peu plus quand même, en une dizaine de lignes on va dire...
C'est complètement faisable quoi.
Les wrappers, au contraire on va l’utiliser si la fonctionnalité va être amenée à changer.
Si la fonctionnalité est complexe.
Mais par contre on va être amené à les faire soi-même alors que les polyfill, on peut en trouver parfois tout faits.
Maintenant, je vais vous parler un petit peu de CSS.
C’est un peu moins mon domaine, mais je pense que j’ai quand même un petit peu des choses à dire.
D’abord, par construction, CSS est quelque chose de permissif.
S’il y a quelque chose qu’il ne comprend pas il va juste l’ignorer.
Donc, c’est possible d’utiliser des choses qui sont nouvelles,
Donc les anciens navigateurs vont ignorer.
Par contre, il est très important d’utiliser des fallbacks.
Je sais pas si c’est quelque chose d’évident pour tout le monde ?
Il faut… Là j’ai un exemple avec les gradients juste après,
Il faut que les navigateurs qui supportent pas les nouvelles fonctions qu’on met aient quand même des fonctions à utiliser pour pas qu’on se retrouve avec du fond jaune clair sur fond blanc,
Parce qu’il y aura un gradient qui marche pas.
Donc, il faut qu’on arrête de penser qu’on peut avoir le même rendu sur tous les navigateurs.
Là j’ai pris quelques pré-requis quand même.
Déjà, j’ai présumé qu'IE6 n’était plus utilisé.
Parce que je ne connais pas bien.
Il y a peut-être des personnes qui auront des trucs pour IE6,
Mais moi j’en ai pas trop.
Donc, on va présumer que IE7 c’est le navigateur le plus vieux.
On suppose ! OK ?
Ensuite pour les sélecteurs on va supposer que ce qui est vraiment important pour nous c’est les CSS2.
Les sélecteurs CSS2, c’est des choses qui nous permettent de sélectionner des voisins, de sélectionner des enfants directs, de sélectionner la première ligne je crois enfin des trucs comme ça.
Non justement pas la première ligne. Mais le premier enfant justement par exemple, "first-child".
Voilà, ça supporte des trucs comme ça.
Et ça c’est vraiment important. On a vraiment besoin au jour le jour.
Donc c’est très bien : IE7 le supporte.
Utilisons-les.
CSS3 en revanche, amène des choses un peu plus avancées comme Note, Target, First Time etc.
On peut l’utiliser pour du cosmétique.
C’est pas grave pour ceux qui supportent pas.
Ils l’auront pas, mais ça peut être utile.
La première lettre on peut la rendre plus grande, plus jolie, puis orange.
:target ça permet de mettre en surbrillance l’ancre sur laquelle on est allé.

Si ça marche pas c’est pas non plus la fin du monde.
Si vraiment on veut l’utiliser dans les navigateurs comme IE7 et 8, il y a une bibliothèque qui existe qui s’appelle Selectivizr.
Attention ! Ça a quand même un prix de performance !
Ensuite, on a quand même d’autres priorités qui sont pas. D’autres propriétés pardon.
En CSS2 on a quelque chose comme display-table que Raphael Goetter aime beaucoup.
On a des choses comme inline-block, on a du contenu généré.
Donc, très bonne nouvelle, IE8 le supporte.
Alors pas IE7.
On n’en revient à une question de cible, justement.
Qu’est-ce qu’on veut cibler ? C’est une question business.
CSS3 va amener des trucs comme des gradients comme des fonds multiples et la solution ça va être d’utiliser des vieilles propriétés comme fallback.
Donc par exemple ici avec justement les fonds en gradients.
Donc là on a mis en commentaire, j'ai du le piquer quelque part,
On a mis en commentaire les navigateurs sur qui ça fonctionne.
Donc on voit qu’on utilise les gradients, mais pour ceux qui supportent pas on a aussi un truc en RGBA.
Donc en l’occurrence c’est surtout pour IE9.
Et pour ceux qui supportent pas comme IE8, on a un truc en RGB.
Donc là ça va nous permettre de vraiment supporter tout le monde, et de proposer un fond d’écran à tout le monde.
Jolie pour ceux qui supportent les gradients,
Et pas jolie… Enfin pas jolie. Moins joli pour ceux qui le supportent pas.
Et finalement c’est pas très difficile. C’est juste un réflexe à prendre finalement.
Je suis convaincu qu'ici dans la salle il y a des gens qui ont voulu utiliser les gradients dans leurs applis,
Ils ont mis -webkit, peut-être -mozilla, allez !
Et c’est tout quoi.
Même si les bonnes pratiques commencent à arriver, c’est pas encore assez partagé je pense.
Alors, il y a d’autres choses qui existent les transformations, les animations, les transitions.
Ça c’est quelque chose qui sont vraiment très sympas.
C’est pas supporté évidemment dans les vieux navigateurs aussi.
Ça pourrait être fait en JS. Mais attention ! Ce qu’il faut pas oublier, c’est qu’avec les navigateurs anciens, c’est aussi ceux qui ont pas de fonction, c’est aussi ceux qui sont les plus lents.
La solution c’est de pas les utiliser dans ces navigateurs. Finalement c’est peut-être pas très grave.
Voilà, donc attention ! Les vieux navigateurs sont vraiment lents.
Ils sont lents pour télécharger les ressources, ils sont lents pour les parser,
ils sont lents pour exécuter du JavaScript, ils sont lents pour accéder au DOM, ils sont lents pour afficher une page.
Ils sont lents !
Donc il faut accepter que les vieux navigateurs n’aient pas les fonctions modernes.
Quelque chose qui est quand même super important : c’est qu’on ne code pas pour des navigateurs, on code pour des utilisateurs.
Et les utilisateurs qui utilisent IE7, ils ont pas choisi.
Enfin je pense pas hein ? [Rires]

Donc, c’est des utilisateurs de votre application, de votre site, c’est des visiteurs.
Fournissons-leur une bonne expérience tout de même !
C’est pas forcé que ce soit la même.
Ça peut être dégradé.
Ça peut être par exemple, au lieu que ce soit du Flexbox avec des trucs qui soient sur les côtés avec des sidebars, on linéarise tout, c’est pas grave.
Puisqu’il faut qu’ils aient accès aux contenus, qu’ils puissent manipuler.
Finalement c’est ça le plus important.
Alors je vais terminer en peut-être fournissant quelques outils, en montrant un petit peu des choses.
Donc Modernizer évidemment c’est très connu.
En revanche, je trouve qu’on l’utilise un peu à tort et à travers.
Là ce que j’ai montré tout à l’heure, tous les mécanismes de fallback, de wrappers, de poly files, en fait, c’est pas Modernizer.
On n’en a pas forcément besoin.
On peut l’utiliser lorsque quelque chose qui n’est pas… Comment dire. Lorsque quelque chose qui n’est pas présent, lorsque il n’y a pas de gradients, il faut qu’on modifie un autre style ailleurs.
Par exemple on a notre div on veut mettre notre gradient en fond.
Et on voudrait que s’il n’y a pas de gradients, le truc qui est autour il ait une bordure, par exemple.
Un autre élément, là on peut pas s’en sortir avec du CSS classique.
On va être obligé d’utiliser de la détection de fonctionnalités.
Là, à la limite, OK.
Mais je pense qu’il faut essayer de se réfréner de l’utiliser,
Puisque ça introduit une dépendance à un JavaScript externe,
Que finalement, c’est pas non plus anodin, c’est relativement gros.
Je sais qu’on peut le compiler pour en avoir une version plus petite.
Mais tout de même !
Ça peut ne pas être téléchargé parce qu’on a un problème de latence et de connectivité.
Voilà. Donc là, par exemple dans un projet dont je vous ai parlé tout à l’heure on n’utilise pas du tout de Modernizer.
Et pourtant, je pense que c’est très graphique et que ça bouge dans tous les sens quoi.
Une autre librairie que j’aime bien qui s’appelle has.js qui est beaucoup plus bas niveau, beaucoup plus orientée JavaScript on va dire.
Donc par exemple est-ce que le navigateur supporte foreach ?
Souvent ça va être utilisé au sein d’une autre bibliothèque pour pouvoir faire de la détection au sein d’un wrapper par exemple.
Ensuite, on peut parler de préprocesseur.
Moi je connais pas trop.
Mais ce que j’en comprends c’est que c’est un petit peu le Wrapper de CSS.
Ça va encapsuler une fonction parce qu’on est capable de faire du mixing de fonctions, des imports. Enfin comme c'est dans les différents préprocesseurs, ça fait la même chose mais ça a des noms différents.
Ça va aider à utiliser tous les préfixes.
Par ce qu’on va se créer des fonctions une bonne fois pour toutes et voilà, on va l’utiliser partout. Et du coup ça peut permettre aussi de supporter des vieux navigateurs côté serveur dans une démarche mobile first.
Il y a un bon article de Nicolas Gallagher là-dessus
Que je vous engage à aller voir.
D’autres sites qui sont très utiles whatcaniuse vous connaissez évidemment, pour connaître le support d’un navigateur.
Alors, faut faire attention parce que là-haut il y a le pourcentage de support de part de marché.
Mais ça, ça se base sur Stat Counter.
Et Stat Counter il est assez, il est pas toujours très fiable en fait.
Il est assez biaisé envers Chrome, par exemple.
Et IE est souvent sous-représenté.
Donc faut faire attention des fois aux supports qui sont indiquées.
HTML5Please, qui ne connaît pas ?
Bon très bien, je passe.
CSS3Please c’est top aussi.
Ce qui est génial dans CSS3Please c’est qu’en fait le code il est prêt, il fonctionne il est multi-navigateurs, on peut le copier coller.
Et on peut le tester en live.
Donc si vous avez un doute, hésitez pas à aller voir ça, j’aurais vraiment la dernière syntaxe qui fonctionne dans tous les navigateurs.
Bon, vous pouvez virer, vous pouvez ignorer les filters de Microsoft éventuellement. C’est pas nécessaire.
Alors d’autres outils :
Arena qui est top, en bas là.
Je pense que je peux même le montrer.
On a du temps ou pas ?
Ah ben nickel !
Tu peux passer au milieu si tu veux, la prochaine fois ?
Alors attendez, c’est celle-là.
Donc, ça ça permet de gérer les transitions en fait.
Enfin, vous savez qu’il y a plein de trucs, plein de manières différentes de gérer les transitions qu’ils vous proposent.
Alors là, par exemple, linéaire.
Si je clique sur left….
En fait, on voit directement ce que ça fait sur les différentes propriétés. Donc c’est quand même assez cool en fait.
On peut changer la durée évidemment, l’opacité, voilà.
On peut en choisir d’autres, voilà ça change la courbe.
Et le top du top, c’est qu’en fait on peut prendre le truc, on peut prendre le petit handle, la petite main, et la déplacer comme ça là.
Est-ce que je vais y arriver bien ?
C’est dur avec une main finalement !
Et avec un trackpad.
Non sur mon écran il y a rien.
Enfin voilà bon bref !
En gros voilà.
On peut toujours tester.
Et en bas en fait, le code il est changé en live.
Et du coup, il y a plus qu’à copier coller. Et voilà.
Donc ça je trouve ça vraiment génial c’est très graphique, c’est très…
C’est juste un outil qui est bien quoi et que j’avais envie de montrer aujourd’hui.
Alors ça je l’enlève, voilà, je reviens sur le bureau.
C’est bon ! ok.
Donc, là j’arrive quasiment à la fin.
Donc, à retenir, ce que je voudrais qu’on retienne :
C’est que c'est facile… C’est plutôt facile, on va dire, faut pas déconner.
C’est plutôt facile de coder pour IE7 finalement.
C’est un peu d’efforts, mais c’est faisable.
Ça demande pas 40 % de développement en plus comme pour IE6.
Faut pas oublier qu’on code pour des utilisateurs. C’est pas eux qui choisissent d'avoir IE7.
Et c’est plutôt facile aussi de coder pour tous les navigateurs, pas que pour Webkit, avec les préfixes comme je l’ai montré tout à l’heure.
Je conclurai en disant que la pérennité, pardon, la diversité c’est important pour la pérennité du Web, pour qu’il continue à évoluer, et qu’on continue à avoir des trucs supers cool comme on l’a vu ce matin.
Hier quelqu’un m’a dit : ouais t’as qu’à dire qu’il faut faire des applets java et ça marchera partout.
Mais j’ai oublié, je voulais le dire au début j’ai oublié.
Je peux le dire maintenant.
J’espère que vous avez appris des trucs. [Applaudissements]
Et je suis preneur de questions.
Question 1
Intervenant dans la salle (IS) : Bonjour, Jean-Philippe Encosse.
Julien : Bonjour Jean-Philippe.
IS : en fait, j’avais une remarque plutôt à faire. C’est que déjà, les machines ont généralement l’âge de leur navigateur.
Donc quand on est sur un IE6 ou un IE7 qui est lent, et même si ça passe sur une machine moderne sur laquelle on développe, faut se dire que les utilisateurs ont une machine qui a à peu près l’âge de IE7.
Donc qui est aussi très lente.
On a tendance, c’est un point que tu as évoqué, et que je mettrais même dans les points que tu as mis en troisième point, on a tendance à faire du graceful degradation pour tout ce qui est vraiment fancy et graphique,
Pour que l’expérience utilisateur soit bonne,
Mais dégager les wrappers qui potentiellement peuvent tuer les performances de la machine, et garder une bonne performance du reste.
Et poussez les utilisateurs à essayer de migrer parce que jQuery a fait le choix d’ignoré IE7 et IE8 dans les prochaines versions.
Donc faut que petit à petit on éduque les gens quand même à avancer, et a passer aux navigateurs modernes.
Julien : Ouais ! Non je suis très critique envers ce choix de jQuery.
Jquery c’était bien parce que n’importe qui le prenait, le mettait sur son site, et ça marchait.
Finalement il avait pas besoin de se prendre la tête dessus.
Et même ceux qui savent pas, ça marchait quand même.
Et là avec ce choix là, ils savent toujours pas, et ça va plus marcher.
Donc là je suis assez critique là-dessus.
Et sur ta première remarque, c’est aussi complètement vrai.
Quand on est développeur, généralement on a une machine qui poutre, comme on dit.
On a un écran qui poutre.
Et on a tendance à oublier que les utilisateurs ils ont pas une machine qui poutre et un écran qui poutre.
Moi je suis sur mon Netbook là assez souvent.
Ca poutre pas du tout.
Et j’étais très surpris récemment d’essayer l’application dont j’ai parlée qu’on développe sur un Firefox récent, dans un Windows 7.
Ça va hyper vite quoi !
Et quand je développe sur mon Linux de 4 ans, qui a pas de drivers optimisés, c’est vachement plus lent.
Ouais ! Faut pas oublier que tout le monde n’est pas sur sa machine géniale de développement avec quatre processeurs et un Retina.
Question 2
IS : Bonjour Stéphane, Orange.
Une petite réponse sur les navigateurs et pousser les gens à en changer.
Les grands comptes sont pas des gens qui avancent rapidement,
Et quand ils essaient d’avancer parfois ils se cassent le nez.
Par exemple chez nous on s’est dit :
Tiens on pourrait peut-être passer à Vista.
Donc ils ont testé sur un parc pilote.
Et d’un seul coup, ils se sont rendus compte qu’il faudrait d’abord changer toutes les machines avant d’installer Vista.
Du coup, on a pris un retard monstre, et on est toujours avec 100 000 machines avec IE7 et 4000 machines avec IE6.
Donc voilà.
Entre votre vœu pieux vous de développeurs, en particulier quand vous avez affaire à des petits contes PME des choses comme ça, méfiez-vous ! Les grands comptes avancent pas à la même vitesse que le reste du monde.
ça c’est juste une remarque en passant.
Sinon, une question quand même :
Tu peux expliquer pourquoi tu n’aimes pas les balises sémantiques que moi j’appelais de mes vœux quand le groupe HTML5 s’est constitué le article, le header etc. etc.
?
Julien : c’est quoi l’effet des balises ? Non non garde ton micro !
Bonjour ! J’ai le droit je suis orateur aujourd’hui, je fais tout ce que je veux.
IS : pas mal ! Ça leur fait une salle contre les gens d’Orange voyez ! On est un peu pressé.
Julien : qu’est-ce que ça apporte aujourd’hui ces balises ?
IS : moi ce que je vois dans ces balises, c’est l’idée que on a des analyseurs sémantiques de plus en plus performants, je pense à des moteurs de recherche chez Orange R&D [il pouffe]. Et je pense aussi à Google, et tous ces gens-là et je me dis :
même si on développe des algorithmes de plus en plus perfectionnés pour trouver dans la page ce qui est le plus pertinent et évacuer ce qui semble répété de page en page, c’est donc la navigation et qui n’a pas intérêt à être aussi bien annexé.
Vous me dites si je vais trop vite, vous criez ! D’accord ?
En revanche, je me dis qu’on va simplifier la vie en particulier les moteurs de recherche grâce à ces balises sémantiques.
Et ces balises sémantiques sont assez facilement mappables sur… mappables euh ?
associables… À des rôles dans la page qu’on appelle les rôles aria.
Donc c’est aussi utile en termes d’accessibilité, même si on a pas besoin de ces balises-là.
Elles ont du sens dans un Web qui de plus en plus est capable de spécialiser les contenus qu’il fournit.
Plutôt que de dire ceci est mon document ceci est la fin de mon document et démerde-toi avec.
Julien : je suis d’accord sur la théorie.
Alors, la pratique maintenant.
IS : là je sais pas je travaille chez… [Rires]
Julien : aujourd’hui je ne vois pas en pratique… En fait c’est peut-être un petit peu la poule et l’œuf.
Je suis peut-être d’accord avec toi. Tant qu’on n’en est pas là peut-être que ça sera pas pris en compte.
Mais je me dis qu’on peut peut-être attendre que les vieux meurent là IE8.
Ça va prendre peut-être un an ou deux ans ? Et puis là euh voilà.
Question 3
IS : j’ai un petit élément de réponse par rapport à ça.
J’aurais tendance à dire que la question de Stéphane contient en elle-même sa propre réponse.
À savoir : la spec du W3C ne précise pas le sens sémantique des différentes balises. [Autre intervenant : c’était le cas il y a quelques temps].
Bah oui mais c’est plus le cas !
Et du coup, en fait, si on les utilise, on les utilise sans savoir vraiment ce qu’on doit mettre dedans.
Et du coup, ça n’a pas trop de sens.
En fait, la manière dont ont été choisie le faite de rajouter ces balises sémantiques, c’est en analysant sur un panel de pages Web existant dans le monde quelles étaient le nom des classes et des identifiants des classes les plus utilisés et on a créé ces balises en se disant :
Autant créer des balises représentant ce que les développeurs dans les pages… Sur lesquels les développeurs ont cherché à mettre de la sémantique, puisqu’ils utilisaient ces balises.
Sauf que, la spec ne précisant pas la sémantique de ces balises, les développeurs ne les utilisent pas en se disant :
si je les utilise, que je mets une sémantique dessus, c’est pas dit du tout que la sémantique qui va être faite par quelque chose qui va les analyser automatiquement par ailleurs sera la même que la sémantique que je vais mettre moi.
Donc, il vaut mieux ne pas les utiliser pour pas qu’il y ait un risque de mésentente sémantique.
Donc voilà.
Julien : en fait, faut pas me faire dire ce que j’ai pas dit.
Je trouve que c’est très bien.… Moi je les trouve très bien.
En fait, le vrai intérêt ça va être avec la hiérarchisation des titres.
C’est-à-dire qu’on peut mettre un… Si on met une section avec h1 dedans, et qu’il y a un h1 au-dessus du bac automatiquement, le H1 qui est dans la section il va être décalé par rapport au… Enfin ça va être comme un h2.
Ça c’est un vrai intérêt mais le problème c’est qu’en pratique aujourd’hui, il y a trop d’inconvénients, parce qu’il y a trop de navigateurs qui supportent pas.
Et ça va faire n’importe quoi dans ces navigateurs-là.
Et surtout que ces vieux navigateurs c’est des vieux Jaws qui se font plus et qui auront pas la bonne structure.
Pour l’instant, je dis pas qu’il faut pas les utiliser à l’avenir.
Mais aujourd’hui, en 2012, je pense moi personnellement que c’est pas une bonne idée.
Question 4
IS : je voulais juste faire un petit complément de réponse par rapport à ce que tu disais Stéphane.
On a appris aussi un truc qu’on sait pas forcément : pourquoi les grands comptes ne migrent pas leur Navigateur ?
Il y a beaucoup de grands comptes, notamment dans le secteur bancaire, qui avec IE6 ont fait énormément de développements qui leur ont coûté des centaines de milliers d’euros, autour des ActiveX ce genre de choses.
Et qui ne peuvent pas en faite passer à des navigateurs plus récents parce que ça leur coûterait des milliers de milliers d’euros de refaire leurs applications propriétaires.
[Autre intervenant : et qu’ils ont pas le code côté serveur parce que, pour faire le développement il faut qu’on récupère le code.]
Question 5 :
IS : je trouve, dans le même esprit, vous parlez de dégradation gracieuse.
Moi, enfin, je trouve que c’est quelque chose qu’il faut changer.
Il va falloir parler d’amélioration progressive à son client.
C’est vachement important parce que c’est vraiment… C’est la manière de dire les choses.
C’est exactement la même chose en termes d’implémentation.
Mais c’est comme ça aussi qu’on va faire évoluer les mentalités.
Et c’est en arrêtant de voir le verre à moitié vide et en essayant de le prendre à moitié plein.
Et alors c’est clair : ça ne changera rien en termes de technique.
Mais par contre on a des clients qui sont vachement réceptifs.
Moi je le vois tous les jours.
J’ai des clients quand on leur parle d’amélioration progressive dise :
Finalement c’est peut-être comme ça que je vais faire quelque chose de super pour quelqu’un et de normal pour un autre plutôt que l’inverse : je vais faire quelque chose de fonctionnel pour quelqu’un et d’un peu nul pour l’autre.
Julien : moi ça m’intéresse vachement que tu proposes une conf’ un jour où tu expliques comment tu expliques ça aux clients.
Moi clients, enfin tel que je le connais, parce que c’est moi le client en l’occurrence chez Orange.
Si on dit un client : ouais on veut d’abord un truc pourri, puis après peut-être que pour les autres on fera un truc joli, il va pas te prendre.
Du coup, ouais, c’est ma vision à moi et je me dis qu’il faut une conf’ pour que tu expliques ça.
IS : OK mais ça c’est peut-être un problème d’ergonomie aussi. Peut-être qu’il faut revoir le Web d’une manière différente aussi.
Et je pense qu’on peut arriver à des choses supers riches dans le numérique etc. sans pour autant faire l’interface hyper lourdingue.
On l’a bien vu avec des choses qui ont disparu comme drag & drop etc.
Et finalement c’est pas un mal pour les utilisateurs.
C’est qu’un moment parfois faut pas chercher à faire du waouw partout.
Et peut-être qu’il faut revenir à quelque chose de plus simple.
On est revenu là-dessus avec le mobile, le responsive etc.
Et je pense que c’est quand même un truc qui est en train de se passer.
C’est qu’aujourd’hui on se rende compte que si on veut faire sites multi-device pour tous les clients, pour les mobiles et pour tout le monde,
On peut réussir à faire parce que ouais !
Parce qu’on va peut-être s’adapter au mobile.
Finalement peut-être que la clé c’est le mobile !
Et le mobile, ben finalement quand on fait du mobile, on peut faire du IE6 quoi.
Et moi j’aime à dire que… Non mais…
Ce que je veux dire c’est que moi j’aime à dire que en dehors des animations et tout ça qui sont de l’ordre du superflu,
Il y a beaucoup de choses que l’on peut faire si on pense vraiment à utilisateur comme tu le disais, et plus forcément que à l’interface.
Mais vraiment à l’interface pour l’utilisateur.
Julien : on peut l’applaudir [applaudissements]
Question 6
IS : salut, Mathieu, couteau suisse du Web.
J’ai une remarque une question un peu ouverte.
Ma remarque c’est sur le fait de tester avec du vieux matos pour voir ce que ça donne pour les utilisateurs qui n’ont pas forcément un quadri-processeur avec 28 Giga de ram.
Julien : et dans le métro.
IS : ou dans le métro. Il y a plein de petites astuces très bêtes, sans changer votre matos pour pouvoir tester dans ces conditions-là. Par exemple, l’année dernière c’était plutôt sur du back-end, il y a quelqu’un qui m’a suggéré pour tester avec une base de données chargée de mettre la base de données sur un disque dur USB.
Vous pouvez faire la même chose avec votre cache de navigateur en fait.
Le configurer pour le mettre sur un disque dur USB, vous reloadez votre page et vous voyez à quel point c’est lent.
Ça peut simuler des trucs comme ça.
Vous pouvez prendre PhotoShop ou un GIMP et le lancer en arrière-plan en lui demandant de mettre un blur sur un document de 2000×2000.
Un truc comme ça. Et pendant ce temps vous testez votre site.
Et comme ça vous pouvez vraiment vous rendre compte de ce que ça donne avec un matos de merde, sans avoir le matos de merde en question.
Voilà, y’a plein de petites astuces comme ça sympa.
Ou lancer une vidéo 1080 p derrière pendant que vous relancez vos supers animations sur votre site Web.
Vous allez voir les animations sur site Web vont être nettement moins fluides.
Et voilà, vous pouvez vraiment vous rendre compte de ce que ça donne chez tout le monde qui n’a pas votre matos.
Donc ça c’était voilà. petite remarque façon couteau suisse.
Sinon je voulais savoir.
Parce qu’on discutait de grands comptes qui pourront jamais, avant des années, avoir des versions récentes etc.
est-ce que tu avais une opinion sur le fait de dire sur le site aux utilisateurs : vous avez un navigateur tout pourri, donc la page Web va pas forcément bien s’afficher ?
Sans forcément l’engueuler, sans forcément le pousser à le mettre à jour, juste au moins le prévenir et lui dire :
Peut-être que tu pourrais faire pression sur ta hiérarchie, on sait jamais, ça finira peut-être par marcher.
Ou un truc comme ça quoi voilà.
Julien : enfin la hiérarchie elle-même va tomber dessus. Peut-être.
IS : peut-être aussi oui.
Julien : je réponds rapidement si tu veux.
Je pense que c’est bien ce que tu dis. De faire ça voilà. J’adore tout ce que tu fais. [Rires]

Sérieusement, par exemple quand Github a fait le choix de ne plus supporter IE7, je crois, récemment.
Sauf que tu vas sur Github avec IE7, y a rien qui s’affiche comme quoi il ne supporte plus.
[Une vélotypiste demande d’épeler].
Julien : Github : g i t h u b.
Et on a juste une page toute pétée.
Sans explication.
Donc je trouve ça… C’est vraiment pas respectueux envers les utilisateurs qui vont dessus.
Question 7
IS : oui, rebonjour.
C’est juste encore par rapport aux histoires de IE6 dans les grands comptes et avec les navigateurs etc.
Dans les grands comptes de plus en plus je vois qu’ils ont effectivement, contrairement à ce que disait Stéphane, un parc qui est en général pas plus vieux de trois ans.
Souvent ils renouvellent leur matériel tous les trois ans.
Et de plus en plus chez les grands comptes, ils installent deux navigateurs.
Enfin souvent c’est par example un IE6 et un Firefox récents.
Autres intervenants : chez nous c’est un IE7 et un Mozilla 3.6. [Rires]
IS : oui évidemment des fois on cherche.
Non mais du coup ça permet d’utiliser IE6 pour leurs vieilles applications métiers valables qu’en cobol où ils ont pas le code.
Et de bénéficier quand même du meilleur rendu pour les applications les plus récentes.
Question 8
IS : Bonjour, Fabien.
Une petite question par rapport aux préfixes Webkit.
Je voulais savoir pour IE8 qui va bientôt arriver… Windows 8.
Et donc la question c’est les préfixes qui vont être supportés un peu à l’image de ce que fait Opera ?
Julien : j’ai pas la réponse spécifiquement.
Florient dit qu’a priori ils seront supportés dans IE10. C’est ça ? Certains, mais pas tous. Mais généralement, quand ils sont supportés que supporte quand même celle qui n’ont préfixé, ou alors la leur, genre -ms. Et du coup, vaut mieux les utiliser si tu fais un nouveau code.
Enfin, tu perds rien à utiliser tout, toute les versions préfixées et la version non préfixée.
Enfin c’est clair ou pas ? Ouais OK.
Question 9
IS : juste pour rebondir sur cette histoire de préfixes.
On a écrit un article sur OpenWeb sur le sujet. On a fait tester par des gens qui avaient IE10 en version pre-release.
Et sur la version quasiment finale.
On s’est aperçu qu’il fallait quand même garder les préfixes même si Microsoft a annoncé les enlever sur la dernière.
Donc vaut mieux se les trimbaler, c’est plus sûr.
Julien : mais tu parles des préfixes MS là ?
IS : oui préfixes MS bien sûr.
Question 10
IS : moi je voulais revenir un peu sur un projet de cette taille, avec le nombre d’équipes, le nombre de temps passé dessus.
Est-ce que dans la conception, dès la conception, à partir de quelle étape vous prenez en compte cette amélioration progressive ou celle de…
Pour faire en sorte de dire cette fonctionnalité soit on la prend pas, soit on la prend mais ça implique tel choix en termes de performances, tel choix en termes de fichiers en plus à télécharger, en termes de façon de l’appréhender soir on…
Est-ce que cette étape-là est processisée chez vous ?
Est-ce que vous avez un moyen de l’organiser ?
Julien : chez nous, c’est encore un peu… En fait on n’est pas une agence de développement Web, on fait des téléphones, et des réseaux.
Chez nous c’est encore vraiment au niveau de l’artisanat, je dirais.
Ça commence un petit peu à se professionnaliser.
On a eu récemment un petit Paris Web interne, on va dire.
Donc ça commence.
Et du coup, ben c’est un peu de l’artisanat, et c’est un petit peu chacun, chaque développeur qui décide on va dire peut-être au sein de l’équipe.
Alors nous on a fait le choix qu’on supportait IE7.
Comme c’est moi qui ai commencé à coder j’ai fait tout de suite des trucs pour que ce soit facile à supporter.
Les polyfills pour les foreach les maps etc.
En tout cas chez nous, qui ne sommes pas une agence Web encore une fois, c’est pour l’instant à ce niveau-là.
C’est dommage ! Mais je pense que ça va changer.
Question 11
IS : Bonjour. Anthony.
Pour rebondir sur ce que disait Mathieu sur les outils intéressants.
Il y a aussi des ralentisseurs de connexion sur les systèmes d’exploitation, donc pour simuler du 3G, du Edge, des paquets perdus des choses comme ça.
Julien : et Web Page Test le fait aussi.
IS : oui oui. Mais c’est plus sympa de l’avoir sur ta machine en développement journalier.
Vous avez des tests automatisés pour tous les navigateurs ? Pour vérifier que ça casse pas ?
Julien : quand tu dis nous, tu dis nous Oranges pour le portail par exemple ?
IS : j’étais pas là au début, donc je savais pas que tu avais des problèmes. [Sourires]
Mais c’est une fausse question, en fait. Je disais il faut des tests automatisés. [Rires]
Quand on utilise des choses pas standards, pas encore standards, quand on utilise des préfixes, ça casse très souvent.
Quand la version non préfixée arrive dans une version de navigateur, comme par hasard ils ont cassé la version préfixée.
Enfin il y a plein de choses qui peuvent casser. Il faut des tests automatisés.
Julien : chez Chrome.
IS : non chez tout le monde ! Mais oui évidemment Google… [Rires]
Julien : les tests automatisés c’est bien, mais ces chiant, faut dire qui est. c’est pas toujours fait.
Mais c’est bien si on en fait. C’est clair.
Il y a des outils, et faut peut-être prendre le temps de le faire.
[NDT : Selenium] ou des trucs comme Kasper peut-être ?
[Un intervenant qui parle]
Julien : il dit que Kasper c’est Webkit donc pour faire des tests automatiques avec Kasper c’est dommage.
Question 12
IS : surtout pour revenir sur ce que dit Anthony.
Est-ce qu’il y a des moyens simples de faire des tests unitaires sur les feuilles de style ?
Julien : tu veux dire tester si la feuille de style est rend pareille ?
IS ouais voilà. Est-ce que du cours ta feuille de style s’applique, vérifier qu’elle s’applique facilement. Enfin bon.
Julien : tu veux tester qu’une propriété marche bien ?
IS : par exemple oui, sur un navigateur.
Julien : ben tu fais des screenshots automatisés. Et tu fais des petits scripts qui…
IS : bah du coup tes obligé de regarder toi-même tes screenshot, en fait.
Julien : non non tu peux utiliser une librairie qui compare les images.
IS : d’accord.
Julien : c’est ce que font les navigateurs pour leurs tests de régression pour voir s’ils cassent pas des choses.
Mais des fois ils ont pas tous leurs tests d’ailleurs.
Mais, tu prends un screenshot à un moment donné de tous tes composants, voire d’une page finale, et tu fais tourner un petit robot de temps en temps qui compare à un PNG préenregistré pour voir si c’est la même chose. Bah ouais quoi ! [Rires]
Non ! Un truc bête, il y a des librairies en Python qui font ça en deux secondes.
On avait fait ça dans une boîte avec Mathieu avant.
Un autre intervenant : c’est quand même fastidieux.
Julien : chut. [rires]
Julien : j’ai ça à donner à quelqu’un. J’hésite. [Applaudissements]