.page .menu li color: red;

body div.menu ul li color: blue;


Si les deux déclarations désignent bien le même élément, l’une est prioritaire sur l’autre et du style de la première déclaration dont va hériter l’élément de liste. La couleur bleue de la deuxième déclaration ne sera pas appliquée.

Si la première déclaration (.page .menu li) prend le pas sur la deuxième (body div.menu ul li) c’est que le calcul de spécificité lui donne plus d’importance.

La spécificité d’une déclaration est un calcul qui indique le « poids » d’une déclaration.

Ce « poids » est alors utilisé pour comparer les différentes déclarations entre-elles et savoir laquelle est prioritaire sur l’autre, laquelle a le plus de « poids ».

Le calcul se fait :
– en fonction de 3 types d’éléments qui composent une déclaration (ID, class, élément balise)
– sur 3 chiffres concaténés

Pour connaitre le premier des trois chiffres concaténés, il faut compter le nombre d’ID dans la déclaration (a).
Pour le deuxième chiffre, il faut compter le nombre de class (b).

Enfin, le troisième chiffre est donné par le nombre d’élément balise (c).

Le poids d’une déclaration est le nombre donné par ces trois résultats mis côte à côte (abc).

Dans notre exemple :

.page .menu li color: red;
Nombre d'ID : 0 (donc a=0)
Nombre de class : 2 (donc b=2)
Nombre d'élément : 1 (donc C=1)

Le poids de cette déclaration est donc de 21 (021).

body div.menu ul li color: blue;
Nombre d'ID : 0 (donc a=0)
Nombre de class : 1 (donc b=1)
Nombre d'élément : 4 (donc C=4)

Le poids de cette déclaration est donc de 14 (014).

La première déclaration est donc bien prioritaire sur la deuxième.

Quelques exemples :
#contenu #contenu-principal

La spécificité est de 200 (a=2 ; b=0 ; c=0)

div.informations #mentions p.important span

La spécificité est de 123 (a=1 ; b=2 ; c=3)

Et comme une image (ludique) vaut toujours mieux qu’un long discours :

http://www.stuffandnonsense.co.uk/…/specificitywars-05v2.jpg

Cela nous permet de comprendre pourquoi, dans certains cas « inexplicable » notre déclaration ne s’applique pas alors qu’elle ne contient aucune erreur. L’élément cible hérite en fait d’une déclaration ayant une spécificité plus forte.
Parfois, ces problèmes peuvent simplement se régler en « surchargeant » la déclaration afin de lui donner plus de poids. Attention néanmoins à ne pas avoir le reflexe de trop charger ses déclarations (pour éviter ce type de désagrément) au point d’avoir des déclarations très fortes et peu souples.

Aller plus loin :

Spécification CSS2 (traduction française) > Le calcul de la spécificité d’un sélecteur – http://www.yoyodesign.org/doc/w3c/css2/cascade.html#specificity

Notre but cette fois et de parcourir une implémentation (parmi tant d’autres) d’un moteur de gestion de carte. Notre moteur tentera de tirer parti d’Ajax en évitant au joueur de devoir supporter une période de loading.

Notre carte est volontairement simple : pas de support de layers, nous n’afficherons que le sol. Le but ici est de démontrer qu’Ajax peut être un outil fort intéressant dans le cadre du pré-loading d’une carte, rien d’autre. Evidemment si cette structure peut vous donner des idées c’est tant mieux…

Concept

Notre carte est composée de cases, toutes placées fort judicieusement les unes à côté des autres. Jusque là rien de bien nouveau.

Concept de la carte

Nous ne voulons pas de loading, il nous faudra donc :

1. Pouvoir faire le rendu de la carte de façon modulaire
2. Pouvoir gérer un ou plusieurs buffers, dont le rendu sera assuré par les méthodes du point 1.

Dans notre cas nous prendrons 4 buffers, en haut, en bas, à droite et à gauche. La dimension des buffers dépends de vous et de vos tests, ici je les prendrai de 1×5 (1 case de large sur 5 cases de long).

Base de données

Structure de la DB

Notre carte sera découpée en lignes et colonnes, ce qui nous permettra plus facilement de gérer un buffer de cases.

Chaque case dispose d’une image qui lui est propre, cette image peut être NULL. Si ce champ est NULL nous utiliserons l’image par défaut du type de terrain (type_terrain.type_img)

Pour le principe ajoutons une table joueur minimaliste. Elle ne retient qu’une chose : la position du joueur.

Dans la réalité le schéma de votre DB sera nettement plus complexe, on est tous d’accord, mais ça nous suffira pour l’instant.

Ecrire des queries pour cette structure est très simple : prenons un exemple : comment trouver le buffer de gauche de notre carte ?


SELECT C.case_id, C.type_terrain_id, C.case_ligne, C.case_col, C.case_img, T.type_img
FROM type_terrain T, cases C
WHERE T.type_terrain_id=C.type_terrain_id
AND C.case_col = 4
AND C.case_ligne BETWEEN 11 AND 15


Ce select renvoie donc le buffer gauche de notre carte. C’est à dire une colonne composée de 5 cases. Pour obtenir les autres buffers nous jouerons sur les deux dernières conditions, faisant varier soit les colonnes soit les lignes. Par exemple, pour trouver le buffer du bas


AND C.case_col BETWEEN 5 AND 9
AND C.case_ligne = 16


Nous allons essayer de faire aussi générique que possible. De quoi avons-nous besoin ? Tout d’abord d’un script capable de nous renvoyer le XML proprement dit. Nous appellerons ce script un module.

Notre structure, en sus de la carte, devra être capable d’accueillir bien d’autres modules, pour à peu près n’importe quoi. Puisque nous risquons d’avoir un nombre de modules importants il ne serait pas opportun de lier chaque appel Ajax à un module en particulier, ça nous obligerait à connaître à chaque fois l’URL de ce module, ce qui peut être contraignant (et ennuyeux niveau sécurité).

Pour éviter de coupler module et code côté client nous allons définir un point d’entrée. Ce script particulier sera chargé de dispatcher l’appel Ajax vers le module ad-hoc puis d’en renvoyer le code XML. Avantage supplémentaire, nous pourrons valider ce que le client nous envoi directement au niveau du point d’entrée.

Le code en dessous vous donne un aperçu de l’implémentation du point d’entrée et d’un module.

Le point d’entrée



die "action non définie!";
/**
Erreur mal gérée! Idéalement il faut logger les détails de la requête.
Il peut également être intéressant de renvoyer un XML contenant les détails de l'erreur
Ca simplifiera d'autant le debugging.
**/

else

switch($_REQUEST['action'])


// Renvoie le code XML généré
echo $str_xml;
?>


Un module

(ici la carte, donc)


//Cette fonction renvoie du HTML, pas du XML, ce n'est pas un appel AJAX

?>


Côté client

Mais qu’en est-il côté client ? Très simple : du javascript à foison ! Dans le chapitre précédent nous avions un simple « Moteur javascript », et bien c’est lui qui va se charger de tout :

1. Des appels pour récupérer le code XML
2. Des buffers
3. De l’affichage des informations recueillies

La solution la plus propre pour gérer l’affichage est d’utiliser des feuilles de style XSL. Mais ce n’est pas forcément la solution la plus simple. XSL fait appel à des technologies telles que XPath, qui ne sont pas toujours accessibles aux moins expérimentés.

En pseudo-code, voilà ce que donne notre moteur JS :

Vérifier si le buffer contient ce dont on a besoin
Si il ne le contient pas
Recupérer le handler (l'objet XMLHttpRequest)
Construire la requête en fonction de ce qu'on désire obtenir
Envoyer la requête et récupérer la réponse

On identifie la cible dans laquelle il faut insérer le contenu (avec son attribut ID)
On insère le code HTML obtenu grâce à la transformation XSL


Il existe des tas de très bon tutoriaux pour découvrir quelles sont les fonctions qui vont bien en JavaScript. Allez jeter un œil du côté de developpez.com par exemple pour un très bon papier dessus.

Avec ce que nous avons vu ici vous devriez être capable de construire une structure simple de gestion d’appels Ajax. Pour augmenter les possibilités de cette structure il ne vous reste qu’à développer de nouveaux modules, à choisir l’action qui y est liée (mod) et à effectuer l’appel javascript qui va bien.

Dans le cas qui nous intéresse, une carte, il est clair que nous gagnons en ergonomie ce qui nous perdons en complexité. Le joueur ne doit plus reloader la page à chaque mouvement de son personnage, mais seulement quand le besoin d’un scroll se fait sentir.

Implémenter le support du scrolling manuel (le joueur qui déplace la vue) est également un jeu d’enfant : c’est déjà supporté.

Soyons clair, la méthode décrite n’est pas parfaite et peut-être améliorée. Le code présenté n’est pas orienté objet, ce qui est très dommage. Point de vue performance, le switch sur l’action n’est sûrement pas la panacée. Avec de nombreuses actions différentes vous aurez vite un code horrible. Mais cet exemple a le mérite de montrer qu’il n’est pas forcément si complexe de concevoir « from scratch » le support d’une carte en Ajax.

Dans le prochain épisode nous verrons qu’il existe aussi des frameworks qui supportent déjà toutes ces fonctions, vous évitant donc de réinventer la roue à chaque fois. Stay tuned, et rendez-vous dans un petit mois!

Il n’est pas question dans cet article de faire l’inventaire de toutes les failles possibles de sécurité pour un site en PHP. Je conseille à ce sujet le très bon Guide Sécurité PHP du PHP Security Consortium, après avoir bien sûr parcouru la rubrique sécurité du manuel PHP.
Cet article a pour but de vous donner les bases qui vous permettront de développer l’esprit tranquille, le tout illustré d’exemples concrets applicables aux jeux web.

Configuration et utilisation des variables

La configuration de php, stockée dans le php.ini est importante puisqu’elle conditionne le comportement des variables prédéfinies. Utilisez une configuration par défaut, elle est le fruit de l’expérience de la communauté PHP. Evitez d’utiliser des fonctionnalités spécifiques, qui pourraient ne pas être disponibles sur n’importe quel serveur ! On peut citer register_globals, magic_quotes_gpc, short_open_tags, …
Et bien sûr, si vous êtes plusieurs à développer, utilisez tous la même configuration.

Voici les points vraiment très importants :

• register_globals doit être positionné à Off. Lorsque vous utilisez des variables de session, utilisez toujours $_SESSION, idem pour les cookies, variables passées en GET et POST : $_COOKIE, $_GET et $_POST.

• Positionnez error_reporting à E_ALL, afin d’afficher toutes les erreurs, warnings et notice. Un bon moyen est d’appeler error_reporting(E_ALL) au début de chaque script. Si vous avez le moindre avertissement, c’est potentiellement une faille de sécurité !

• Evitez d’utiliser le include($page), même si vous contrôlez avec une liste de pages autorisées.

• Si vous avez un espace d’administration, contrôlez son accès avec un mot de passe (.htaccess)

• Si vous offrez la possibilité d’uploader un fichier, contrôlez son contenu, cela pourrait être… un script php, qui pourrait être exécuté par le serveur !

• De manière générale, évitez de re-développer des fonctionnalités déjà existantes, comme la gestion des sessions. Sauf si vous êtes un véritable expert, il y a de fortes chances pour que vous laissiez passer certains aspects importants (la sécurité en est un), et cela pour un gain pas forcément réel.

• Sur la même note, si vous utilisez des outils externes (forum phpBB, punBB, …) assurez-vous de le maintenir à jour régulièrement afin de combler les failles de sécurité. Si vous décidez de gérer vous-même votre hébergement (serveur dédié), sachez que c’est un métier à part entière, et un métier complexe. Là encore, agissez prudemment, n’utilisez que des outils stables et sécurisés, et entourez-vous de personnes compétentes sur le sujet.

• Pour éviter les injections SQL, assurez-vous de toujours échapper les variables utilisées dans les requêtes, surtout si elles proviennent de l’utilisateur. La fonction addslashes est généralement utilisée, mais il est préférable d’utiliser celle correspondant à votre base de données : mysql_real_escape_string pour MySQL (qui échappe en plus le caractère 0)
  Attention aux magic quotes : les variables peuvent être déjà échappées ou non selon la configuration php.
  Le manuel PHP fournit une solution sécurisée les prenant en compte :
  

// Stripslashes
if (get_magic_quotes_gpc())
$value = stripslashes($value);

// Protection si ce n'est pas une valeur numérique ou une chaîne numérique
if (!is_numeric($value))
$value = "'" . mysql_real_escape_string($value) . "'";

return $value;


mysql_query($query);
?>


Il est généralement recommandé de désactiver les magic quotes, et de systématiquement
échapper les variables utilisées dans une requête SQL (cela simplifie également
leur sortie sur la page html). Pour désactiver les magic quotes quelle que soit
la configuration, on peut placer ce bout de code au début de chaque page :


set_magic_quotes_runtime(FALSE);
if(get_magic_quotes_gpc())
function remove_magic_quotes(&$var)
if(is_array($var))
array_walk($var, "remove_magic_quotes");
else if (is_string($var))
$var=stripslashes($var);



remove_magic_quotes($_POST);
remove_magic_quotes($_GET);
remove_magic_quotes($_REQUEST);
remove_magic_quotes($_COOKIE);



Pour éviter les problèmes d’injection SQL, on peut aussi se tourner vers les requêtes préparées, supportées entre autres dans la nouvelle extension PDO inclue dans PHP 5.1.

Contrôle des données fournies par l’utilisateur

Si vous n’en avez jamais entendu parler, c’est que vous n’avez lu aucun article sur la sécurité.
Les données fournies en provenance de l’utilisateur, qu’elle proviennent d’un formulaire de saisie (variable $_POST), ou qu’elles soient passées en paramètre de la requête HTTP ($_GET), peuvent aisément être falsifiées. Il faut donc impérativement contrôler TOUTE valeur que vous récupérez du navigateur web, et vérifier que ces valeurs sont bien fournies !

Une bonne pratique est de lister, pour chaque action, les variables nécessaires, ainsi que des contraintes sur leur contenu (ceux qui ont suivi des cours se remémoreront la notion de « pré-condition »). Si une valeur est facultative pour l’utilisateur, mais que vous en avez besoin pour un traitement, pensez à l’initialiser avec une valeur par défaut.

Exemple pour l’action « inscription d’un joueur » :

$_POST[‘nom_perso’] : texte, min 1 caractère, max 100 caractères, obligatoire
$_POST[‘description’] : texte, min 0 caractère, max 1000 caractères, obligatoire
$_POST[‘force’] : nombre, min 1, max 20, obligatoire
$_POST[‘endurance’] : nombre, min 1, max 20, obligatoire
force + endurance = 20

Toutes ces contraintes devront être vérifiées avant de pouvoir effectuer l’inscription. Si une contrainte n’est pas respectée, à vous de décider de renvoyer une erreur à l’utilisateur (« Nom du perso obligatoire ») ou bien de considérer cela comme une tentative de tricherie ! S’il n’est pas possible en navigant normalement de fournir une certaine valeur, alors c’est très probablement une tentative de triche. Exemple, vous avez sur une page 3 liens :

• avancer.php?direction=1
• avancer.php?direction=2
• avancer.php?direction=3

Il n’y a que 3 directions possibles, et il n’existe nulle part sur le site de lien avec une direction différente de 1, 2 ou 3. Si l’on vous fournit une valeur différente, alors c’est que l’utilisateur a modifié le lien manuellement !

Les contraintes listées précedemment pourraient se traduire ainsi :


function valider_inscription($variables)
if (!isset($variables['nom_perso'])) return array('TRICHE', 'nom_perso non défini');
if (!is_string($variables['nom_perso'])) return array('TRICHE', 'nom_perso non textuel');
if (strlen($variables['nom_perso'])<1 || strlen($variables['nom_perso'])>100) return array('VALID', 'Le nom du perso doit comprendre entre 1 et 100 caractères');

return array('OK', '');



Cette fonction pourra être utilisée ainsi :


list($erreur, $message)=valider_inscription($_POST);
if ($erreur=="TRICHE")
//selon votre politique, logger la tentative, afficher un message à l'utilisateur, etc
else if ($erreur=="VALID")
//Renvoyer le formulaire avec le message d'erreur $message à l'utilisateur
else
//OK, effectuer l'inscription en utilisant $_POST['nom_perso'], $_POST['force'], etc



A propos de la politique concernant la triche, il est utile d’enregistrer quelque part toutes les tentatives de triche. Lorsqu’une entrée ne correspond pas à ce qu’elle devrait être, on peut enregistrer cela sur le disque, avec la requête lancée, la page appelée, l’IP, ainsi que toutes les variables de session (numéro de compte). Ce fichier peut même entre envoyé à un administrateur par mail régulièrement. Cela permet de voir immédiatement une tentative de piratage, son auteur, et de prendre immédiatement les mesures qui s’imposent.
On peut faire la même chose pour les requêtes SQL ayant échoué. A chaque requête lancée, on va vérifier que l’exécution s’est déroulée correctement (mysql_query() renvoit false en cas d’échec). Si ce n’est pas le cas, alors on va envoyer un mail à l’administrateur avec toutes les infos citées précédemment. En plus de permettre de contrôler que toutes les requêtes sont bonnes, cela permet quelquefois de détecter une tentative de hack par injection SQL.

Voici deux exemples qui vous convaincront de la nécessité de bien contrôler ses variables.

1) Imaginons que vous ayez une fonctionnalité de don d’argent à un autre personnage.
L’utilisateur choisit un destinataire, puis saisit la somme qu’il veut lui céder dans un formulaire. Imaginez d’abord que vous contrôliez bien que la somme soit un nombre, mais que vous ne testiez pas les bornes. Votre traitement ressemble à :


UPDATE Perso set argent=argent-somme where id_perso=$donneur
UPDATE Perso set argent=argent+somme where id_perso=$destinataire


Imaginez qu’un joueur malin saisisse une somme négative… cela aura pour effet de retirer de l’argent au destinataire, et d’en ajouter au donneur !

2) Votre jeu se déroule sur une carte, chaque personnage se trouvant une case. Votre script d’attaque, attaquer.php, prend en paramètre un nombre correspondant au personnage visé, id_perso_vise. Lorsque l’utilisateur choisit d’attaquer, le site lui présente une liste de personnages qui sont à sa portée, c’est-à-dire à moins de 3 cases, accompagné d’un lien attaquer.php?id_perso_vise=xxxx
Si vous ne contrôlez pas que le personnage visé est bien à moins de 3 cases dans le script attaquer.php, alors un joueur pourrait modifier l’url, et attaquer n’importe quel perso où qu’il soit !

Il existe des cas très subtils, par exemple prenons si une variable $force contient la chaîne « 15+250 » (saisie par l’utilisateur) :

• Dans un calcul PHP, $force sera converti en nombre, la conversion récupère tous les chiffres jusqu’au premier caractère non numérique è if ($force<20) renverra true
• Si alors vous faites une requête : UPDATE Perso set force=$force, alors la valeur 265 sera insérée dans la table !
  è il faut vérifier l’utilisateur a bien saisi un nombre (is_numeric). Il est aussi possible de systématiquement convertir le nombre en entier avec intval() par exemple, mais cela ne permet pas de détecter la tentative de triche.

Concurrence d’accès aux données

Maintenant que les données en entrées des traitement sont bien contrôlées, nous allons nous intéresser aux traitements aux-mêmes.

Reprenons notre exemple de don d’argent. Cette action est effectuée par un script donner.php qui prend en paramètre le destinataire du don, ainsi que la somme – entier positif, qui doit être inférieur au montant disponible sur le compte bancaire du joueur. Le numéro du donateur (joueur connecté) est bien entendu conservé dans une variable de session.

La structure générale du script est la suivante :


//Validation : on vérifie que le joueur possède assez d'argent
$r=mysql_query("SELECT argent from Perso where id_perso=".$_SESSION["id_perso']);
list($argent_dispo)=mysql_fetch_row($r);
if ($somme > $argent_dispo)
// renvoyer un message d'erreur à l'utilisateur indiquant qu'il n'a pas assez d'argent

...

//Traitement : on transfert l'argent d'un perso à l'autre
mysql_query("UPDATE Perso set argent=argent-".$_POST['somme']." where id_perso=".$_SESSION['id_perso']);
mysql_query("UPDATE Perso set argent=argent+".$_POST['somme']." where id_perso=$destinataire");


Tout va bien jusqu’à présent, notre code fonctionne. Maintenant, imaginons qu’il survienne un délai notable entre la validation et le traitement. Les serveurs web gèrent plusieurs processus ou requêtes simultanément. Un script peut donc être interrompu provisoirement, avant de reprendre son exécution plus tard. Vous pourriez également avoir à effectuer des calculs longs et compliquées entre la validation et la mise à jour de la base de données.

Si un joueur envoie alors plusieurs fois de suite la même requête http (avec le même contenu), ce qui peut aisément être effectué en cliquant plusieurs fois de suite, très rapidement, sur le bouton de validation, alors nous avons plusieurs requêtes qui arrivent simultanément au serveur web. Notre serveur web sait exécuter plusieurs scripts (processus) simultanément, et leur exécution peut être effectuée simultanément – surtout si par exemple, le serveur dispose de plusieurs CPU ; mais aussi parce que le système peut décider de suspendre un processus pour en démarrer un autre.

Considérons donc le cas où 2 appels identiques (mêmes paramètres) à donner.php sont arrivés au serveur web simultanément. Nous allons les appeler A et B. Le donateur (joueur n°42) dispose de 50 pièces sur son compte. Il souhaite en donner 30 au joueur n°123, qui en possède initialement 20.
Le séquencement des opérations peut être le suivant :

Le système démarre l’appel A au script
A effectue la phase de validation è ok, le joueur veut donner 30 et dispose de 50
Le système interromps l’appel A et démarre l’appel B au script.
B effectue la phase de validation è ok, le joueur veut donner 30 et dispose de 50
B effectue le traitement, il retire 30 à A et les verse à B è joueur 42 dispose de 20, joueur 123 dispose de 50
B se termine
A reprend son exécution
B effectue le traitement, il retire 30 à A et les verse à B è joueur 42 dispose de -10, joueur 123 dispose de 80 !

C’est ce genre de problème qui a conduit des informaticiens, il y a quelques dizaines d’années, à inventer les bases de données et la notion de transaction. Je ne vais pas rentrer dans les détails ici (internet fournit une large documentation sur le sujet), sachez juste que les transactions ne sont pas supportées par le format de table par défaut de MySQL, MyISAM, mais qu’elles le sont avec InnoDB.
Les transactions permettent de verrouiller les données manipulées, et de s’assurer qu’elles n’ont pas été modifiées entre le début et la fin de la transaction. Si nous avions encapsulé toutes nos requêtes SQL dans une même transaction, nous aurions eu l’assurance que le 2ème appel n’aurait pas abouti.

Outre ce cas d’école, il existe de nombreuses situations où vous pourriez avoir des problèmes.

Prenons l’exemple d’une gestion des points d’action (PA). Le joueur gagne 1 PA par heure. Pour gérer ce système, on stocke la date/heure (timestamp) de dernière connexion pour chaque joueur. Lorsqu’il se connecte, on calcule le temps écoulé depuis le dernier gain de PA, et on lui redonne autant de PA que d’heures écoulées. Notre script pourrait ressembler à :


$r=mysql_query("SELECT timestamp_gain from Perso where id_perso=".$_SESSION['id_perso']);
list($timestamp_gain)=mysql_fetch_row($r));
if (time()-$timestamp_gain>3600) //si plus de 3600 secondes (1h) se sont écoulées depuis la dernière connexion
$gain = floor((time()-$timestamp_gain)/3600); //calculer le nombre d'heures écoulées
mysql_query("UPDATE Perso set PA=PA+$gain, timestamp_gain= timestamp_gain+3600*$gain_timestamp where id_perso=$id_perso");



Maintenant, imaginez si deux appels à ce script arrivent simultanément au serveur web… Quel est le risque ? Que le joueur perçoive 2 fois trop de PA !

Pour éviter cette situation délicate, il n’existe guère de salut en dehors des transactions. Vous pourriez effectuer toute l’opération en une seule requête (la requête est compliquée mais c’est parfaitement faisable), mais ce n’est valable que pour ce cas précis. Vous pourriez aussi gérer vous-même une section critique à l’aide de sémaphores UNIX, de la fonction flock() ou la fonction GET_LOCK() de MySQL. Oubliez tout de suite, c’est une très mauvaise idée. D’une part, parce que (hormis avec flock), vous devenez dépendant de fonctions qui ne seront pas forcément disponibles sur toute plate-forme, mais surtout parce que vous êtes en train de réinventer la roue ! La gestion des transactions est un problème compliqué, fiez-vous plutôt aux implémentations fiables et éprouvées qui existent déjà, vous gagnerez du temps et de la sueur ! 🙂

Pour clôre ce chapitre (et vous faire des frayeurs :p), appliquez le comportement que l’on vient de voir à une action d’attaque d’un adversaire : le joueur inflige des dommages à un adversaire. Si le nombre de Points de Vie de l’adversaire bascule en dessous de zéro, l’adversaire meurt. Plusieurs joueurs peuvent même attaquer un même adversaire simultanément. Que peut-il se passer en cas d’attaques simultanées sur un même perso ?

Multi-comptes

Vous avez maintenant toutes les cartes en main pour sécuriser votre site. Il reste cependant un problème potentiel : le multi-comptes. En effet, dans un jeu traditionnel, comme un jeu de carte, une personne ne peut jouer qu’un seul joueur. Dans un jeu sur internet, il en va autrement. Une même personne peut très facilement se créer plusieurs comptes sur votre jeu !
Selon le type de jeu, cela aura un impact plus ou moins important. Dans un jeu de guerre, où le nombre de joueurs influence les chances de victoire, cela peut être catastrophique. A moindre échelle, un autre compte peut être utiliser pour affaiblir l’ennemi avant de l’attaquer avec son vrai personnage, pour espionner ou même infiltrer son ennemi.

Il faut savoir qu’il est presque impossible, au niveau technique, d’empêcher le multi-comptes. Les principales techniques de détection, basées sur l’e-mail, l’adresse IP ou les cookies, peuvent être contournées par une personne suffisamment expérimentée. De même, il peut arriver que plusieurs personnes jouent réellement à partir du même poste (familles, écoles, cyber-cafés, …). Aucune technique de détection n’est donc véritablement fiable.

En conséquence, il est important d’évaluer les impacts et les risques provoqués par une personne gérant plusieurs comptes sur votre jeu. De là, vous devrez en déduire une politique à adapter face à ce problème.
Selon le type et les règles du jeu, cela pourrait être :

• autorisation explicite de faire du multi-comptes (aucun d’impact)
• autorisation implicite (très faible impact)
• interdiction explicite sans répression.
• interdiction explicite avec répression, ce qui suppose la mise en place d’un système de détection. On peut joueur sur le niveau de tolérance, sur l’éducation plutôt que la répression, s’aider de la dénonciation, etc. Le système de détection n’étant pas fiable, certains jeux mettent même en place des équipes chargées d’enquêter et juger les cas litigieux.

Le meilleur moyen de limiter le multi-comptes reste sans aucun doute de faire en sorte qu’il n’ait aucun impact sur le jeu… Ce qui n’est pas toujours forcément évident. C’est donc un aspect qui devrait être pris en compte dès la conception du jeu !

Pour conclure, retenez surtout qu’il n’y a pas de solution toute faite. Il faudra la choisir en fonction de votre jeu, de votre public et… de votre intuition ! 😉

Je remercie Merrick, VYS et DT pour leurs remarques et relecture de cet article 🙂

Voici quelques astuces et reflexes à avoir au moment de préparer ses pages et ses feuilles de style pour bien profiter des possibilité des styles d’impression.

L’appel à la feuille de style

De la même manière que vous appelez votre ou vos feuilles de style habituellement, vous pouvez ajouter des appels à d’autres feuilles en spécifiant bien le média auquel elles se destinent.

Exemple :

La typo

Certaines polices de caractères sont plus agréables à l’écran que d’autres. De la même manière, une police de caractère peut être désagréable ou moins « jolie » une fois imprimée. On peut donc utiliser la feuille de style d’impression pour changer de typo.
Les typo à empâtement, par exemple, sont très fréquentes sur support papier alors qu’elles le sont moins sur écran.
Il faut aussi penser à adapter la taille des caractères.

Exemple :
body
font: 10pt Times New Roman, serif;


Les liens

Les liens de navigation interne n’ont plus d’intérêt sur une feuille imprimée. On peut donc, dès le début, prévoir une classe spécifique à appliquer sur tous ces liens. Ainsi, on peut faire disparaître, par exemple, le sousligné sur les liens type « …que vous trouverez sur la page Recherche ».

Les liens externes, eux, sont certainement des liens qui continuent à avoir un sens hors du site.

CSS2 permet d’afficher l’adresse d’un lien après celui-ci. C’est très intéressant pour une feuille de style d’impression puisque, sur papier, impossible de cliquer. Sans cette possibilité, l’information principale du lien (l’adresse) est perdue.
Ne soyez pas déçus, néanmoins, si vous imprimez avec Internet Explorer : cette fonction n’est pas encore implémentée. Cela ne générera pas d’erreur … mais cela n’affichera pas l’adresse internet non plus !

Exemple :
a.navigationInterne
text-decoration: none;

a:after
content: " (" attr(href) ") ";
font-size: 0.9em;

a.navigationInterne:after
content: "";


Les couleurs et les images de fond

Les couleurs de fond peuvent avoir de gros inconvénients, une fois sur papier.
Elles peuvent, dans certains cas, gêner la lisibilité (plus que sur écran où le contraste n’est pas le même).

C’est encore plus vrai pour les images de fond qui peuvent être jolies et sans effet gênant sur un écran mais poser des problèmes de contraste à la lecture sur papier.

Couleurs de fond et images de fond peuvent aussi utiliser beaucoup d’encre pour un effet graphique mineur. L’internaute apprécierait qu’un site ait pensé à lui éviter le problème.
Cette fonctionnalité est d’ailleurs déjà implémentée par défaut dans certains navigateurs.

Attention, en enlevant les couleurs de fond, à ne pas se retrouver avec un texte illisible. Si un texte jaune, par exemple, était très lisible sur son fond noir, une fois la couleur de fond enlevée, le jaune sur le blanc de la feuille sera très difficile à lire. Il convient d’adapter la couleur du texte à tout changement de couleur de fond.

Exemple :
p
background: none;
color: #000;


Les marges, les espacements

L’aération d’une page imprimée n’est pas la même que pour une page web.
Il sera alors peut-être nécéssaire de revoir les marges, notamment horizontale, sur votre feuille d’impression.
Pensez que l’internaute sera déçu s’il doit imprimer sur 2 pages avec une marge de 4 cm un texte qui tiendrait sur 1 en utilisant simplement toute la largeur de la feuille.

Adaptez les espacements entre les éléments au média. Les titres n’ont pas forcément besoin d’être autant espacés de leur texte sur une version papier qu’à l’écran.

Les sauts de page

Rien de plus désagréable pour un internaute qu’une page sur laquelle n’a été imprimée qu’une seule ligne, qu’un paragraphe dont les derniers mots sont sur la page suivante, qu’un titre qui n’est pas immédiatement suivi par, au moins, la première ligne de son paragraphe, ou qu’une image dont la légende a été imprimée sur la page suivante, etc.
Les styles d’impression permettent de gérer tout ça. Analysez bien vos pages pour voir quels sont les coupures à éviter. Attention à ne pas tomber dans l’excès inverse et de faire des coupures partout : l’internaute n’appréciera pas non plus de devoir imprimer trop de pages.

Les propriétés à utiliser :
– page-break-before (gestion du saut de page avant l’élément)
– page-break-after (gestion du saut de page après l’élément)
– orphans (gestion des lignes seules en bas de page)
– widows (gestion des lignes seules en haut de page)

Exemple :
h1, h2, h3, h4, h5, h6
page-break-after:avoid;

p
orphans: 2;


Dans l’exemple ci-dessus, aucun saut de page ne sera fait après un titre hn et aucun début de paragraphe ne sera imprimé avec moins de deux lignes en bas de page.

Les zones inutiles

Certaines zones très courantes sur un site web sont néanmoins inutiles sur une version imprimée.
C’est le cas par exemple du menu. L’internaute qui imprime une page n’a plus besoin, quand il voudra relire sa page, d’avoir dans sa lecture tous les items du menu imprimés.

Un formulaire n’a également plus de sens sur une feuille imprimée (sauf, bien-sûr, les formulaires fait pour l’impression).
Il n’est pas forcément utile que le formulaire soit encore visible sur une page contact, par exemple, qui aurait été imprimée pour garder une trace du numéro de téléphone, de l’adresse, etc.

Les liens tels que « Retour à l’accueil » peuvent aussi être évité sur une feuille d’impression. Il faut identifier ces liens et leur assigner une classe particulière pour pouvoir les retirer lors de l’impression.

Exemple :
#menu, #piedDePage, form, #retourHautPage
display: none;

.lienNonImprime
display: none;



Les informations perdues

En supprimant le menu, en ayant pas la barre d’adresse imprimée, certaines informations se retrouvent « hors de la page web ».
L’internaute retrouve souvent ce type d’information imprimée en en-tête et pied-de-page (avec la date, parfois le titre…) en fonction de son navigateur et de sa configuration.
Mais le webmaster n’a pas la main sur ces informations.

Pour palier à cela, on peut concevoir, sur chacune des pages, une zone qui ne sera pas visible pour les écrans mais qui le sera à l’impression.
Cette zone reprendrait des informations telles que le titre du site, son URL, des informations importantes qui pourrait manquer au lecteur de la page imprimée (l’email du webmaster, par exemple).

Exemple :
Sur la feuille de style pour écran :

#infosImpression
display: none;



Sur la feuille de style pour imprimante:

#infosImpression
display: block;



Intro

Ajax, Web 2.0, la mode est à l’asynchrone … Ajax est-il incontournable ? Est-il véritablement intéressant d’utiliser Ajax comme méthode d’échange d’information dans le cadre du développement d’un jeu ?

Petits rappels

AJAX, pour Asynchronous JavaScript and XML est une technique de développement web qui vise à rendre les pages plus ergonomiques. L’objectif est de donner une sensation de réponse instantanée à l’utilisateur. Le principe de base est terriblement simple : échanger de faibles quantités d’information via un appel asynchrone – et en général grâce à du code XML, entre le client et le serveur.

Quand on parle d’Ajax, on entend trois choses:

1. L’utilisation intensive de JavaScript
2. L’utilisation de l’objet XMLHttpRequest
3. L’utilisation du langage XML pour le transfert des informations

Les puristes ajouteront un soupçon de XSLT pour le rendu, mais ce sont des puristes 😉

Vous l’aurez tous compris, Ajax, comme le DHTML, n’est pas une technologie en soi, c’est le fait d’utiliser un groupe de technologie ensemble dans un but précis.

Utiliser Ajax a des avantages : meilleure gestion de la bande passante, interactivité améliorée, hype pour n’en citer que quelque uns. Cette technique a aussi des inconvénients : diminution de l’accessibilité, mise en péril de l’ergonomie à laquelle l’utilisateur est habitué, temps de réponses non maîtrisés et principe de l’asynchronisme généralement mal assimilés par les programmeurs débutants.

Mise en situation

Mettons-nous dans la peau d’un webmaster lambda. Il développe son premier jeu. Pour simplifier notre propos considérons que son jeu ne compte que trois éléments: des pages plutôt statiques, comme des news, un classement, ou une FAQ. Des pages plutôt dynamiques, comme une carte. Et des pages composées presque exclusivement de formulaires, comme l’administration de compte ou le passage d’ordres.

Comment juger de l’intérêt d’une technologie ? En dehors de l’aspect subjectif « j’implémente parce que j’en ai envie » ou « parce que ça m’amuse », mesurons le degré d’intérêt en fonction de trois critères : l’ergonomie, les performances et la simplicité.

Valeur ajoutée à l’ergonomie générale
Comment l’utilisateur va t-il percevoir ce changement ? Va-t-il avoir la sensation que les « performances » de l’interface sont améliorées ? Va-t-il disposer de nouvelles fonctionnalités qui s’intègrent harmonieusement avec le reste, avec les fonctions par défaut de son navigateur (par exemple avec le bouton Back) ?

Supposons que notre webmaster n’affiche que 5 news. Il pourrait vouloir proposer un lien « Voir les news suivantes », ou un accès aux « archive » avec un calendrier. Sans Ajax le principe est simple, on ajoute un paramètre au script qui affiche la page et on rafraichi la totalité de la page. Avec Ajax on économise l’appel à ce script. On ne rafraichi que le contenu que l’utilisateur demande : les news. Il reçoit sa réponse plus vite, sans le « clignotement » de la page qui se rafraîchi. Attention néanmoins à ne pas le dérouter. Il faut que le changement sur la page soit clair, bien visible.

En ce qui concerne la carte, il est nécessaire de supporter un minimum de scrolling. La solution du rafraîchissement de la page à chaque déplacement est possible, bien sur, mais fort limité tout de même. Sans parler que son jeu aura l’air à la traîne techniquement. Quand on parle de scrolling on pense forcement à maintenir un (ou des) buffer(s). Techniquement, Ajax est bien adapté à ce type d’utilisation. A tout moment il est possible de déclencher le pré chargement d’une partie de la carte de façon invisible. Maintenir le buffer devient plus simple. Le XML se prête aussi à ce type d’utilisation. Le buffer deviendra un ou plusieurs node(s) dont on assurera le rendu via une fonction JS qui va bien.

Reste les pages dotées de formulaires. Nous étions habitués à devoir les valider d’abord côté client, puis à éventuellement demander une correction à l’utilisateur. Depuis fort longtemps nous sommes tous habitué à vérifier nos formulaires une seconde fois côté serveur. Ajax apporte ici deux avantages majeurs :

1. la possibilité de proposer des informations contextuelles (pensez au système d’auto-completion de gmail par exemple).
2. la possibilité de valider le formulaire au fur et à mesure, donnant un feedback plus rapide à l’utilisateur, évitant ainsi la frustration du formulaire refusé.

Bien sur, ça n’exclu pas la vérification côté serveur, mais ici l’intérêt en terme d’ergonomie est énorme, puisque les formulaires sont partout dans nos jeux.

Gain de performances côté serveur
Que va-t-on gagner en définitive ? On peut estimer le gain en fonction du temps d’exécution des scripts. De la répartition des requêtes SQL. Du taux d’utilisation moyen des ressources. Mais globalement ce qui nous intéresse c’est surtout le temps de réponse du site.

Le serveur n’a pas besoin de calculer le rendu de toute la page. Il n’effectue le plus souvent qu’un seul SELECT, pour récupérer les informations demandées par l’utilisateur. L’économie ici est triple :

1. On économise sur les SELECT qu’aurait effectué le serveur si il avait du rafraîchir toute la page, puisque seules les infos demandées sont rafraîchies
2. On économise la bande passante : pas besoin de renvoyer tout le code HTML, mais seulement un petit bout de code XML.
3. On économise sur le rendu : raffinement supplémentaire, le rendu peut-être délégué à une fonction JS, autant d’économie en temps d’exécution PHP.

Ceci dit Ajax peut avoir un effet pervers : la multiplication des requêtes. Il est tentant par exemple d’effectuer un rafraîchissement automatique par polling. Une aide contextuelle dans un formulaire utilisé pour chaque passage d’ordre signifie une requête au serveur web (et potentiellement une requête SQL) à chaque fois. Si la solution peut-être envisageable attention aux ressources qu’elle requiert.

Simplicité de mise en œuvre
Est-il aisé d’implémenter cette solution ? Est-il plus aisé de continuer à utiliser les techniques habituelles de DHTML ? Pourra-t-on la maintenir facilement ? Pourra-t-on facilement l’améliorer ? Considérons pour le moment que notre MJ ne se base pas sur un framework existant.

Soyons réaliste, non Ajax n’est pas simple à mettre en œuvre. Il demande une certaine expérience du développement web, sans doute plus que le DHTML à son époque. Il demande également une grande rigueur dans le code. Il est souvent nécessaire de jongler avec les éléments via leur id’s, de pouvoir modifier le contenu à la volée, en respectant le look&feel du site, d’où le besoin intensif de CSS. Ajax nécessite aussi de bien comprendre le concept d’asynchronisme, d’en connaître les limites et les risques.

Conclusions

Nous approfondirons les points abordés dans la suite, mais d’ores et déjà une réponse s’impose : oui, Ajax peut nous être utile. Le gain d’ergonomie peut-être énorme : assistance au remplissage des formulaire, aide contextuelle, réactivité accrue, meilleure gestion des cartes, autant de domaine ou Ajax excelle. La mise en place demande tout de même un minimum de réflexion. Où l’appliquer, tout d’abord. Quel sera l’impact sur les performances du serveur ? Enfin, la conception même du jeu devra évoluer, on pourra dans un premier temps se contenter d’intégrer Ajax à l’existant, mais pour en tirer vraiment partit il faudra souvent repasser par la case développement. Stay tuned et rendez vous dans le numéro 2…

L’apparence

Pour que votre site soit fonctionnel, les liens doivent être immédiatement reconnus comme tels. Ils doivent donc impérativement se différencier du texte normal.
L’usage veut que le lien soit souligné et bleu. Si la majorité des sites s’affranchissent du bleu (créant ainsi un apprentissage de l’internaute), le soulignement reste encore un repère utile.
Il est d’ailleurs fortement déconseillé d’utiliser le soulignement pour autre chose que les liens hypertextes. L’effet en est TRES perturbateur.

Si on décide de se passer du soulignement, il faut lui substituer un autre repère visuel.
C’est le cas, par exemple, des menus qui sotn souvent présentés de telle sorte qu’ils n’ont pas besoin d’être souligné. C’est aussi le cas des boutons dans lesquels on reconnaît immédiatement une action à faire.

Pour plus de fonctionnalité, les CSS peuvent vous aider à donner des repères supplémentaires en fonction des actions (survol du lien, liens déjà vus, etc).

Le libellé

Il faut le soigner à plusieurs niveaux. D’abord, parce que c’est ce qui va -ou non- insciter l’internaut à cliqurer. Vos liens mis en valeur comme vu dans le paragraphe « L’apparence », il est possible que l’oeil de l’internaute ballaye le page, entre autres, de liens en liens.

Le libelé doit donc être clair et explicite. Evitez les liens trop génériques et, si vous optez quand même pour un lien type « En savoir plus », n’oubliez pas de préciser de quoi vous parler : « En savoir plus sur le livre L’ignorance de Milan Kundera ».

Les moteurs d’indexation sont également très sensibles aux libelés des liens. Si vous pensez à rédiger un lien parlant, il auta de grandes chances de contenir des mots-clé, très utiles pour votre référencement naturel.

Pour un lien d’action, utilisez un berbe à l’infinitif qui décrit bien l’effet induit par le clic. Exemple : « Valider mon choix ».

Attention, par contre, à éviter les libelés trop longs. Le lien doit être explicite en lui-même. Pour qu’il puisse être un bon repère pour l’internaute, il est préférable qu’il ne fasse que quelques mots.

De plus, les règles d’accessibilité préconisent moins de 80 caractères par liens.

L’attribut « title »

Il n’est pas un élément obligatoire, mais il apporte plusieurs avantages.

En premier lieu, il vous permet de (et il doit) donner des information supplémentaires à l’internaute. Sur le type d’ouverture (« Nouvelle fenêtre »), sur le poid à charger (« format .pdf – 53k) ou des renseignements plus précis (« Lire la fiche de lecture : Le Petit Prince d’Antoine de Saint-Exupéry » sur un lien « Le Petit Prince »), etc.

Cela peut être l’occasion de renforcer votre référencement naturel : densité des mots-clé ou couverture du champ lexical.

Pour finir, ces informations supplémentaires sont également très utiles en terme d’accessibilité. Là aussi, il ne faut pas dépasser 80 caractères.

Le lien entrant

Avoir d’autres sites qui font un lien vers le votre est une très bonne chose (surtout si la page qui vous cite traîte d’un sujet connexe). Cela augmente, bien sûr, vos chances d’être trouvé par l’internaute et c’est bon pour le référencement naturel.
Si vous ne pouvez agir que rarement sur l’apparence des liens chez un site partenaire qui fait un lien vers vous, veille par contre à la qualité du libelé et à la présence de l’attribut « title ».

Dans le cas d’un partenariat rémunéré, un repère modifie l’URL afin de savoir que le lien a été cliqué. Certaines méthodes sont mauvaises pour le référencement car elles empêchent les robots d’indexation d’enregistrer correctement le lien. C’est donc également un aspect à surveiller lors d’un partenariat.

Les liens, par leur rôle spécifiques au web – et par leur importance dans le référencement naturel – méritent la plus grande attention. pour un Internet plus riche et plus pertinent.

Même si vous utilisez souvent, voir tout le temps, le pixel comme unité de mesure dans vos feuilles de styles, sachez qu’il en existe d’autres et que le pixel n’est pas la mesure forcément la plus recommandée.
– Et nous allons voir pourquoi.

Deux sortes d’unités

Il existe en fait deux sortes d’unités :

les unités dites absolues

Les unités absolues sont données en fonction d’un axe imaginaire situé en haut et à gauche de l’objet parent, par exemple la fenêtre de navigation.

Attention : ces unités ne permettent pas d’obtenir un résultat similaire sur plusieurs écran. En effet, 1 centimètre sur un écran de 14 pouces n’a rien à voir avec le « même » centimètre sur un écran de 21 pouces.

En revanche, vous pouvez (devez) les utiliser dans vos feuilles de styles réservées à l’impression.

les unités dites relatives

Les unités relatives peuvent être négatives puisqu’elles expriment une mesure en rapport à une valeur de référence.

L’unité « ex » exprime une mesure dont le point de référence est la hauteur des minuscules de la police courante.

Et maintenant, je fais quoi ?

Il est donc fortement conseillé d’utiliser l’unité em pour les tailles de textes.

Pour les élements graphiques, le pourcentage est fortement conseillé. Et les pixels pour positionner des éléments précisément sur un écran.

Les unités cm et mm sont à proscrire pour l’écran, mais à utiliser pour l’imprimante.

Vous connaissez sans aucun doute le W3C et toute les normes qui en sort. Et vous savez très certainement que nos pages internet doivent répondrent à certains critères afin qu’elles s’affichent correctement quelque soit le navigateur utilisé.

Pour tester vos pages, vous avez évidement les outils proposés par le W3C. Vous pouvez notament contrôler vos pages ici : http://validator.w3.org/

Vous indiquez l’URL de la page à contrôler et vous aurez le résultat aussitôt. En vert, c’est ok. En rouge : il va falloir revoir certaines choses.

Si vous avez testé ce validateur, vous aurez remarqué comme il est très compliqué de mettre au point des pages valident. Les erreur annoncées ne sont pas toujours très claires et sont, bien souvent, dépendantes d’autres erreurs.

Au passage, vous pouvez placer ce lien sur vos pages : http://validator.w3.org/check?uri=referer

Ceci vous permet de tester directement la qualité de vos pages.

Encore plus simple !

Firefox arrive comme un grand dans le monde des navigateurs en proposant tout plein de petites extensions permettant d’améliorer la navigation, mais également le développement de pages en ajoutant des outils d’aide aux développeurs.

HTML Validator est donc une extension de Firefox qui vous permet d’un simple coup d’oeil de contrôler la validité de vos pages en indiquant (en bas à droite)

Une extension vraiment pratique qui vous fera gagner un temps précieux. En cliquant sur l’icône en bas à droite de Firefox, vous aurez alors une page avec le code source et l’explication (plus ou moins claire) de l’erreur.

Malheureusement, vous constaterez amèrement que certaines régies publicitaires ne respectent pas toujours les standards et génèrent de ce fait des erreurs que vous ne pourrez pas corriger (cas de Google AdSense par exemple).

HTML Validator pour Firefox est disponible ici.

L’attribut alt

L’attribut alt est fait pour accueillir un contenu alternatif. Il sera utilisé par le navigateur, par l’agent utilisateur en général, au cas où il ne pourrait pas lire l’élément, une image par exemple.

Dans une page web, un certains nombre d’éléments peuvent ne pas être accessible au navigateur, à l’agent utilisateur. Les images, par exemple, ne sont bien évidement pas « lues » par un navigateur vocal ou si un internaute, en bas débit par exemple, a décidé de désactiver les images.
Cela peut-être le cas des applets, des objets, des images ; en fait, de tous les éléments graphiques.

Pour que les internautes ne perdent pas pour autant l’information, on fournit à l’agent utilisateur une alternative textuelle. Elle a pour but d’indiquer à l’internaute le contenu de l’applet, de l’objet, de l’image.

Exemple [[Les exemples sont donnés en XHTML]] :

Tous les objets graphiques doivent fournir une information alternative.
Dans le cas d’une image purement décorative, l’attribut alt peut être laissé vide, mais doit être présent.

Exemple :

Le contenu du alt doit faire 60 caractères maximum (un caractère encodé vaut pour un).

Si l’objet, par contre, fournit de nombreuses informations, qu’il est impossible ou réducteur de le résumer dans un alt, on utilise alors en complément l’attribut longdesc qui fait appel à un fichier de description plus complet.

Exemple :

L’attribut title

L’attribut title (non la balise title contenue dans le head et qui apparaît dans la barre de titre du navigateur) est le titre d’un élément.

Il peut être présent pour une image.

Exemple :

Il est également attendu sur les liens pour fournir une information en plus de celles du libellé.

Exemple :
L'accessibilité


Si nous reprennons l’exemple du logo, nous pourrions avoir :

L’information données par l’attribut title est destinée à tous les types de navigateurs et fournis dons un texte visible par tous.
Le texte d’un title apparaît donc dans les navigateurs classiques dans une petite info-bulle, au survol de l’élément.

En cas d’absence de title mais de présence de alt, Internet Explorer affiche le contenu du alt dans l’info-bulle. Et c’est probablement de là qu’est née une partie de la confusion entre ces deux éléments et qui a fait que l’on trouve encore beaucoup de alt dans des balises a (ce qui n’a pas de sens au vu de la fonction du alt).
Si les deux attributs sont présents, Internet Explorer utilise le title en priorité pour son info-bulle.

L’attribut title autorise 80 carctères maximum (un caractère encodé vaut pour un).

Plutôt que de mettre tout votre style en interne, dans une page, il faut privilégier la feuille de style externe.

plutôt que

Le séparteur

A la fin d’une déclaration, on met un « ; ».

Le point-virgule est un séparateur, entre deux déclarations, il n’est donc pas nécessaire de le mettre à la fin de la dernière déclaration.

Le gain peut parraître minime, mais sur Internet, chaque octet compte.

h2 margin-top:20px
h3 text-indent:10%
p text-align: justify

plutôt que

h2 margin-top:20px;
h3 text-indent:10%;
p text-align: justify;

Les couleurs

La notation hexadécimale des couleurs peut être passée sur 4 caractères au lieu de 7 lorque chacune des trois couleurs est décrite par deux caractères identiques.

color:#ABC

plutôt que

color:#AABBCC

Les unités

Lorsqu’une valeur est à 0, il est inutile de préciser son unité, quelle qu’elle soit.

margin:0 5em

plutôt que

margin:0px 5em

Les valeurs par défaut

Chaque propriété à une valeur par défaut initiale. Inutile, donc, de déclarer le comportement d’un élément si celui-ci est déjà par défaut.

div border:1px solid #A1F5C3

plutôt que

div position:static; border:1px solid #A1F5C3

Les propriétés raccourcies

(Voir 14)

Une même propriété peut, à elle seule, déclarer plusieurs propriétés. Elles sont donc à privilégier fortement ; en plus du gain de poids, elles sont aussi bien plus agréable au développement et à la relecture car elles permettent un code moins verbeux.[Pour en savoir plus : [CSS Cheat Sheet (pdf – 379k) de Dave Child ou sa traduction française par goetzilla: Aide-mémoire CSS (pdf – 43k) ]]

border: solid #DEF; border-width: 0 2px 2px 0;

plutôt que

border-color: #DDEEFF; border-style: solid; border-left-width: 0px; border-right-width: 2px; border-top-width: 0px; border-bottom-width: 2px;

Les déclarations communes

Lorsque qu’une ou plusieurs déclarations s’appliquent à plusieurs éléments, les declarations communes apportent, elles aussi, plusieurs avantages.
Celui du gain de poids, un code moins verbeux, mais aussi une maintenance plus agréable puisqu’une même propriété pourra être modifier sur plusieurs éléments, même différents mais tous concernés, d’un coup.[[<1>]]

#footer, #footer a, #footer span font-size: smaller

plutôt que

#footer font-size: smaller
#footer a font-size: smaller
#footer span font-size: smaller

Les propriétés qui héritent

Les CSS sont basées sur le système d’héritage et un certain nombres de propriétés héritant, il n’est pas nécessaire de les re-déclarer dans les éléments enfants.[[<1>]]

* font-family: Arial, Helvetica, sans-serif

plutôt que

* font-family: Arial, Helvetica, sans-serif
p font-family: Arial, Helvetica, sans-serif
a font-family: Arial, Helvetica, sans-serif

Les selecteurs qui appartiennent déjà à une classe

Pour un même groupe, il est parfois inutile de créer une classe pour chaque élément du groupe. Il suffit de faire appel à la classe (ou à l’id) du groupe et de préciser quel élément sera touché par la règle.

Si le poids de la feuille de style y gagne, le poids du code HTML en tire également le même bénéfice.

#footer color: #BDB76B
#footer a color: #562
#footer span margin: 0 5px
et

plutôt que

#footer color: #BDB76B
.footerLiens color: #562
.footerTexte margin: 0 5px
et