Iframes est-il considéré comme une "mauvaise pratique"? [fermé]
quelque part le long de la ligne j'ai ramassé la notion que l'utilisation d'iframes est 'mauvaise pratique'.
Est-ce vrai? Quels sont les avantages/inconvénients de leur utilisation?
11 réponses
Comme avec toutes les technologies, il a ses hauts et ses bas. Si vous êtes en utilisant un iframe à me déplacer correctement développé le site, c'est une mauvaise pratique. Toutefois, une iframe est parfois acceptable.
L'un des principaux problèmes avec une iframe a à voir avec les signets et la navigation. Si vous utilisez il suffit d'insérer une page à l'intérieur de votre contenu, je pense que c'est très bien. C'est à ça que sert une iframe.
cependant j'ai vu iframes abusé ainsi. Il ne doit jamais être utilisé comme une partie intégrante de votre site, mais comme un morceau de contenu dans un site.
Habituellement, si vous pouvez faire sans une iframe, c'est une meilleure option. Je suis sûr que d'autres ici peuvent avoir plus d'informations ou des exemples plus spécifiques, tout se résume au problème que vous essayez de résoudre.
cela dit, si vous êtes limité à HTML et n'avez pas accès à un backend comme PHP ou ASP.NET etc, parfois un iframe est votre seul option.
ils ne sont pas une mauvaise pratique, ils sont juste un autre outil et ils ajoutent flexibilité.
à utiliser comme élément de page standard... ils sont bons, parce qu'ils sont un moyen simple et fiable de séparer le contenu sur plusieurs pages. En particulier pour le contenu généré par l'utilisateur, il peut être utile de "sandbox" pages internes dans un iframe si faible markup n'affecte pas la page principale. L'inconvénient est que si vous introduisez plusieurs couches de défilement (l'un pour le navigateur, un pour le iframe ) vos utilisateurs deviennent frustrés. Comme l'a dit adzm, vous ne voulez pas utiliser un iframe pour la navigation primaire, mais pensez-y comme un texte/balisage équivalent à la façon dont une vidéo ou un autre fichier multimédia serait intégré.
pour le script des événements de fond, le choix est généralement entre un iframe caché et XmlHttpRequest pour charger le contenu de la page courante. La différence est qu'un iframe génère un chargement de page, de sorte que vous pouvez déplacez en arrière et en avant dans la cache du navigateur avec la plupart des navigateurs. Notez que Google, qui utilise XmlHttpRequest partout, utilise également iframe s dans certains cas pour permettre à un utilisateur de passer en arrière et en avant dans l'histoire du navigateur.
c'est une "mauvaise pratique" de les utiliser sans comprendre leurs inconvénients. Adzm post résume très bien.
sur le flipside, gmail fait un usage intensif d'iFrames en arrière-plan pour certaines de ses fonctionnalités plus fraîches (comme le téléchargement automatique de fichiers). Si vous êtes conscient des limites d'iFrames, Je ne pense pas que vous devriez vous sentir gêné de les utiliser.
ayant travaillé avec eux dans de nombreuses circonstances, j'en suis venu à penser que les iframe sont l'équivalent en programmation web de la déclaration goto. C'est, quelque chose de généralement être évitée. Dans un site, ils peuvent être quelque peu utiles. Cependant, sur plusieurs sites, ils sont presque toujours une mauvaise idée pour tout sauf le contenu le plus simple.
envisager les possibilités ... s'ils sont utilisés pour paramétrer le contenu, ils ont créé une interface. Et sur un site professionnel, cette interface nécessite un SLA et une gestion de version - qui sont presque toujours ignorés dans rush pour obtenir en ligne.
si utilisé pour le contenu actif - les cadres que le script hôte - alors il y a les restrictions (différentes) de script de domaine croisé. Certains peuvent être piratés, mais rarement de manière cohérente. Et si votre contenu encadré a besoin d'être interactif, il aura du mal à le faire au-delà du cadre.
S'ils sont utilisés avec du Contenu autorisé, les sites participants sont alourdi par la nécessité de déplacer l'information sur l'admissibilité hors de la bande entre les hôtes.
donc, bien que, occasionally utile dans un site, ils sont plutôt inadaptés à mashups. Vous regardez mieux les vrais portails et portlets. Pire encore, ils sont les chouchous de tous les amateurs de web - beaucoup de directeurs de technologie ont saisi sur eux comme une solution à de nombreux problèmes. En fait, ils créent de plus.
Il ya certainement des utilisations pour les gens iframes. Comment mettre autrement le widget weather networks sur votre page? La seule autre façon est de saisir leur XML et de l'analyser, mais ensuite, bien sûr, vous avez besoin de conditions pour jeter vers le haut les graphiques météorologiques pertenant... ça n'en vaut pas la peine, mais c'est plus propre si tu as le temps.
basé sur mon expérience un côté positif pour iframe sont lors de l'appel de codes tiers, qui peut impliquer d'appeler un javascript qui appelle a a une commande Document.write(); . Comme vous le savez peut-être, ces commandes ne peuvent pas être appelées de façon asynchrone en raison de la façon dont elles sont interprétées (DOM Parser, etc.). Un exemple de ceci est http://sourceforge.net/projects/phpadsnew/ j'ai fait usage d'iframes pour aider à accélérer notre site car il y avait plusieurs appels à phpadsnews et le site attendait la réponse avant de procéder au rendu de différentes parties de la page. avec une iframe, j'ai été capable de permettre au site de rendre d'autres parties de la page et d'appeler encore la commande Document.write() de phpads de façon asynchrone. Prévention et verrouillage js.
le modèle original frameset (Frameset et Frame-elements) était très mauvais du point de vue de l'utilisabilité. IFrame est une invention plus récente qui n'a pas eu autant de problèmes que le modèle original frameset, mais il a son inconvénient.
si vous permettez à l'utilisateur de naviguer à l'intérieur de L'IFrame, alors les liens et les signets ne fonctionneront pas comme prévu (parce que vous signet L'URL de la page extérieure, mais pas L'URL de l'iframe).
lorsque votre page principale se charge en protocole HTTP et que certaines parties de votre page doivent fonctionner en protocole HTTPS, iFrame peut battre JSONP hands down.
en particulier, si votre type de données n'est pas nativement json et doit être traduit sur le serveur en json et traduit sur le client en html complexe par exemple.
donc non-iFrame n'est pas mauvais.
j'ai vu IFRAMEs appliqué avec succès comme un moyen facile de faire des menus de contexte dynamique, mais le public cible de cette application web était seulement les utilisateurs Internet Explorer.
je dirais que tout dépend de vos exigences. Si vous souhaitez vous assurer que votre page fonctionne également bien sur chaque navigateur, évitez IFRAMEs. Si vous ciblez un public restreint et bien connu (p. ex. sur L'Intranet local) et vous voyez un avantage à utiliser IFRAMEs alors je dirais que c'est OK pour faire.
Ils ne sont pas mauvais, mais en fait très utile. J'ai eu un gros problème il y a quelque temps, quand j'ai dû intégrer mon fil twitter et qu'il ne voulait pas laisser md le faire sur la même page, alors je l'ai mis sur une autre page, et je l'ai mis dans une iframe.
ils sont également bons parce que tous les navigateurs (et navigateurs téléphoniques) les soutiennent. Ils ne peuvent pas être considérés comme une mauvaise pratique, tant que vous les utilisez correctement.
il est intéressant de noter que iframes sera, indépendamment de la vitesse de la connexion internet de vos utilisateurs ou le contenu de l'iframe, causer un petit (0,3 s ou plus) mais ralentissement perceptible dans la vitesse de vos téléchargements de page. Ce n'est pas quelque chose que vous verrez en le testant localement. En fait, cela est vrai pour tout élément ajouté à une page, mais iframes semblent être pire.