¿Es iframes una idea terrible?

Estoy construyendo un widget y he estado usando iframes para presentar contenido dentro de él. En algún momento, podría comenzar a servir HTML y JS de terceros, así que pensé que iframes sería una buena idea.

Hace que el widget JavaScript sea un poco más complicado, y me preocupa que esta no sea la mejor implementación.

¿Tienes algún consejo? Sería de gran ayuda escuchar lo que otras personas piensan sobre iframes.

0
agregado editado
Puntos de vista: 3

15 Respuestas

Una cosa que descubrí recientemente es que las páginas .aspx incrustadas en iframes a veces tienen problemas para perder cookies, lo que provocó la pérdida del estado de la sesión en una aplicación con la que estuve involucrado.

Para mí, fue en un escenario donde una tienda de desarrollo diferente consumía una de mis páginas .aspx en su propia página. Esto significa que estábamos en servidores separados, que pueden ser importantes o no.

Aparentemente, esto se debió a que la página principal rechazó las cookies de la página secundaria ... Al igual que la cookie de sesión, también lo hace la sesión.

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

Este problema no afectó a Firefox, pero apareció en IE7 y fue un verdadero misterio durante unas horas.

Además, tengo que contradecir el artículo que he vinculado anteriormente en un punto. El artículo dice que no obtendrá esto si la página que lo contiene también es .aspx ... En este caso, eso no era cierto porque ambas páginas eran .aspxs.

Eso arroja algunas dudas sobre todo lo demás que el artículo dice acerca de esta situación, pero condujo a una resolución, por lo que también es algo.

Como sugería el artículo, puse el siguiente código, que inyecta un encabezado de p3p (proyecto de preferencias de privacidad: nunca había oído hablar de él) en el evento Init de la página:

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

... Y eso solucionó el problema.

0
agregado

Personalmente, lo evitaría si pudiera sin demasiada molestia. Al usar Javascript (o AJAX si necesita cargarlos dinámicamente), puede simplemente usar un div y cambiar el contenido según sea necesario; en algunos casos esto le dará mucha más flexibilidad y simplificará su JS, especialmente si hay mucho de interacción entre su widget y el resto de la página.

Dicho esto, investigaría ambas opciones, y si la ruta JS parece demasiado complicada o complicada, simplemente vaya con iframes.

0
agregado

Una buena opción es usar la propiedad de CSS de desbordamiento. El valor predeterminado es visible, pero puede establecerlo en oculto, desplazarse o automático. Usaría auto en tu caso. Si su contenido se vuelve demasiado grande, parecerá que tiene un iframe, pero aún está justo en la página.

see: overflow property

0
agregado

Técnicamente no hay nada malo con iFrame que con alternativas. Pero semánticamente, hay maldad.

La Web se basa en HTTP, un protocolo que dice que una URL dada siempre conduce a un recurso único.

Usando iFrame, solo sirve varios recursos fundidos en páginas web detrás de una URL para todos ellos. Si le preocupa cómo debería crecer la Web, es problemático. Además, para los robots de los motores de búsqueda, es complicado.

0
agregado

Depende de lo que hace el widget. Los iframes tienen su lugar, pero causan pocos dolores de cabeza en el diseño (sin mencionar la complicación de su JS), por lo que la mayoría de las personas tienden a evitarlos a menos que sea absolutamente necesario.

0
agregado

Solo hay una cosa "realmente mala" con ellos de la que soy consciente.

Si su tercero tiene JavaScript, intenta modificar su DOM demasiado pronto ... IE6 e IE7 arrojarán el oh tan poco útil " Operation Aborted " error, luego en blanco no solo el iframe, pero toda la página circundante . (por ejemplo, su sitio aparece abajo)

No se soluciona en IE8, pero el bloqueo se maneja mejor.

0
agregado

iframes, como marcos, son solo controles para usar para la tarea en cuestión. Como tal, no es ni bueno ni malo en sí mismo, pero podría ser bueno o malo en función de la tarea en cuestión y los requisitos del cliente. Hasta donde yo sé, todos los navegadores modernos (y usuarios que no sean linux) podrán "ver y consumir" iframes sin ningún problema.

0
agregado

No, nada de malo en iframes. Es probable que Iframes sea una mejor idea si va a empezar a publicar contenido de terceros.

La próxima especificación HTML5 también planea construir más características de seguridad en iframes para situaciones como esta, por lo que consideraría una buena práctica usarlas también ahora.

0
agregado
I +1 aquí - la única advertencia, por supuesto, es asegurarse de que el uso sea realmente ideal (es decir, en lugar de simplemente usar Ajax para captar los datos necesarios, el servidor siempre puede tomar y analizar el "contenido de terceros" y recuperado a través de llamadas fuera de banda).
agregado el autor Jason Bunting, fuente

No necesariamente, siempre y cuando el contenido dentro del iframe sea predecible.

0
agregado

Antes de que XMLHTTPRequest fuera ampliamente utilizado, las personas usaban una combinación de JavaScript e iframes para publicar contenido de forma dinámica sin realizar actualizaciones completas de la página.

Hay mucha información sobre el desarrollo de sitios de esta manera, por lo que debería tener un tiempo relativamente fácil de encontrar una solución a muchas de las dificultades que es probable que golpee.

La única cosa que me parece dolorosa es el uso de JavaScript entre dominios en iframes. Si la página que inserta en el iframe pertenece a un dominio diferente de la página "principal", los navegadores tienen restricciones de seguridad que impiden el acceso a una de la otra. El truco es que ambas páginas declaren

document.domain = 'somedomain.com';

Hay muchas cosas en la web sobre este tipo de solución.

¡Buena suerte!

0
agregado
Creo que solo pueden cambiar document.domain para que sea un dominio de nivel superior, es decir, www.acme.com puede cambiar el dominio a acme.com, pero no a google.com. Por lo tanto, esto solo ayuda a iframes a comunicarse a través de subdominios de un solo dominio. (Podría estar equivocado, pero eso es lo que recuerdo)
agregado el autor Josh, fuente
@Josh: tiene razón, el document.domain solo funcionará para las páginas en el mismo dominio principal pero en otro subdominio diferente.
agregado el autor Livingston Samuel, fuente
@Josh Tienes razón, pero siempre puedes usar window.location.href .
agregado el autor nyuszika7h, fuente

En mi experiencia, iframes son hacks o ahorradores de tiempo, asegúrese de que si los está usando son necesarios por esas razones. Si tiene control sobre el contenido (o puede obtener el control a través de la creación de reflejos o raspado), debe considerar el uso de AJAX o de las características del servidor para extraer datos externos y sacarlos de la página: terminará siendo más flexible, más robusto y más fácil de administrar al final.

0
agregado

Voy a estar en desacuerdo con la mayoría y decir que sí, iframes es una idea absolutamente terrible . Cualquiera que haya trabajado dentro de la comunidad de Diseño Web por un tiempo estará de acuerdo en que los iframes son pura maldad y deben evitarse a menos que ABSOLUTAMENTE sea esencial.

Mis razones para creer que son malas es porque rompen el patrón de navegación de una página web. Al utilizar un iframe, puede romper los botones de retroceso y avance de los navegadores y confundir a los usuarios. Rompe toda la idea detrás del protocolo HTTP; que una URL siempre conducirá a una ubicación única. Si el iframe fuera un caballo, se habría retirado hace mucho tiempo. Hay otras maneras de servir el contenido dinámicamente y estos deberían usarse en su lugar.

Si está creando un widget , desaparecen las preocupaciones inmediatas sobre el uso de iframes (malo para los motores de búsqueda, malo para el marcador, etc.), pero el contenido será mejor servido dinámicamente o incluso en una nueva ventana en lugar de en un iframe

0
agregado
-1 como se dijo en otra respuesta: "no es ni bueno ni malo en sí mismo, pero podría ser bueno o malo en función de la tarea en cuestión". Además, el problema con el botón Atrás y Adelante no es específico de iframes, sino que también ocurre con otro contenido dinámico.
agregado el autor Christophe, fuente

Re: "la idea entera detrás del protocolo HTTP, que una URL siempre conducirá a una ubicación única"

Sirvo todo mi CMS desde la misma URL para seguridad y escalabilidad (usando principalmente POST en lugar de parámetros GET). No quiero que el contenido seguro sea visible sin autenticación, y un sistema de envío me facilita el desarrollo ya que no tengo que preocuparme por la autenticación de cada página nueva.

Además, para algunas aplicaciones, el SEO no es aplicable (como para ERP basado en web).

Uso un iFrame para publicar contenido desde un árbol de ensamblaje generado por PHP. No quiero que el árbol (y las visibilidades de los nodos) se actualicen siempre que el usuario quiera ver detalles de una pieza/ensamblaje.

0
agregado
¡Me alegro de no ser uno de tus usuarios! (No se puede marcar como favorito en todo !)
agregado el autor SamB, fuente

Hay varios problemas de usabilidad y accesibilidad con iframes . Algunos navegadores y lectores de pantalla no pueden mostrar iframes, por lo que debe proporcionar contenido 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>

Si comienza a publicar contenido de terceros, debe estar atento al enfoque de captura de iframes una vez que se haya terminado de cargar. Si bien es una molestia menor para los usuarios habituales, puede ser muy confuso para los usuarios que navegan con lectores de pantalla.

0
agregado

Hay un problema importante con los iframes que apenas se menciona pero que me molesta.

Nuestro colega tiene una vida de trabajo invertida en una base de datos dinámica que hemos cargado en las hojas de cálculo de Google Docs que luego mostramos en nuestro sitio junto con un montón de material de apoyo.

No hay absolutamente nada para evitar que alguien agarre el código iframe de la fuente de mi página y lo meta en su página. Ahora están recibiendo todos nuestros datos, actualizados hasta hace unos minutos, publicados en su página por absolutamente nada.

Si un iframe de Google pudiera estar vinculado a un dominio específico, eso detendría eso en sus pistas.

Alguna idea, chispas brillantes?

0
agregado
Esto es bastante antiguo, pero si aún está buscando una solución, entonces puedo pensar en utilizar el encabezado X-Frame-Option para restringir quién puede cargar el iframe. Ahora, obviamente no puede aplicar este encabezado en una url de Google docs ya que no la controla. Pero lo que puede hacer es, en lugar de usar una URL de Google docs directamente, crear su propia url, que redirecciona a un lado del servidor a la url de Google docs. Y luego puede aplicar el encabezado adecuado de X-Frame-Option a su propia URL
agregado el autor Suhas, fuente