notas - ¿Cuándo debería usar marcos HTML?
marcos en html bloc de notas (4)
He escuchado innumerables razones sobre por qué no usar marcos HTML, desde su falta de accesibilidad, la falta general en UX, su ineficiencia / imposibilidad de mantener, o simplemente que están desactualizados.
Todo esto me lleva a dos preguntas:
- ¿Este consenso general de odio se aplica también a los iframes?
- ¿En qué escenario (s) es aceptable usar marcos / marcos flotantes en su código?
(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 ''usar un iframe como un fotograma'': dividir la página en áreas de iframe separadas, con enlaces de fotogramas cruzados que crean un lío de navegación que no funciona bien con marcadores, abierto en nuevo pestaña, etc.
(2) No usarí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 XMLHttpRequest para actualizar parte de la página.
Aun así, sin tener cuidado de hacer accesibles los enlaces de cambio de página (usando hash-history y teniendo un enlace analógico estático para cada hash-link, vinculado con <a> s real esa respuesta al medio clic et al), una página que se actualiza / navega usando XMLHttpRequest recreará muchos de los problemas de navegación de los marcos, con una usabilidad fuertemente negativa, accesibilidad e implicaciones de SEO.
Me parece un poco triste que muchos autores estén creando sitios web animados, modernos y "llamativos" que, usando ingenuamente la load() de jQuery load() o similar, exhiben los peores comportamientos de los marcos antiguos y odiados.
(1) No. Existen usos legítimos para iframes, donde no hay ninguna razón para usar marcos hoy con los navegadores modernos.
(2) Nunca use 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 una razón por la 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 (proxied para que parezca provenir del sitio A), entonces el sitio B css y javascript pueden y por lo general manguera completamente el sitio A. Esta es una razón legítima.
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.
De esta forma, le da acceso a los anuncios en su sitio pero, al mismo tiempo, los protege contra ataques de recursos desconocidos.
Las páginas de desarrollo de mozilla lo explican mejor :
El elemento HTML representa un contexto de exploración anidado, integrando efectivamente otra página HTML en la página actual.
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 clientes para enviar un boletín informativo para este producto.
Los clientes no están relacionados con el producto en absoluto y no tiene una relación de base de datos con un producto. Son entidades independientes del producto.
En este caso, marco un IFrame con un formulario de adición de cliente y un botón de envío 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.