Quelques raisons pour lesquelles les cadres devraient être évacués de tout bonne pratique Web.
Les cadres, introduits initialement par Netscape 2.0 en mars 1996, furent un parfait exemple du succès instantané qui caractérise si bien tout ce qui touche de près ou de loin au HTML. L'incroyable possibilité de subdiviser la fenêtre d'un navigateur en plusieurs fenêtres indépendantes pouvant communiquer entre elles eut tôt fait de séduire une bonne partie de la communauté de développeurs. Ceux-ci y virent une occasion en or d'accroître la productivité et l'optimisation des documents composant un site Web, notamment en séparant la navigation des contenus. Rapidement, le concept fut intégré dans Internet Explorer, si bien que dès la publication de la spécification HTML 4.0 en septembre 1997, les cadres faisaient une entrée remarquée dans les normes HTML et dans l'histoire du Web par la même occasion.
Comme c'est souvent le cas dans ce domaine, il ne fallut pas plus de quelques mois pour que n'émerge une nouvelle forme de résistance contre cette implémentation. Certains développeurs, théoriciens et autres cogiteurs du Web s'arrêtèrent à analyser les avantages et inconvénients associés aux cadres. Ils conclurent qu'en vérité, la possibilité d'ainsi découper un navigateur entraînait beaucoup plus de torts que de bénéfices. Aujourd'hui, tous s'entendent pour le dire, les cadres ont perdu la cote d'amour auprès des développeurs. Ils continuent d'ailleurs de perdre des plumes années après années, en partie dû au fait que des alternatives beaucoup plus intéressantes deviennent disponibles. Parmi ces alternatives, notons les inclusions de fichiers rendues possibles par le recours aux langages de programmation et une prise de conscience de l'importance du respect de la sémantique Web.
Ce qui serait convenable d'appeler le plus grand paradoxe occasionné par les cadres, c'est la dénaturation du principe fondamental qui tisse le Web. L'Url est cet indice unique permettant d'accéder à n'importe quel document présent sur la toile par son adresse virtuelle. Un document contenu dans un ensemble de cadres perd cette identité propre pour endosser celle de son parent, de sorte que plusieurs documents viennent à être regroupés sous une seule adresse, rendant passablement difficile l'action de pointer vers un document spécifique.
C'est également cet identifiant unique qui rend possible l'action de mettre une page en signet (de l'ajouter à ses favoris). Puisqu'un document Web contenu dans un ensemble de cadres est représenté par un URL groupé, il devient impossible de le signer spécifiquement. Un tel document ajouté aux favoris sera toujours associé à l'adresse de l'ensemble de cadres le contenant, si bien que lors d'un éventuel retour, l'utilisateur se verra contraint de naviguer dans le site pour retrouver la page qui l'intéressait a priori. Cela peut s'avérer particulièrement fâcheux et même carrément impossible dans un site contenant des centaines, voire des milliers de pages. Surtout si on fait référence à un document généré dynamiquement, dont le véritable URL est composé d'une série interminable de paramètres accrochés les uns aux autres.
La problématique de la décontextualisation du document Web cadré prend toute son ampleur lors de l'indexation par un engin de recherche. L'une des utilisations les plus fréquentes des cadres consiste à créer une séparation nette entre la navigation et les contenus. Un tel document répertorié par un engin et présenté lors d'une requête deviendra alors accessible à l'utilisateur sans son contexte, perdant ainsi toute sa cohérence. Le même type de problème se pose également lorsqu'un document cadré est pointé spécifiquement par son URL. Ces documents sont généralement décontextualisés, ce qui les rend souvent inutilisables. Imaginez seulement une page Web qui, affichée seule, perd sa navigation ! Difficile de s'y retrouver !
L'utilisation des cadres rend inefficace l'impression des pages de contenu par le navigateur. Celui-ci interprète souvent la commande d'impression de manière erronée, en fonction du cadre sur lequel se trouve le focus au moment de son lancement. À cause de cette gestion instable des ressources, l'impression des documents est souvent compliquée ou insatisfaisante pour l'utilisateur qui doit s'y reprendre à plus d'une fois avant de réussir à coucher sur papier le document convoité.
L'utilisation des cadres repose sur un principe de séparation visuelle et non de structure de l'information. Pour tout agent utilisateur interprétant les documents dans leur ensemble, cela pose un sérieux problème de cohérence en matière de convivialité et d'orchestration logique puisqu'un même document ne contient qu'une partie et non l'ensemble de l'information présentée. Pour un individu naviguant sur un site cadré avec une technologie alternative comme un lecteur d'écran ou un navigateur texte par exemple, cela demande une gymnastique d'interprétation supplémentaire de la part du navigateur qui est souvent inadéquate ou inadaptée. C'est particulièrement vrai dans le cas des plages Braille, qui ne peuvent interpréter qu'un cadre à la fois et non pas l'ensemble des cadres d'un seul trait... la globalité du document et la logique de structuration en est donc âprement affectée aussitôt que l'utilisation des cadres est brouillonne.
En
théorie, il serait adéquat de penser que le recours aux cadres réduise
le nombre de fichiers dans un site Web, mais dans les faits, cela est
très rarement le cas. Les problèmes récurrents de décontextualisation
de l'information dans la navigation et dans les engins de recherche, le
regroupement de l'Url nuisant à la mise en signet et l'utilisation de
versions alternatives des pages par les balises <noframes>
rendent toujours inévitable la duplication des fichiers. Une solution
plus élégante consiste à recourir à une technologie permettant
l'inclusion de fichiers côté serveur, qui seront intégrés dans les
documents globalement par le navigateur. D'un point de vue structurel,
le résultat est le même, mais d'un point de vue d'accessibilité du
document et de sa qualité sémantique, il en va tout autrement. Des
arguments en faveur des cadres visant à assurer la présence continuelle
d'un logo, d'une entête ou d'un menu de navigation ne répondent qu'à
des visées présentationnelles, au détriment des véritables enjeux de
cohérence.
Des études sur les habitudes des internautes semblent démontrer que l'apparition de multiples barres de défilement dans une même page a pour effet d'occasionner une certaine confusion chez l'utilisateur inexpérimenté qui, du coup, ne sait plus où donner de la souris. Créer plusieurs zones fragmentées dans une même "page" nuirait également à la compréhension sous divers agents utilisateurs alternatifs pour les mêmes raisons. L'information ainsi découpée perd toute sa signification pour ne plus supporter qu'une logique visuelle pouvant ne pas convenir à tous les utilisateurs. De plus, la navigation inter-cadres a souvent pour effet de créer l'illusion d'une désactivation du bouton "précédent" dans le navigateur, ce qui est un mal en soi puisqu'il faut parfois plus d'un clic pour effectivement parvenir à rebrousser chemin.
Les cadres permettent au développeur mal intentionné de faire afficher dans son site une information Web ne lui appartenant pas dans le but de se l'approprier. Afin de se protéger contre une telle violation, de nombreux développeurs forcent la recontextualisation des documents dans leur environnement Web par JavaScript, causant ainsi une gestion supplémentaire des pages par abus de programmation. Ce type de procédé est également utilisé pour contrecarrer les problèmes d'indexation et de signage de documents. C'est donc dire que l'utilisation des cadres entraîne presque toujours le recours à des solutions compensatoires lourdes de conséquences pour un navigateur sur dix étant incapable de les supporter au moins partiellement (sans compter la charge de travail supplémentaire du développeur qui doit les maintenir à travers tout un site).
Cantonnés
exclusivement dans les DTDs HTML 4.0 et XHTML 1.0 Frameset, les cadres
sont complètement abandonnés dans les versions strictes de HTML et
XHTML. C'est donc dire qu'ils n'ont plus leur place dans les futurs
développements des normes d'un Web conforme à XML. Un site utilisant
des cadres ne passera tout simplement pas l'inspection sous un Doctype
Strict ou XML. En soi, cette raison en apparence bien minime est en
fait d'une importance capitale. Si tous les développements à venir se
basent sur les technologies XML et une séparation nette entre structure
et présentation dans le respect de la sémantique, le concept de cadres
perd toute sa raison d'être. À la lumière de ces arguments, tout porte
à croire que les cadres, au même titre que l'élément <blink>,
appartiennent à une époque révolue, soit celle de la conception Web du
siècle dernier, caractérisée par un manque de rigueur vis-à-vis du
respect des normes issues du W3C.
Si
les cadres posent toute une série de problèmes d'accessibilité, il est
tout de même possible de les rendre le moins dysfonctionnels possible
grâce à quelques petits procédés (x)HTML. Malheureusement, il n'y a
rien qui puisse être fait pour venir en aide aux navigateurs incapables
de les supporter, à part miser sur la diffusion du contenu par un mode
alternatif. Pour tous les agents utilisateurs aptes à les supporter, il
existe quelques petites recommandations visant à donner un sens à
l'ensemble de cadres afin de le rendre le plus convivial possible. Mis
à part l'évidente utilisation systématique du <noframes>, le recours à l'attribut title
dans chaque appel de cadre facilitera énormément la compréhension de
l'utilisateur lorsque celui-ci tentera de naviguer à l'aveuglette dans
un tel labyrinthe.
Un cadre portant un titre significatif sera d'un grand secours à l'internaute naviguant à l'aide d'une technologie alternative, surtout si les noms des fichiers vers lesquels l'ensemble de cadres pointe sont eux aussi particulièrement significatifs. Rendre le tout le plus accessible possible, c'est s'assurer qu'en lisant le nom du fichier et la description l'accompagnant, l'utilisateur comprendra d'emblée vers quel type d'information le document mènera. Il pourra ainsi prendre une décision à demi éclairée sur l'intérêt à pousser plus de l'avant son exploration ou alors à passer son chemin et ne plus revenir. Outre ces quelques recommandations, il n'existe en soi rien qui puisse être mis en œuvre pour rendre les cadres véritablement accessibles. Bien qu'il soit possible d'en limiter les dégâts, il n'en demeure pas moins qu'une barrière demeurera toujours une barrière, que celle-ci soit construite de fer forgé ou de vieilles planches tordues.
Mais au moins, en appliquant ces quelques règles à un ensemble de cadres, l'utilisateur se verra remettre une carte d'accès à l'entrée du site Web. Ce sera déjà un pas dans la bonne direction.