Pourquoi les développeurs détestent les iframes?
Duplicata possible:
Les iframes sont-ils considérés comme une "mauvaise pratique"?
Lorsque je travaille avec des développeurs Web, j'entends toujours d'eux que l'utilisation des iframes est quelque chose que nous devons éviter autant que possible, et certains disent que c'est quelque chose de mauvais, ennuyeux et pose beaucoup de problèmes.
Aussi quand j'ai dit un jour à mon ancien patron "pas un développeur" que j'utiliserais iframe, il m'a regardé comme un mauvais développeur :)
Ce que je veux savoir, les iframes ont-ils une très mauvaise histoire avec le développement web?
Est-ce un désastre?
Dans certains cas, je vois qu'il est indispensable d'utiliser des iframes, cela signifie-t-il que je suis un mauvais développeur?
Ou tout cela à cause de sa difficulté à gérer à cause de certains problèmes de sécurité dont nous devons nous soucier lors du développement?
Veuillez énumérer vos points si vous détestez aussi ou corrigez-moi si je pense mal.
Les iframes peuvent avoir des problèmes similaires à ceux des cadres et une utilisation inconsidérée de XMLHttpRequest: ils brisent le paradigme d'un document par URL, qui est essentiel pour le bon fonctionnement du Web (pensez aux signets, aux liens profonds, aux moteurs de recherche , ...).
Si vous créez une application Web, utilisez la technique que vous souhaitez (y compris les cadres, flash, applets, $ quoi que ce soit). Si vous créez une page Web réelle et informative, respectez le HTML sans cadre, le CSS et les JavaScripts discrets et gardez à l'esprit que la page doit toujours être utilisable avec le script désactivé.
Comme l'a dit Nosredna, c'est probablement parce que les gens les confondent avec les cadres, et il y a en fait beaucoup d'arguments valides contre les cadres. Certains d'entre eux ne s'appliquent pas aux iframes, mais là encore, certains le sont.
Le problème le plus frappant est probablement celui des liens profonds: il est vrai que les iframes en souffrent moins que les cadres, mais si vous autorisez vos utilisateurs à naviguer entre les différentes pages de l'iframe, ce sera un problème. Il y a aussi quelques problèmes d'utilisation que vous devrez surveiller. L'exemple le plus courant est celui des doubles barres de défilement, que je trouve personnellement incroyablement ennuyeuses.
J'ai tendance à éviter les iframes, principalement parce que je trouve que c'est une solution non élégante. J'ai trouvé que lorsque je m'assois et que j'y pense, il y a presque toujours une meilleure solution. Malgré cela, je crois aussi qu'il y a une place pour eux. C'est le goto du monde du Web: juste parce qu'il a une histoire d'utilisation abusive, il est devenu consensus qu'il ne devrait jamais être utilisé. Ce n'est vraiment pas le cas ici, mais je pense que vous devriez réfléchir à deux fois avant d'utiliser des iframes.
Je voulais ajouter que la plupart du temps, les iframes n'aident pas non plus le référencement d'une page. Googlebot ne met pas le contenu d'un iframe sur la page.
Il y a une situation où les iframes sont (presque) requis: lorsque le contenu de l'iframe se trouve dans un domaine différent, et que vous devez effectuer une authentification ou vérifier les cookies qui sont liés à ce domaine. Il empêche en fait les problèmes de sécurité au lieu de les créer.
Par exemple, si vous écrivez un type de plugin qui peut être utilisé sur n'importe quel site Web, mais que le plugin doit s'authentifier sur un autre domaine, vous pouvez créer un iframe transparent qui s'exécute et s'authentifie sur le domaine externe.
Je pense que les gens confondent les iframes avec les cadres HTML, et les cadres sont assez universellement méprisés.
Les gens utilisent des iframes tout le temps sans même s'en rendre compte. Si je me souviens bien, TinyMCE utilise des iFrames.
Une des raisons est la sécurité - les attaques par injection iframe étaient assez courantes. Voir cette page Ars Technica pour une description:
http://arstechnica.com/security/news/2008/03/ongoing-iframe-attack-proving-difficult-to-kill.ars
et une autre page qui résume certaines vulnérabilités (je ne sais pas combien d'entre elles sont valables pour la récolte actuelle de navigateurs, mais l'article n'est pas si vieux):
http://www.thespanner.co.uk/2007/10/24/iframes-security-summary/
D'un autre côté, ils permettent la communication interdomaines et sont assez couramment utilisés par les webapps "ajaxy":
http://softwareas.com/cross-domain-communication-with-iframes
Un problème est qu'ils ont leur propre cycle de vie de page, donc l'interactivité entre l'hôte et l'enfant iframe est limitée (chaîne de requête, variables de session ou JS). Une alternative serait d'envisager d'utiliser une div à défilement.
Un autre problème est l'impression. La sortie d'un iframe (ou d'un div de défilement d'ailleurs) peut être imprévisible et varie énormément entre les différents navigateurs.
Il n'y a rien de mal avec les Iframes pour créer des applications Web. Ils permettent une combinaison de contenu ciblé avec une encapsulation de mémoire. Combien de fois quelqu'un a-t-il construit une petite chose ajax javascript qui a totalement fait sauter des morceaux quand il a oublié et téléchargé la dernière bibliothèque sur sa page parent ou du contenu chargé DIV? La plupart des autres problèmes entourent le référencement, ce qui n'a d'importance que si vous vouliez vraiment voler le contenu de quelqu'un d'autre qui est assez stupide de toute façon. Les iframes vous offrent une mémoire encapsulée et la possibilité de partager des pages bien conçues sur plusieurs sites. Malgré ce que beaucoup voudraient vous faire croire, les Iframes et/ou leurs équivalents seront là pour très longtemps.
Je pense que les IFrames ont leur place. Je ne les utiliserais pas sur des sites Web frontaux/accessibles au public en raison de problèmes de référencement, etc. Pour une application Web interne/principale, je pense qu'ils sont utiles lorsque vous devez isoler le style d'une section particulière du reste de la page, par exemple une visionneuse de rapports ou un éditeur HTML, où les styles hérités de la page parente pouvaient poser problème si tout le contenu était dans un seul document. Mon 2c ...
Une des raisons pour lesquelles ils sont rejetés est qu'ils sont intrinsèquement lents. Au moment où l'iframe commence à charger sa page hôte est déjà à un stade avancé du pipeline de chargement. Les iframes et la navigation rapide sont presque impossibles à combiner.
les iframes d'aujourd'hui ont une mauvaise réputation en raison de la prise en charge d'iframe dans les anciens navigateurs. Similaire à VB.NET ayant un mauvais rap en raison de l'histoire de VB6. Je les utilise ces jours-ci en cas de besoin ... gardez à l'esprit qu'il est possible que cela ne fonctionne pas comme vous l'aviez prévu de temps en temps et que vous en teniez compte.
Les éléments HTML ne doivent pas avoir de comportement.
Je suppose que cela va à l'encontre de l'intégrisme html-descriptions-contenu + css-does-the-visual-design. La surutilisation de l'iframe est également une perte de performances car elle effectue des appels séparés pour récupérer le cadre. Si vous y pensez AJAX est essentiellement comme iframe, sauf qu'il est à la mode aujourd'hui (peut-être pas à l'avenir).
En ce qui concerne la sécurité, c'est un peu problématique car l'utilisateur peut charger la merde totale d'un autre domaine sans même le savoir.
Vous ne devez pas utiliser d'iframes pour la conception. CSS fait un bien meilleur travail pour la même chose et permet également beaucoup plus de liberté.
Parce qu'ils peuvent être difficiles à travailler en matière de sécurité. Un navigateur moderne et bien élevé ne vous permet pas d'écrire du code dans un iFrame qui manipule des éléments dans d'autres iFrames de la page. Cela peut parfois rendre certaines techniques difficiles à réaliser.