Les IFrames (HTML) sont-ils obsolètes? [fermé]

Obtenir des messages contradictoires à ce sujet, j'espère qu'ils ne le sont pas. Je ne peux pas imaginer que son soutien s'arrêterait, puisqu'un milliard de sites les utilisent.

Quelques questions supplémentaires à ce sujet:

1. Pourquoi devraient-ils supprimer progressivement cette balise?
2. Une alternative pour cela?

À mon avis, le W3C a sauté le pistolet en vidant les iframes des doctypes Strict HTML et XHTML. En théorie, vous utiliseriez l' <object>élément pour ajouter des objets étrangers à votre document, mais les différences et les limitations du navigateur en ont fait un non-démarreur pour de nombreux développeurs. Avec le HTML 5 beaucoup plus pragmatique (qui est encore un brouillon), les iframes sont de retour et ont même deux nouveaux attributs seamless:, et l'intrigant sandbox.

Le support pour <iframe>est toujours là dans HTML 5, donc je ne pense pas que cela changera dans un proche avenir.

Pour répondre à vos autres questions:

1. <iframe>Les s (en tant que cadres en général) ne sont la plupart du temps pas conviviaux:
   • Ils ne permettent pas un accès facile au contenu du cadre via une URL (sans perdre au moins le contenu en dehors du cadre).
   • La plupart des utilisateurs "technophobes" sont irrités par les cadres.
   • Autant que je sache, le rendu est plus lent pour les navigateurs
2. Les alternatives incluent la génération de pages dynamiques (SSI, PHP, Rails, etc.) et l'utilisation de JavaScript / AJAX pour modifier le contenu, par exemple d'un <div>

Pour être clair: je parle d' <iframe>élément d'interface. Pas un élément caché pour charger d'autres choses comme par exemple Google Mail.

Les iframes sont obsolètes pour la mise en page. Ne les utilisez jamais à la place d'une bonne mise en page CSS, même la mise en page basée sur un tableau est meilleure.

Les bonnes raisons d'utiliser les iframes sont:

• ads : adwords par exemple utilise cette technique, c'est bon pour l'encapsulation - ad css ne détruira pas votre page.
• iframe caché : il peut être utilisé pour des centaines de choses utilisables, comme le suivi, l'alternative ajax, etc.

Les IFrames ne sont pas obsolètes, mais les raisons de leur utilisation sont rares.

• L'utilisation d'IFrames pour diffuser votre propre contenu crée un «mur» autour de l'accès au contenu dans cette zone.
• Pour les robots d'exploration comme Google, il n'est pas immédiatement clair que le cotent d'une iframe sera classé aussi haut que si le contenu faisait simplement partie de la page. Pour beaucoup, c'est une raison suffisante pour ne pas l'utiliser.
• Cela rend le DOM de l'IFrame moins accessible par des outils comme jQuery, prototype etc.

Raisons d'utiliser les iframes:

• C'est génial pour séparer les trucs d'autres personnes d'autres domaines, mais cela ne s'intègre pas facilement. (feuilles de style, javascript etc ...)
• L'intégration du multimédia peut parfois être facilitée via une iframe par opposition à l'utilisation de la balise incorporée.
• Vraiment, des cas vraiment spécialisés comme le cas de gmail où ils l'utilisent pour la gestion des sons et de l'historique.

Je répondrais également qu'il n'est pas nécessaire de supprimer les iframes, c'est une balise nécessaire et qu'elle sera là pendant un certain temps.

J'ai vu de nombreux forums suggérant la balise Object en remplacement d'IFrame, ce qui fonctionne probablement dans la plupart des cas.

Par exemple, j'avais un PDF affiché dans un IFrame (car il y avait d'autres choses que nous devons afficher sur la page en plus du PDF uniquement) et j'ai pu le faire s'afficher correctement en utilisant Object.

Qu'est-ce que c'était:

<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>

Est devenu:

<object id="confirmed_pdf" class="current_pdf" data="/prescriptions/show_pdf?id=123" type="application/pdf" height="570" width="480">
  <p>[Show this message if displaying the PDF did not work]</p>
</object>

Mais Object n'était pas un remplaçant approprié pour remplir l'exigence de pouvoir imprimer UNIQUEMENT la partie PDF de la page.

Un IFrame est comme sa propre fenêtre dans la page (une fenêtre dans une fenêtre, en gros), et une fois que vous obtenez l'objet window, vous pouvez appeler .print () dessus, comme:

jQuery("#confirmed_pdf").contentWindow.print();

IFrame a une propriété contentWindow, c'est ce qui permet d'imprimer uniquement cette partie. L'objet n'a pas de propriété contentWindow, il n'y a donc aucun moyen d'imprimer uniquement la section de la page.

Donc, il semble que si vous utilisez simplement IFrame pour afficher quelque chose, il existe d'autres balises comme Object qui peuvent être utilisées à la place. Mais si vous avez besoin d'interagir avec le contenu de l'IFrame de certaines manières, alors IFrame peut être nécessaire.

Les IFrames sont beaucoup utilisées avec AJAX. GMail, par exemple, utilise neuf IFrames cachées, je crois.

Les IFrames ne sont pas morts, mais les cadres / cadres sont en train de mourir.

Dans les 2 dernières versions d' IE (IE7 / IE8), le zoom sur les cadres (pas les IFrames) a donné des résultats désastreux.

Par tous les moyens, utilisez IFrames, mais à mon humble avis, restez à l'écart des cadres / cadres.

Dans mon entreprise précédente, nous fournissions une application hébergée que les clients intégreraient dans leurs propres sites Web. Parfois, ils utilisaient un IFrame pour ce faire, en adaptant notre page hébergée à leurs conceptions existantes. Parfois, cela était même fait de manière transparente (c'est-à-dire que l'IFrame n'avait ni bordures ni barres de défilement, cela ressemblait simplement à une partie de la page). J'ai considéré que c'était une bonne utilisation de la balise.

Ils peuvent être extrêmement utiles dans certaines circonstances, mais ceux-ci sont limités. En particulier l'intégration de fonctionnalités communes sur plusieurs sites.

Par exemple, j'ai un client qui gère un certain nombre de sites de commerce électronique de produits écossais. Dans ce cadre, nous avons développé quelques applications simples pour localiser d'éventuels noms de clan à partir de votre nom de famille ou de votre choix de tartans (rire si vous le souhaitez, mais les tartans valent 700 millions de dollars par an pour notre économie). La base de données derrière cela est étonnamment grande (près de dix mille lignes dans les noms de base et les tables de tartans) et assez régulièrement mise à jour.

Nous avons donc configuré les applications pour s'exécuter sur un site Web, puis les avons intégrées dans nos autres sites Web à l'aide d'un iframe, permettant un simple passage de paramètre javascript afin que nous puissions intégrer la sélection d'un tartan ou d'un clan avec des fonctionnalités sur le site d'intégration. L'iframe est défini comme sans ordre de sorte qu'il semble totalement transparent à l'utilisateur final.

Bien sûr, il y aurait d'autres façons de faire cela, mais l'utilisation d'une iframe est simple et robuste. Et ce n'est certainement pas obsolète.

Des chevaux pour les cours ... Les <iframe> sont comme n'importe quoi d'autre ... dans le bon but, ils sont le bon outil; dans le mauvais but, ils sont un hack laid, ou pire.

En Ajax, les <div> sont souvent le conteneur le plus approprié. Dans certains endroits, l'activité de faire passer du contenu externe dans le cadre de votre propre site, comme le soutiennent les <iframe>, est inappropriée.

Mon équipe a utilisé un <iframe> l'autre jour comme moyen idéal pour donner aux utilisateurs l'accès à leur historique de messagerie HTML - les e-mails étaient des pages <html> complètes que nous voulions insérer facilement dans notre modèle Web. Les <iframe> étaient absolument parfaits pour présenter ces données] ».

D'un autre côté, les <iframe> devraient presque toujours être supprimés ou désactivés dans tout contenu soumis par l'utilisateur qui est renvoyé sur le site, car dans ce contexte, ils constituent un problème de sécurité majeur.

La spécification du gadget Google repose actuellement sur les iframes: http://code.google.com/apis/gadgets/docs/spec.html

Actuellement, ils constituent le seul moyen simple de fournir une isolation pour les applications javascript qui sont extraites de plusieurs domaines / fournisseurs.

De plus, de nombreux widgets que les gens intègrent sur leurs sites Web à partir de tiers utilisent des iframes.

Bien qu'ils aient leurs inconvénients, les iframes offrent une solution pragmatique aux problèmes courants sur le Web. Je devrais deviner qu'ils seront là pendant un certain temps.

Je viens de changer un site d'un Frameset normal à Iframes car les cadres normaux ne pouvaient pas faire ce dont j'avais besoin. Cela n'a causé aucun problème avec le reste de la base de code.

Les problèmes de conformité et de sécurité peuvent également vous conduire à utiliser les Iframes; Les paniers d'achat sont des implémentations populaires basées sur IFrame lorsque vous souhaitez incorporer visuellement un panier dans certaines pages Web sans assumer l'entière responsabilité du traitement des paiements.

Nous fournissons généralement un Iframe pour intégrer nos produits de commerce électronique et nos clients comme à quel point cela peut être clé en main.

Je travaille pour une entreprise qui utilise des cadres pour tout, des menus déroulants, des listes, des blocs de contenu, etc., juste pour couvrir les subtilités des formulaires Web .net. L'application est très lente et ne fonctionne que sur IE. Ne fais pas ça.