Les archives de la catégorie "Intégration"

HTML5, CSS3 et les technologies qui fonctionnent

Il y a quelques jours, j'ai lu via le blog de Kaelig cet article sur le recrutement de développeurs front-end :

2) Ne me demandez pas de connaître XHTML/HTML4.1/HTML5

Les balises sont définies en HTML. A moins que vous n'ayez besoin d'un balisage pouvant être parsé en XML pour une raison ou une autre, me demande de connaître XHTML revient à dire : "je spamme de mots-clés pour être sûr de dégoter la bonne personne".

Une meilleure façon de le dire serait : "Nous nous attendons à ce que vous connaissiez HTML, à utiliser ses balises de manière efficace, et d'avoir une bonne compréhension de la sémantique derrière chaque balise".

Protip : ne laissez personne vous dire qu'il connaît HTML5 si tout ce qu'il sait se limite à l'utilisation du doctype.

Il y a quelques jours, j'ai aussi vu passé ce tweet de Benoît Meunier citant une interview de Judy Ramey (elle même citant Danny Hillis) :

Les choses qu'on appelle « technologies » sont les choses qui ne fonctionnent pas encore. Personne ne parle de la technologie d'interrupteurs d'éclairage.

Si j'évite au maximum de parler de "HTML5" ou de "CSS3" avec mes clients, je plaide coupable d'une utilisation parfois abusive de certains termes un peu fourre-tout. Par contre, je me rends compte que plus le temps passe, moins j'utilise ces termes pour désigner les choses "qui fonctionnent".

Box-shadow ? C'est du CSS. Les animations et transitions ? Du CSS. Les filtres et shaders ? Du CSS3 !

C'est très subjectif. Mais j'ai l'impression que dans le langage courant, HTML et CSS désignent tout ce qui fonctionne, alors que HTML5 et CSS3 désignent ce qui ne fonctionne pas encore.

Une licorne en intégration

Devinette ! Quel est le point commun entre les morceaux de code suivants ?

<!--[if IE 10]><html class="ie10"><![endif]-->
<!--[if IE 9]><html class="ie9"><![endif]-->
<!--[if IE 8]><html class="ie8"><![endif]-->
<!--[if IE 7]><html class="ie7"><![endif]-->
<!--[if !IE]>--><html><!--<![endif]-->
-webkit-border-radius:5px;
-moz-border-radius:5px;
-o-border-radius:5px;
-ms-border-radius:5px;
border-radius:5px;

Bon, à part le côté répétitif lourdingue, vous ne voyez pas ?

Ils contiennent tous les deux une licorne, une créature légendaire, inspirée du mélange d'autres créatures, elles, bien vivantes.

Dans le premier exemple, la ligne <!--[if IE 10]><html class="ie10"><![endif]--> n'a jamais existé. Microsoft a abandonné le support des commentaires conditionnels dans Internet Explorer 10, et ce dès la deuxième Platform Preview.

Dans le deuxième exemple, les lignes -o-border-radius:5px; et -ms-border-radius:5px; n'ont elles non plus jamais existé. Microsoft et Opera ont tous les deux supporté la propriété sans préfixe.

Pourtant, je tire ces exemples de code légendaire de sites récents, codés par de vrais intégrateurs, dans la vraie vie. Le premier exemple est un bon rappel que dans le métier d'intégrateur, la veille fait partie intégrante de notre travail. Et le deuxième exemple est un bon rappel qu'il n'y a jamais de bonne pratique universelle (et, non, désolé, ajouter tous les préfixes possibles pour toutes les propriétés ça n'a jamais vraiment été une bonne idée).

La compression d’images par les opérateurs

Il y a deux semaines, bluetouff chez reflets.info a découvert que
SFR modifie le source HTML des pages que vous visitez en 3G. "Soit", me suis-je dit. Si la pratique est condamnable de la part d'un FAI, elle n'en reste pas moins assez proche de ce que peut faire un navigateur proxy comme Opera Mini ou bientôt Chrome sur Android.

Puis ce week-end, j'ai lu le guide sur l'intégration d'email marketing chez Mailchimp. Je suis resté scotché devant ce paragraphe (page 35 dans la version PDF) :

Si possible, testez vos e-mails lors de leur envoi avec différents FAI. Différents serveurs d'e-mails altérerons votre message avant qu'il n'arrive dans la boîte de réception de votre destinataire. Par exemple, certains FAI utilisent des serveurs d'e-mails qui retireront tout contenu sous une ligne dans votre e-mail qui commence par un point (on sait, c'est bizarre). Nous avons été surpris de voir à quel point un e-mail pouvait avoir un rendu différent sous Outlook 2003, mais reçu via Comcast, Bellsouth et Earthlink.

"Pfiou", me suis-je dit. J'ai bien de la chance de ne jamais avoir rencontré ce genre de problème.

Et puis c'est arrivé. Hier. Un e-mail, tout ce qu'il y a de plus classique, intégré par mes soins, livré dans les temps. Et une heure plus tard, un mail de retour du client. "Mon collègue a un rendu bizarre sur son téléphone", avec une capture d'écran de l'application Mail sous iOS, et effectivement un rendu étrange. Différentes images, censées être sur fond blanc avec du texte dessus, ont une couleur de fond différente.

"Impossible", me suis-je dit. Je revérifie tout de mon côté. Mes tranches, mes images, mon code. Rien. Je regarde la capture d'écran qui prouve pourtant bien l'existence d'un problème. Et puis je m'arrête sur la barre de statut d'iOS, qui indique fièrement : "Orange 3G".

"Non", me suis-je dit. Ça ne peut quand même pas être ça. Je teste alors sur mon iPhone, chez SFR, en 3G. Rien. J'envoie l'e-mail à tous mes collègues afin de tester sur différents appareils et différentes connexions. Et là, ça y est, miracle, le bug est apparu. Et effectivement, sur une connexion Orange, en 3G, les images sont dégradées.

J'ai donc fait ce que toute personne saine d'esprit ferait dans ce cas là : un tableau avec pleins d'images de différentes tonalités de gris dans différents formats (JPG à 100%, GIF, PNG 8 bits, et un simple background HTML comme témoin). J'ai testé, via la connexion partagée de mon collègue depuis son iPhone sur mon Macbook ou sur mon iPhone.

Et le résultat est sans appel.

Orange modifie vos couleurs

Les trois formats d'images sont recompressés. Mais le GIF est recompressé de manière absolument horrible, à tel point que ça saute aux yeux. Même le blanc n'est plus blanc.

J'ai fait différents tests sur des images GIF, dans différents modes d'enregistrement, avec une palette de couleurs plus ou moins élevée, pour essayer de comprendre ce qui déclenchait cette recompression. Et je n'ai pas la réponse.

D'après mes tests, ça ne dépend pas :

  • De la dimension des images. Certaines images plus grandes que d'autres n'ont pas eu d'effet visible lors de la recompression par Orange.
  • Du poids des images. Certaines images de 3 Ko ont été sauvagement recompressées alors que pas d'autres de 8 Ko.
  • De la palette de couleurs. Certaines images forcées à une palette de 16 couleurs sont encore recompressées de manière visibles. D'autres avec 32 couleurs, pas.

Je pense que le principal coupable est donc l'outil de compression GIF utilisé par Orange, et qu'il n'y a pas malheureusement pas grand chose à faire pour éviter ça. Le problème semble connu puisqu'il avait déjà été remonté dans un article de 2011.

Une solution consisterait alors à utiliser le format PNG (8 ou 24 bits) plutôt que du GIF. Sauf que malheureusement d'anciens logiciels mails, comme Lotus Notes 6 et 7, ne supportent pas du tout le format PNG et affichent des images cassées à la place.

Je n'ai pu faire des tests que chez SFR et Orange (Sosh). Mais si vous souhaitez savoir si votre opérateur compresse comme un sagouin les images à votre place, je vous invite à tester cette page et à partager vos captures d'écran dans les commentaires.

La cible

Sur le web, c'est à mon avis une mauvaise idée d'établir un lien entre le positionnement de son site, sa cible de communication, et des notions techniques de support en intégration. Bien souvent, ça sert d'excuse pour faire son travail d'intégrateur pauvrement. "Le site ne fonctionne pas sur Windows Phone, mais c'est ok, ce n'est pas notre cible." Ou "Le site fait 3 Mo mais c'est ok, notre cible a une bonne connexion."

Je pense que la cible du web est le mieux résumée par Tim Berners Lee (ici lors de la cérémonie d'ouverture des Jeux Olympiques de Londres en 2012).

"This is for Everyone", Tim Berners Lee lors de la cérémonie d'ouverture des Jeux Olympiques de Londres en 2012

Le web c'est pour tout le monde. Cela signifie qu'en tant qu'intégrateur, en tant que concepteur web, vous devez faire en sorte que votre site soit accessible au plus grand nombre. Bien sûr, c'est une vision idéaliste. C'est la cible à atteindre. Mais le contexte d'un projet et ses contraintes, comme par exemple le temps consacré à l'intégration, fait qu'on n'y arrivera pas toujours. Mais parfois, les modifications les plus simples peuvent avoir des conséquences inattendues.

En décembre dernier, Chris Zacharias racontait une anecdote comme je les aime sur son travail d'optimisation sur Youtube.

Il y a trois ans, quand j'étais développeur web chez Youtube, l'un des ingénieurs séniors a commencé à se plaindre du poids trop élevé de la page de lecture d'une vidéo. La page gonflait jusqu'à 1,2 Mo et des douzaines de requêtes. Cet ingénieur s'exclamait ouvertement "Si ils peuvent écrire un clone complet de Quake en moins de 100 Ko, on n'a aucune excuse pour ça !". Étant donné que j'étais d'accord avec lui et que j'étais content de trouver un nouveau projet, j'ai décidé de défendre cette cause et de faire passer la page de lecture de vidéo à moins de 100 Ko. Dans la navette pour chez moi ce soir là, j'ai codé un prototype. J'ai décidé de limiter les fonctionnalités à un header basique, le lecteur vidéo, cinq vidéos associées, un bouton de partage, un bouton de favoris, et dix commentaires chargés en AJAX. J'ai appelé ce projet "Feather".

Même avec aussi peu de fonctionnalités, la page pesait déjà 250 Ko. J'ai creusé dans le code et j'ai réalisé que nos outils d'optimisation (comme Closure compiler) étaient incapables d'exclure du code qui n'était pas utilisé dans la page elle-même (ce qui serait une attente injuste pour un tel outil dans ces circonstances). Le seul moyen de réduire le code encore plus était d'optimiser à la main les CSS, JavaScript et sprites d'images. Après trois jours pénibles, je suis parvenu à une solution bien plus maigre. Mais je n'étais toujours pas sous les 100 Ko. Alors qu'on venait de finir d'écrire le lecteur vidéo en HTML5, j'ai décidé de l'utiliser plutôt que le lecteur bien plus lourd en Flash. Bam ! 98 Ko et seulement 14 requêtes. J'ai parsemé le code de contrôles de surveillance basiques, et j'ai lancé cette version pour une fraction de notre trafic.

Après une semaine de collecte de données, les chiffres nous sont parvenus... Et ils étaient déconcertants. La moyenne totale de la latence de la page sous Feather avait augmenté. J'avais diminué le poids de la page et le nombre de requêtes à un dixième de ce qu'il y avait avant, et d'une manière ou d'une autre, les chiffres montraient que les vidéos mettaient plus longtemps à se charger sous Feather. Ce n'était pas possible. En creusant dans les chiffres un peu plus et après de nombreux tests répétés, ça n'avait aucun sens. J'allais abandonner le projet, ma vision du monde totalement brisée, quand mon collègue a découvert la réponse : la géographie.

Quand nous avons visualisé les données géographiquement et les avons comparé par région, il y avait une augmentation disproportionnée du trafic d'endroits l'Asie du Sud, l'Amérique du Sud, l'Afrique et même des régions isolées de Sibérie. Et quelques enquêtes supplémentaires ont révélé que, dans ces endroits, le temps moyen de chargement d'une page sous Feather était de plus de deux minutes ! Cela signifiait qu'une page classique de vidéo, à plus d'un méga-octet, prenait plus de vingt minutes pour se charger ! C'était la sanction infligée avant même que le flux vidéo n'ait la chance d'afficher la première image. En conséquence, des populations entières ne pouvaient simplement pas utiliser Youtube car c'était trop long pour voir quoi que ce soit. Avec Feather, même s'il fallait plus de deux minutes pour afficher la première image d'une vidéo, regarder une vidéo était devenu une vraie possibilité. En une semaine, l'existence de Feather s'est propagé dans ces zones géographiques et nos chiffres ont été complètement faussés en conséquence. De nombreuses personnes qui ne pouvaient pas utiliser Youtube auparavant en avaient soudainement la possibilité.

Grâce à Feather, j'ai appris une leçon précieuse sur l'état du web à travers le reste du monde. Nombre d'entre nous avons la chance de vivre dans des régions avec un bon débit, mais il y a encore de larges portions du monde pour qui ce n'est pas le cas. En gardant notre code client petit et léger, vous pouvez littéralement ouvrir votre produit à de nouveaux marchés.

Si vous bloquez activement l'accès à votre site sur mobile ou pour des vieilles versions de navigateur, ou si votre page fait plus de 5 Mo, vous risquez effectivement de vous rendre compte que votre audience n'utilise pas de mobile et a une bonne connexion. Mais ça ne signifie pas que c'est le cas de votre cible.

Un pré-processeur est un outil

Il y a une résurgence d'articles récemment sur les pré-processeurs CSS :

J'avais déjà donné mon avis sur le sujet l'année dernière dans mon manifeste du CSS pur et dur. Il se trouve que depuis cet article, j'ai eu l'occasion de travailler sur un projet utilisant Sass. Mon avis n'a pas vraiment changé, mais mes craintes ont un peu changé de cible.

Le problème, ce ne sont pas les pré-processeurs en eux-même. Mais comme le dit très bien Roy Tomeij chez The Sass Way :

Sass ne crée pas du mauvais code. Ce sont les mauvais développeurs qui le font.

J'en parlais déjà l'année dernière, selon moi, la qualité d'une intégration se mesure sur trois objectifs (dans l'ordre) : l'internaute, le projet et moi. Le problème à mon avis, c'est qu'un pré-processeur incite à se concentrer totalement sur le dernier point (mon petit nombril d'intégrateur) en oubliant totalement le premier (l'internaute). Et le risque, c'est d'oublier totalement pourquoi on fait une intégration et de générer du code bouffi comme celui-ci :

a.icon-listen-bl:hover,
.event-related .box-title a:hover,
.category-related .box-title a:hover,
.readmore a:hover,
.footer a:hover,
.pagination a:hover,
.news a:hover,
.latest-tweet .date a:hover,
.feature .box-header .title a:hover,
.caption .title a:hover,
.full-agenda-link a:hover,
.article a:hover,
.medialib-nav a:hover,
.timeline-months a:hover,
.Timeline .feature .box-footer a:hover,
a.icon-listen-bl:active,
.event-related .box-title a:active,
.category-related .box-title a:active,
.readmore a:active,
.footer a:active,
.pagination a:active,
.news a:active,
.latest-tweet .date a:active,
.feature .box-header .title a:active,
.caption .title a:active,
.full-agenda-link a:active,
.article a:active,
.medialib-nav a:active,
.timeline-months a:active,
.Timeline .feature .box-footer a:active,
a.icon-listen-bl:focus,
.event-related .box-title a:focus,
.category-related .box-title a:focus,
.readmore a:focus,
.footer a:focus,
.pagination a:focus,
.news a:focus,
.latest-tweet .date a:focus,
.feature .box-header .title a:focus,
.caption .title a:focus,
.full-agenda-link a:focus,
.article a:focus,
.medialib-nav a:focus,
.timeline-months a:focus,
.Timeline .feature .box-footer a:focus {
text-decoration: underline;
}

Aucun humain sain d'esprit n'aurait écrit manuellement ce code, bouffi et rempli de sélecteurs peu efficaces.

Un pré-processeur est un outil. Au même titre que votre système d'exploitation, votre IDE, vos bibliothèques CSS ou JavaScript préférées, ce sont des outils.

Si vous utilisez une visseuse électrique et que vous abîmez tous vos pas de vis, il y a des chances pour que soit vous utilisez une mauvaise visseuse, soit vous ne savez pas vous en servir. Un pré-processeur n'est pas un mauvais outil.

Mais comme on dit dans l'informatique : PEBKAC.