javascript - bootstrap - Página web principal en modo estándar, iframe en modo compatibilidad: ¿algún problema?
iframe javascript (2)
Tenemos algún contenido HTML heredado que debemos renderizar en modo compatibilidad. El requisito proviene de nuestros clientes que quieren que sus informes basados en HTML (algunos de los cuales se crearon en IE6 días) se vean e impriman exactamente igual, independientemente de la versión del navegador o las tecnologías subyacentes. Al mismo tiempo, queremos utilizar el modo estándar y HTML5 para el resto de nuestra aplicación web.
Una solución obvia es alojar el contenido heredado en un <iframe> en modo de compatibilidad. Lo siguiente parece funcionar en varios navegadores:
main.html (en modo estándar):
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<title></title>
<style type="text/css">
body {
font-family: Arial;
font-size: 9pt;
font-style: italic;
font-weight: bold;
}
</style>
<script type="text/javascript">
window.onload = function () {
info.firstChild.data = "document.compatMode: " + document.compatMode;
// test frame''s HTML5 API: document.getSelection()
setInterval(function () {
var selection = document.getElementById("contentFrame").contentDocument.getSelection();
var selectedNode = selection.focusNode;
if (selectedNode)
info2.firstChild.data = "Selected node: " + selectedNode.nodeName + ", offset: " + selection.focusOffset;
else
info2.firstChild.data = "";
}, 500);
}
</script>
</head>
<body>
<h1>Standard Mode Page</h1>
<span>body font</span>
<table border="1">
<tr>
<td>Table font</td>
</tr>
</table>
<span>body font</span>
<pre id="info"> </pre>
<pre id="info2"> </pre>
<iframe id="contentFrame" style="width: 500px; height: 300px;" src="frame.html"></iframe>
</body>
</html>
frame.html (en modo de compatibilidad):
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "">
<html>
<head>
<title></title>
<style type="text/css">
body {
font-family: Arial;
font-size: 9pt;
font-style: italic;
font-weight: bold;
}
</style>
<script type="text/javascript">
window.onload = function () {
info.firstChild.data = "document.compatMode: " + document.compatMode;
editable.focus();
}
</script>
</head>
<body>
<h1>Compatibility Mode Frame</h1>
<span>body font</span>
<table border="1">
<tr>
<td>Table font</td>
</tr>
</table>
<span>body font</span>
<pre id="info"> </pre>
<div id="editable" contentEditable="true" style="border: 1px dotted red">
Editable
</div>
</body>
</html>
Tenga en cuenta la diferencia en la representación de la table , utilizando el mismo CSS:
Mi pregunta a los desarrolladores web experimentados: ¿ es este un escenario soportado que se puede usar en el entorno de producción (IE8 + principalmente, pero ocasionalmente Safari / Chrome / Firefox)? ¿Hay una mejor manera de hacer esto?
Me encontré con una question relacionada, aunque opuesta, que me dejó con sentimientos encontrados.
[ACTUALIZACIÓN] (basado en los comentarios):
Todo el código JavaScript reside dentro de la página principal y parece funcionar bien. Lo que es interesante (¡y genial!), La vista del marco interno se representa en modo compatibilidad, sin embargo , las funciones de modo estándar están disponibles para su DOM (al menos, cuando se accede desde la página principal). Por ejemplo, document.getSelection funciona (y también lo hace cross-browsers).
Por escenario soportado me refiero a cualquier endoso por los estándares W3C HTML y DOM. Hasta ahora no he encontrado una respuesta definitiva a esto. Este comportamiento también puede ser solo un buen efecto secundario, aunque el hecho de que funcione en navegadores cruzados es prometedor.
MSDN dice lo siguiente: A partir del modo IE9, las páginas web no pueden mostrar múltiples modos de documentos. Por ejemplo, considere una página web basada en estándares que contiene un elemento de marco que muestra contenido en modo peculiar. El modo IE9 muestra el cuadro secundario en modo estándar (porque el documento principal está en modo estándar). De acuerdo con mis pruebas, esto no es verdad ; mi ejemplo funciona como se desea en IE9: la página principal está en modo estándar, la página de marco está en modo quirk. [EDITADO] Como se señala en los comentarios, es el modo casi estándar (es decir, no el modo de peculiaridad clásica), con sus propias reglas de representación .
A partir del modo IE9, las páginas web no pueden mostrar múltiples modos de documentos. Por ejemplo, considere una página web basada en estándares que contiene un elemento de marco que muestra contenido en modo peculiar. El modo IE9 muestra el cuadro secundario en modo estándar (porque el documento principal está en modo estándar).
De acuerdo con mis pruebas, esto no es verdad ; mi ejemplo funciona como se desea en IE9: la página principal está en modo estándar, la página de marco está en modo quirk.
No exactamente; cuando su muestra funciona como se desea, en realidad se muestra en un único modo de visualización, con el modo peculiar modelado para el contenido del marco . No debe preocuparse por la mecánica subyacente, siempre y cuando el resultado resultante coincida con lo que estaba buscando, aunque hay alguna evidencia anecdótica de diferencias entre los modos emulados y nativos (principalmente para hacer con la manipulación js DOM).
Estaría un poco más preocupado sobre cómo IE10 + manejaría tales escenarios marginales :
Comenzando con la Vista previa de IE11, los modos de documento están en desuso y ya no se deben usar, excepto de manera temporal. Asegúrese de actualizar los sitios que se basan en funciones heredadas y modos de documentos para reflejar los estándares modernos.
Edición Ninja: parece que esto ya se ha resuelto en SO ; modificando la solución aceptada a sus necesidades, debe omitir Doctype y agregar <meta http-equiv="X-UA-Compatible" content="IE=5" /> ; X-UA-Compatibility correctamente definida según la especificación msdn
Esta es una pseudo-respuesta a su pregunta poco específica;
Con respecto a su aprensión de confiar en esta característica de IE para "compatibilidad con versiones anteriores", me siento de la misma manera. Microsoft ha proporcionado esta opción porque hay muchas compañías que tardan mucho tiempo en actualizar su contenido web. Esta opción está diseñada para permitirles tener un stop-gap rápido y sucio, no una solución permanente.
Entonces, ¿cuál es la solución permanente? Si esa es su pregunta, entonces IMO esta es la respuesta; no confíe en la pausa y desarrolle la salida correcta para los informes.
Sin saber cuáles son esos informes, es imposible aconsejarlo adecuadamente sobre esa parte, pero aquí hay una puñalada en la oscuridad:
Hay muchas opciones para convertir "HTML" a PDF. (Pongo HTML entre comillas porque cada motor de renderización está obligado a requerir diferentes versiones / estándares de HTML y tendrá que conocer esas suposiciones antes de elegir uno). Si desea un resultado que formatee al 100% el mismo en cualquier navegador, entonces quieres un formato que sea estático y no cambie; como PDF. Además, también tiene las opciones de impresión a su cuidado.