Les articles de la catégorie « Intégration »

La semaine dernière, Apple fêtait les 30 ans du Mac avec une page dédiée. Je suis tombé sur cette page via John Gruber, qui s’extasiait qu’elle soit responsive. Ça m’a tout de suite surpris, car j’ai tendance à penser qu’Apple n’aime pas trop le responsive design (même s’ils ont fait quelques tentatives sur certains e-mails).

Aussitôt les 11,3 Mo de la page chargée sur mon ordinateur (sans commentaire), je me suis empressé d’assouvir mon TOC d’intégrateur et de redimensionner la page. Et là, surprise, il se passe bien quelque chose (les textes sont redimensionnés), mais la page n’est clairement pas responsive.

Je vais donc visiter la page sur mon iPhone, curieux de voir le rendu de cette page. Après tout, le gabarit du site d’Apple n’est pas responsive. Alors comment est-ce qu’Apple aurait pu rendre une page responsive sur un site non responsive ?

La réponse est simple : en trichant.

Comme le dirait Cyril Lignac, « c’est très astucieux ». Plutôt que de rendre leur gabarit responsive (avec l’enfer que ça peut engendrer), les intégrateurs d’Apple ont préféré simplement mettre à l’échelle le header et le footer du site. Pour ça, ils utilisent simplement la propriété transform:scale(0.3125); (où 0.3125 est une valeur calculée en JavaScript le ratio calculé entre la taille du site, 1024px, et la largeur de l’écran d’un iPhone, 320px).

La propriété transform étant ce qu’elle est, Cyril Lignac s’exclamerait surement aussi « c’est très gourmand ».

Si ce n’est clairement pas une solution optimale (la navigation reste difficilement utilisable dans cet état), je trouve l’idée quand même très originale. À noter que la même chose avait été utilisé par Apple pour la page du Mac Pro.

Voici une partie du footer de Sarenza.com vue dans une résolution de 540px de large, actuellement en production.

Voici le header de 3suisses.be dans n’importe quelle résolution supérieure à 980px de large, actuellement en production.

Voici le header du site Time.com dans une résolution entre 500px et 700px de large, actuellement en production. C’est comme ça en production depuis au moins les six derniers mois où j’ai visité le site.

Et voici le header du site de la marque Tape à l’Oeil dans une résolution inférieure à 768px de large sur desktop. C’est comme ça en production depuis la refonte du site en septembre dernier.

Je n’essaie pas de jouer au petit malin en vous montrant ces exemples. Ces exemples sont des exemples de site responsive de marques renommées qui à un moment rencontrent un problème d’affichage plus ou moins grave. Je ne dis pas que ces sites sont mal conçus (je trouve le menu de 3suisses.be particulièrement bien intégré). Mais ces sites se heurtent à un problème que j’ai également rencontré l’an passé en travaillant sur des adaptations responsive de gros sites.

On assume depuis longtemps qu’il est indispensable de tester son site sur différents navigateurs, sur différentes versions de ces navigateurs, sous différents systèmes d’exploitation, sous différentes versions de ces systèmes d’exploitation. Avec un site responsive, il faut toujours faire ça, mais en plus tester toutes les largeurs et hauteurs de fenêtres possibles.

Bienvenue dans l’enfer du responsive.

Et c’est encore plus un enfer dans une équipe de grande taille, ou avec différents prestataires externes, ou sur un site faisant appel à des contenus extérieurs (ou réalisés en externe). Et ça l’est encore plus dans le contexte d’un site dont le contenu évolue constamment.

Je n’ai malheureusement pas encore trouvé de solution miraculeuse pour identifier ce genre de soucis, à part une vigilance manuelle accrue. J’ai bien essayé de faire des captures d’écran de sites dans différentes résolutions avec des navigateurs sans-tête comme PhantomJS, ou alors avec des services comme BrowserStack. Mais cela nécessite toujours une vérification manuelle des captures. Alors qu’on s’empresse de plus en plus à faire des sites responsive, il me semble important de commencer à instaurer des processus de monitoring des designs de sites. (Je crois avoir vu passé quelque chose dans ce sens l’année dernière du côté de la BBC ou du Guardian, mais je n’ai rien retrouvé. C’est la BBC qui a un outil pour ça, basé sur PhantomJS, merci Kenny.)

En attendant, en tant qu’intégrateur, je ne peux que de redoubler de prudence lors de la conception de mon code (le design atomique, ça aide), et m’assurer que tout le monde comprenne bien pourquoi ça prend un peu plus de temps pour changer un « s ». Et aussi inviter mes collaborateurs à mettre en pratique la maxime du métro New-Yorkais : « If you see something, say something ».

Cette semaine, je me suis encore bien amusé sur de l’intégration d’e-mails. Et plus particulièrement sur quelques découvertes faites sur l’application Gmail sur Android. Je ne teste pas systématiquement sur cette application car elle ne fait pas parti des batteries de tests inclus dans des services comme Email on Acid ou Litmus. Et pourtant, cette application est un véritable concentré d’amusement.

Et quand je dis amusement, je veux en faire parler d’un véritable cauchemar. Je me suis rendu compte qu’un gabarit responsive que j’utilisais régulièrement ne s’affichais pas du tout correctement sur Gmail 4.6 sur une Nexus 7 de 2012. Alors que je m’attendais à avoir un affichage normal de la version desktop (Gmail ne supportant pas les media queries), je me suis retrouvé avec un e-mail tout cassé. Je suspectais l’application d’appliquer un redimensionnement sur des tailles de tableaux. Du coup, je me suis fait un e-mail de test avec une série de tableaux les uns en dessous des autres, chaque <table> ayant une largeur différente (640, 600, 550, …, 400, 350, 320).

<table border="0" cellpadding="0" cellspacing="0" width="640" bgcolor="red">
	<tr>
		<td>Lorem ipsum dolor sit amet…</td>
	</tr>
</table>

Voici le rendu que j’espérais obtenir.

Et voici le résultat obtenu.

OK. C’est le genre de moment où j’annule tous mes rendez-vous et je débranche le téléphone, parce que l’après-midi promet d’être longue.

Il s’avère qu’en fait, l’application Gmail sur Android supprime tous les attributs width précisés sur des <table>. Voilà, comme ça, c’est fait, merci Google. J’ai donc relancé un test similaire, mais en précisant cette fois-ci la largeur sur l’unique <td> de chacun de ces tableaux, et non plus sur les tableaux en eux-même.

<table border="0" cellpadding="0" cellspacing="0" bgcolor="red">
	<tr>
		<td width="640">Lorem ipsum dolor sit amet…</td>
	</tr>
</table>

Voici le résultat obtenu.

C’est déjà mieux. Mais Gmail ne semble pas tenir compte de la taille précisée sur les premiers tableaux (respectivement 640, 600, et 550 pixels de large). Mais ça c’était sur une tablette Nexus 7. En testant sur un téléphone Nexus 5, j’ai commencé à comprendre un peu plus précisément ce qu’il se passait. Voici le rendu obtenu avec le même code :

 

Sur Nexus 5, tous les tableaux sont forcés à la largeur de l’écran, sauf les deux derniers (de 320 pixels de large). En affinant un peu plus mes tests, j’ai fini par déterminer que sur Nexus 5, les tableaux seront affichés au maximum à 324 px de large, contre 525 px sur une Nexus 7.

En vérifiant avec d’autres e-mails, je me suis rendu compte que Gmail n’appliquait pourtant pas systématiquement ce redimensionnement forcé. Et il s’avère que c’est assez « facile » de le contourner (j’ai quand même bien mis deux heures pour comprendre ça tout seul).

Pour forcer Gmail à ne pas effectuer de redimensionnement automatiquement, il « suffit » d’avoir dans son e-mail au moins un tableau avec au minimum deux colonnes contenant des images dont la taille atteint la taille désirée. (Je vous laisse imaginer le nombre de tests qu’il m’a fallu pour arriver à cette conclusion, et maintenant vous comprenez pourquoi ça m’a pris deux heures.)

Autrement dit, si vous voulez forcer l’affichage de votre e-mail à 640 px de large, vous devez insérer un tableau avec deux cellules, contenant deux images de 320 px de large chacune.

<table border="0" cellpadding="0" cellspacing="0" class="mobileHide">
	<tr>
		<td><div style="font-size:1px; line-height:1px;"><img src="spacer.gif" width="320" height="1" alt="" border="0" style="display:block;" class="mobileHide" /></div></td>
		<td><div style="font-size:1px; line-height:1px;"><img src="spacer.gif" width="320" height="1" alt="" border="0" style="display:block;" class="mobileHide" /></div></td>
	</tr>
</table>

Le style suivant permettra ensuite de s’assurer que ce tableau ne s’affiche pas dans la version mobile de l’e-mail.

@media only screen and (max-width: 480px) {
	table[class="mobileHide"], img[class="mobileHide"] { display:none !important; }
}

C’est exactement le genre de fonctionnalité que je déteste dans un moteur de rendu HTML/CSS. Sur le papier, forcer les largeurs des tableaux ne contenant qu’une seule cellule à la taille de l’écran sonne comme une bonne idée pour les utilisateurs. En pratique, ça ne fonctionne pas vraiment, et ça rend le travail des intégrateurs un véritable enfer.

Habituellement, quand j’intègre un formulaire et que je prévois des styles pour les champs erronés, j’ajoute (côté client et côté serveur) une classe .field--error sur l’élément parent du champ concerné. Hier, j’ai voulu faire le malin et styler des champs de formulaires erronés avec le pseudo-sélecteur CSS :invalid. Et je me suis rendu compte que ça ne correspondait pas du tout à ce à quoi je m’attendais.

Le problème, c’est qu’un simple input:invalid { border:1px solid red; } s’applique tout le temps, dès le chargement de la page, sans la moindre action de la part d’un utilisateur. Pour comprendre le pourquoi du comment, je me suis tourné vers les spécifications des sélecteurs CSS niveau 4 du W3C.

E:valid, E:invalid
Un élément de saisie utilisateur qui

Je dois être maudit. La seule partie qui m’intéresse sur une spécification de 17 000 mots est incomplète. Je suppose qu’il y a un nom de loi pour ça.

Mais ce n’était que la version Editor’s Draft de la spécification. Je me tourne donc vers la version Working Draft.

Un élément est :valid ou :invalid quand son contenu ou sa valeur est, respectivement, valide ou invalide en respect avec la sémantique de validité des données définie par le langage du document (par exemple [XFORMS11] ou [HTML5]). Un élément qui n’a pas de sémantique de validité de donnée n’est ni :valid ni :invalid.

Un champ de formulaire est donc toujours valide ou invalide, et ne dépend absolument pas de l’interaction utilisateur Peter-Paul Koch suggère que les champs devraient être :indeterminate. Mais ce sélecteur ne correspond qu’à l’état indéterminé d’une checkbox.

J’ai donc cherché un peu plus s’il n’existait pas un sélecteur correspondant  à ce que je cherche à faire (à savoir styler un champ erroné après saisie ou après validation du formulaire). Et il se trouve que Mozilla (la fondation qui défend le web ouvert et les standards) a un sélecteur propriétaire et non standardisé, :-moz-ui-invalid, qui sert exactement à ça. Un message datant de décembre 2010 de Ian Hickson indique l’intérêt du W3C pour cette fonctionnalité. Et puis plus rien.

En creusant alors un peu plus les spécifications des sélecteurs CSS niveau 4, j’ai fini par trouver mon bonheur avec le sélecteur :user-error.

La pseudo-classe :user-error représente un champ de saisie avec une entrée incorrecte, mais seulement après que l’utilisateur ait interagit de manière significative avec lui.

Mais forcément, c’est du « CSS 4 » et ce n’est donc supporté dans aucun navigateur à l’heure actuelle.

En résumé, en 2013, on peut faire les Simpsons en full CSS, mais pas styler un champ de formulaire erroné.

Aujourd’hui, j’ai reçu une newsletter d’Apple. Jusque là, rien de bien intéressant. Sauf que l’affichage sur mon iPhone m’a troublé.

Mais… Mais… C’est un e-mail responsive ! Alléluia ! Apple montre enfin un léger signe d’intérêt pour le responsive design. Ni une ni deux, j’ai donc fait ce que n’importe qui aurait fait en recevant cet e-mail. Je l’ai marqué comme spam. J’ai inspecté son code source.

Et là déception, Apple fait ce que j’appelle du « responsive mais pas trop ». Un e-mail, deux intégrations totalement distinctes l’une à la suite de l’autre, et affichées selon la résolution. (Ça va vite à résumer, mais n’empêche que rien que ça dans un e-mail ça reste un joli casse-tête.)

Par contre, il y a une chose que j’aime énormément sur l’e-mail en version mobile : l’absence de header. Pas de logo de la marque, pas de navigation, on commence directement par le contenu.

Après vérification, Apple a commencé à faire des e-mails responsive avec l’e-mail de lancement des iPhone 5s et 5c le 20 septembre dernier.

Voici des liens vers les e-mails en question :

• E-mail responsive iPhone 5s et 5c (captures d’écran desktop et mobile)
• E-mail responsive Macbook Pro (captures d’écran desktop et mobile)