Vous êtes sur la page 1sur 2

Bonnes pratiques en HTML

Aucune information sur l’apparence/style ne doit être présente dans le HTML : on ne


trouve que du contenu, des ressources pour le site et de la description.

On ferme les TAGS, on n’entremêle pas les TAGS, on utilise tous les attributs requis et on
vérifie qu’il est valide W3C.

Blocs descriptifs : choisir des éléments qui décrivent bien le contenu lorsque c’est
disponible. (exemples: nav, footer)

Mettre des ID et non des classes (CLASS) si l'élément est spécifique… Par exemple, bloc9
n'est pas une classe mais un identifiant unique alors que blocImage ou blocLogo peut en
être une car plusieurs blocs vont être mis en page de la même façon. Eviter tout ce qui
peut paraître incohérent, bizarre ou illogique.

Mettre des attributs textuels aux images (alt) en précisant leur taille pour améliorer
l’efficacité du rendu. (Plus c’est précis, moins le navigateur doit faire des choix et
adapter).

Les chemins (paths) pour les ressources doivent être mis en relatif (par rapport à
l’endroit où l’on se trouve) par opposition à absolu (chemin complet); encore pour des
raisons d’efficacité et d’éviter les problèmes lorsqu’on déplace le site.

L’indentation doit être faite scrupuleusement : il est pénible de devoir commencer à


indenter pour voir si le code est correct : c’est fondamental avant de déboguer.

On conseille d’encoder directement les caractères spéciaux pour éviter les problèmes
d’affichage.

On commente uniquement ce qui n’est pas évident pour quelqu’un qui sait coder en
HTML 5/CSS 3 comme par exemple : la structure sous forme de lignes, colonnes et blocs
ou un bloc qui se comportera différemment des autres.

Passez au validateur HTML 5 pour corriger 90% des erreurs :


https://validator.w3.org/
Bonnes pratiques en CSS
Une seule page de style est bien plus facile pour gérer la mise en page, dans un dossier
css.

Si vous souhaitez une uniformité dans le style, mettez un ID sur le body et vous pourrez
ainsi modifier le contenu et l’apparence globale du site facilement.

Quand vous le pouvez, choisissez toujours % par rapport à px car cela servira l’année
prochaine pour avoir une approche dite « responsive design » (qui s’adapte à différents
formats).

Ne pas faire de pré-déclaration automatique CSS qui sera surchargée (remplacée)


ensuite… (recopier un code fait pour un autre site sans vérifier, adapter, mettre à jour.)
Exemple ci-dessous avec body (inutile et éventuellement trompeur même si dans cet
exemple, on ne fait qu’ajouter de nouveaux éléments qui ne perturbent pas les
précédents):

body,div,fieldset,input,img,a,a:hover,select, ul, p, h1, h2, h3, h4, h5, h6, iframe {


margin:0;
padding:0;
border:0;
text-decoration:none;
outline:none;
list-style:none;
vertical-align:bottom;
white-space:normal;
}

body {
color: black;
background-color: white;
background-image: url(images/bg2.jpg);
}

De plus, pour plus de clarté, on devrait trouver un seul sélecteur par ligne (=retour à la
ligne après les ,). Rappelez-vous qu’ils sont appliqués par ordre d’apparition dans le
fichier (de haut en bas). Un ordre est conseillé (cf. ci-dessous).
Les accolades fermantes doivent se trouver seules sur une ligne.

L’ordre conseillé par bloc css est le suivant :


1/ Positionnement (position: absolute; top: 0; right: 0; bottom: 0; left: 0; z-index: 100;)
2/ Modèle de boîte (display: block; float: right; width: 100px; height: 100px;)
3/ Typographie (font: normal 13px "Helvetica Neue", sans-serif; line-height: 1.5; color: #333; text-
align: center;)
4/ Effets visuels (background-color: #f5f5f5; border: 1px solid #e5e5e5; border-radius: 3px; )
5/ Autres-Divers

Passez au validateur CSS ce qui permettra de corriger 90% des problèmes.


http://jigsaw.w3.org/css-validator/ - validate_by_input

Vous aimerez peut-être aussi