São iframes uma idéia terrível?

Eu estou construindo um widget, e eu tenho usado iframes para apresentar conteúdo dentro dele. Em algum momento, eu poderia começar a servir HTML e JS de terceiros, então pensei que iframes seria uma boa ideia.

Isso torna o widget JavaScript um pouco mais complicado, e eu estou preocupado que isso possa não ser a melhor implementação.

Você tem algum conselho? Seria uma grande ajuda ouvir o que as outras pessoas pensam sobre iframes.

0
adicionado editado
Visualizações: 1

15 Respostas

Uma coisa que descobri recentemente é que as páginas .aspx incorporadas em iframes às vezes têm problemas com a perda de cookies, o que levou a um estado de sessão perdido em um aplicativo com o qual eu estava envolvido.

Para mim, foi em um cenário em que uma loja de desenvolvimento diferente estava consumindo uma das minhas páginas .aspx em sua própria página. Isso significa que estávamos em servidores separados, que podem ou não estar salientes.

Aparentemente isso foi causado pela página pai rejeitando cookies para a página filho ... Como vai o cookie de sessão, assim vai a sessão.

The specific mechanics of how this works are a little involved: More Details

Esse problema não impactou o FireFox, mas apareceu no IE7 e foi um verdadeiro mistério por algumas horas.

Além disso, tenho que contradizer o artigo que relacionei acima em um ponto. O artigo diz que você não obtém isso se a página que o contém também for .aspx ... Nesse caso, isso não era verdade porque ambas as páginas eram .aspxs.

Isso coloca algumas dúvidas sobre tudo o que o artigo diz sobre essa situação, mas levou a uma resolução, então é algo assim também.

Como o artigo sugeriu, eu coloquei o seguinte código, que injeta um cabeçalho p3p (Privacy Preferences Project - eu nunca tinha ouvido falar dele) no evento Init da página:

HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")

... E isso resolveu o problema.

0
adicionado

Pessoalmente, eu evitaria se você puder sem muito trabalho. Usando Javascript (ou AJAX se você precisar carregá-los dinamicamente), você pode facilmente usar um div e alterar o conteúdo conforme necessário - em alguns casos isso lhe dará muito mais flexibilidade e simplificará seu JS, especialmente se houver muito de interação entre seu widget e o resto da página.

Dito isso, eu investigaria ambas as opções, e se o caminho JS parece muito complicado ou complicado, basta ir com iframes.

0
adicionado

Uma boa opção é usar a propriedade CSS overflow. O valor padrão é visível, mas você pode configurá-lo para oculto, rolagem ou automático. Eu usaria auto no seu caso. Se seu conteúdo ficar muito grande, parecerá que você tem um iframe, mas ainda está na página.

see: overflow property

0
adicionado

Tecnicamente não há nada mais errado com o iFrame que com alternativas. Mas semanticamente, há mal.

A Web é baseada em HTTP, um protocolo que diz que uma determinada URL sempre levará a um recurso exclusivo.

Usando o iFrame, você só serve vários recursos derretidos em páginas da web atrás de um URL para todos eles. Se você tiver preocupações sobre como a Web deve crescer, é problemático. Além do mais, para os robôs dos mecanismos de busca, é complicado.

0
adicionado

Depende do que o widget faz. Os iframes têm o seu lugar, mas causam poucas dores de cabeça no layout (para não mencionar tornar o seu JS mais complicado), por isso a maioria das pessoas tende a evitá-los a menos que seja absolutamente necessário.

0
adicionado

Há apenas uma coisa "muito ruim" com eles que eu conheço.

Se o seu terceiro faz algum JavaScript, que tenta modificar o seu DOM um pouco cedo demais ... IE6 e IE7 vão jogar o oh tão inútil " Operação anulada " erro, então em branco não apenas iframe, mas toda a página circundante . (por exemplo, seu site aparece desativado)

Não foi corrigido no IE8, mas a falha é melhor tratada.

0
adicionado

iframes, como frames, são apenas controles para usar na tarefa em questão. Como tal, não é bom nem ruim em si, mas pode ser bom ou ruim com base na tarefa em mãos e nos requisitos do cliente. Até onde eu sei, todos os navegadores modernos (e não-linux) poderão "ver e consumir" iframes sem nenhum problema.

0
adicionado

Não, nada de errado com iframes. Iframes são provavelmente uma idéia melhor se você vai começar a servir conteúdo de terceiros.

A próxima especificação HTML5 também planeja construir mais recursos de segurança em iframes para situações como essa, então eu consideraria uma boa prática usá-los agora também.

0
adicionado
Eu + aqui - a única ressalva, é claro, é ter certeza de que o uso é realmente ideal (ou seja, ao invés de simplesmente usar o Ajax para pegar os dados necessários - o servidor pode sempre pegar e analisar o "conteúdo de terceiros" e ser recuperado por meio de chamadas fora de banda).
adicionado o autor Jason Bunting, fonte

Não necessariamente, desde que o conteúdo dentro do iframe seja previsível.

0
adicionado

Antes de XMLHTTPRequest se tornar amplamente utilizado, as pessoas estavam usando uma combinação de JavaScript e iframes para servir conteúdo de uma forma dinâmica sem fazer atualizações de página inteira.

Há muitas informações sobre o desenvolvimento de sites dessa forma, portanto, você deve ter um tempo relativamente fácil de encontrar uma solução alternativa para muitos dos obstáculos que você provavelmente atingirá.

A única coisa que descobri ser uma dor é o uso de JavaScript entre domínios em iframes. Se a página que você incorpora no iframe for de um domínio diferente da página "pai", os navegadores terão restrições de segurança para permitir que você acesse um do outro. O truque é que ambas as páginas declarem

document.domain = 'somedomain.com';

Há muitas coisas na Web sobre esse tipo de solução alternativa.

Boa sorte!

0
adicionado
Acredito que eles só podem alterar o domínio document.demain para um domínio de nível mais alto - ou seja, o www.acme.com pode alterar o domínio para acme.com, mas não para google.com. Assim, isso só ajuda iframes a se comunicar através de subdomínios de um único domínio. (Eu posso estar errado, mas é disso que eu me lembro)
adicionado o autor Josh, fonte
@Josh - você está certo, o document.domain funcionará apenas para páginas no mesmo domínio pai, mas com subdomínio diferente.
adicionado o autor Livingston Samuel, fonte
@Josh Você está certo, mas você sempre pode usar window.location.href .
adicionado o autor nyuszika7h, fonte

Na minha experiência, iframes são hacks ou economizadores de tempo - certifique-se de que, se você os estiver usando, eles são necessários por esses motivos. Se você tiver controle sobre o conteúdo (ou pode obter controle por meio de espelhamento ou raspagem), considere usar AJAX ou inclusões do lado do servidor para puxar dados externos e empurrá-los para fora da página - isso acabará sendo mais flexível, mais robusto e mais fácil de gerenciar no final.

0
adicionado

Eu vou discordar da maioria e dizer que sim, iframes são uma idéia absolutamente terrível . Qualquer pessoa que tenha trabalhado na comunidade de Web Design por um tempo concordará que iframes são pura maldade e devem ser evitados a menos que ABSOLUTAMENTE sejam essenciais.

Minhas razões para acreditar que são ruins é porque elas quebram o padrão de navegação de uma página da web. Usando um iframe, você pode efetivamente quebrar os botões de voltar e avançar nos navegadores e confundir seus usuários. Isso quebra toda a ideia por trás do protocolo HTTP; que um URL sempre levará a um local exclusivo. Se o iframe fosse um cavalo, teria se retirado há muito tempo. Existem outras maneiras de veicular conteúdo dinamicamente e, em vez disso, elas devem ser usadas.

Se você está criando um widget , as preocupações imediatas com o uso de iframes desaparecem (ruim para os motores de busca, ruim para Bookmarking, etc), mas de qualquer maneira o conteúdo seria melhor servido dinamicamente ou até mesmo em uma nova janela em vez de em um iframe.

0
adicionado
-1 como dito em outra resposta: "não é bom nem ruim em si mesmo, mas pode ser bom ou ruim baseado na tarefa em questão". Além disso, o problema com o botão voltar e avançar não é específico para iframes, mas também ocorre com outros conteúdos dinâmicos.
adicionado o autor Christophe, fonte

Re: "toda a idéia por trás do protocolo HTTP; que uma URL sempre levará a um local único"

Eu sirvo todo o meu CMS a partir do mesmo URL para segurança e escalabilidade (usando principalmente POST em vez de parâmetros GET). Eu não quero conteúdo seguro visível sem autenticação, e um sistema de despacho facilita o desenvolvimento para mim, pois não preciso me preocupar com a autenticação para cada nova página.

Além disso, para algumas aplicações, o SEO não é aplicável (como para o ERP baseado na web).

Eu uso um iFrame para servir conteúdo de uma árvore de montagem gerada pelo PHP. Não quero que a árvore (e as visibilidades de nós) sejam atualizadas sempre que o usuário desejar visualizar detalhes de uma peça/montagem.

0
adicionado
Estou feliz por não ser um dos seus usuários! (Não é possível marcar isso em tudo !)
adicionado o autor SamB, fonte

Existem várias href="https://stackoverflow.com/questions/2258379/what-are-usability-accessibility-screen-reader-or-any-other-development-functi"> usabilidade e accessability questões . Alguns navegadores e leitores de tela não podem exibir iframes, portanto, você deve fornecer conteúdo alternativo:

<iframe src="content.html">
    
This content will only be displayed by browsers that do not support iframes. You should provide a link to the content, or in your case an alternative way to use your widget.

</iframe>

Se você começar a veicular conteúdo de terceiros, atente para o foco de captura de iframe após o carregamento. Embora seja um pequeno incômodo para usuários comuns, pode ser muito confuso para os usuários que navegam com leitores de tela.

0
adicionado

Há um problema significativo com iframes que dificilmente são mencionados, mas que me incomodam.

Nosso colega tem uma vida inteira de trabalho investido em um banco de dados que muda dinamicamente e que carregamos nas planilhas do Google Docs, que exibimos em nosso site junto com um monte de material de apoio.

Não há absolutamente nada que impeça alguém de pegar o código do iframe da fonte da minha página e colocá-lo na página dele. Agora eles estão recebendo todos os nossos dados, atualizados até poucos minutos atrás, e foram veiculados em suas páginas por absolutamente nada.

Se um iframe do Google pudesse ser vinculado a um domínio específico, isso impediria isso.

Alguma idéia, faíscas brilhantes?

0
adicionado
Isso é bem antigo, mas se você ainda está procurando uma solução, então eu posso pensar em usar o cabeçalho X-Frame-Option para restringir quem pode carregar o iframe. Agora, você não pode obviamente aplicar esse cabeçalho a um URL do Google Docs, já que você não o controla. Mas o que você pode fazer é, em vez de usar um URL do Google Docs diretamente, criar seu próprio URL que redireciona o servidor para o URL do Google Docs. E então você pode aplicar o cabeçalho X-Frame-Option adequado ao seu próprio URL
adicionado o autor Suhas, fonte