Le line-height est une propriété de base très importante mais trop souvent mal utilisée. En fait, elle est très souvent ignorée, ou bien définie approximativement parce qu’elle concerne l’espace qu’occupe le texte. Et visuellement, le texte est difficile à mesurer. Néanmoins, le line-height est essentiel au confort de lecture ainsi qu’à l’équilibre spatial d’une page web.

Je vais essayer d’expliquer le peu qu’il y à comprendre en m’appuyant sur un élément que vous venez de lire : le titre de mon billet.

Le line-height a deux amours

Le line-height a principalement 2 objectifs, qui ne sont et ne doivent pas être contradictoires :

1. Confort de lecture
2. Alignement vertical

Alors que le confort de lecture s’établit pour un bloc de texte, l’alignement vertical s’établit pour une ligne de texte. ¹

Le souci est que je vois souvent les intégrateurs négliger le confort de lecture, voire l’ignorer totalement lorsqu’il s’agit d’alignement vertical. Pourtant, il est facile de jouer sur les deux fronts.

Confort de lecture

En CSS, le line-height ne définit pas l’espacement des lignes mais plutôt la hauteur d’une ligne (ce qui, forcément, définit indirectement leur espacement, mais la nuance est importante). Ainsi, un paragraphe de 3 lignes, dont le line-height est de 16px fera 48px de hauteur. C’est évident à comprendre non ?

Relatif au font-size

L’erreur serait de considérer le font-size pour calculer la hauteur d’un paragraphe : si un paragraphe a un font-size de 20px, alors chaque ligne fait 20px de haut. FAUX. Le font-size n’entre pas directement en compte. Le font-size définit uniquement la taille des caractères d’une police. A vous de le définir à votre guise.

Le line-height sera néanmoins définit en fonction du font-size. Une règle simple est d’appliquer un line-height équivalent à 1,4x le font-size (environ). Prenez le paragraphe que vous êtes en train de lire : le font-size est de 15px (parce que c’est ce que je voulais tout simplement). Si on multiplie 15 par 1,4, on obtient 21. Mon line-height est en réalité de 22, ce qui est terriblement proche.

Cette règle peut légèrement varier selon la police utilisée (les polices avec serif apparaissent un peu plus grandes, du coup, un line-height légèrement plus grand est préférable). Mais au final, le confort de lecture se juge surtout à l’oeil : à vous de juger l’équilibre font-size/line-height.

Titre ≠ paragraphe

Les titres sont un cas particulier : en général, le line-height est plus petit, parce que les titres comportent beaucoup moins de lignes (1 seule très souvent, 2 régulièrement, 3 parfois, et rarement + de 3).

Du coup, le ratio line-height/font-size est très proche de 1.

Alignement vertical

L’alignement vertical s’effectue à 90% pour les éléments à une seule ligne de texte : boutons, titres, menus.. Il s’applique donc sur une seule ligne, ou bien la première ligne d’une série.

Reprenons mon titre de billet : je veux aligner verticalement le texte de mon titre avec le carré de gauche, qui s’avère être le format du post (article, lien, image, citation ou brève). Mon carré est placé en premier. C’est donc le titre qui doit s’adapter pour être aligné avec le carré.

Alignement vertical FTW

Mon carré fait 40px de haut. La solution de facilité serait d’appliquer un line-height de 40px : chaque première ligne de mon titre serait alignée verticalement avec le carré, et ce, quel que soit le font-size appliqué. Cette solution serait correcte pour une seule ligne, mais on aurait des soucis dès l’apparition d’une deuxième ligne.

En effet, le font-size de mes titres varie selon le format du post. Du coup, même si un line-height de 40px peut passer pour un font-size de 36px, il sera ridicule pour mon format “Brève” qui a un font-size de 17px.

Un line-height de 40px avec un font-size de 17px : ça colle pas.

En fait, on aurait fait une erreur dans l’ordre de définition des propriétés : le line-height doit servir au confort de lecture, avant toute chose. La volonté s’aligner verticalement ne doit pas se faire au détriment du confort de lecture. Et ce confort de lecture n’apparaissant qu’à partir de la deuxième ligne, peut se voir être négligé si l’on ne travaille que sur une seule ligne.

Ordre de définition des propriétés

Voici dans quel ordre on doit choisir la valeur des propriétés :

font size -> line-height -> padding-top

A quoi correspond chaque propriété ?

• Font size : la taille des caractères. Il s’établit selon des critères d’esthétique, d’équilibre. Il est défini indépendamment, en premier. A vous de le choisir, judicieusement.
• Line-height : le confort de lecture (uniquement !). Ratio de 1,4 pour des paragraphes, 1 pour des titres.
• Padding-top : c’est l’arme secrète qui va nous permettre d’aligner la première ligne sans compromettre le confort de lecture.

J’ai plusieurs formats de post. On va se focaliser sur 3 d’entre eux :

• Articles : font-size 36px / line-height 36px
• Liens : font-size 28px / line-height 28px
• Brèves : font-size 17px / line-height 24px

Première chose : maintenant que les line-height ont été établis selon le font-size, on va oublier les font-size. Ils ne sont plus utiles. On va se focaliser sur les line-height qui, eux, rentrent en considération dans l’alignement vertical.

Articles

Mes titres d’articles ont un line-height de 36px, et je veux qu’ils s’alignent verticalement dans un espace de 40px. Puisqu’on ne peut plus toucher au line-height (sous peine de dégrader le confort de lecture), on va décaler le titre vers le bas en haut utilisant du padding-top. Mais de combien ? Et bien de la différence entre line-height et hauteur désignée, divisée par deux. Une image pour expliquer ça ?

Avec un titre qui occupe 36px de haut, il nous faut 2px en haut et 2px en bas pour l’aligner verticalement avec le carré de 40px.

Vous remarquerez qu’à ce stade, le padding-bottom est négligeable. Il pourrait être de 40px qu’il n’entrerait pas en compte dans l’alignement vertical. Du coup, vous pouvez le définir à votre guise. Par exemple, ayant un border-bottom de 1px, j’ai établi mon padding-bottom à 16px.

Qu’en est-il des autres formats ?

Liens

Les liens que je poste sont moins importants que mes articles. Du coup, leur font-size n’est qu’à 28px, et leur line-height aussi. Du coup, le calcul est : (40-28) / 2 = 6px de padding-top.

Brèves

La particularité de mes brèves est qu’il n’y a pas de titre (ou du moins, il n’est pas affiché sur mon site). Du coup, c’est un paragraphe, pas un titre. Le font-size de 17px a généré un line-height de 24px. Calcul rapide : (40-24) / 2 = 8px de padding-top.

Avec cette utilisation simple du padding-top, on aligne la première ligne sans compromettre le confort de lecture établi en amont.

Mail d’une amie :

J’ai une colle pour toi :

1 – 4 colonnes de 240px => largeur totale 960px

2 – je rajoute un margin-right de 5px et soustrais 5px de la largeur de la colonne => largeur totale 960px

Et pourtant dans le 2ème cas, visuellement la largeur totale est inférieure à 960px.

How is it possible ?

Elle n’était vraisemblablement pas bien réveillée parce qu’elle connaissait la réponse, mais je vais développer la méthode ici pour ceux qui auraient des soucis.

Largeur totale ≠ largeur utilisée

Si vous avez un espace total de 480 pixels de large et que vous y mettez, côte à côte, 4 colonnes de 120px de large, alors tout l’espace horizontal est rempli.

120 * 4 = 480

Maintenant, si l’on diminue la largeur des colonnes jusqu’à 90px mais qu’on rajoute à leur droite 30px de marge, le compte total ne va pas changer.

(90 + 30) * 4 = 480

Le souci, c’est la dernière marge à droite. Elle rentre dans le calcul des 480px de large, mais visuellement, c’est du vide.

n colonnes, n-1 marges

Quel que soit le nombre de colonnes, le nombre de marges sera toujours inférieur de 1.
Pour n colonnes on a bien n-1 marges.

Ce que l’on veut : supprimer la dernière marge à droite. ¹

nth child : le sélecteur providentiel

Au lieu d’appliquer une classe à la dernière colonne de chaque ligne, on va utiliser la fabuleuse pseudo-classe CSS 3 :nth-child.

Dans mon exemple, on veut virer la marge de chaque colonne multiple de 4.
Il faut faire :

.column:nth-child(4n){ margin-right:0;}

En fait, le nombre n correspond à un nombre qui va incrémenter indéfiniment, en commençant par 1. Donc on a :

• 4*1 = 4 (la 4e colonne)
• 4*2 = 8 (la 8e colonne)
• 4*3…

Il permet donc de sélectionner toutes les colonnes multiples de 4.

Etant donné que nth-child n’est pas supporté par IE6, IE7 et IE8, il vous sera sans doute nécessaire d’utiliser plutôt une classe “last” sur la dernière colonne de chaque ligne.

Calcul des largeurs optimales

Comment être sûr d’occuper totalement l’espace horizontal disponible ? En d’autres termes, comment faire en sorte que :

largeur totale des colonnes
+ largeur totale des marges
= largeur totale du conteneur

Ici, je veux que que mes 4 colonnes fassent 90px de large.
Largeur totale des colonnes = 90*4 = 360px.
Il reste donc 480-360 = 120px pour 3 marges.
Chaque marge fera donc 120/3 = 40px de large.

Ici, le compte est bon, j’ai envie de dire.
Toutes les colonnes ont la même largeur, et les marges aussi, et la largeur utilisée est égale à la largeur totale.
L’utilisation de l’espace est donc optimale.

Trouver facilement les valeurs optimales

Imaginons des colonnes qui font 85px de large.

• Largeur totale des colonnes = 85*4 = 340px
• Largeur restante pour les marges = 480 – 340 = 140px
• Largeur de chaque marge = 140/3 = 46,6666666666666666666667

Le drame ! Bien sûr, on pourrait essayer de trouver la solution en tâtonnant, en testant 86, puis 84, puis 87… Quelle perte de temps !

Pour calculer la largeur optimale, voici la règle :

La marge gagnée sur chaque colonne doit être un multiple du nombre de marges.

Ok. Alors, repartons au début. On avait 4 colonnes à 120px de large et 0px de marge.
On a 3 marges, donc faut procéder par palier de 3px :

• 120 – 0 = 120px
• 120 – 3 = 117px (de large pour une colonne)
• 120 – 6 = 114px
• …
• 120 – 30 = 90px (notre exemple)
• 120 – 33  = 87px
• 120 – 36 = 84px

Du coup, on voit bien que 85px de large pour une colonne, c’est pas bon. Il faut choisir soit 87px ou bien 84px.

Prenons 84px qui est le plus proche :

• colonnes = 84*4 = 336px
• marge totale = 480-336 = 144px
• chaque marge = 144/3 = 48px

Avec des colonnes à 84px de large et des marges à 48px de large, l’espace horizontal de 480px est utilisé en entier.

Après mon tutoriel CSS : l’Art et la Science, voici un tutoriel sur l’autre partie importante de mon expérience d’intégrateur : WordPress le Tutoriel.

Je considère mes connaissances comme étant open-source. Et, de peur de les voir perdues à jamais, je préfère les écrire et les faire partager gratuitement avec la communauté des intégrateurs que nous sommes.

Ce tutoriel WordPress vous aidera à créer vous-même votre propre thème WordPress, mais contient aussi un thème WordPress vide gratuit sur lequel vous pouvez vous baser.

Il est des connaissances que l’on veut transmettre telles qu’on les ressent. Celle des CSS que j’ai acquise au fil des ans est celle que je souhaite à présent léguer à travers une histoire peu commune mais très ludique.

Que vous soyez novice ou qualifié, l’Art & la Science saura je l’espère vous apporter un savoir mais aussi (et peut-être avant tout) une conception des CSS. Mon intention est de vous faire parvenir la perception clairvoyante d’une compétence vivante et expressive qui saura séduire celui qui l’embrassera.

WordPress vient d’annoncer une Release Candidate pour la version 3. J’ai pour ma part installé et mis en prod la version Beta 2 qui, ma foi, est très stable. Si vous comptez l’installer, allez-y! Les mises à jour se font comme les WP actuellement, c’est à dire automatiquement. Et le système de template pour les thèmes est identique donc vos thèmes marcheront sans souci! Le seul souci est qu’il n’y a pas de version française encore mais bon, c’est uniquement pour l’admin qui est vraiment très simple en anglais.

Nouveautés WordPress 3

Dans les nouveautés, il y a :

• choisir son login et son mot de passe : au lieu d’avoir “admin” et un mot de passe généré automatiquement, on peut les choisir soi-même.
• un nouveau thème par défaut, bourré de nouvelles fonctions et qu’on va customiser dans ce tutoriel
• custom background : un outil dans l’admin pour pouvoir choisir un fond pour le site. Si vous développez des thèmes vous même, ça vous est inutile.
• Multi-sites! En fait, WordPress et WordPress µ ont fusionné : il est donc possible avec 1 seule installation WP de mettre en place autant de blogs différents que l’on veut. Par exemple : css.bbxdesign.com pour un blog de CSS, inspiration.bbxdesign.com pour un blog d’inspiration etc.
• Custom Post Types
• Custom Taxonomies

Je vais développer ces 2 derniers points car ils sont les plus intéressants.

Custom Post Types : vos propres Posts et Pages

Si vous utilisez WP, vous savez qu’il y a 2 grand types d’éléments pour poster :

• Posts : ce sont les billets du blogs rangés chronologiquement. Ils peuvent être dans des Catégories et avoir des Tags.
• Pages : ce sont des pages contenant du contenu fixe et intemporel. Il n’y a pas de notion de chronologie, ni de catégorie, ni de tags. Il y a uniquement une notion de hiérarchie (relation page parent/page enfant).

Si vous avez un blog, ces 2 types d’éléments sont parfaitement suffisants. Vous créez des billets avec les Posts et vous ajoutez une page “A propos” et “Contact” avec les Pages.

Mais imaginons qu’en plus de ça, vous voulez une catégorie Portfolio qui regroupe vos plus beaux travaux, avec un screenshot, une description et quelques infos sur le client. Comment faire ? Vous pouvez créer des Posts que vous classerez dans une catégorie “Portfolio”. Mais c’est non seulement fastidieux à mettre en place dans votre thème mais c’est aussi fastidieux à gérer dans l’admin.

On va donc créer un autre type de post : les “Projets“. Pour ça, on va utiliser le fichier functions.php.

Une fonction pour customiser l’admin

On va regrouper tout notre code dans une fonction qui sera appelée à l’initialisation de l’admin. Comme ça, lorsqu’on lance l’admin, on activera toutes les fonctions décrites dans my_custom_init :

add_action('init', 'my_custom_init');
function my_custom_init()
{
/* notre code PHP pour rajouter les custom post type */
}

Tout le code que je vais écrire maintenant devra être inclus dans la fonction my_custom_init.

Déclarer le Custom Post Type

Maintenant nous allons rajouter l’élément “Projet” dans notre admin :

register_post_type('projet', array(
 'label' => __('Projets'),
 'singular_label' => __('Projet'),
 'public' => true,
 'show_ui' => true,
 'capability_type' => 'post',
 'hierarchical' => false,
 'supports' => array('title', 'author', 'thumbnail')
));

Il faut utiliser la fonction register_post_type qui porte bien son nom : elle enregistre un nouvel élément, un nouveau type de Post. Il y a ensuite plusieurs paramètres. Ils n’y sont pas tous parce que beaucoup sont optionnels. J’ai mis les plus importants :

• ‘projet’ correspond au nom du nouvel élément. Il sera utilisé dans les fichiers de template.
• ‘label’ est le nom qu’on retrouvera dans la colonne de gauche de l’admin. Il est préférable de mettre un pluriel.
• ‘singular_label’ est l’équivalent au singulier
• ‘public’ définit si les posts seront publics ou non.
• ‘show_ui’ définit si ce nouvel élément apparaît dans l’admin
• ‘capability_type’ définit si le nouvel élément est identique à un Post classique ou à une Page classique. Ici on veut un titre et une image miniature donc Post. En général, les Posts sont beaucoup plus intéressants car ils ont davantage de fonctions que les Pages.
• ‘hierarchical’ définit si il peut y avoir une hiérarchie (comme pour les Pages). Ici, c’est non car chaque élément est au même niveau.
• ‘supports’ est un array qui définit quels éléments d’un Post normal on veut avoir. Ici je veux juste le titre, l’auteur du Post et une miniature. Il y a pleins d’autres éléments :
  • ‘title’
  • ‘editor’ (la fenêtre principale de contenu)
  • ‘author’
  • ‘thumbnail’
  • ‘excerpt’
  • ‘trackbacks’
  • ‘custom-fields’
  • ‘comments’
  • ‘revisions’ (la sauvegarde automatique de versions passées)
  • ‘page-attributes’ (choix de template pour les pages et gestion de la hiérarchie)

Pour avoir les thumbnails dans votre thème, il faut ajouter dans functions.php :

add_theme_support( 'post-thumbnails' );

Merci à benoit pour m’avoir rappelé de mettre cette astuce.

Si vous avez tout bien fait vous devriez voir :

Vous pouvez maintenant créer un nouveau projet en cliquant sur “Add New”

Whaaa, c’est vide! Eh oui : on a juste mis “title”, “author” et “thumbnail”. Et c’est tout ce dont on a besoin! Hop je rajoute un Projet “bbxdesign” avec un screenshot :

Ok c’est cool, j’ai réussi à rajouter un nouveau projet! Ca marche nickel dans l’admin. Sauf que pour l’instant, j’ai rien qui s’affiche dans le blog!

Afficher les Custom Post Type

Sur votre blog (sur la home par exemple), dans la boucle des posts, il y a actuellement les Posts normaux. Mais nous on veut afficher les Projets! Pour ça, il faut faire un query_posts avec comme post_type le mot “projet”. Sur index.php par exemple, mettez :

<?php
$home_paged = (get_query_var('paged'));
$arguments = array(
 'post_type' => 'projet',
 'post_status' => 'publish',
 'paged' => $home_paged
);
query_posts($arguments);
get_template_part( 'loop', 'index' );
?>

Le $home_paged est une astuce qui permet de récupérer la valeur de la page courante et ainsi éviter de casser la pagination! Ensuite vient un array d’arguments : post_type en projet, post_status en publish (pour éviter d’afficher les brouillons) et page avec la variable.
Ensuite on fait le query_posts avec ces options puis on appelle la boucle avec get_template_part. Il faut savoir que get_template_part est une nouvelle fonction de WordPress 3 qui permet d’inclure d’autres fichiers php. Ici on appelle le fichier loop.php. C’est d’ailleurs très pratique pour éviter de copier-coller la boucle WP dans plusieurs fichiers.

Si vous ouvrez le fichier loop.php du thème “twentyten”, vous verrez qu’il est vraiment très long. On va tout virer et mettre juste un peu de code pour la home, histoire de vous montrer facilement comment afficher les éléments pour un projet. Nous, tout ce qu’on veut, c’est afficher le titre (c’est à dire le nom du projet), ainsi que la miniature.

<?php while ( have_posts() ) : the_post(); ?>
 <div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
 <h2><?php the_title(); ?></h2>
 <?php the_post_thumbnail(); ?>
 </div>
<?php endwhile; ?>

Donc là, c’est très simple. On met la div avec le bon id et la bonne classe, on met le nom du projet (the_title) et l’image (the_post_thumbnail) et ça donne :

J’ai pris le thème de base “twentyten” et j’ai donc customisé les fichiers index.php et loop.php. La home contient donc des Projets et non pas des Posts. Mais vu que j’ai les 2, je peux faire une page /blog où j’aurais tous mes Posts!

Maintenant vous pouvez ajouter des projets à la volée, virer la sidebar, le header et gérer une partie Blog avec les Posts et une partie Portfolio avec les Projets.

Custom Taxonomy : de nouvelles catégories et de nouveaux tags

Derrière ce nom barbare de “Taxonomy” se cache tout simplement les Catégories et les Tags. Avec WordPress 3, vous pouvez créer d’autres taxonomies. Imaginons qu’avec ce Portfolio vous voulez ajouter 2 choses :

• le type de projet : un logo, un site vitrine, une animation flash….
• les couleurs utilisées

On pourrait utiliser les Catégories et les Tags, mais elles sont déjà utilisées par les Posts pour le Blog! On va donc créer d’autres catégories et d’autres tags, exclusivement pour le Portfolio.

register_taxonomy( 'type', 'projet', array( 'hierarchical' => true, 'label' => 'Type', 'query_var' => true, 'rewrite' => true ) );
register_taxonomy( 'couleur', 'projet', array( 'hierarchical' => false, 'label' => 'Couleur', 'query_var' => true, 'rewrite' => true ) );

On utilise la fonction register_taxonomy. Dans l’ordre on choisit

• le nom de la taxonomie
• l’élément auquel il s’applique (ça peut être ‘post’, ‘page’ ou un post type qu’on a créé, en l’occurence ‘projet’)
• ‘hierarchical’ definit si il y a une relation parent/enfant. Si oui, c’est comme les Catégories. Si non, c’est comme les Tags.
• ‘label’ c’est le nom plus descriptif qui s’affichera dans l’admin
• ‘query_var’ à mettre sur true pour qu’on puisse appeler cette taxonomie dans nos templates
• ‘rewrite’ c’est la chaîne de caractères présente dans les permaliens. Si on met “true”, ça prend la valeur par défaut, c’est à dire le nom de la taxonomie.

(Bien sûr, tout ceci est toujours à mettre dans la fonction my_custom_init commencée tout à l’heure.)

Si vous rechargez l’admin, vous voyez par magie :

J’ai déplacé les blocs “Type” et “Couleur” à gauche pour que ce soit plus lisible. Maintenant vous pouvez ajouter le type “animation flash”, “logo”, “direction artistique”… et les couleurs “vert”, “orange”, “bleu”… Ca ressemble à peu près à ce qui ai fait sur Steaw Web Design (sauf qu’on utilise des sous-catégories).

Afficher les Custom Taxonomies dans le thème

Ok c’est cool, vous avez vos Custom Taxonomies dans l’admin. Maintenant faut les afficher dans le thème! On va reprendre le fichier loop.php de tout à l’heure et rajouter ça :

<?php while ( have_posts() ) : the_post(); ?>
 <div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
 <h2><?php the_title(); ?></h2>
 <?php echo get_the_term_list( $post->ID, 'type', '<p>Type de projet : ', ', ', '</p>' ) ?>
 <?php the_post_thumbnail(); ?>
 <?php echo get_the_term_list( $post->ID, 'couleur', '<p>Couleurs : ', ', ', '</p>' ) ?>
 </div>
<?php endwhile; ?>

On utilise la fonction get_the_term_list pour afficher les taxonomies du post courant ($post->ID). C’est dans un paragraphe, et les éléments sont séparés par des virgules. En fait, la taxonomie c’est l’ensemble de la liste (ex: “Couleurs”) et terme c’est chaque élément de la liste (ex: “orange”, “vert”).

Visuellement, ça donne ça :

Vous remarquerez que ça crée des liens pour chaque terme. En cliquant dessus, on arrive à une archive. En local, j’arrive pas à le faire marcher mais ça fonctionne sur mon JukePod pour l’année 2004 par exemple.

Conclusion

Avec les custom post type et les custom taxonomy, vous pouvez créer plusieurs “flux” sur votre site, comme par exemple un blog et un portfolio, sans avoir à mélanger les deux ou à s’embêter avec des sous-catégories.

Par exemple, pour le blog Steaw et le portfolio Steaw, on a du créer 2 WordPress différents avec d’un côté des Posts, des Catégories, des Tags et de l’autre… ben pareil : des Posts, des Catégories, des Tags! On le ferait aujourd’hui, on utiliserait le custom post type Projet pour le Portfolio. Il y a même un gars qui a fait un IMDB avec WordPress 3…

Sources : Nettuts et kovshenin

Le code HTML

Ici rien de plus simple, une simple liste fait l’affaire, avec un id pour toute la liste.

<ul id="tut01">
	<li><a href="#"><span>Accueil</span></a></li>
	<li><a href="#"><span>Tutoriaux</span></a></li>
	<li><a href="#"><span>Portfolio</span></a></li>
	<li><a href="#"><span>A propos</span></a></li>
</ul>

Le code CSS

Ici, le but est de faire en sorte que le menu aie un look sympa (un style noir) et qu’en passant le curseur par dessus il devienne vert. Tout est une question de couleurs. Il faut tester les couleurs sous Photoshop par exemple et les changer à votre guise. Etant donné que les CSS ne gèrent pas les dégradés, il faut jouer sans. A la base, c’est un défi (utiliser uniquement des CSS). Et au final il y a 2 contraintes :

• la largeur du menu doit être fixe (ici 400 pixels)
• la largeur de chaque élement du menu doit être la même (ici 100 pixels), et la somme de toutes les largeurs doit être égale à celle du menu (ici 4×100 = 400 pixels)

N’oubliez pas de prendre en compte la bordure extérieure de 1 pixel. Voici le code obtenu:

#tut01{
border:1px solid #5b9400;
height:36px;
list-style:none;
margin:0 auto;
margin-bottom:15px;
padding:0;
width:400px;
}

#tut01 li{
display:inline;
}

#tut01 li a{
background:#434b4a;
border-bottom:18px solid #070607;
display:block;
float:left;
font-size:13px;
height:18px;
line-height:18px;
text-align:center;
text-decoration:none;
width:100px;
}

#tut01 li a span{
color:#fff;
font-weight:bold;
position:relative;
top:9px;
}

#tut01 li a:hover{
background:#a2d84e;
border-bottom:18px solid #7dbf0f;
}