Retour sur l’article de cybercodeur Liens et nouvelle fenêtre que je trouve très intéressant et que tout le monde n’a pas l’air d’avoir bien compris.

Eric Daspet a écrit un article (Liens et nouvelle fenêtre) très intéressant sur le problème d’ouverture de nouvelles fenêtres en xhtml strict. D’après lui la question Comment dois-je faire sans l’attribut ‘target’ qui a disparu? revient souvent. J’ai passé un bout de temps à lire tous les commentaires et il m’est resté une impression que les gens n’ont pas tout bien compris les points intéressants.

D’abord il est important de commencer par lire son article, car ça démarche est bien expliquée.

Ensuite ce qui m’a le plus posé de problème, c’est la manière dont le principe de séparation : contenu structuré / habillage / comportement n’est pas compris ou mal interprété.

Pour moi l’intérêt du XHTML strict est de séparer tout ça, ce qui revient globalement à :

• un fichier pour le contenu et sa structure (xhtml)
• un fichier pour l’habillage et le style (css)
• un fichier pour le comportement (javascript)

Pour le reste il ne s’agit que de principe de développement : si dans une équipe assurant la maintenance d’un produit, un collaborateur ne sait pas comment fonctionne et est organisé celui-ci, ça ne peut pas marcher quelle que soit la technique…

Eric a voulu donner une solution à un problème précis en utilisant un principe très général.

Dans les commentaires, j’en ai lu qui prétendaient que cela ne valait pas le coup de créer un fichier de 50 lignes pour reproduire un comportement qui fonctionne déjà en quelques lettres ajoutées au code html. En revanche c’est très intéressant dans un contexte où la création d’une nouvelle fenêtre n’est pas le seul comportement :

Imaginez un site commercial qui aurait impérativement besoin de faire ouvrir les liens vers des sites externes dans d’autres fenêtres (j’ai du mal mais je peux comprendre que des fois on ne puisse pas faire comme on veut). Comme souvent sur les sites commerciaux, un certain nombre de formulaires permettent aux visiteurs de saisir des informations (données d’inscription, informations de commande, de paiement…) Dans ces formulaires tous les champs de saisie sont des balises input, select, textarea… Pourtant ils n’ont pas toujours le même comportement : zone numérique, champs contenant des adresses email.

En séparant structure et comportement, il suffit de modifier le fichier javascript pour prendre en compte par exemple l’évênement “saisie d’une adresse email” dans un champ de type email identifié par class="email". Et là les 51 lignes deviennent très intéressante car dès que les règles comportementales se multiplie, 1 seul fichier est modifié, à 1 seul endroit. Je peux vous assurer que niveau maintenance / évolutivité c’est un énorme gain de temps.

Maintenant, si les équipes de développement ne se conforment pas aux “normes” de développement de leur projet, c’est qu’elles sont soit mal formées, soit mal encadrées. Je mets norme entre guillemets parce qu’il ne s’agit d’appliquer les standards proposés par le W3C mais ceux d’un projet qui peuvent ou non les appliquer.