Vous êtes ici :  Accueil    Formations online    Webmaster pro
  Niveau 1    Formation HTML    Frames en HTML

La technique des frames en HTML

Il est vrai que le terme anglais frames, traduit en français, ne signifie rien de plus subtil que "cadres". Les programmeurs français n'auraient donc aucune raison concrète de ne pas employer la traduction. Toutefois, pour des motifs obscurs, frames fait partie de ces mots qui ont la réputation d'être "intraduisibles". Cela ne veut pas dire qu'il n'y ait pas parfois des "puristes" qui, tout de même, se servent du terme français - mais cette attitude est rare.
 
Comme tant d'idées, aussi celle des frames a été née à partir d'un cas de "besoin". C'est qu'à l'époque, un problème assez important préoccupait les Webmasters : ils se demandaient, comment éviter la programmation de certaines parties répétitives sur chaque page d'un site. Ils voulaient, par exemple, que des éléments du genre menu, logo, banners ou des séries d'images figurant sur toutes les pages ne doivent être programmés qu'une seule fois. Rappelons-nous que les méthodes "modernes" comme celle de JavaScript ou PHP n'avaient pas encore été développées. On disposait évidemment de la fameuse technique du "copier-coller". Mais lorsqu'un site atteint dix, vingt, soixante pages, même ce travail relativement rapide commence à peser.
 
Ainsi, les frames ont été inventés. Ils permettent au Webmaster de ne programmer qu'une seule fois les éléments répétitifs. Grâce aux "cadres", ils apparaissent sur chaque page, sans changer d'aspect ou de position.

Qu'entendons-nous par frames ?

Or, c'est quoi, un frame ? - Imaginons que notre page serait partagée en plusieurs parties dont chacune est censée héberger un élément prédéfini.

On pourrait, par exemple, caser le logo et le titre du site dans un cadre rangé en haut de la page. A gauche, nous pourrions prévoir un cadre pour le menu qui, tout comme le logo et le titre, reste identique dans toutes les pages. A droite, finalement, nous plaçons un cadre plus grand, destiné à recevoir les textes ou les images qui se modifient avec toute nouvelle page.

Mais pourquoi diviser notre page en plusieurs parties ? Cette idée nous rapproche-t-elle de l'objectif de ne programmer qu'une seule fois les parties communes à toutes les pages ? - Oui, sous condition que ces diverses parties soient capables de réagir l'une indépendamment de l'autre.

Et cela est justement le "truc" de la technique des frames. Chaque partie de notre page peut avoir sa propre "vie". Le contenu du frame d'en haut, par exemple, peut rester "immuable" tandis que le frame en bas affiche des images et des textes qui changent.

Nous pouvons évidemment choisir toute combinaison qui nous semble utile. Ainsi, il est fréquent qu'un Webmaster définit un frame exclusivement destiné au logo du site.

La technique des frames peut-elle
présenter des inconvénients ?

Toutefois, cette idée à première vue très pratique présente un inconvénient : nous savons que, sur la page d'accueil, ce logo ne correspond qu'à une simple image tandis que, dans les autres pages, il contient un lien ramenant l'internaute à la page d'accueil. Nous sommes donc obligés de prévoir deux logos différents (l'un sans lien, l'autre avec lien) dont l'un ou l'autre, selon la page active, doit alternativement être chargé dans le cadre conçu à cet usage. Bien que cette revendication formelle de la science du Webdesign puisse être satisfaite par la technique des frames, elle complique son emploi. Nous verrons plus tard, comment ce problème peut être résolu.

L'exemple du logo nous montre que la technique des frames - quoique très pratique - peut présenter des désavantages.

En quoi le contenu d'un frame consiste-t-il ?

Nous avons dit que la technique des frames consiste à "morceler" notre page et, ensuite, à donner une "propre vie" à chacun de ces morceaux. Mais en quoi ces morceaux consistent-ils ?

La réponse est plus simple qu'on ne croit : dans des pages HTML tout à fait ordinaires. Pour remplir un frame, nous créons un document HTML - avec head et body - tout comme nous l'avons appris au cours des dernières leçons. Dans ce document, nous avons le droit d'utiliser tous les balises, attributs et valeurs généralement destinés aux pages HTML. Une page destinée à apparaître dans un frame ne se distingue en rien du genre de page que nous avons utilisé jusqu'à maintenant.

Un peu donc dire qu'une page de frames est un système dans lequel plusieurs pages HTML sont placées les unes à côté ou en-dessous des autres. Le seul élément qui distingue ces pages destinées aux frames des documents HTML que nous avons connus jusqu'à ce jour, c'est leur taille : tandis que nos "anciens" documents HTML remplissaient toujours l'écran entier, le contenu d'une page établie pour un frame doit être adaptée à la taille du frame auquel elle appartient. Nous devons donc faire attention de ne pas la remplir outre mesure.
 
Dans la suite de ce chapitre, nous apprenons, comment une telle page rentre dans un système de frames.

Combien de frames peuvent être
placés dans une page ?

Assez de théorie. Entrons dans la partie pratique de ce chapitre. Commençons avec la question, combien de frames nous pouvons placer dans une page. La réponse est simple et complexe en même temps. La partie simple : théoriquement, la technique permet l'emploi de tant de frames que nous voulons, d'un nombre en principe illimité.
 
La pratique est moins claire que la théorie. Prenons un programmeur qui est l'heureux propriétaire d'un moniteur à 23 pouces avec une résolution de rêve. Un tel écran lui permet de visualiser le contenu de cinq ou six cadres à la fois, sans qu'il ait l'impression d'une "surcharge". Un internaute, par contre, qui doit, peut-être, se contenter d'un écran à 15 ou 17 pouces serait perdu devant une telle quantité de frames dans sa fenêtre de navigation. Il aurait l'impression que la masse du texte et des images répartis entre tant de cadres l'écrase - il lui serait impossible ou, au moins, pas très facile, de garder la vue d'ensemble sans que l'image se brouille devant ses yeux.

Y a-t-il donc une règle qui fixe le nombre des frames dans une page ? - A priori, non. Nous pouvons toujours partir du principe que deux frames ont l'air un peu "maigre" - l'observateur pourrait se demander si l'emploi de deux frames valait la peine d'avoir recours à cette technique quand même assez complexe, et l'écran risque de présenter un aspect assez vide. Le nombre de trois ou quatre frames procure généralement un aspect agréable, tandis qu'à partir de cinq, le programmeur doit faire en sorte que l'écran ne paraisse pas "surchargé".

Mais ces indications ne peuvent pas être généralisées à cent pour cent, et chaque type de page peut revendiquer son propre modèle de frames.

Le système des frames

Le moment est venu de créer notre premier système de frames. - Jusqu'à maintenant, nous n'avons effectivement parlé que des frames, sans faire allusion à une éventuelle apparition en forme d'un système quelconque. Mais nous nous sommes doutés que les frames ne peuvent pas être placés sauvagement. Chaque frame doit prendre en considération la taille et la situation des autres.

Nous savons que, tant que nous travaillons a priori pour les résolutions de 800 sur 600 pixels, que la ligne horizontale de notre écran est "naturellement" restreinte à 800 pixels. Si, par conséquent, nous donnons à un frame la largeur de 500 pixels, le deuxième ne peux pas revendiquer une largeur de, disons, 400 pixels. Les deux doivent forcément se "mettre d'accord" : soit que le premier "réclame" moins de place, soit que le deuxième se "contente" de 300 pixels : de toute manière, notre écran ne peut accepter qu'une somme complète de 800 pixels horizontaux.

Nous en concluons : plus de frames divisent la page, plus le nombre de pixels à la disposition de chaque cadre est restreint.

Mais notre système de frames ne peut pas non plus être plus petit que la fenêtre de navigation : il doit toujours remplir l'écran entier. Les règles du Webdesign - et la plupart des navigateurs - ne permettent pas que nous limitions la taille d'un système de frames à une partie de l'écran. Ainsi, il est interdit de prévoir par exemple deux frames de 300 sur 600 pixels chacun et réserver les 200 sur 600 pixels restant à un affichage "hors frames".

Note : N'oublie pas que, lorsqu'on donne des indications sur la taille de l'écran ou celle d'un frame, on nomme d'abord la valeur horizontale, ensuite la valeur verticale. L'indication 300 sur 600 pixels, par exemple, correspond à une taille de 300 pixels horizontaux et 600 pixels verticaux.

Maintenant, nous avons une premième idée de la division de l'écran par un système de frames. Commençons alors à créer notre premier système.

La page d'accueil "invisible"

Nous savons tous ce qu'on entend par "page d'accueil" : la première page d'un projet Internet qui fournit à l'internaute les liens vers l'intérieur du site et assez d'informations pour le persuader de continuer son voyage virtuel.
 
Mais une page d'accueil "invisible" ? - Ne discutons pas la question, si - en relation avec la technique des frames - le terme "page d'accueil" est bien choisi. On pourrait effectivement dire qu'il contredit à l'idée de base d'une "véritable" page d'accueil qui, nous venons de le mentionner, contient par office certains éléments qui servent à l'information de l'internaute - des éléments qui, logiquement, sont tout à fait "visibles". La conception d'une page d'accueil "invisible" ne peut donc pas satisfaire ces exigences de base. Toutefois, elle a en commun avec la "véritable" page d'accueil d'être la toute première page du site.
 
Acceptons donc le terme de "page d'accueil invisible" et contentons-nous d'étudier la technique. Mais, si notre "nouvelle" page d'accueil - la page d'accueil invisible - prend la position de la "véritable" page d'accueil, quelle est la place que nous attribuons à celle-ci ?

Rappelons-nous que la technique des frames à pour objectif de diviser l'écran en plusieurs parties dont chacune réagit indépendamment de l'autre. Ainsi, nous ne disposons plus de "véritables" pages, dans le sens qu'une page remplit l'écran entier, mais uniquement de "morceaux" de pages qui, correctement combinés, forment des pages complètes. Mais ces "nouvelles" pages issues des combinaisons de frames ne sont plus tout à fait "individuelles" : grâce à la technique des frames, la deuxième page peut garder certaines parties de la première qu'on retrouve également sur la troisième ou quatrième.

Revenons à la "véritable" page d'accueil, celle qui est visible pour tout le monde. Comme les autres pages, elle ne consiste plus en un seul "morceau" de page, mais en plusieurs "morceaux" qui, ensemble, forment l'unité de la page d'accueil. Lorsque nous travaillons avec les frames, nous retenons que toute "véritable" page d'accueil consiste en la première combinaison de frames qui apparaît au moment où l'internaute se branche sur notre site.

Nous pouvons donc dire qu'avec l'emploi de la technique des frames, la page d'accueil "invisible" est techniquement la première page du site, mais elle n'est pas accessible à l'internaute. La "véritable" page d'accueil, par contre, n'est techniquement plus placée au début, mais elle est la première page visible pour l'internaute.

Nous l'avons compris : l'objectif principal d'une page d'accueil "invisible" est la création d'un système de frames. C'est ici que nous décidons du nombre de frames et de leur taille. Le système créé ici gère en général l'affichage du site entier ou, au moins, d'une partie importante du site.

Quels sont les éléments qui doivent être placés
dans une page d'accueil invisible ?

Rappelons-nous qu'un système de frames consiste toujours dans plusieurs "morceaux" qui, ensemble, forment des pages. Mais nous n'avons pas le droit d'assembler ces morceaux sauvagement : nous avons toujours besoin d'une sorte de "cadre" dans lequel nous pouvons "monter" nos morceaux. Ce cadre les entoure est fait en sorte qu'ils tiennent ensemble. Or, ce "cadre" n'est rien d'autre que notre page d'accueil invisible.

1. Le head d'une page d'accueil invisible

Au début de notre formation, nous avons appris, comment créer le head d'un document HTML. Nous savons qu'il est situé entre les balises <HEAD> et </HEAD>, que sa lecture est presque exclusivement réservée aux navigateurs et moteurs de recherche et que presque tous ses éléments sont invisibles pour l'internaute. Rien de nouveau, alors. Jusqu'ici, il n'y a pas la moindre différence entre le head d'un document HTML "quelconque" et celui d'une page d'accueil invisible.
 
La différence principale consiste dans l'importance du texte entre les balises <TITLE> et </TITLE>. Et c'est le moment de relancer notre "cri d'alarme" :

   Attention au référencement !   

En principe, ce n'est plus la peine de mentionner l'extrême importance du texte entre les balises <TITLE> et </TITLE>. Cela fait plusieurs leçons que nous avons pris l'habitude de le traiter très soigneusement, conscients que le choix des termes que nous y utilisons peut être décisif pour l'emplacement de nos pages dans les moteurs de recherche. Nous avons également appris que ce texte s'affiche en haut des navigateurs et qu'il entre automatiquement dans les favoris des internautes quand ils décident d'y garder notre page.

Pourquoi, par conséquent, l'importance de ce texte entre <TITLE> et </TITLE> est-elle plus grande lorsqu'il figure dans une page d'accueil invisible ?
 
Rappelons-nous que cette page représente une sorte de "cadre" qui "entoure" les divers morceaux - c'est-à-dire les frames - pour que, ensemble, ils puissent former les diverses pages du site. Ce "cadre" reste alors intact pendant que certains morceaux sont échangés contre d'autres. Il est logique que ces morceaux ne peuvent pas afficher le contenu d'un <TITLE> en haut du navigateur - comme il y a toujours plusieurs morceaux dans une page, le navigateur ne saurait pas, lequel choisir.
 
Par conséquent, il se contente d'un seul <TITLE> : de celui de la page d'accueil invisible. Ce <TITLE> est donc affiché en haut du navigateur et entre dans les favoris des internautes.

Les moteurs de recherche, par contre, ne se contentent pas du <TITLE> de la page d'accueil invisible : eux, au contraire des navigateurs, fouillent aussi les <TITLE> des "morceaux". Toutefois, ils accordent une importance différente aux <TITLE> des pages d'accueil invisibles et à ceux des "morceaux" - pour eux, le <TITLE> d'une page d'accueil invisible est essentiel. Et tandis que les <TITLE> des "morceaux" peuvent attribuer à un bon emplacement du site dans un moteur, celui de la page d'accueil y est décisif.

Qu'apprenons-nous de ce comportement des moteurs ? - Que nous sommes obligés de traiter soigneusement tous les <TITLE> de toutes les pages d'un site, même si l'emploi des frames les rend imperceptibles aux internautes. Le <TITLE> de la page d'accueil invisible, par contre, mérite des soins encore plus intenses.

La ligne <!DOCTYPE...>

Toutefois, il y a encore une autre différence entre le head d'un document HTML "ordinaire" et celui d'une page d'accueil invisible : la ligne <!DOCTYPE...>. Nous avons appris que son code contient des informations très importantes pour les navigateurs. Par conséquent, nous sommes obligés de la traiter avec le plus grand soin : nous n'avons pas le droit d'y insérer la moindre faute de frappe - chaque espace mal placé, chaque confusion de minuscule ou majuscule peut "troubler" les navigateurs et les inciter à mal comprendre les informations de base que nous sommes obligés de leur communiquer.
 
Dans un chapitre à part, nous parlerons en détail de ces informations et des raisons, pour lesquelles nous sommes obligés de les traiter avec tant de soins. Pour le moment, toutefois, notre premier souci est le travail pratique : la création d'abord. Nous nous contentons alors de l'essentiel - savoir transmettre aux navigateurs la bonne information.
 
Jusqu'à maintenant, nous avons travaillé dans un mode appelé "Transitional". Ce mode nous a permis de profiter pleinement des facultés de la version 4.01 du HTML sans pour autant renoncer aux possibilités des anciennes versions. Nous n'avons aucune raison de renoncer à ce mode - sauf dans le cas de notre page d'accueil invisible.
 
Nous avons déjà dit que cette page a pour seul et unique but la création d'un système de frames : on peut donc dire qu'elle comprend un "jeu" de frames ou - pour "américaniser" le terme de jeu de frames - un set de frames. Suivant cet ordre d'idée, le W3C a baptisé Frameset le mode permettant une telle création.

Pour éviter le risque de fautes de frappe, nous procédons comme auparavant : nous inscrivons cette ligne très soigneusement dans notre première page d'accueil invisible. Il va de soi que nous nous prenons tout le temps nécessaire et tapons caractère par caractère, sans oublier ni les espaces, ni la différence entre les minuscules et les majuscules. Après nous avoir assurés que la ligne ne contient aucune erreur, nous utilisons la technique du copier-coller pour la transférer dans toutes nos futures pages d'accueil invisibles.

2. La section du système de frames

Nous avons déjà dit que c'est dans cette section de la page que notre véritable système de frames est créé. Ici, nous définissons le nombre, l'emplacement et la taille de tous les frames de notre site ou, au moins, d'une partie importante de notre site.
 
La première section de notre page d'accueil invisible s'est terminée avec la balise </HEAD> - dans ce point, elle ne se distingue pas des autres documents HTML. Nous avons appris que la balise finale du head est forcément suivie par la balise initiale du body, c'est-à-dire de <BODY>.

C'est ici que s'annonce la première véritable différence entre un document HTML "ordinaire" et une page d'accueil invisible : la page d'accueil ne possède pas de body et, par conséquent, pas de balise <BODY> ni </BODY>.

Pourquoi cette page ne dispose-t-elle pas de body ? - Rappelons-nous la mission primitive de cette partie d'un document HTML. Nous avons appris que tous les éléments placés entre <BODY> et </BODY> sont destinés à l'affichage sur l'écran de l'internaute.
 
Or, dans le cas d'une page d'accueil invisible, il n'y a aucun élément - le <TITLE> du head à part - censé être affiché. Par conséquent, l'idée d'origine du body perd son sens : nous n'avons donc pas besoin de lui.

Nous savons déjà que, dans le HTML, il n'y a pas de partie de page qui n'est pas entourée par un couple de balises. Faute de <BODY>, nous avons donc besoin d'un autre marqueur susceptible de gérer nos définitions de frames. Nous avons dit que ces définitions consistent en un ou plusieurs sets de frames gérés par les navigateurs en mode Frameset. Logiquement, les balises destinées à la gestion de cette section de page s'appellent <FRAMESET> et </FRAMESET>.

Les balises <FRAMESET> et </FRAMESET>

Nous avons donc dit que la balise <FRAMESET> suit immédiatement le marqueur </HEAD>. Aucun autre élément n'a le droit de figurer entre ces deux balises. Le schéma de notre page correspond donc à

Essentiellement, le champ entre <FRAMESET> et </FRAMESET> ne consiste que dans trois éléments : deux attributs baptisés cols et rows et un autre marqueur du nom <FRAME>.
 
Les attributs cols et rows fixent la taille et l'emplacement des frames tandis que les attributs et valeurs appartenant à <FRAME> définissent leur "comportement" et leur apparence.

L'attribut cols

Pour définir la taille et l'emplacement d'un frame, nous avons besoin de fixer les mesures des deux directions de la fenêtre de la navigation : la page doit être découpée verticalement, c'est-à-dire de gauche à droite, et horizontalement, alors d'en haut en bas.

La tâche de découper la page dans le sens horizontal a été confiée à l'attribut cols (de col, c'est-à-dire "colonne", en anglais). Ses valeurs ont donc pour objectif de découper la page dans le sens horizontal et, par conséquent, de "dessiner" les limites verticales des frames.

La valeur de l'attribut cols consiste toujours en plusieurs chiffres. Chaque chiffre indique la largeur horizontale d'un "morceau" de page. Si nous coupons la page en deux parties, nous avons donc besoin de deux chiffres. Si nous préférons la découper en trois parties, nous nous servons de trois chiffres, etc.
 
Nous commençons toujours par la partie la plus à gauche (du point de vue du programmeur assis devant son écran) de la fenêtre du navigateur pour, ensuite, avancer vers le côté droit.
 
Reprenons notre exemple d'un écran de 800 sur 600 pixels. Nous n'avons pas oublié qu'un système de frames remplit toujours l'écran entier. Nous avons donc la tâche de découper les 800 pixels horizontaux de l'écran dans plusieurs parties.

Nous sommes libres de choisir toutes sortes de combinaisons de chiffres, tant qu'elles cadrent avec la mise en page que nous envisageons et, bien entendu, que la somme des chiffres égale 800.

Tu as certainement remarqué que cette méthode présente un "hic" : il semble bien beau de couvrir un écran de 800 sur 600 pixels avec notre système de frames. Mais nous ne pouvons pas empêcher les internautes d'ouvrir notre page sur un écran de 1024 sur 768 pixels. Que notre système de 800 sur 600 pixels devient-il sur un tel écran ?

Jusqu'à maintenant, toutes les valeurs numériques que nous avons utilisées étaient des valeurs absolues, c'est-à-dire des valeurs indiquées en forme d'un chiffre "concret". Si, par exemple, nous avons parlé de 800 pixels, il s'agissait d'une valeur fixe qui s'affichait d'une manière identique sur tous les écrans, peu importe s'ils étaient plus grand ou plus petits ou si nous visions une résolution de 800 sur 600 ou de 1024 sur 768 pixels. La seule différence : sous une résolution de 800 sur 600 pixels, une ligne de 800 pixels couvrait la largeur entière de l'écran, tandis que la largeur d'un écran de 1024 sur 768 pixels n'était couverte que partiellement.

Autrement dit, 800 pixels étaient 800 pixels et 1024 pixels étaient 1024 pixels - tout était clair et net.
 
Toutefois, cette situation n'était pas très commode pour les Webmasters qui étaient donc obligés de choisir une résolution d'écran pour y adapter leur système de frames. Et prendre un tel choix n'est pas toujours facile.
 
Heureusement, les Webmasters n'étaient pas les seuls à se préoccuper de ce problème. Les créateurs des navigateurs se sont également interrogés, comment le résoudre. Ils se sont dit qu'il serait utile de disposer d'une valeur du style "écran entier" qui s'adapte automatiquement à tout genre de fenêtre de navigation, peu importe sa résolution.

Effectivement, le HTML dispose d'une telle valeur - et son emploi est très simple.
 
Reprenons notre exemple de l'écran d'une résolution horizontale de 800 pixels. Si ces 800 pixels sont entièrement couverts par notre page, nous disons - en langue courante - que l'écran est occupé à 100 pour cent.
 
Si, en contrepartie, nous avons affaire à un écran de résolution horizontale de 1024 pixels et à une page qui le couvre entièrement, nous parlons également de 100 pour cent.

La mesure en pourcentage nous fournit donc une possibilité "d'uniformiser" notre indication. Si nous employons un chiffre relatif du style 35%, 40% ou 100%, la valeur de ce chiffre se modifie d'une manière relative à l'objet ciblé - dans notre cas, à l'écran de l'internaute.

Par conséquent, nous n'avons qu'à remplacer les chiffres absolus par des chiffres relatifs - c'est-à-dire par des expressions en pour cent - pour avoir des valeurs qui adaptent nos frames automatiquement à la résolution de l'écran.

Tant que nous avons utilisé les valeurs absolues, nous avons combiné les valeurs de la manière que leur somme égalait toujours 800 - les 800 pixels de la largeur de la fenêtre de navigation. De cette façon, nous pouvions être sûrs qu'un écran de résolution 800 sur 600 pixels serait correctement couvert.

Ainsi, les temps où 800 pixels étaient 800 pixels est révolu. Aujourd'hui, 800 pixels peuvent se transformer en 100 pour cent, couvrir, de cette manière, une longueur de 1024 pixels et devenir relatifs.

Si tu as envie de t'amuser avec des calculs, tu peux essayer de trouver l'équivalent à <FRAMESET cols="240,320,240"> ou, plus compliqué, de <FRAMESET cols="125,420,255">. Mais si tu ne te sens pas trop fort en maths, ne te fais pas de soucis : le navigateur fera le travail pour toi.

Un mathématicien dirait que cela serait tout à fait correct. Malheureusement, la "norme" n'est pas du même avis - et bien que quelques-uns des navigateurs courants acceptent ce style d'expression, il n'est pas reconnu par tous. Par conséquent, il est strictement interdit de l'employer.

Mais les créateurs des navigateurs ont trouvé un "remplaçant" : la capacité des astérisques de fonctionner comme multiplicateurs. Nous avons le droit d'employer ces petites étoiles sympas comme fonction mathématique correspondant à une multiplication.

Nous n'avons pas oublié que, dans la technique des frames, nous partons toujours d'une "unité" qui représente l'écran entier et est exprimé par "100%". Notre valeur de base reste donc invariablement 100 pour cent.

Peu importe le nombre d'astérisques que nous utilisons, un astérisque correspond toujours à une partie dont les mesures sont identiques à celles des autres.

Allons plus loin. Imaginons que nous avons toujours envie de diviser la largeur d'écran en quatre parties identiques, mais nous souhaitons que le frame du milieu occupe deux de ces parties. Notre tâche consiste donc à créer un système de trois frames : la largeur du premier et celle du dernier sont identiques, tandis que celle du deuxième est double.

De nouveau, les astérisques rendent facile la réalisation de notre tâche : si un astérisque (*) exprime la largeur d'un quart de la page, deux astérisques (2*) expriment logiquement la largeur de deux quarts de la page.

Attention : Nous écrivons 2* pour deux parties de la page et 3* pour trois parties de la page. Mais s'il ne s'agit que d'une partie de la page, nous n'utilisons pas de chiffre mais nous contentons d'un astérisque : une partie de la page correspond donc tout simplement à *.

On dirait que tout le monde devrait être content. Les Webmasters n'ont plus besoin de choisir entre les différentes résolutions d'écran, leurs frames s'adaptent automatiquement à toutes les tailles. Or - tu l'as certainement déjà remarqué : il y reste toujours un problème.

Tout va bien - jusqu'au moment où nous regardons notre page (créée comme toujours sous une résolution de 800 sur 600 pixels) sous une autre résolution. Sous 1024 sur 768, nous nous rendons compte que la relativité a bien été conservée : notre frame à gauche couvre toujours un quart de la page. Mais au contraire de la taille des frames qui s'est adaptée à la nouvelle résolution, le texte de notre menu est resté pareil. Autrement dit, le texte qui, sous 600 sur 800, remplissait parfaitement le frame à gauche se "perd" maintenant dans l'espace devenu plus grand.
 
Cela est le moment où nous ne sommes plus du tout persuadés de l'utilité de la technique relative. Nous trouvons bien joli que le frame à droite présente ses textes et images à l'intérieur d'un espace plus large, mais la mise en page de notre menu à gauche est devenue "ridicule".
 
Nous aurions donc besoin d'une technique qui réunit les atouts de la technique relative et ceux des chiffres absolus.
 
Heureusement, cette technique existe. Et de nouveau, elle base sur les astérisques qui, nous le voyons, peuvent être bien utiles. Jusqu'à maintenant, nous n'avons fait connaissance qu'avec leurs capacités en tant que multiplicateurs. Mais nous avons également la possibilité de les utiliser comme synonyme du "reste".

Ainsi, si nous combinons des chiffres absolus avec un astérisque, seul l'astérisque est interprété comme valeur relative : juste le frame dont la taille est représentée par l'astérisque s'adapte automatiquement à la résolution de l'écran.

La réponse est bien simple : du point de vue du résultat, il n'y a aucune différence. Du point de vue du Webmaster stressé, par contre, on peut dire que la première formule est plus rapidement tapée que la deuxième et que (cela regarde les "paresseux" en maths) le navigateur prend sur soi la tâche de calculer la valeur du dernier chiffre.

L'attribut rows

Dans la section précédente, nous avons présenté des méthodes pour "relativiser" la taille de nos frames. Plus tard, nous verrons que nous disposons encore d'autres techniques pour créer une page de mesures relatives. Or, nous nous rendrons compte que l'emploi des indications en pour cent restera toujours une des méthodes les plus efficaces.
 
Pour le moment, nous n'attachons cette méthode qu'à la taille de nos frames. Mais dans les prochains chapitres, nous ferons connaissance de plein d'autres occasions de l'utiliser et, par conséquent, d'attribuer des mesures relatives à de divers éléments de nos pages.

Toutefois, jusqu'à maintenant, il n'était question que de la taille horizontale des frames. Il est alors temps de s'occuper également de leur taille verticale.

Lorsque nous divisons la longueur d'une page, notre somme de référence n'est évidemment plus 800 pixels, mais 600 pixels. Si, par contre, nous préférons nous servir des mesures en pour cent, notre somme de référence reste toujours 100 pour cent.

La construction du système de frames

Jusqu'à maintenant, nous nous sommes occupés de la division horizontale et de la division verticale d'une page. Or, nous les avons traitées séparément. Pour construire notre système de frames, nous avons évidemment besoin de combiner les valeurs des attributs cols et rows, c'est-à-dire de gérer les dimensions verticales et horizontales en même temps.

Mais pour construire un système de frames, nous n'avons pas seulement besoin d'indiquer les dimensions. Nous avons également besoin de leur donner un nom.

L'attribut name : la "clé" de
la programmation avancée

Avec l'attribut name, nous entamons un des sujets les plus importants que nous avons jamais traités. Peu importe si nous créons un formulaire - c'est-à-dire si nous entrons dans le domaine du e-commerce - si nous nous servons du PHP, du Perl, du JavaScript, du DHTML ou de beaucoup d'autres techniques plus complexes que le HTML, l'attribut name reste toujours au centre de notre travail. Sans lui, rien ne marche.

Pourquoi un élément ou, dans notre cas, un frame, a-t-il besoin d'un nom ? - Tout simplement pour la même raison pour laquelle on attribue un nom a chaque humain ou à un animal de compagnie : pour pouvoir l'appeler.

Retournons à notre exemple d'encyclopédie. Imaginons un système de trois frames : celui d'en haut de la page contient les lettres de l'alphabet, celui à gauche les mots clés, celui à droite l'explication correspondant au mot clé choisi par l'internaute.

Cela est faisable, mais devient assez compliqué et, finalement, risque de manquer de clarté. Tout serait plus facile si nous avions accordé des noms aux frames. Disons, par exemple, que notre frame en haut s'appellerait "lettres", celui de gauche "mots" et celui de droite "explication". Cela nous donnerait la possibilité d'envoyer au navigateur l'ordre : "Affiche les mots-clés avec "F" dans le frame nommé "mots"." Un tel ordre ne laisserait place à aucun malentendu - le navigateur saurait exactement, de quel frame il serait question.

Les créateurs du HTML ont confié la tâche d'attacher un nom à un objet - dans notre cas à un frame - à l'attribut name ("nom" en anglais). Sa valeur consiste tout simplement dans le nom que nous avons choisi. Le code name="mots" accorde le nom "mots" au frame auquel l'attribut name est attaché.

Nous avons compris que le choix des noms que nous donnons à nos frames est relativement libre. Nous pouvons les choisir par rapport à la tâche confiée au frame : à celui qui est censé afficher les lettres, nous avons fourni le nom "lettres" et à celui censé afficher les mots-clés, nous avons donné le nom "mots". Mais nous aurions aussi bien pu choisir des appellations moins imaginatives comme, par exemple, "frame1", "frame2" ou "haut", "gauche" et "droite".

Maintenant, où nous maîtrisons parfaitement "l'art" de choisir un nom pour nos frames, le temps est venu de faire en sorte qu'il soit attaché au "bon" frame. Pour remplir cette tâche, nous nous servons d'une nouvelle balise.

La balise <FRAME>

Rappelons-nous que nous avons attaché les attributs cols et rows à la balise <FRAMESET>. Nous avons appris que ces deux attributs servent à fixer les tailles horizontales et verticales de nos frames. Nous savons aussi que la balise <FRAMESET> dispose d'un partenaire final </FRAMESET>. L'espace entre ces deux marqueurs est utilisé pour créer notre système de frames.
 
Par conséquent, la balise <FRAME> doit toujours être placée entre <FRAMESET> et </FRAMESET>. Elle est d'ailleurs la seule balise qui a le "droit" de se glisser entre les deux partenaires.
 
La balise <FRAME> ne possède que deux attributs vraiment "vitaux". Un peu plus tard, nous ferons connaissance avec le deuxième. Pour le moment, nous ne nous occupons que de name.

Attention : la balise <FRAME> ne dispose pas de partenaire final.

Finalement, nous connaissons tous les éléments nécessaires pour créer un système de frames :
	la balise <FRAMESET> qui, à l'aide de ses attributs cols et rows définit la taille des frames
	la balise <FRAME> qui se sert de son attribut name pour attribuer des noms à nos divers frames

Il ne nous reste donc qu'à combiner ces éléments.
 
Avant toute autre chose, nous sommes obligés de décider, si nous commençons avec la taille horizontale ou avec la taille verticale de nos frames. Notre exemple nous oblige de commencer avec la taille verticale, c'est-à-dire de découper notre page dans le sens horizontal. Notre but est la création d'un système de frames du style :

Pour quelle raison sommes-nous, dans le cas de notre exemple, obligés de commencer à découper la taille verticale ? - Si nous regardons notre modèle, nous nous rendons compte qu'il ne possède qu'une seule ligne qui couvre une direction complète de l'écran : il n'y a aucune ligne qui couvre la longueur complète de l'écran, et juste une seule ligne qui couvre la largeur complète de l'écran.

Or, pour entamer la construction d'un système de frames, nous avons toujours besoin d'au moins une ligne qui couvre une direction complète de l'écran : peu importe s'il s'agit de sa longueur ou de sa largeur.

Par conséquent, nous commençons à découper notre page dans le sens vertical.

Nous devons donc communiquer au navigateur que le premier frame est prêt. Pour lui faire comprendre notre décision, nous fixons le nom de ce frame : lorsque le navigateur découvre un nom de frame, il sait que la taille de ce frame a été fixée définitivement.

Le principe est donc bien clair. Pourquoi ne t'attaquerais-tu donc pas immédiatement à un système beaucoup plus complexe ?

Ta tâche consiste dans la programmation d'un système de frames correspondant au modèle :

Comme toujours, nous commençons la rédaction de notre page par le head, c'est-à-dire avec la ligne <!DOCTYPE...>. Par la suite, nous insérons les balises <HTML> et <HEAD>, et nous rédigeons notre texte entre <TITLE> et </TITLE>.

Les lignes suivantes sont automatiquement insérées par notre logiciel Arachnophilia - tu n'as pas oublié que ce logiciel est le seul avec lequel nous travaillons dans ce stade de la formation. Il nous permet de taper nos codes comme dans un logiciel de traitement de texte, avec la différence que son jeu de couleurs nous avertit dès qu'une faute de frappe se glisse dans notre code.
 
Un "véritable" pro ajouterait encore d'autres lignes à son head, destinées, surtout, aux moteurs de recherche. Mais pour le moment, nous y renonçons : ces éléments sont trop importants pour être traités en "passant". Nous en parlerons en détail, dans le cadre d'un chapitre à part.

Maintenant, nous scrutons notre modèle pour décider, si nous commençons avec l'attribut rows ou avec l'attribut cols. Nous savons que, pour entamer un système de frames, nous avons besoin d'une ligne qui couvre l'écran dans toute sa longueur ou, alternativement, dans toute sa largeur. C'est toujours avec cette ligne - ou avec une de ces lignes s'il y en a plusieurs - que nous entamons notre travail. Si nous disposons de plusieurs de ces lignes, nous avons le choix de commencer avec celle qui nous convient le mieux.
 
Un coup d'oeil sur le modèle nous a appris qu'il ne contient pas de ligne qui couvre la longueur totale de l'écran, mais une ligne qui couvre la largeur totale. Elle partage l'écran verticalement, c'est-à-dire qu'elle le divise de la manière qu'au-dessus d'elle, nous recevons un champ de 20 pour cent de haut et, en dessous, un deuxième champ qui couvre le reste de la longueur de l'écran.

Maintenant, nous nous posons la question si, avec la création de cette ligne, nous avons terminé un frame. Un coup d'oeil sur notre modèle nous donne la réponse : aucun frame n'a été terminé. Avant qu'un premier frame soit prêt, il reste d'autres lignes à tirer, non seulement au-dessus de notre première ligne, mais aussi en dessous.
 
Ainsi, nous fixons notre attention sur la partie en haut de la page - nous n'avons pas oublié que nous procédons toujours dans le sens d'un haut vers le bas ou, alternativement, de gauche à droite. Notre modèle nous dit que cette partie de la page doit être divisée encore une fois, cette fois-ci dans le sens vertical : la partie à gauche doit couvrir 15 pour cent de la largeur de la page, tandis que le reste est censé appartenir à la partie à droite.

De nouveau, nous nous demandons, s'il y a un frame - ou même plusieurs - que nous pouvons considérer comme terminé. Un nouveau regard sur le modèle nous fait découvrir qu'effectivement, les deux frames en haut de la page sont terminés :

Pour les "fixer" définitivement, nous devons confirmer au navigateur que la construction des deux frames est terminée.

Nous avons appris que chaque frame reçoit son propre nom. Nous avons le droit de choisir librement un terme destiné à servir comme nom - évidemment, dans le cadre des règles que nous avons apprises plus haut dans cette leçon. Pour attribuer le nom, nous nous servons de l'attribut name attaché à la balise <FRAME>. Mais nous n'avons pas le droit d'attacher plusieurs attributs name à une seule balise <FRAME> - chaque frame a droit à sa propre balise <FRAME> avec son propre attribut name.
 
Dans notre cas, nous avons terminé la construction de deux frames à la fois. Par conséquent, nous devons choisir deux noms à la fois. Nous proposons les noms "logo" pour le frame en haut à gauche et "titre" pour le frame en haut à droite.

Nous savons que la balise <FRAME> ne possède pas de partenaire final : nous n'avons donc pas besoin de la fermer. Le champ ouvert par <FRAMESET>, par contre, doit être fermé par </FRAMESET> au moment où son contenu complet est réuni.
 
Actuellement, deux champs <FRAMESET> ont été ouverts, mais jusqu'à maintenant, aucun des deux n'a été fermé. Toutefois, le moment de les fermer est-il déjà venu ? - Demandons nous si le contenu des deux champs est déjà complet.

Nous savons que la première de ces deux parties, celle d'en haut qui mesure 20 pour cent de la longueur totale de la page, a été divisée de nouveau : entre-temps, elle contient deux autres frames. Cette partie est donc terminée.
 
La deuxième partie, par contre, celle d'en bas, dont la longueur correspond au reste de la longueur de l'écran, n'est pas terminée : un coup d'oeil sur le modèle nous révèle qu'elle doit être partagée entre trois autres frames.
 
Par conséquent, nous ne pouvons pas encore fermer cette première balise <FRAMESET> : tant qu'elle contient une partie non terminée, elle doit rester ouverte.

Ainsi, nous avons dit que le premier frame de la première ligne de notre code - celui de 20 pour cent de largeur - est terminé. Nous devons donc nous occuper du deuxième, c'est-à-dire de celui qui couvre la partie inférieure de notre écran.
 
Notre modèle nous révèle que cette partie doit être partagée en trois frames.

Dans ce stade de notre travail, nous n'avons évidemment plus besoin d'une ligne qui couvre la longueur ou la largeur de l'écran entier, mais juste d'une ligne qui couvre la longueur ou la largeur de la partie que nous sommes censés diviser.

Si nous comptons nos champs <FRAMESET>, nous nous rendons compte que nous en avons utilisé quatre : deux de ces quatre ont déjà été refermés. Il nous en reste alors deux qui sont toujours ouverts.

Pour comprendre les "finesses" de ce code, tu ouvres ton logiciel Arachnophilia et tu l'y introduis, élément par élément. Après chaque étape, tu contrôles le résultat dans tes navigateurs.
 
Nous aurions évidemment eu la possibilité de modifier certaines parties de notre code.

L'attribut src

Il est vrai que nous savons maintenant créer tout genre de système de frames. Mais à quoi un système peut-il servir si ses différentes parties restent vides ? - Nous allons donc les remplir.
 
Nous avons déjà dit que le seul élément apte à remplir un frame consiste dans une page HTML "ordinaire". Nous n'avons pas le droit d'y introduire un texte ou une image qui ne fait pas partie d'un document HTML.

Lorsque nous créons les pages censées apparaître dans un frame, nous sommes évidemment obligés de faire attention à leur contenu : une page destinée à un frame "menu" ne doit comporter rien que le menu, et une page destin&ea