Trames insensées
Le problème avec la division du document
Chacun qui se saisit d'HTML bien sûr connait ce problème suffisamment: Comment
faut-il structurer un document et – plus important – comment est-ce qu'on ce
réalise en HTML?
Cette question ne se pose plus dès de CSS 2 comme on peut positionner des
éléments à son gré à partir ce temps-là. Ces pages en recourent intensément,
donc il y a une subdivision bien reconnaissable de chaque page à l'en-tête, le
liston de navigation ainsi que des autres données même si le texte de document
propre. Subdiviser est nécessaire pour la raison de qu'il ne semble pas du
cafouillage et simultanément garantir le maniement facile.
Jusqu'à CSS 2 il y avait le problème qu'on put certes restructurer les
individuels éléments, mais on ne pouvait pas encore y changer la mise en page
du document. Pour y atteindre une subdivision d'un document, des trames furent
introduites. Elles permettent diviser un document à plusieurs parts à une façon
que ce qu'il devra subsister vraiment subsiste et seulement la portion variable
est chargée à la nouvelle.
Le set de trames
On y pourrait subdiviser une fenêtre en plusieurs sous-unités que peuvent servir des différents buts. On pourrait p. ex. créer une barre de navigation pour charger des différentes pages d'un domaine, ou on crée un en-tête que pourrait en revanche contenir un menu central. Mais il y a des autres variantes pensables, p. ex. créer un pied de page que contient des liens p. ex. aux conditions d'utilisation de votre domaine, aux mentions légales, etc.
Pour définit un set de trames il est nécessaire de créer un document supérieur
que spécifie ce qu'il faut charger dans lesquelles. Malheureusement il n'est
pas possible de directement inscrire l'HTML dans une trame, mais il faut
spécifier des fichiers que sont chargés par le document supérieur.
Le type de document du fichier supérieur y devrait être HTML 4.01 Frameset ou
XHTML 1.0 Frameset. On peut spécifier n'importe quel type de document pour les
documents chargés bien qu'il serait mieux à préférer HTML 4.01 Transitional ou
XHTML 1.0 Transitional comme ils possèdent quelques facultés pour avoir accès
au set de trames qui a les chargé.
L'utilisation des trames malheureusement ne va pas sans problèmes et il y a en part des considérables problèmes qu'on ne peut pas résoudre si facile, donc il faudrait éviter leur utilisation.
en hautL'iframe
En fin de compte l'iframe
sert le même but comme une trame normale, mais par contre il est un élément
inline placée dans un document normal et charge de contenu additionnel. Il est
nécessaire de spécifier HTML 4.01 Transitional, HTML 4.01 Frameset, XHTML 1.0
Transitional, XHTML 1.0 Frameset ou (X)HTML5 pour le type de document pour
utiliser l'iframe. Mais il y a aussi
quelques problèmes incommodants qu'on ne peut pas résoudre
si facilement lorsqu'on applique cette technique; c'est pour cette raison qu'il
faudrait en éviter en règle générale même si
l'iframe était inclus dans (X)HTML5.
L'iframe en outre a quelques
singularités qui le font tourner plus problématique que le set de trames
normal.
Problèmes avec l'implémentation
Le problème principal qui se présente avec l'utilisation des trames est le fait qu'il faut fractionner un document qu'on voudrait y structurer. Il faut ensuite les charger dans des trames comme des documents individuels, donc ce n'est pas une subdivision absolument logique mais réelle. Chaque trame présente, en pareil d'une fenêtre, un viewport autonome, on pourrait accéder auquel totalement indépendant des autres trames. Il donc se produisent quelques limitations comme on ne peut pas avoir accès aux autres trames sans l'aide de JavaScript. Si on charge un document dans une des trames qui doit influer sur des autres trames définies, il n'est pas possible à effectuer avec l'HTML pur.
Vous êtes en outre forcés de dessiner vos pages à une façon que permet la fractionner à un set de trames. Il va certes fonctionner excellentement avec beaucoup de schémas de pages, mais lorsque vous avez besoin des mises en page plus dédiées, les trames encore une fois atteignent leurs limites.
en hautÉpiphénomènes incommodants
Lorsque vous utilisez un set de trames ou un iframe
vous allez trouver rapidement que vous êtes confrontés aux quelques problèmes,
lesquels ne se présenteraient pas sans trames. Comme vous partitionnez une
fenêtre de navigateur en plusieurs parts il n'est pas si facile à façonner
quelque chose. Ce n'est aucun problème avec des mises en page simples, mais
si vous voulez intégrer des images arrière-plan, il devient difficile: Il faut
les intégrer séparément pour chaque trame. Mais il y est nécessaire à
partager l'image arrière-plan prévue aux plusieurs parts et les intégrer dans
leurs respectives trames dépendant à leur position. Au premier abord ça ne pose
aucun problème, parce que les dimensions de vos trames sont connues et vous
donc pouvez couper exactement par le pixel avec un programme de traitement
d'image pour que personne ne puisse visuellement percevoir le dépeçage. Mais au
second abord il y a plusieurs embûches: Votre mise en page fignolée perd le
nord si des dimensions des trames sont changées. Le deuxième problème se
produit lorsque vous spécifiez dans le document que personne peut défiler le
contenu de trames, mais vos usagers ont instruit leurs navigateurs de ne pas
bloquer le défilage des trames n'importe lequel qu'est spécifié par votre site
Web – en attendant que le set de trames est fait explosé par la présentation
des barres de défilage.
On pourrait obvier ce problème par dessiner les individuelles trames à une
façon que chaque zone est clairement différenciée contre des autres zones et
cette subdivision donc n'est pas cachée à vos usagers. Mais malgré cela
l'utilisabilité de la page au plus laisse à désirer.
L'effet vitrine
Le problème principal qui se produit en rapport avec des trames est ce qu'on
puisse l'utiliser pour intégrer des documents étrangers à une façon qu'ils
semblent une part du projet Web propre. Un usager normal ne peut pas découvrir
si facilement lorsqu'il eut renvoyé à une page entièrement différente s'il n'a
pas pris le soin d'analyser le code source de la page et donc pourrait arriver
à la conviction que le contenu qui est montré dans votre trame vraiment fait
partie de votre projet Web.
Il y serait nécessaire de ou indiquer aux usagers que le contenu de la trame
est dû à un autre site comme la vôtre, ou veiller à éliminer le set de trames
en appelant un lien extérieur si bien que la page destinée a l'entière fenêtre
de navigateur à disposition. Malheureusement ceci est manqué, souvent dû à
l'ignorance, donc conduire à l'effet vitrine déjà mentionné.
Il devient particulièrement grave si la page destinée aussi définit des trames
comme la trame dans laquelle elle est chargée, elle est subdivisée par un set
de trames aussi. En raison du set de trames la zone dans laquelle on peut
charger des autres pages devient de plus en plus petite, donc on ne peut plus
utiliser les pages y chargées à un moment donné.
Il y a malheureusement quelques moutons noires qui consciemment prennent avantage de cet effet pour se parer des plumes du paon, parce qu'ils font miroiter aux visiteurs ignorants que le document intégré provient d'eux. C'est non seulement très injuste par rapport d'auteur de la page y «absorbée» de cette manière, mais il pourrait aussi comporter des ennuis.
C'est pour ces raisons qu'on peut souvent trouver le code suivant dans des documents HTML:
Le document y prend soin de détruire le set de trames ou l'iframe dans lequel le document est chargé, donc placer le document destiné uniquement dans la fenêtre de navigateur. L'effet vitrine est donc facilement empêché, et même laisser-aller du celui qui fait référence à une autre page ne constitue plus aucun problème.
en hautProblèmes avec le maniement
Mais c'est aussi l'utilisabilité d'une page qu'en se ressentit. Lorsque vous commutez entre les liens p. ex. par la touche de tabulation, il y a des problèmes qui se produisent si p. ex. la navigation était déplacée dans une trame à part, parce qu'on ne puisse pas accéder à laquelle, sauf vous cliquez dans la trame contenant la barre de navigation. Mais dans ce cas vous ne pouvez plus commuter entre les liens dans le document propre sans avoir besoin de cliquer sa trame encore une fois. Il y a en outre des problèmes avec l'accessibilité qui se produisent inévitablement comme, en règle générale, des lecteurs d'écran ou des lignes braille ne sont pas conçues pour traiter des documents subdivisés en plusieurs parts de cette façon.
Un autre problème se produit lorsqu'une page est indexée par un moteur de
recherche, parce qu'ils ne rendent pas nécessairement le set de trames
supérieur, mais la page destinée que correspond à votre recherche. Mais lorsque
vous avez accès à laquelle, vous êtes confrontés par le problème que la
navigation est perdue en cas échéant lorsqu'elle est mise dans une trame
autonome. Charger le set de trames et ensuite placer la page destinée dans
lequel serait possible seulement avec beaucoup d'effort.
Et même si la navigation est visible, il y a des autres problèmes. Comme une
trame peut rudimentairement réagir aux événements dans une autre trame – si
tant est qu'il puisse réagir, il faut considérable effort, surtout ça ne peut
pas être effectué sans JavaScript – la navigation y inclus normalement est
statique, donc le lien sur la page courante reste actif bien qu'il faudrait le
désactiver. Il y faudrait fouiller touts liens pour les réactiver et ensuite
désactiver le lien qui réfère la page pour qu'on ne puisse plus charger le
document courant encore une fois. Il y est recommandé à appliquer des autres
techniques, p. ex. SSI, que permettent éviter ces problèmes plus facilement.
Mais lorsque vous voulez placer un marque-page des problèmes se produisent
encore une fois: Au lieu de la page montrée vous mettrez le set de trames
supérieur comme marque-page par lequel la page avec ses ajustages fondamentals
(soit la page que le set de trames chargera au début) est chargé et vouz
devriez charger le document désiré par vous. Mais ça va produire des ennuis
pour l'usager qui se trouve importuné avec des actions superflues et donc
pourrait se décider rapidement à partir la page.
Le même problème se produit lorsqu'on regarde la barre d'adresse de la fenêtre
de navigateur dans laquelle le set de trames était chargé. C'est l'adresse du
set de trames supérieur qui est indiquée dans laquelle; les documents chargés
ne font pas leur apparition du tout. C'est exactement le comportement
avantageant l'effet vitrine.
Il faudra recourir aux technologies côté serveur comme CSS, des langues script
et SSI par lesquelles vous pouvez intégrer certaines parts dans vos documents
sans les fractionner en plusieur parts pour éviter des problèmes de prime
abord. Les pages sur ce domaine, par exemple, recourent intensivement aux
telles techniques; le menu à gauche en haut est ainsi créé par un script Perl
qu'est appelé moyennant du SSI et inclut le code XHTML nécessaire à l'endroit
où l'appel est consigné. L'avantage de telles techniques tombe sous le sens:
Vous pouvez faire quelques vérifications dans les scripts, p. ex. si le fichier
destiné d'un lien est au fait présent, et sinon, désactiver les liens affectés.
Il ne faut rien modifier au menu ou fouiller énièmes documents si vous intégrez
un fichier dans votre projet Web et y risquer oublier quelque chose. En plus le
document montré conserve son intégrité physique.
On pourrait bien construer cette page que vous regardez en ce moment par
utiliser des trames parce que le mise en place de cette page permet cela, mais
comme déjà décrit, il y a des divers problèmes que se produiraient dans ce
cas-là que n'existent pas dans sa forme courante.
Des singularités problématiques de l'iframe
En utilisant des trames l'iframe se révèle comme
notamment plus problématique parce qu'on peut le faire facilement disparaître
dans un document HTML. Il en faut seulement ajouter l'attribut
style que contient seulement
display: none; comme valeur et
l'iframe n'est plus présenté. Le document contenant
un iframe si caché semble un document normal si bien
qu'un usager qui ne se doute de rien ne présume pas qu'il y a quelque chose qui
se cache dans le document. Il y faudra examiner le code source pou trouver des
éléments si cachés.
Une trame cachée de telle façon pourrait être abusée par exemple pour charger
JavaScript étranger qu'effectue des additionnelles actions
dans le contexte du document contenant
l'iframe. Des cybercriminels en partie
mettent ce comportement à profit pour faire un usager qui ne se doute de rien
charger de code malfaisant à son insu, lequel est exécuté entièrement
subrepticement. Ce problème se révèle comme particulièrement sale si le serveur
livrant est remplacé par une version modifiée qui injecte un
iframe dans le code HTML et ensuite livre le code
HTML modifié à l'appeleur. Il n'est plus nécessaire par cette voie de modifier
les documents HTML d'un site Web, donc nettement réduire des traces traîtresses
côté serveur. Ce problème, mieux connu sous le nom de
Linux/Cdorked.A,
sous forme d'un Apache modifié qui commençait apparaître au fin de 2012 ou au
début de 2013, mais entre-temps il y a des versions modifiées pour des autres
serveurs Web aussi.
C'est exactement ce que fortement montre le potentiel de
l'iframe pour l'abuser. On porrait bien sûr cacher
des trames normales par la même manière, mais il devient largement plus
incommode à refiler du code malfaisant aux usagers comme il faudrait ou
modifier un set de trames existant, que par contre a besoin d'une analyse
lexicale, ou il faut créer un set de trames en un premier temps que définit une
trame cachée. Mais ceci pourrait produire des problèmes lorsque la version HTML
utilisée ne définit pas le set de trames, qu'est le cas de ces pages. L'XHTML
1.1 ainsi ne supporte aucunes trames et on ne pourrait pas justement les créer
par JavaScript comme le nœud nècessaire est manqué dans le MOD. Injecter des
trames normales ou des iframes ne marche pas par
conséquent, parce que le navigateur tout simplement ne va pas montrer le
document et par contre signalera une erreur.
Bilan
Qu'on prenne la chose comme on voudra, des trames n'importe quelle sorte posent
plus de problèmes comme du bénéfice. Certes, à l'époque dans laquelle on a
introduit les trames – mais aussi au présent en cas des hébergeurs d'espace Web
gratuit – elles furent la seule faculté à établir une navigation fixe comme CSS
n'était pas encore si développé comme aujourd'hui, en plus il n'y a aucunes
langues script à votre disposition, développer du JavaScript est tout
simplement trop incommode et des techniques avancées côté serveur ne sont pas
débloquées. Mais avec d'espace Web bien configuré offrant ces facultés il y a
des meilleures méthodes pour subdiviser un document sans avoir besoin de
fractionner et donc perdre la référence logique mutuelle entre les individuels
documents partitifs.
On pourrait ainsi inclure une barre de navigation très facilement par SSI, et
en utilisant un script écrit raisonnablement il est même possible à construire
la navigation dépendant du fichier à une façon qu'on ne peut pas p. ex. charger
le document courant encore une fois et il est accentué spécialement dans la
navigation. On peut en outre dessiner logiquement le document moyennant de CSS
à une manière qu'on réserve une menue part pour l'en-tête et la navigation,
mais le reste est tenu disponible pour le texte propre de document.
Comme le document est seulement visuellement subdivisé à plusieurs parts, mais
autrefois retient son intégrité, l'accessibilité est assurée comme des lecteurs
d'écran et des lignes braille peuvent traiter le document sans problèmes et
extraire des informations. En plus la navigation ne peut pas se perdre lorsque
vous êtes relayés à telle page comme elle est une composante intégrale de
laquelle, et en fin de compte on pourrait créer du JavaScript que peut
travailler avec toutes parts d'un document à une manière facile. Il y ne faut
plus du biais par des nœuds des individuelles trames et le JavaScript ne doit
pas gauchement déterminer ce auquel qu'il ira avoir affaire dans les autres
trames.
Il est seulement l'iframe qu'on pourrait utiliser
assez raisonnablement pour inclure certains éléments des autres domaines dans
les documents propres. Cette voie est engagée par exemple par Facebook et
Google pour offrir des divers boutons à inclure dans les documents propres,
mais c'est aussi Paypal et des autres services, même si des nombreux
fournisseurs des captchas, mettent
des éléments à la disposition dont il faut inclure à cette façon. Mais ça
impérativement faudra un type de document supportant
l'iframe comme il y a des différentes choses qui ne
fonctionnent pas du tout. Il y faudrait des autres, plus saines, solutions,
notamment lorsque les types de document qui le ne définissent pas sont
utilisés, mais beaucoup de développeurs craignent le surcroît d'effort
corrélatif.