Voir input et mourir

Wed, 07 Dec 2011 08:38:47 +0100

HTML5 c’est bien. CSS3 aussi.
Bon ok faut pas vouloir faire un dégradé rapidement qui soit compatible Gecko/Webkit, ni faire en une ou deux lignes une boîte avec des coins arrondis.
En plus on a de nouveaux jouets, comme les input type=‘search’. Justement en parlant de ça, il se trouve que pour un client je me suis retrouvé devant une maquette où se trouve un champs de recherche habituel, celui-ci étant habillé de gris entre autres choses… À charge pour moi de faire une intégration HTML5/CSS3 de la chose.

Comme je passe pas mes journées à intégrer des inputs j’ai commencé par des tests. Et là, c’est le drame.
Voici une page html standard pour mon test :

<!DOCTYPE html>
<html lang="fr">
<head>
   <meta charset="utf-8" />
   <title>input[type="search"]</title>
   <meta http-equiv="X-UA-Compatible" content="chrome=1">
</head>
<body>
   <form id="search">
      <input type="search" placeholder="Rechercher…" name="q" autocomplete="off">
   </form>
</body>
</html>

On peut constater d’emblée une différence fondamentale de rendu entre Gecko et Webkit

Différences de rendu entre Gecko et Webkit pour <input type="search">

Qu’importe me dis-je, je m’en vais y mettre un coup de CSS dans sa face et on verra bien qui est le maître du monde. Dont acte :

	#search input[type="search"] {
		display: block;
		background-color: #666;
		color: #fff;
		border: 1px solid #666;
		border-top-color: #454545;
		border-left-color: #454545;
		padding: 10px;
		font-size: 16px;
		-webkit-border-radius: 6px;
		-moz-border-radius: 6px;
		border-radius: 6px;
		width: 190px;
	}

Et quand on vérifie le rendu dans Gecko et Webkit on se rend compte qu’on a pas le cul sorti des ronces

Les CSS c’est beau… quand ça marche

Diantre, normalement ça marche. Et pas là… Après avoir vérifié et revérifié le html et la css — les coquilles ça arrive — j’ai ouvert ma page dans Safari et en vérifiant la page avec l’inspecteur web j’ai découvert avec horreur que Webkit utilise ses propres règles CSS pour afficher un input type="search".

Là où Gecko se borne — pour l’instant — à afficher un input tout à fait classique, Webkit utilise des règles CSS très propriétaires pour singulariser ce type d’élément de formulaire. Si on scrute avec l’inspecteur voilà ce que nous dit Webkit :

input[type="search"] {
	-webkit-appearance: searchfield;
	box-sizing: border-box;
}

Donc, si on court-circuite la façon dont Webkit gère l’affichage il y a de fortes chances que notre super CSS s’applique aussi correctement. Après avoir cherché un peu voilà ce qu’il faut déclarer pour Webkit :

#search input[type="search"] {
	-webkit-appearance: textfield;
	-webkit-box-sizing: content-box;
	box-sizing: content-box;
}

Voilà, court-circuit de -webkit-appearance et -webkit-box-sizing et avec le code css complet on a enfin un affichage identique d’un navigateur à l’autre.

La CSS finale :

#search input[type="search"] {
	display: block;
	-webkit-appearance: textfield;
	-webkit-box-sizing: content-box;
	box-sizing: content-box;
	background-color: #666;
	color: #fff;
	border: 1px solid #666;
	border-top-color: #454545;
	border-left-color: #454545;
	padding: 10px;
	font-size: 16px;
	-webkit-border-radius: 6px;
	-moz-border-radius: 6px;
	width: 190px;
}

On vient de quitter une époque ou la simple évocation de “compatibilité IE6” provoquait des vomissements et des crises d’eczéma chez les webdesigners pour se retrouver dans une ère où il faut être encore plus prudent, très au courant des derniers développements, et aussi très malin pour ne pas avoir à ré-écrire dans 18 mois tout ou partie de nos CSS. Je ne sais pas si on y a gagné en flexibilité, au moins on y a gagné en possibilités nouvelles… on verra dans quelques mois ce qu’il en coûte. Ou pas.

Où l’on s’aperçoit qu’on s’est fait chier pour pas grand-chose

Nicolas Guilhou

Voir input et mourir