Cadre (World Wide Web)

Netscape Navigator 2.0 a introduit les éléments utilisés pour les cadres en mars 1996. D'autres fournisseurs de navigateurs, comme Apple avec Cyberdog, ont suivi plus tard dans l'année. À cette époque, Netscape a proposé l'intégration des cadres au World Wide Web Consortium (W3C) dans la norme HTML 3.0.

Les cadres étaient utilisés pour afficher et naviguer sur les premiers magazines en ligne et applications web , comme les services de messagerie et les sites de chat . Ils permettaient d'afficher des éléments sur l'ensemble du site sans nécessiter de fonctionnalités serveur telles que les inclusions côté serveur ou la prise en charge CGI . Ces fonctionnalités étaient rares sur les premiers serveurs web accessibles au public.

Les premiers sites web utilisaient souvent un cadre en haut pour afficher une bannière qui ne pouvait pas être déplacée par défilement. Ces cadres de bannière incluaient parfois le logo du site ainsi que de la publicité .

XHTML 1.1, successeur prévu de HTML 4, a supprimé toutes les frames. XFrames , son remplacement final prévu a fourni l' URI composite pour adresser un ensemble de frames rempli.

La norme HTML5 ultérieure a supprimé les cadres (framesets) par des moyens différents de ceux utilisés par XHTML. L' iframeélément `<frameset>` subsiste avec un certain nombre d'options de « sandbox » destinées au partage de contenu entre sites.

En permettant le chargement et la navigation indépendants du contenu, les frames offraient plusieurs avantages par rapport au HTML simple utilisé lors de leur développement initial :

• Simplifier la maintenance du contenu partagé sur la plupart des pages, comme les données de navigation. Si un élément doit être ajouté à un menu de navigation latéral, l'auteur de la page Web n'a besoin de modifier qu'un seul fichier de page Web, alors que chaque page individuelle d'un site Web traditionnel sans cadre devrait être modifiée si le menu latéral apparaissait sur toutes les pages.
• Réduire la quantité de bande passante nécessaire en évitant de retélécharger les parties de la page qui n'ont pas changé.
• Permettant d'afficher plusieurs informations côte à côte, chaque section pouvant être parcourue indépendamment. Cela peut inclure la comparaison côte à côte de deux images ou vidéos, ou deux manières différentes d'appréhender un même élément, comme une page de texte défilant indépendamment à côté d'une vidéo, d'images, d'une animation, d'objets 3D en rotation, etc.
• Autoriser l'affichage des notes de bas de page ou des digressions dans une section dédiée de la page lorsqu'elles sont liées, afin que le lecteur ne perde pas sa place dans le texte principal.
• Le principal avantage des cadres est qu'ils permettent de maintenir certaines parties de la page fixes tandis que d'autres défilent. Ceci est utile pour les éléments que vous ne souhaitez pas faire disparaître de l'écran lors du défilement, comme les options de navigation ou les bannières publicitaires.
• Les cadres permettent d'unifier des ressources hébergées sur des serveurs distincts. Par exemple, vous pouvez utiliser des cadres pour combiner votre propre contenu (et les éléments graphiques de navigation) avec des discussions générées par des forums.

L’utilisation de cadres pour le contenu HTML a suscité de nombreuses critiques, principalement liées à des problèmes d’utilisabilité et d’accessibilité . En voici quelques exemples :

• Le cadrage rompt l’identité entre le contenu et l’URL tels qu’ils sont affichés dans le navigateur, ce qui rend difficile de créer un lien vers ou de mettre en signet un élément de contenu particulier dans le cadre
• L'implémentation des cadres est incohérente d'un navigateur à l'autre
• Les navigateurs qui affichent le contenu de manière linéaire ne gèrent pas bien les images.
  • programmes de lecture d'écran
  • navigateurs de texte ou audio
  • Les navigateurs de messagerie tels qu'Agora
  • navigateurs mobiles
• Le framing complique l’indexation web et peut nuire à l’optimisation pour les moteurs de recherche .
• Le framing brouille les frontières entre le contenu sur différents serveurs, ce qui soulève des problèmes de violation du droit d'auteur
• Les visiteurs arrivant des moteurs de recherche peuvent atterrir sur une page destinée à être affichée dans un cadre, ce qui fait que le visiteur n’a aucun moyen de naviguer vers le reste du site
• Les cadres modifient le comportement du bouton retour.
• Les utilisateurs ne s'attendent généralement pas à ce que les navigateurs impriment les cadres de cette manière.
• Les liens externes présents sur les pages web utilisant des cadres peuvent afficher d'autres pages dans ces cadres, car par défaut, un lien s'ouvre dans le cadre courant sauf indication contraire de l'auteur. Des webmasters peu scrupuleux pourraient exploiter cette faille pour faire croire que le contenu d'un autre site fait partie intégrante du site hébergeant les cadres.
• Si la résolution de l'écran ou la taille de la fenêtre du navigateur est trop faible, chaque cadre affichera des barres de défilement, ce qui peut donner un aspect désordonné et gaspiller un espace déjà limité. Ce comportement résulte généralement d'une mauvaise conception du site (mises en page fixes au lieu de mises en page fluides), où toutes les fonctionnalités des cadres ne sont pas exploitées de manière optimale. Ce problème peut être atténué par :
  • désactiver le défilement pour les cadres plus petits qui ne nécessitaient généralement pas de barre de défilement ;
  • Utiliser des caractéristiques de conception fluides dans les pages cibles au lieu de conceptions fixes, afin que le contenu ne provoque pas de barres de défilement horizontales.

Les cadres (iframes) posent des difficultés techniques et d'interface utilisateur pour l'application de la politique d'origine identique . Par exemple, une page externe peut inciter un utilisateur à effectuer une action sur une page interne (chargée via l'élément iframe) rendue presque totalement transparente.

Avec le développement des technologies web, bon nombre des objectifs pour lesquels les cadres étaient utilisés sont devenus possibles d'une manière qui permettait d'éviter les problèmes identifiés avec ces cadres.

• Les feuilles de style en cascade (CSS) permettaient aux éléments d'une page de défiler indépendamment (à l'aide de la overflowpropriété) ou de rester affichés à l'écran pendant que d'autres contenus défilaient (à l'aide de position:fixed).
• Les inclusions côté serveur permettaient de modifier le contenu partagé une seule fois et de le livrer automatiquement au client dans le cadre d'une page finalisée ; à mesure que la vitesse du processeur et de la connexion du serveur augmentait, le travail supplémentaire nécessaire pour effectuer cette opération à la volée devenait un facteur moins important.
• Les langages de script CGI et orientés Web, ainsi que les frameworks de développement Web tels que PHP et Active Server Pages , et les systèmes de gestion de contenu basés sur des bases de données comme WordPress , offraient des options beaucoup plus riches pour la gestion du contenu et la navigation.
• Les scripts côté client et le HTML dynamique permettaient de modifier visuellement certaines parties d'une page en fonction des actions de l'utilisateur. Cela offrait une bien plus grande flexibilité pour l'affichage de contenu secondaire, comme les notes de bas de page ou les instructions, car ces éléments pouvaient désormais être affichés et masqués n'importe où sur la page, sans nécessiter de cadre prédéfini.
• AJAX permettait un affichage dynamique du contenu d'une page, même lorsque celui-ci devait être récupéré depuis le serveur, par exemple en fonction de l'utilisateur connecté ou d'événements survenus ailleurs.