Respostas:
Tal como acontece com todas as tecnologias, tem seus altos e baixos. Se você estiver usando um iframe para obter um site desenvolvido adequadamente, é claro que é uma prática ruim. No entanto, às vezes, um iframe é aceitável.
Um dos principais problemas com um iframe tem a ver com favoritos e navegação. Se você o estiver usando para simplesmente incorporar uma página ao seu conteúdo, acho que está bem. É para isso que serve um iframe.
No entanto, eu vi iframes abusados também. Ele nunca deve ser usado como parte integrante do seu site, mas como uma parte do conteúdo de um site.
Geralmente, se você pode fazer isso sem um iframe, é uma opção melhor. Tenho certeza de que outras pessoas aqui podem ter mais informações ou exemplos mais específicos, tudo se resume ao problema que você está tentando resolver.
Com isso dito, se você está limitado ao HTML e não tem acesso a um back-end como PHP ou ASP.NET etc, às vezes um iframe é sua única opção.
window.postMessage(), por exemplo, para implementar o redimensionamento colaborativo de iframe.
Eles não são uma prática ruim, são apenas outra ferramenta e agregam flexibilidade.
Para uso como um elemento de página padrão ... eles são bons, porque são uma maneira simples e confiável de separar o conteúdo em várias páginas. Especialmente para o conteúdo gerado pelo usuário, pode ser útil "sandbox" páginas internas em uma iframemarcação tão ruim que não afeta a página principal. A desvantagem é que, se você introduzir várias camadas de rolagem (uma para o navegador e outra para iframe), seus usuários ficarão frustrados. Como o adzm disse, você não deseja usar um iframepara navegação primária, mas pense neles como um texto / marcação equivalente à maneira como um vídeo ou outro arquivo de mídia seria incorporado.
Para scripts de eventos em segundo plano, geralmente a escolha é entre ocultar iframee XmlHttpRequestcarregar conteúdo para a página atual. A diferença é que um iframegera um carregamento de página, para que você possa voltar e avançar no cache do navegador com a maioria dos navegadores. Observe que o Google, que usa XmlHttpRequesttodo o lugar, também usa iframes em certos casos para permitir que um usuário volte e avance no histórico do navegador.
É uma "má prática" usá-los sem entender suas desvantagens. O post de Adzm resume muito bem.
Por outro lado, o gmail faz uso pesado de iFrames em segundo plano para alguns de seus recursos mais interessantes (como o upload automático de arquivos). Se você está ciente das limitações dos iFrames, não acredito que você deva sentir algum receio em usá-los.
Tendo trabalhado com eles em muitas circunstâncias, realmente cheguei a pensar que os iframe's são o equivalente de programação da Web da instrução goto. Ou seja, algo a ser geralmente evitado. Dentro de um site, eles podem ser um pouco úteis. No entanto, entre sites, eles quase sempre são uma má idéia para qualquer coisa, exceto o conteúdo mais simples.
Considere as possibilidades ... se usadas para conteúdo parametrizado, eles criaram uma interface. E em um site profissional, essa interface requer um SLA e gerenciamento de versão - que quase sempre são ignorados às pressas para ficar online.
Se usado para conteúdo ativo - quadros que hospedam script -, existem as restrições (diferentes) de script entre domínios. Alguns podem ser invadidos, mas raramente de forma consistente. E se o seu conteúdo emoldurado precisar ser interativo, será difícil fazê-lo além do quadro.
Se usado com conteúdo licenciado, os sites participantes ficam sobrecarregados com a necessidade de mover informações de direitos fora da banda entre os hosts.
Portanto, embora sejam úteis ocasionalmente em um site, eles não são adequados para mashups. Você está olhando melhor para portais e portlets reais. Pior, eles são os queridinhos de todos os amadores da web - muitos gerentes de tecnologia os criticaram como uma solução para muitos problemas. De fato, eles criam mais.
Com base na minha experiência, um lado positivo do iframe é ao chamar códigos de terceiros, que podem envolver a chamada de um javascript que chama a possui um Document.write();comando. Como você deve saber, esses comandos não podem ser chamados de forma assíncrona devido à maneira como são analisados (DOM Parser etc). Um exemplo disso é http://sourceforge.net/projects/phpadsnew/ Eu usei iframes para ajudar a acelerar nosso site, pois havia várias chamadas para phpadsnews e o site aguardava a resposta antes de continuar a renderizar diferentes partes da página. com um iframe, fui capaz de permitir que o site renderize outras partes da página e ainda chame o Document.write()comando de phpads de forma assíncrona. Prevenção e bloqueio de js.
Definitivamente, existem usos para os iframes. De que outra forma você colocaria o widget de redes meteorológicas em sua página? A única outra maneira é pegar o XML e analisá-lo, mas é claro que você precisa de condições para exibir os gráficos meteorológicos constantes ... não vale a pena, mas é muito mais limpo se você tiver tempo.
O modelo original do conjunto de quadros (Conjunto de quadros e Elementos de quadro) era muito ruim do ponto de vista da usabilidade. O IFrame foi uma invenção posterior que não teve tantos problemas quanto o modelo original do conjunto de quadros, mas tem sua desvantagem.
Se você permitir que o usuário navegue dentro do IFrame, os links e os favoritos não funcionarão conforme o esperado (porque você marca o URL da página externa, mas não o URL do iframe).
Quando a página principal é carregada no protocolo HTTP e partes da página precisam funcionar no protocolo HTTPS, o iFrame pode superar o jsonp.
Especialmente, se seu dataType não é nativamente json e precisa ser traduzido no servidor para json e traduzido no cliente de volta para, por exemplo, html complexo.
Então não - o iFrame não é mau.
Eles não são ruins, mas realmente úteis. Algum tempo atrás, tive um enorme problema em que tive que incorporar meu feed do twitter e ele simplesmente não deixava o md fazê-lo na mesma página; por isso, coloquei-o em uma página diferente e o coloquei como um iframe.
Eles também são bons porque todos os navegadores (e navegadores de telefone) os suportam. Eles não podem ser considerados uma má prática, desde que você os use corretamente.
Vale ressaltar que os iframes, independentemente da velocidade da conexão com a Internet dos usuários ou do conteúdo do iframe, causarão uma pequena desaceleração (0,3s ou mais), mas notável, na velocidade de download da sua página. Isso não é algo que você verá ao testá-lo localmente. Na verdade, isso é verdade para qualquer elemento adicionado a uma página, mas os iframes parecem ser piores.
Vi os IFRAMEs aplicados com muito êxito como uma maneira fácil de criar menus de contexto dinâmicos, mas o público-alvo desse aplicativo Web era apenas usuários do Internet Explorer.
Eu diria que tudo depende de suas necessidades. Se você deseja garantir que sua página funcione igualmente bem em todos os navegadores, evite IFRAMEs. Se você tem como alvo uma audiência estreita e conhecida (por exemplo, na Intranet local) e vê um benefício no uso de IFRAMEs, diria que não há problema em fazê-lo.