web-dev-qa-db-fra.com

Page Web principale en mode standard, iframe en mode de compatibilité: des problèmes?

Nous avons du contenu HTML hérité que nous devons rendre en mode de compatibilité. L'exigence vient de nos clients qui souhaitent que leurs rapports HTML (dont certains ont été créés dans IE6 jours) soient exactement identiques, quelle que soit la version du navigateur ou les technologies sous-jacentes. Dans le même temps, nous voulons utiliser le mode standard et HTML5 pour le reste de notre application Web.

Une solution évidente consiste à héberger le contenu hérité dans un <iframe> en mode de compatibilité. Les éléments suivants semblent fonctionner sur plusieurs navigateurs:

main.html (en mode standard):

<!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">&nbsp;</pre>
    <pre id="info2">&nbsp;</pre>
    <iframe id="contentFrame" style="width: 500px; height: 300px;" src="frame.html"></iframe>
</body>
</html>

frame.html (en mode de compatibilité):

<!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">&nbsp;</pre>
    <div id="editable" contentEditable="true" style="border: 1px dotted red">
        Editable
    </div>
</body>
</html>

Notez la différence dans le rendu du table, en utilisant le même CSS:


Standard and compatibility mode mix

Ma question aux développeurs Web expérimentés: est-ce un scénario pris en charge qui peut être utilisé dans un environnement de production (IE8 + principalement, mais occasionnellement Safari/Chrome/Firefox)? Existe-t-il une meilleure façon de procéder?

Je suis tombé sur un sujet apparenté, quoique opposé question , ce qui m'a laissé des sentiments mitigés.

[MISE À JOUR] (sur la base des commentaires):

Tout le JavaScript réside à l'intérieur de la page principale et semble fonctionner très bien. Ce qui est intéressant (et génial!), La vue du cadre intérieur est rendue en mode de compatibilité, mais les fonctionnalités du mode standard sont disponibles pour son DOM (au moins, lorsque accessible depuis la page principale). Par exemple. document.getSelection fonctionne (et fait également des navigateurs croisés).

Par scénario pris en charge je veux dire toute approbation par les normes HTML et DOM du W3C. Jusqu'à présent, je n'ai pas trouvé de réponse définitive à cela. Ce comportement peut tout aussi bien être juste un effet secondaire de Nice, bien que le fait qu'il fonctionne sur plusieurs navigateurs est prometteur.

MSDN dit ce qui suit: Depuis le mode IE9, les pages Web ne peuvent pas afficher plusieurs modes de document. Par exemple, considérons une page Web basée sur des normes qui contient un élément de cadre qui affiche du contenu en mode excentrique. Le mode IE9 affiche le cadre enfant en mode standard (car le document parent est en mode standard). D'après mes tests, ce n'est pas vrai ; mon exemple fonctionne comme souhaité dans IE9: la page principale est en mode standard, la page frame est en mode bizarre. [EDITED] Comme indiqué dans les commentaires, il s'agit du Presque Standard Mode (c'est-à-dire, pas le mode bizarre classique) , avec ses propres règles de rend .

26
noseratio

Depuis le mode IE9, les pages Web ne peuvent pas afficher plusieurs modes de document. Par exemple, considérons une page Web basée sur des normes qui contient un élément de cadre qui affiche du contenu en mode excentrique. Le mode IE9 affiche le cadre enfant en mode standard (car le document parent est en mode standard).

D'après mes tests, ce n'est pas vrai ; mon exemple fonctionne comme souhaité dans IE9: la page principale est en mode standard, la page frame est en mode bizarre.

Pas assez; lorsque votre échantillon fonctionne comme vous le souhaitez, il est en fait affiché dans un seul mode d'affichage, avec le mode excentrique émulé pour le contenu du cadre . Vous ne devriez pas vous soucier des mécanismes sous-jacents tant que la sortie résultante correspond à ce que vous recherchiez, bien qu'il existe des preuves anecdotiques de différences entre les modes émulé et natif (principalement en relation avec la manipulation js DOM).

Je serais un peu plus préoccupé par comment IE10 + gérerait de tels scénarios marginaux :

À partir de IE11 Preview, les modes de document sont obsolètes et ne doivent plus être utilisés, sauf de façon temporaire. Assurez-vous de mettre à jour les sites qui s'appuient sur les fonctionnalités héritées et les modes de document pour refléter les normes modernes.

Édition Ninja: ressemble à cela a déjà été résolu sur SO ; en modifiant la solution acceptée selon vos besoins, vous devez omettre Doctype et ajouter <meta http-equiv="X-UA-Compatible" content="IE=5" />; X-UA-Compatibility correctement défini selon spécification msdn

8
o.v.

Ceci est une pseudo-réponse à votre question légèrement non spécifique;

En ce qui concerne votre appréhension à compter sur cette fonctionnalité IE pour la "rétrocompatibilité", je ressens la même chose. Microsoft a fourni cette option car il existe de nombreuses entreprises qui prennent beaucoup de temps Il est temps de mettre à jour leur contenu Web. Cette option est censée leur permettre d'avoir un arrêt rapide et sale, pas une solution permanente.

Alors, quelle est la solution permanente? Si telle est votre question, alors l'OMI c'est la réponse; ne vous fiez pas à l'intervalle et développez la sortie correcte pour les rapports.

Sans savoir quels sont ces rapports, il est impossible de vous conseiller correctement à ce sujet, mais voici un coup de couteau dans le noir:

Il existe de nombreuses options pour convertir "HTML" en PDF. (Je mets HTML entre guillemets car chaque moteur de rendu nécessite nécessairement des versions/normes HTML différentes et vous devrez connaître ces hypothèses avant d'en choisir une.) Si vous voulez une sortie qui formatera 100% de la même manière sur n'importe quel navigateur, alors vous voulez un format censé être statique et ne pas changer; comme PDF. De plus, vous disposez également des options d'impression.

2
Luke