Recibiendo mensajes contradictorios sobre eso, espero que no lo sean. No puedo imaginar que el soporte se detenga, ya que miles de millones de sitios los usan.
En mi opinión, el W3C saltó el arma al deshacerse de iframes de los tipos de documento Strict HTML y XHTML. En teoría, usaría el <object>elemento para agregar objetos extraños a su documento, pero las diferencias y limitaciones del navegador han hecho que esto no sea un principio para muchos desarrolladores. Con el HTML 5 mucho más pragmático (que todavía es un borrador), los iframes están de regreso e incluso tienen dos atributos nuevos: seamlessy el intrigante sandbox.
La compatibilidad con <iframe>HTML 5 todavía está disponible, por lo que no creo que esto cambie en un futuro próximo.
Para responder a sus otras preguntas:
<iframe>s (como marcos en general) la mayoría de las veces no son fáciles de usar:
No permiten un fácil acceso al contenido del marco a través de una URL (sin perder al menos el contenido fuera del marco).
La mayoría de los usuarios "tecnófobos" se irritan con los marcos.
Hasta donde yo sé, son más lentos de renderizar para los navegadores.
Las alternativas incluyen la generación dinámica de páginas (SSI, PHP, Rails, etc.) y el uso de JavaScript / AJAX para cambiar el contenido de, por ejemplo, un <div>
Para ser claros: me refiero a <iframe>un elemento de interfaz. No es un elemento oculto para cargar otras cosas como, por ejemplo, Google Mail.
*** NO use iframes para AdWords, es una violación de los TOS. *** scribd.com/doc/97655/…
cgp
37
altCognito: AdWords usa iframes, no yo :) No quise decir poner un iframe de adword en otro iframe.
Pensador
7
Sé que es un error común (de ahí todos los artículos), así que quería marcarlo para asegurarme de que la gente entendiera lo que estaba diciendo.
cgp
5
Los iframes son imprescindibles cuando se incluye contenido complicado que debe servirse desde otro dominio y no deben manipularse con el código CSS o JS de la página actual.
vsync
4
De lo que estás hablando no tiene nada que ver con los iframes. El punto es: utiliza un iframe para incorporar un contexto de navegación externo anidado. No lo usa para 'diseño de página'. Si necesito un contexto de navegación anidado, ¿cómo diablos usaría un "buen diseño CSS" en su lugar? No tiene sentido.
Chris B
24
Los IFrames no son obsoletos, pero las razones para usarlos son raras.
El uso de IFrames para ofrecer su propio contenido crea un "muro" alrededor del acceso al contenido en esa área.
He visto muchos foros que sugieren la etiqueta Object como reemplazo de IFrame, que probablemente funcione en la mayoría de los casos.
Por ejemplo, tenía un PDF que se mostraba en un IFrame (porque había otras cosas que debemos mostrar en la página además del PDF) y pude hacer que se mostrara bien usando Object.
<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>
Pero Object no fue un reemplazo adecuado para cumplir con el requisito de poder imprimir SOLO la parte PDF de la página.
Un IFrame es como su propia ventana dentro de la página (una ventana dentro de una ventana, básicamente), y una vez que obtiene el objeto de la ventana, puede llamar a .print () en él, como:
jQuery("#confirmed_pdf").contentWindow.print();
IFrame tiene una propiedad contentWindow, eso es lo que hace posible imprimir solo esa parte. El objeto no tiene una propiedad contentWindow, por lo que no hay forma de imprimir solo la sección de la página.
Entonces, parece que si solo está usando IFrame para mostrar algo, hay otras etiquetas como Object que se pueden usar en su lugar. Pero si necesita interactuar con el contenido del IFrame de ciertas formas, entonces el IFrame puede ser necesario.
Cuento cinco iframes. Uno no está oculto, y de hecho, uno de ellos es casi toda la vista. Los IFrames no se utilizan con Ajax normalmente (de todos modos, no en ninguno de los marcos principales). Gmail usa iframes para cosas como: seguimiento del historial, sonido (extraño) y algún tipo de dibujo de lienzo.
cgp
Me refería a un artículo que leí hace unos años.
John Topley
7
Los IFrames no están muertos, pero Frameset / Frames están muriendo.
En las últimas 2 versiones de IE (IE7 / IE8), hacer zoom en Frames (no IFrames) ha creado resultados desastrosos.
Por supuesto, use IFrames, pero en mi humilde opinión, manténgase alejado de Framesets / Frames.
En mi empresa anterior, proporcionamos una aplicación alojada que los clientes integrarían en sus propios sitios web. A veces, usarían un IFrame para hacer esto, encajando nuestra página alojada en sus diseños existentes. A veces, esto incluso se hizo sin problemas (es decir, el IFrame no tenía bordes ni barras de desplazamiento, simplemente parecía parte de la página). Considero que esto es un buen uso de la etiqueta.
Los iframes son imprescindibles para lidiar con las cosas que necesita para poner en los sitios web de los clientes con su propio estilo y Javascript, que el código del usuario no romperá. CSS se puede anular fácilmente y JS puede causar conflictos a veces (en casos raros) por lo que es mejor para un enfoque de "sistema cerrado".
vsync
5
Pueden ser extremadamente útiles en algunas circunstancias, pero son limitadas. En particular, incorporando una funcionalidad común en varios sitios.
Por ejemplo, tengo un cliente que administra varios sitios de comercio electrónico de productos escoceses. Como parte de esto, hemos desarrollado un par de aplicaciones sencillas para localizar posibles nombres de clanes a partir de su apellido o su elección de tartanes (ríase si lo desea, pero los tartanes valen $ 700 millones al año para nuestra economía). La base de datos detrás de esto es sorprendentemente grande (casi diez mil filas en las tablas de nombres centrales y tartanes) y se actualiza con bastante regularidad.
Así que tenemos las aplicaciones configuradas para ejecutarse en un sitio web y luego las incorporamos en nuestros otros sitios web mediante un iframe, lo que permite el paso simple de parámetros de javascript para que podamos integrar la selección de un tartán o clan con la funcionalidad en el sitio de inserción. El iframe está configurado como noborder, por lo que parece completamente transparente para el usuario final.
Por supuesto, habría otras formas de hacer esto, pero el uso de un iframe es simple y robusto. Y ciertamente no es obsoleto.
Caballos para cursos ... <iframe> s son como cualquier otra cosa ... para el propósito correcto son la herramienta correcta; para el propósito equivocado son un truco feo, o peor.
En Ajax, <div> s suelen ser el contenedor más apropiado. En algunos lugares, la actividad de pasar contenido externo como parte de su propio sitio, como lo admiten <iframe> s, es inapropiada.
Mi equipo usó un <iframe> el otro día como una forma ideal de dar a los usuarios acceso a su historial de correo electrónico HTML: los correos electrónicos eran páginas <html> completas que queríamos insertar fácilmente en nuestra plantilla web. <iframe> s eran absolutamente perfectos para presentar esos datos] '.
Por otro lado, los <iframe> s casi siempre deberían eliminarse o desactivarse en cualquier contenido enviado por el usuario que se devuelva al sitio, porque en ese contexto son un problema de seguridad importante.
Actualmente, son la única forma sencilla de proporcionar aislamiento para aplicaciones javascript que se extraen de múltiples dominios / proveedores.
Además, muchos de los widgets que las personas insertan en sus sitios web de terceros utilizan iframes.
Si bien tienen sus inconvenientes, los iframes brindan una solución pragmática a problemas comunes en la web. Tengo que adivinar que estarán presentes durante algún tiempo.
Acabo de cambiar un sitio de un Frameset normal a Iframes, ya que los marcos normales no podían hacer lo que necesitaba. No causó problemas con el resto del código base.
Los problemas de cumplimiento y seguridad también pueden llevarlo a utilizar Iframes; Los carritos de compras son implementaciones populares basadas en IFrame cuando desea incorporar visualmente un carrito de compras como parte de algunas páginas web sin asumir la responsabilidad total del lado del procesamiento de pagos.
Normalmente entregamos un Iframe para integrar nuestras cosas de comercio electrónico y a los clientes les gusta lo llave en mano que puede ser.
Trabajo para una empresa que utiliza marcos para todo, desde menús desplegables, listas, bloques de contenido, etc. solo para cubrir las complejidades de los formularios web .net. La aplicación es muy lenta y solo se ejecuta en IE. No hagas esto.
Respuestas:
En mi opinión, el W3C saltó el arma al deshacerse de iframes de los tipos de documento Strict HTML y XHTML. En teoría, usaría el
<object>elemento para agregar objetos extraños a su documento, pero las diferencias y limitaciones del navegador han hecho que esto no sea un principio para muchos desarrolladores. Con el HTML 5 mucho más pragmático (que todavía es un borrador), los iframes están de regreso e incluso tienen dos atributos nuevos:seamlessy el intrigantesandbox.fuente
La compatibilidad con
<iframe>HTML 5 todavía está disponible, por lo que no creo que esto cambie en un futuro próximo.Para responder a sus otras preguntas:
<iframe>s (como marcos en general) la mayoría de las veces no son fáciles de usar:<div>Para ser claros: me refiero a
<iframe>un elemento de interfaz. No es un elemento oculto para cargar otras cosas como, por ejemplo, Google Mail.fuente
Los iframes son obsoletos para el diseño de página. Nunca los use en lugar de un buen diseño CSS, incluso el diseño basado en tablas es mejor.
Buenas razones para usar iframes son:
fuente
Los IFrames no son obsoletos, pero las razones para usarlos son raras.
Razones para usar iframes:
También respondería que no es necesario eliminar los iframes, es una etiqueta necesaria y estará disponible por un tiempo.
fuente
He visto muchos foros que sugieren la etiqueta Object como reemplazo de IFrame, que probablemente funcione en la mayoría de los casos.
Por ejemplo, tenía un PDF que se mostraba en un IFrame (porque había otras cosas que debemos mostrar en la página además del PDF) y pude hacer que se mostrara bien usando Object.
Lo que era:
<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>Convirtió:
<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>Pero Object no fue un reemplazo adecuado para cumplir con el requisito de poder imprimir SOLO la parte PDF de la página.
Un IFrame es como su propia ventana dentro de la página (una ventana dentro de una ventana, básicamente), y una vez que obtiene el objeto de la ventana, puede llamar a .print () en él, como:
jQuery("#confirmed_pdf").contentWindow.print();IFrame tiene una propiedad contentWindow, eso es lo que hace posible imprimir solo esa parte. El objeto no tiene una propiedad contentWindow, por lo que no hay forma de imprimir solo la sección de la página.
Entonces, parece que si solo está usando IFrame para mostrar algo, hay otras etiquetas como Object que se pueden usar en su lugar. Pero si necesita interactuar con el contenido del IFrame de ciertas formas, entonces el IFrame puede ser necesario.
fuente
Los IFrames se utilizan mucho con AJAX. GMail, por ejemplo, utiliza nueve IFrames ocultos, creo.
fuente
Los IFrames no están muertos, pero Frameset / Frames están muriendo.
En las últimas 2 versiones de IE (IE7 / IE8), hacer zoom en Frames (no IFrames) ha creado resultados desastrosos.
Por supuesto, use IFrames, pero en mi humilde opinión, manténgase alejado de Framesets / Frames.
fuente
En mi empresa anterior, proporcionamos una aplicación alojada que los clientes integrarían en sus propios sitios web. A veces, usarían un IFrame para hacer esto, encajando nuestra página alojada en sus diseños existentes. A veces, esto incluso se hizo sin problemas (es decir, el IFrame no tenía bordes ni barras de desplazamiento, simplemente parecía parte de la página). Considero que esto es un buen uso de la etiqueta.
fuente
Pueden ser extremadamente útiles en algunas circunstancias, pero son limitadas. En particular, incorporando una funcionalidad común en varios sitios.
Por ejemplo, tengo un cliente que administra varios sitios de comercio electrónico de productos escoceses. Como parte de esto, hemos desarrollado un par de aplicaciones sencillas para localizar posibles nombres de clanes a partir de su apellido o su elección de tartanes (ríase si lo desea, pero los tartanes valen $ 700 millones al año para nuestra economía). La base de datos detrás de esto es sorprendentemente grande (casi diez mil filas en las tablas de nombres centrales y tartanes) y se actualiza con bastante regularidad.
Así que tenemos las aplicaciones configuradas para ejecutarse en un sitio web y luego las incorporamos en nuestros otros sitios web mediante un iframe, lo que permite el paso simple de parámetros de javascript para que podamos integrar la selección de un tartán o clan con la funcionalidad en el sitio de inserción. El iframe está configurado como noborder, por lo que parece completamente transparente para el usuario final.
Por supuesto, habría otras formas de hacer esto, pero el uso de un iframe es simple y robusto. Y ciertamente no es obsoleto.
fuente
Caballos para cursos ... <iframe> s son como cualquier otra cosa ... para el propósito correcto son la herramienta correcta; para el propósito equivocado son un truco feo, o peor.
En Ajax, <div> s suelen ser el contenedor más apropiado. En algunos lugares, la actividad de pasar contenido externo como parte de su propio sitio, como lo admiten <iframe> s, es inapropiada.
Mi equipo usó un <iframe> el otro día como una forma ideal de dar a los usuarios acceso a su historial de correo electrónico HTML: los correos electrónicos eran páginas <html> completas que queríamos insertar fácilmente en nuestra plantilla web. <iframe> s eran absolutamente perfectos para presentar esos datos] '.
Por otro lado, los <iframe> s casi siempre deberían eliminarse o desactivarse en cualquier contenido enviado por el usuario que se devuelva al sitio, porque en ese contexto son un problema de seguridad importante.
fuente
La especificación de gadget de Google se basa actualmente en iframes: http://code.google.com/apis/gadgets/docs/spec.html
Actualmente, son la única forma sencilla de proporcionar aislamiento para aplicaciones javascript que se extraen de múltiples dominios / proveedores.
Además, muchos de los widgets que las personas insertan en sus sitios web de terceros utilizan iframes.
Si bien tienen sus inconvenientes, los iframes brindan una solución pragmática a problemas comunes en la web. Tengo que adivinar que estarán presentes durante algún tiempo.
fuente
Acabo de cambiar un sitio de un Frameset normal a Iframes, ya que los marcos normales no podían hacer lo que necesitaba. No causó problemas con el resto del código base.
fuente
Los problemas de cumplimiento y seguridad también pueden llevarlo a utilizar Iframes; Los carritos de compras son implementaciones populares basadas en IFrame cuando desea incorporar visualmente un carrito de compras como parte de algunas páginas web sin asumir la responsabilidad total del lado del procesamiento de pagos.
Normalmente entregamos un Iframe para integrar nuestras cosas de comercio electrónico y a los clientes les gusta lo llave en mano que puede ser.
fuente
Trabajo para una empresa que utiliza marcos para todo, desde menús desplegables, listas, bloques de contenido, etc. solo para cubrir las complejidades de los formularios web .net. La aplicación es muy lenta y solo se ejecuta en IE. No hagas esto.
fuente