He escuchado infinidad de razones sobre por qué no utilizar marcos HTML, desde su falta de accesibilidad, la falta general en UX, su ineficiencia/falta de mantenimiento o que estén desactualizados.¿Cuándo debería usar marcos HTML?
Estetodo me lleva a dos preguntas:
(1) No intrínsecamente. iframes tiene muchos casos de uso que no sufren los problemas de marcos. Son útiles cada vez que desee mezclar un documento desde otro contexto de seguridad, o sin las secuencias de comandos y estilos que utiliza la página primaria.
Sin embargo, es posible 'utilizar un iframe como un marco': dividir la página hacia arriba en áreas separadas de iframe, con fotogramas entrecruzamientos haciendo un lío de navegación que no juega bien con marcadores, abrir-en-nueva-pestaña, etc.
(2) No utilizaría marcos para nada hoy. Hubo un caso de uso limitado para mantener una gran cantidad de contenido de la página que no desea volver a cargar en cada navegación. Pero en estos días solo usaríamos XMLHttpRequest para actualizar parte de la página.
Aún así, sin tener cuidado de hacer accesibles los enlaces de cambio de página (usando hash-history y tener un enlace estático analógico para cada enlace hash, vinculado con <a> s reales que responden a la mitad del clic et al), una página que se actualiza/navega utilizando XMLHttpRequest recreará muchos de los problemas de navegación de los marcos, con una usabilidad muy negativa, accesibilidad e implicaciones de SEO.
Me parece un poco triste que muchos autores crean llamativos, swooshy, sitios web animados "modernos" que, usando ingenuamente el load() de jQuery o similar, exhiben los peores comportamientos de los marcos antiguos y odiados.
"... quieres mezclar un documento desde otro contexto de seguridad ..." - No pude Ayudo a reír cuando leo eso. Es una pena que tanta gente piense que es una buena idea. Phishing y Clickjacking para la victoria? – jww
@noloader: bueno, sí; puede tener sentido hacerlo en el caso en que la página padre tenga alta confianza y el contenido del marco secundario sea de poca confianza, ya que los posibles ataques de hijo a padre son más limitados (ventanas emergentes modales/descargas/etc y navegación sigilosa, en lugar de phishing/clickjacking). Poner elementos de alta confianza como un formulario de inicio de sesión en un marco en un sitio menos confiable es un verdadero error. – bobince
(1) No. Hay usos legítimos para iframes, donde no hay razón para usar marcos hoy en día con los navegadores modernos.
(2) Nunca utilice marcos; hay otras soluciones mejores y más fáciles disponibles para producir el mismo efecto.
Use iframes solo cuando incrustar todo el sitio es la opción más lógica. Aunque es raro, hay ocasiones en que esto tiene sentido.
En resumen, hay un motivo por el cual las etiquetas frame/frameset/noframe se extraen de HTML5, pero el iframe se transferirá.
(ejemplo) Si el sitio A está obligado a incluir una página del sitio B (representado a aparecer venir desde el sitio A) y CSS del sitio B y el JavaScript y generalmente deberá sitio completamente la manguera A. Esta es una razón legítima.
Considerando tu segundo punto. ¿Utilizaría iframes cuando intente mostrar un sitio completo dentro de otro sitio, por ejemplo, un CMS? El sitio A es la oficina administrativa que permite administrar el contenido y el sitio B el portal que contiene ese contenido gestionable. Entonces, para obtener una vista previa de cómo se ve, ¿proporciona un iframe en el Sitio A? –
Sí, eso suena como un caso de uso legítimo para iframes. Es un entorno controlado y necesita mostrar un sitio separado dentro del contexto del primero. – digitaldreamer
Si por alguna razón tiene "forma anidada".
Digamos que tiene un formulario de edición de producto y dentro de este formulario tiene un área con otro formulario que, por ejemplo, le permite ingresar una lista de los clientes para enviar un boletín informativo para este producto.
Los clientes no están relacionados con el producto en absoluto y no tiene ninguna relación con la base de datos de un producto.Son entidades independientes del producto.
En este caso, marco un IFrame con un cliente que agrega el formulario y el botón enviar que envía el formulario dentro de IFrame.
No encontré ninguna forma mejor de implementar el escenario descrito que usar IFrame. Y sí, tengo el requisito de tener ambos formularios en la misma página, y el formulario del boletín debe colocarse dentro del formulario de edición del producto. Necesidad empresarial dictada por los jefes.
+1 Para mantener las cosas simples, en lugar de usar solicitudes HTTP asíncronas, solo permite una POST de formulario simple desde marcos individuales, que luego permiten actualizaciones de página síncrona solo dentro de ese marco, sin perturbar ningún otro contenido en otros marcos. En mi opinión, esta es precisamente una de las razones por las que existe . –
Puede usar un iframe para dar acceso a anuncios de terceros en su sitio web sin darles ningún control o mensaje adicional al documento principal que contiene el iframe.
esa manera que proporcione acceso a los anuncios en su sitio, pero al mismo tiempo, proteger de los ataques de los recursos desconocidos
The mozilla dev pages explains it better:
El elemento HTML representa un contexto de navegación anidada, la incorporación efectiva otra HTML página en la página actual.
No, los iframes están explícitamente exentos de todo el odio. (en la medida en que son parte de HTML5, mientras que frame/frameset no) –
Me alegra oír eso, ya que personalmente he usado iframes en algunos proyectos XD – Moses
Incluso creo que los conjuntos de marcos tienen usos legítimos, aunque raros. – recursive