Ce qu’il faut savoir sur la nouvelle version d’Outlook.com

L’an dernier, Microsoft a annoncé son intention de remplacer son webmail Outlook.com par une version équivalente à son autre webmail Office 365. Le mois dernier, Microsoft a précisé que cette nouvelle version d’Outlook.com était en cours de déploiement partout dans le monde. Si cette nouvelle version n’est pas encore déployée pour tous les comptes Outlook en France, vous devriez pouvoir y accéder en vous créant un nouveau compte @outlook.fr dès aujourd’hui.

Je teste régulièrement mes intégrations d’e‑mails sur ce webmail (et sa version Office 365) depuis un an. Voici un petit compte-rendu de mes observations, et des bonnes et mauvaises nouvelles que ce webmail apporte.

Au revoir les anciens bugs et hacks

L’ancienne version d’Outlook.com avait une façon bien à elle de filtrer les styles, et le support de certaines propriétés dépendait de la casse. Ainsi, pour utiliser des propriétés comme float ou margin, il fallait impérativement écrire ses propriétés dans une casse autre que minuscule (par exemple Float ou Margin). J’avais identifié 19 propriétés concernées par cette bizarrerie. C’en est fini sur la nouvelle version d’Outlook.com.

L’ancienne version d’Outlook.com avait aussi des styles par défaut assez enquiquinant. Par exemple, des règles ciblant toutes les balises h2 ou h3 ajoutaient des background-color et border-bottom. Le webmail avait aussi une règle * { line-height:142%; } pas très intelligente. C’en est fini sur la nouvelle version d’Outlook.com, et je n’ai pas remarqué de styles génériques gênants.

L’ancienne version d’Outlook.com préfixait les noms de classes en CSS par .ecx et par la classe .ExternalClass. Mais il y avait aussi quelques bugs de préfixage des règles CSS, où les classes correspondant à des noms de balises étaient malencontreusement épargnées. Le nouvel Outlook.com préfixe les noms de classes en CSS par .x_ et par une classe au nom généré aléatoirement à chaque session de navigation. Par exemple, le sélecteur .toto devient .rps_a113 .x_toto. Ça fonctionne bien, et le bug des classes correspondant à des noms de balises a disparu.

L’ancienne version d’Outlook.com avait également un bug ridicule sur mobile où la classe .ExternalClass (par laquelle toutes les règles CSS étaient préfixées) était tout simplement absente du code HTML. Résultat : aucun style dans une balise <style> n’était applicable. Le nouvel Outlook.com applique les mêmes règles de préfixage que ce soit sur desktop ou mobile, et cette fois-ci en incluant bien la classe par laquelle tout est préfixé.

Bonjour les nouveaux bugs et hacks

Mais tout n’est pas rose dans cette nouvelle version d’Outlook.com. À commencer par son support de CSS. Finies les transformations CSS, les transitions CSS, les :hover, et surtout adieu les media queries. Tout le contenu d’une media query est purement et simplement supprimé. Ça fait d’Outlook.com l’un des rares clients mail à ne permettre aucune distinction entre sa version mobile et sa version desktop (là où les webmails de Gmail et Yahoo, par exemple, supportent bien les balises <style> et les media queries sur desktop, mais pas sur mobile).

La nouvelle version d’Outlook.com ne supporte plus non plus les sélecteurs d’attributs en CSS. Mais il a la fâcheuse manie de faire ça en supprimant le sélecteur d’attribut de la règle CSS concernée. Ainsi, le sélecteur suivant…

table *[aria-labelledby="toto"] a { color:red; } 

… est transformé par la nouvelle version d’Outlook.com en :

.rps_a113 table a { color:red; } 

Autrement dit, ce sélecteur n’a plus du tout la même signification que le sélecteur initial désiré. Ça peut poser des problèmes. Mais ça peut aussi apporter des solutions. Ainsi j’ai trouvé qu’en utilisant un sélecteur d’attribut avec un nom d’attribut bidon, on peut créer des styles appliqués uniquement sur le nouvel Outlook.com. J’ai pris l’habitude d’utiliser un sélecteur [owa] (pour Outlook Web App). Ainsi, le sélecteur suivant…

[owa] .toto { color:red; } 

… est transformé par la nouvelle version d’Outlook.com en :

.rps_a113 .x_toto { color:red; } 

La règle est alors appliquée uniquement sur Outlook.com. Pratique !

La nouvelle version d’Outlook.com supprime également toute balise <input>, faisant une grosse croix sur toute possibilité de faire des e‑mails interactifs.

Cette nouvelle version d’Outlook.com a aussi des bugs bien tordus. Par exemple, si une balise <style> contient une déclaration @quelquechose qui elle même contient un anti-slash, alors les polices déclarées entre guillemets dans un attribut style pour la propriété font-family vont être complètement déforméés. Ainsi, le code suivant…

<style type="text/css">
    @ { "\" }
</style>
<p style="font-family: 'Indie Flower', 'Arial', 'Helvetica', 'Lucida Grande', 'sans-serif';">Test 1</p>
<p style="font-family: 'Indie Flower', 'Arial', 'Helvetica', 'Lucida Grande', sans-serif;">Test 2</p>
<p style="font-family: 'Indie Flower', 'Arial', 'Helvetica', Lucida Grande, sans-serif;">Test 3</p>
<p style="font-family: 'Indie Flower', 'Arial', Helvetica, Lucida Grande, sans-serif;">Test 4</p>
<p style="font-family: 'Indie Flower', Arial, Helvetica, Lucida Grande, sans-serif;">Test 5</p>
<p style="font-family: Indie Flower, Arial, Helvetica, Lucida Grande, sans-serif;">Test 6</p>

… est transformé par la nouvelle version d’Outlook.com en :

<style type="text/css"><!--  --></style>
<div>
	<div>
		<p style="font-family:'ni ">Test 1</p>
		<p style="font-family:'ni lower', 'A">Test 2</p>
		<p style="font-family:'ni Flower', 'Aril', 'Helve">Test 3</p>
		<p style="font-family:'nie Flower' 'Arial', Helvtica, Luci">Test 4</p>
		<p style="font-family:'ndie Fower', Aril, Helvetica, ucida Gran">Test 5</p>
		<p style="font-family:Indie Flower,Arial,Helvetica,Lucida Grande,sans-serif">Test 6</p>
	</div>
</div>

Ce que j’ai compris, si toutes les polices sont déclarées entre guillemets, c’est que l’algorithme d’Outlook.com ressemble à quelque chose comme ça. Il compte le nombre de polices déclarées dans la liste, et soustrait deux (appelons le chiffre obtenu n). Puis il commence à la première ouverture de guillemets dans la liste et ne conserve que les n premiers caractères pairs. J’avais prévenu que c’était tordu.

Un autre bug plus courant concerne les liens. La nouvelle version d’Outlook.com supprime les balises <a> quand elle estime que le contenu de l’attribut href n’est pas un lien. Ce contenu se retrouve alors placé entre crochets avant le contenu texte de la balise <a> concernée. Ainsi le code suivant…

<a href="Hello">world</a>

… est transformé par la nouvelle version d’Outlook.com en :

[Hello]world

Cette nouvelle version d’Outlook.com nous réserve certainement plein d’autres surprises. N’hésitez pas à m’en faire part en commentaires ou sur Twitter si vous découvrez d’autres joyeusetés.