Pourquoi les gens utilisent-ils encore des iframes? [fermé]

Pour moi, les iframes sont du mal pur (enfin, peut-être pas si pur). Ils semblent créer beaucoup de problèmes. Oui, tout votre site se chargera une fois, puis vous ne pourrez charger qu'une seule page. Mais les gens ont inventé AJAX dans ce but.

L'un des plus gros problèmes que j'ai rencontrés iframeétait que je ne pouvais pas coller un lien vers l'une des sous-pages, car l'URL n'a jamais changé (oui, je sais qu'il existe une solution de contournement pour cela). Deuxièmement, les moteurs de recherche Web peuvent avoir des problèmes pour indexer correctement ces sites.

Parfois, l'accessibilité de ces sites est pire et certains navigateurs peuvent même les afficher de manière incorrecte.

Il existe de meilleures façons de concevoir une mise en page sans (i) cadres. Tous les jours, je peux voir quelqu'un poser des questions à SO, comme "Comment accéder à iframe avec jQuery?".

Alors, quels sont les avantages des iframes? Quelle raison peut-il être de les utiliser encore? Je voudrais juste savoir pourquoi :)

(puisque ce n'est pas une vraie question, c'est une CW)

Je peux penser à 2 raisons (pour le moment) pour lesquelles les gens utiliseraient encore des iframes au lieu d'AJAX:

1) Les iframes contournent la politique d'origine interdomaine (les images, les scripts et les styles ne le font pas). Cela peut être utile pour extraire des sites / contenus d'autres noms de domaine de manière relativement sûre. Fondamentalement, cela offre l'avantage de pouvoir afficher visuellement les données d'autres domaines sans les laisser piétiner sur toute votre page avec un accès illimité (comme quelque chose comme JSONP serait capable de le faire).

2) Vous pouvez charger plusieurs types de ressources à partir d'une iframe, pas seulement certains types mime (vous êtes relativement limité à application / javascript, application / x-javascript, texte / css, texte / xml, image / png, image / jpeg, image / gif avec scripts, XHR, images et sources). Par exemple, si je veux vous montrer un PDF, je peux ouvrir un iframe et laisser le plugin Adobe Reader vous montrer ce fichier. De plus, dans le même domaine, si je veux pipeline un script, un style et une image tous ensemble (en ligne sur la page, l'image devrait être un URI de données), je peux le faire avec un iframe (et si c'est dans le même domaine, port et protocole, je peux également y accéder avec JavaScript).

Saviez-vous que Gmail est un ensemble d'iframes? La partie visible est juste un positionnement intelligent. De plus, de nombreuses implémentations OAuth (Twitter, Facebook, Google, Yahoo!) Utilisent généralement des iframes pour associer un utilisateur de son domaine à une URL d'authentification réussie (après la connexion de l'utilisateur).

Les IFRAME sont utilisés pour intégrer et isoler du contenu tiers dans un site Web.

La plupart des solutions de publicité Web sont basées sur des iframes - car elles offrent une sécurité (politique interdomaine) et un rectangle isolé à l'écran qui peut être entièrement géré par du contenu et des scripts tiers (un cas d'utilisation courant est la publicité).

Une autre utilisation moderne d'IFRAMES est une gestion de l'historique (solution de contournement commune du bouton retour) des applications AJAX.

Les FRAME sont une mauvaise version des IFRAMES. Leur utilisation est en déclin.

Si un utilisateur a désactivé javascript, les iframes fonctionneront alors que ajax ne le fera pas. Ce n'est pas hors de question, étant donné que les gens utilisent des choses comme NoScript .

Je les utilise sur des sites Web ajax, lorsque j'ai besoin de télécharger des fichiers sans recharger la page.

Je vois toujours des iframes utilisés dans les grandes entreprises où ils fournissent un signe unique sur lequel injecte des informations d'en-tête sur l'utilisateur authentifié qui sont ensuite transmises, via une iframe, vers la ou les applications réelles. Étant donné que le «portail» entourant l'iframe gère tous les détails d'authentification spécifiques, ces applications n'ont pas besoin d'avoir chacune une implémentation, ce qui facilite les choses pour l'équipe de développement et dispose d'un seul endroit pour surveiller et ajuster les détails d'authentification d'utilisateurs.

Il existe de nombreuses raisons techniques pour les utiliser (notamment le problème de sécurité évoqué par Dan Beam).

Ce que vous ne devriez pas faire, c'est utiliser des iframes «comme des cadres», pour naviguer vers de nouvelles pages en mettant à jour uniquement l'iframe. Comme vous le dites, cela empêche la navigation de pouvoir être mise en signet / liée, de répondre aux boutons de navigation normaux et de fournir des possibilités de liens utiles telles que l'ouverture dans un nouvel onglet.

Mais ce n'est pas particulier aux iframes. Vous pouvez voir de plus en plus de pages où la navigation est effectuée en récupérant le nouveau contenu XMLHttpRequestet en l'écrivant dans les div de contenu principal innerHTML. Cela se fait souvent avec jQuery load()et des animations de diapositives intelligentes et intelligentes. Cela rompt la navigation aussi mal que les iframe-used-as-frame, ou même les jeux de cadres old-school. C'est dommage que de nombreux auteurs Web utilisent cette tactique en pensant qu'il s'agit d'une méthodologie de conception Web ultra-moderne, alors qu'en réalité, ce n'est qu'un nouveau skin sur les cadres méprisés d'hier.

Vous pouvez le contourner dans les deux cas, mais cela signifie que vous devez stocker un état d'affichage dans la #partie identificateur de fragment et prendre en charge une navigation par hachage appropriée, ce qui n'est pas trivial. Même dans ce cas, vous avez toujours des problèmes avec des agents non-JS comme les moteurs de recherche; vous finissez par avoir à avoir une navigation ?basée et parallèle #pour prendre en charge les deux. C'est une douleur et la plupart ne dérangent pas.

Les jeux de cadres sont obsolètes à partir de HTML 5, et vous devez parfois avoir un cadre avec un autre site dans un site. AJAX ne peut pas non plus faire grand-chose. Essayez de télécharger un fichier sur un site sur un autre domaine via https sans iframe. AJAX ne vous aidera pas là-bas.

En plus d'autres raisons, j'ai une utilisation spécifique de iframedans mon application. Malheureusement, le navigateur cible dans mon cas est Internet Explorer 6. J'ai besoin d'un pied de page et d'un en-tête qui sont fixés dans mes pages Web. La partie principale de cette page est déroulante.

Cependant, il existe un bogue dans IE6 où je ne peux pas afficher un divélément au-dessus des selectéléments en utilisant la z-indexpropriété CSS. Ainsi, j'ai besoin de créer un iframequi sera utilisé comme un hack pour éviter ce problème.

Bien sûr, il s'agit d'un usage vraiment spécifique iframeet ne concerne que IE6...

Les éditeurs Javascript WYSIWYG utilisent des iframes, car c'est le moyen le plus simple et le meilleur de le faire. Par exemple TinyMCE l'utilise:

http://tinymce.moxiecode.com/

Je construisais un réseau social et je vois que les iframes sont utiles pour les widgets à mettre sur le site Web d'autres personnes pour s'afficher comme un mini profil ou s'intégrer au contenu sur un serveur distant. Cela semble être le moyen le plus simple de créer cela. Je sais que certains widgets utilisent JavaScript. De plus, avec la méthode iframe, la session est la même que la visite du site comme d'habitude, donc idéal pour les boutons similaires.

De nombreux éditeurs de texte formaté (par exemple TinyMCE, HTMLArea) sont implémentés comme iframe.

Les iFrames sont acceptables dans certains cas, comme les requêtes X-domain, ou la publication de données vers une source via des paramètres. Mais lorsque je veux accéder aux données sur plusieurs domaines, je préfère utiliser des fichiers CSS - ils peuvent accepter des paramètres, définir des cookies, ajouter du contenu à la page (: avant et: après) et donner un retour visuel.