Pablo Prieto - Blog - css

13 règles pour accélérer son site web

Pab. — Wed, 01 Aug 2007 11:24:00 +0200

Yahoo nous propose sur cette page 13 règles pour optimiser et accélérer l'affichage de son site.

En résumé et en français :

Minimiser le nombre de requêtes HTTP
Utiliser un réseau de diffusion de contenu ("Content Delivery Network")
Configurer un en-tête d'expiration pour tous les composants images, scripts et styles
Utiliser la compression Gzip
Placer les styles CSS dans la partie head de la page
Placer les scripts en bas de page
Eviter les expressions javascript dans les feuilles de styles
Utiliser des fichiers externes pour les scripts et les styles CSS
Réduire le nombre de résolutions DNS
Compresser le code Javascript (avec des outils comme JSMin)
Eviter les redirections
Retirer les scripts en double (visiblement ça arrive souvent quand on travaille en équipe...)
Configurer correctement les "entity tags" si besoin

Chaque règle est très bien expliquée et documentée, et Yahoo nous fournit même une extension pour Firebug permettant d'analyser la page en cours vis-à-vis de chacune de ces règles.

Pourquoi ai-je un rendu différent entre Firefox Windows et Firefox Mac ?

Pab. — Wed, 13 Jun 2007 14:18:00 +0200

Vous l'avez peut-être déjà constaté, il arrive parfois que le rendu d'une page soit différent entre Firefox sous Windows et son homologue sous Mac. Certains en concluent un peu trop vite à un bug du moteur gecko ou encore que celui-ci serait différent entre les 2 plates-formes. Heureusement il n'en est rien, il s'agit bel et bien du même moteur. Alors d'ou vient cette différence ?

Voici un exemple extrêmement simple, un paragraphe de texte de 300 pixels de large :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
	<title>untitled</title>	
	<style type="text/css" media="screen">
		p{width:300px; background:#EEE;}
	</style>
</head>
<body>	
	<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, (...) anim id est laborum.</p>
</body>
</html>

Et voici ce que l'on obtient sous Firefox Mac (à gauche) et Firefox Windows (à droite) :

On le voit bien ici, la différence vient tout simplement d'une hauteur de ligne différente. On n'y pense jamais assez, mais la propriété line-height est fixée par défaut à "normal" lorsque le concepteur ne la précise pas, laissant alors libre le navigateur de calculer une valeur "raisonnable" pour celle-ci. Cette valeur varie selon les systèmes d'exploitation, en fonction notamment de la résolution logique.

Voici l'extrait de la norme CSS 2 concernant la valeur "normal" :

normal
Tells user agents to set the computed value to a "reasonable" value based on the font size of the element. The value has the same meaning as <number>. We recommend a computed value for 'normal' between 1.0 to 1.2.

Voici maintenant la même page avec une hauteur de ligne fixée à 1.2 :

Le rendu est maintenant uniforme sur l'ensemble des navigateurs, et conforme au résultat attendu.

Conclusion : pensez à fixer vos hauteurs de ligne !

Apollo, WebKit et Windows

Pab. — Mon, 19 Mar 2007 17:37:00 +0100

Apollo vient de sortir aujourd'hui en version alpha sur le labs d'Adobe. En très bref, Apollo permet de créer des applications Internet riches (RIA) multi-plateformes en mixant Flash, HTML, CSS et JavaScript.

Une bonne nouvelle c'est que Apollo utilise WebKit pour le rendu HTML/CSS, c'est à dire le même moteur de rendu que Safari. Apollo permet donc d'avoir le moteur WebKit disponible sous Windows, ce qui est plutôt intéressant pour les designers qui veulent tester leurs pages sans avoir de mac sous la main...

Et justement, Adobe fournit dans ses exemples, une application dénommée Scout et qui permet d'afficher n'importe quelle page web au sein d'Apollo. Un bon plan pour vérifier le rendu d'un design html/css (presque) comme sous Safari ;) Grand luxe, Scout permet même d'analyser le DOM, le code source, ... un peu comme Firebug pour Firefox.

Je ne pense pas que la version de WebKit utilisée soit exactement la même que celle de Safari mais les différences de rendus sont à priori négligeables. Le moteur JavaScript en revanche n'est pas le même, donc prudence là dessus.

Pour utiliser Scout, installez d'abord Apollo puis télécharger ensuite Scout à partir de cette page (l'enregistrement sur le site d'Adobe est nécessaire).

Elements en ligne et marges internes

Pab. — Mon, 18 Dec 2006 13:59:00 +0100

Ou comment bien appréhender la mise en forme des éléments en ligne et créer de jolis boutons...

La gestion des marges internes

Voici le code html qui va nous servir d'exemple :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
	<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
	<title>test1</title>
	
	<style type="text/css" media="screen">
	
		body{
			margin:1em;
			padding:0;
			border:1px solid #F00;
		}
		
		p{
			margin:2em 0;
			background:#CCC;
		}
		
		strong{
			padding:10px;
			border:1px solid #00F;
		}
		
		a{
			padding:10px;
			border:1px dotted #F00;
			color:#00F;
		}
		
	</style>	
</head>
<body>
	
	<p>
		Lorem ipsum <strong><a href="#">dolor</a></strong> sit amet
	</p>
	
</body>

Cet exemple contient donc un paragraphe, dans lequel se trouve une emphase (strong) qui elle-même contient un lien, soit deux éléments en ligne imbriqués. En appliquant comme ici un padding de 10px sur l'élément strong et sur l'élément a, voici ce que l'on obtient sous Firefox :

Et voici la même page sous Internet Explorer (6 et 7, même combat) :

On constate ainsi plusieurs choses :

Un padding appliqué à un élément en ligne ne repousse pas les boites voisines (y compris les blocs parents)
Firefox (idem pour Opera et Safari) respecte ce principe, et donc les padding verticaux sur des éléments en ligne imbriqués se superposent
Sur IE au contraire ils s'ajoutent
Sur IE, un élément en ligne ne peut pas s'afficher en dehors d'un bloc parent possédant le layout (ici le body, entouré en rouge)

Ce dernier point peut être vérifié en forçant le layout sur le paragraphe conteneur (avec une propriété zoom:1), voici alors ce que l'on obtient :

Alors comment faire ?

Cette différence de rendu est plutôt contraignante et ne peux pas être résolue sans utiliser des styles différents pour IE et le reste du monde. Pas le choix, il va falloir annuler pour IE les paddings verticaux sur l'élément strong, pour éviter qu'ils ne s'ajoutent à ceux du lien. Encore une fois, les commentaires conditionnels sont à privilégier pour ce genre de chose :

<!--[if lte IE 7]>
<style type="text/css">		
	strong{
		padding-top:0;
		padding-bottom:0;
	}
</style>
<![endif]-->

Reste ensuite le problème du débordement, que l'on va régler en fixant la hauteur de ligne au niveau de l'élément strong, dans le code CSS principal. Vous pouvez calculer cette hauteur en additionnant la hauteur de ligne du lien + ses paddings haut et bas + un espace supplémentaire pour que le texte au dessus ou en dessous ne soit pas trop collé à l'élément.

strong{
	line-height:4em;
}

On assure ainsi que la boite crée par l'élément strong sera toujours à l'intérieur du bloc parent et que les lignes du dessous ne chevaucheront pas cet élément. Le résultat est maintenant identique sur tous les navigateurs :

Mise en pratique

Une application assez courante est la création de boutons, à partir d'un lien, d'un span et de 2 images de fond :

Voici le code html nécessaire :

<p>
  Cliquez sur ce bouton :  <a class="bouton"><span>Click me !</span></a>
</p>

Et ensuite le code CSS correspondant :

a.bouton{
	background:url("bouton-left.png") no-repeat center left;
	padding:12px 0 12px 20px;
	color:#666;
	line-height:4em;
}
a.bouton span{
	background:url("bouton-right.png") no-repeat center right;
	padding:12px 20px 12px 0;
}
a.bouton:hover{
	color:#000;
}

Et pour IE :

a.bouton{
	padding-top:0;
	padding-bottom:0;
}

Et voilà le travail, vous pouvez voir le résultat en ligne.

Les bugs d'IE7

Pab. — Mon, 06 Nov 2006 10:05:00 +0100

Il n'aura pas fallu longtemps avant de découvrir qu'IE7 avait lui aussi quelques petits problèmes d'interprétation, notamment en matière de DOM et CSS... plusieurs sites recensent déjà les bugs spécifiques à cette version :

Ces quelques liens sont donc à garder sous le coude en cas de désaccord profond entre IE7 et les autres.

Alors attention, IE7 reste néanmoins une grande avancée par rapport à son prédécesseur, et certain de ces bugs CSS listés dans cette page ne sont pas très critiques, c'est à dire qu'on a peu de chance de les croiser tous les jours (à la différence d'un peekaboo bug par exemple sous IE6). Bref si vous voulez mon avis, IE7 est un bon navigateur même si il a ses limites, comme les autres ;)

La fusion des marges, partie 2

Pab. — Thu, 12 Oct 2006 11:45:00 +0200

La suite logique de la première partie, consacrée cette-fois au cas des blocs flottants

Le cas des blocs flottants

Les blocs flottants (float:left ou float:right) ne fusionnent jamais leur marges avec aucun autre bloc. Ainsi l'exemple suivant illustre ce principe (les paragraphes ont une marge haut et bas par défaut de 1em) :

<div id="conteneur">
  <p id="flottant">Lorem ipsum dolor sit amet...</p>
  <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. 
  Curabitur posuere neque mattis dolor. 
  In hac habitasse platea dictumst.</p>
</div>

#conteneur{  
background: #DDD;
}

#flottant{  
float: left;  
background: #666;
}

ceci produira l'affichage suivant :

Malheureusement pour nous, Internet Explorer (y compris la version 7, dommage...) ignore totalement cette exception à la règle :

Attention donc à cette différence de rendu entre Internet Explorer et les autres navigateurs (y compris en mode de rendu strict). Pour éviter cela, le mieux est d'harmoniser l'affichage en supprimant les marges du bloc flottant pour tous les navigateurs.

La proprieté clear

Ajoutons maintenant un troisième paragraphe doté de la proprieté clear:both :

Ici sous Firefox, on constate que l'espace entre le bloc flottant et le bloc clear est de 1em, on pourrait donc croire que leur marges fusionnent. Or il n'en est rien, cet espace est uniquement du à la marge du bloc flottant. Les marges du bloc clear n'affectent en rien le bloc flottant, on le constate si l'on applique une marge de 3em au bloc clear :

L'espace entre celui-ci et le bloc flottant est toujours de 1em. La marge de 3em du bloc clear servira à créer un espace uniquement avec les blocs suivants et précédents dans le flux de page, ici en particulier avec le 2e paragraphe.

A ce moment, le comportement d'Internet Explorer est un peu étrange :

Sous IE6, le deuxième paragraphe "disparait" si le bloc flottant touche le bloc clear, c'est le fameux peekaboo bug.
Sous IE6 et 7, selon la hauteur du deuxième paragraphe, la marge du bloc flottant pousse le bloc clear ou pas :

Pour le peekaboo bug, la solution est simple et connue, il faut dotter le bloc conteneur d'un layout, avec un height:1% par exemple.

Pour le reste il s'agit du même souci que plus haut, la solution encore une fois consiste à harmoniser l'affichage pour tous les navigateurs en fixant les marges du bloc flottant à 0.

La fusion des marges, partie 1

Pab. — Thu, 17 Aug 2006 11:55:00 +0200

La règle de fusion des marges en CSS, souvent mal connue, est la source de beaucoup d'incompréhensions de la part des concepteurs web. Pourtant, bien maîtriser cette notion permet avant tout de bien comprendre et maîtriser le résultat de son design CSS.

La règle de base de la fusion des marges est la suivante : 2 marges consécutives fusionnent si aucune marge interne (padding) ou bordure (border) ne s'interpose entre les deux.

Il faut noter que cette règle ne concerne que les marges verticales (haut et bas donc) et en aucun cas les marges horizontales.

Pour la partie théorique, je vous renvoie à l'inévitable site du W3C.

Hop, passons maintenant à la pratique.

Un premier exemple de base

Voici deux paragraphes l'un à la suite de l'autre, avec chacun une marge haut et bas de 10 pixels :

p{ margin:1em 0;}

<p>Lorem ipsum</p>
<p>Dolor sit amet</p>

L'espacement crée par les marges entre ces deux paragraphes sera de 10px. On constate bien que la marge bas du premier et la marge haut du second paragraphe fusionnent pour n'en former qu'une :

La fusion entre blocs de niveau différents

Entourons maintenant ces 2 paragraphe d'un élément div, lui aussi doté d'une marge :

<div id="conteneur">
  <p>Lorem ipsum</p>
  <p>Dolor sit amet</p>
</div>

#conteneur{ margin:10px 0;}
p{ margin:10px 0;}

On pourrait s'attendre à ce que la marge des paragraphe crée un espace à l'intérieur du div. Or là encore la règle de fusion des marges s'applique entre les marges du div et celles des élements p. Le résultat sera donc le suivant :

Appliquons à présent une bordure à l'élement conteneur :

#conteneur{ margin:10px 0; border:2px dashed #000;}
p{ margin:10px 0;}

Comme le précise la règle, la fusion ne s'opère plus car la bordure du bloc conteneur fait obstacle entre la marge de celui-ci et celles des paragrapes. Les marges des paragraphes sont alors contenues à l'intérieur du bloc conteneur :

Appliquons à présent une marge interne (padding) à notre div conteneur :

#conteneur{ margin:10px 0; padding:10px;}
p{ margin:10px;}

Là encore la règle précise que la fusion ne doit plus s'appliquer, nous allons alors nous retrouver avec un espace non pas de 10px mais de 20 pixels (le padding du bloc conteneur + la marge du p) :

Cette situation (plutôt fréquente) peut être gênante si l'on souhaite simplement créer un espacement de 10px, tout en gardant les marges entre les paragraphes. Pour y remedier, la solution la plus simple et la plus rapide consiste à appliquer un padding au bloc conteneur non pas de 10 mais de 1 pixel seulement :

#conteneur{ margin:10px 0; padding:1px 10px;}
p{ margin:10px 0;}

Et voilà le travail :) Bon, en réalité l'espacement est maintenant de 11px, mais la différence visuelle peut être considerée comme négligeable (comment ça non ?)

(A suivre...)

IE6 et PNG, je t'aime moi non plus

Pab. — Mon, 07 Aug 2006 09:54:00 +0200

Malgré le bug d'IE6 empêchant l'affichage des PNG transparents (32 bits) il existe quelques solutions de contournement. Je vais essayer de rassembler dans ce billet les différents techniques utilisées, en insistant sur leur fiabilité dans la pratique, si vous décidez de les utiliser dans le cadre d'un projet professionnel.

Cas d'un PNG dans une CSS (en image de fond)

Cette technique fonctionne à 2 conditions :

le bloc recevant l'image de fond doit être positionné en absolute ou avoir ses propriétés width ou height fixées
l'image ne peut être ni répétée ni positionnée

Voici un bloc auquel nous allons appliquer un png en image de fond :

<div id="test">	
	<ul>
		<li><a href="#">Item 1</a></li>
		<li><a href="#">Item 2</a></li>
		<li><a href="#">Item 3</a></li>
	</ul>		
</div>

Voici ensuite le code CSS :

#test{
	width:400px;
	background: url("fond.png") no-repeat  0 0;
}

Pour IE, grâce aux commentaires conditionnels, nous allons ensuite annuler l'image de fond et appliquer la propriété filter à la place :

<!--[if lt IE 7]>
<style type="text/css" media="screen">
#test{
	background-image: none;
	filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='fond.png', sizingMethod='crop');
}
</style>		
<![endif]-->

la propriété sizingMethod peut recevoir comme valeur 'image', 'scale' ou 'crop'. La valeur 'scale' ajuste les dimensions de l'image à la taille du bloc, pour plus de détail je vous invite à consulter la doc officielle chez Microsoft.

Bizarrement, l'url de l'image dans la propriété filter doit être relative à la page html, et non à la feuille de style, pensez-y si les 2 fichiers ne sont pas au même niveau.

Un problème de liens...

Vous allez maintenant vous rendre compte que les liens à l'intérieur de notre bloc ne fonctionnent pas... plutôt bloquant.

Pour y remédier, il faut alors rajouter la propriété position:relative aux liens :

<!--[if lt IE 7]>
<style type="text/css" media="screen">
#test{
	background-image: none;
	filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='fond.png', sizingMethod='crop');
}	
#test a{
	position:relative;
}
</style>		
<![endif]-->

Et voilà, les liens redeviennent cliquables.

Cas d'une image dans le corps de page

Ici une seule condition : les attributs width et height de l'image doivent être fixés.

Le principe consiste à remplacer l'image par un gif transparent et lui appliquer en fond le png grâce à l'attribut filter ci-dessus. Ce comportement peut être automatisé grâce à un fichier htc (à télécharger en annexe). On applique simplement ce comportement aux images, avec la propriété CSS behavior :

img{
	behavior: url("png.htc");
}

pour affiner la chose, on peut choisir de l'utiliser dans une classe :

img.png{
	behavior: url("png.htc");
}

<img src="image.png" width="100" height="100" alt="" class="png" />

Placez de préférence les fichiers png.htc et blank.gif au même endroit que votre page html. Ici encore, l'url du fichier htc doit être relative à la page html, et non à la feuille de style.

Bien évidement, behavior et filter ne sont pas des propriétés valides. Encore une fois utilisez les commentaires conditionnels ;)

Pour conclure, je vous conseille de rester prudent avec ces techniques sur des projets sensibles (et des clients pointilleux... ;) ), et prenez le temps de tester "en conditions réelles" avant de vous prononcer sur la faisabilité.