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

nous avons du contenu HTML que nous devons rendre compatible. L'exigence vient de nos clients qui veulent leurs rapports HTML-basés (dont certains ont été créés en IE6 jours) pour regarder et imprimer exactement le même, indépendamment de la version de navigateur ou des technologies sous-jacentes. En 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 existant dans un <iframe> en le mode de compatibilité. Il semble que le navigateur croisé fonctionne comme suit:

principal.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>

cadre".html (en mode 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>

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


Standard and compatibility mode mix

ma question aux développeurs Web expérimentés: s'agit-il d'un scénario pris en charge qui peut être utilisé dans l'environnement de production (IE8+ la plupart du temps, mais parfois Safari/Chrome/Firefox)? y a-t-il une meilleure façon de faire cela?

je suis tombé sur un parent, bien que opposé question , qui m'a laissé avec des sentiments mitigés.

[mise à JOUR] (basé sur le les commentaires):

tout JavaScript se trouve à l'intérieur de la page principale et semble fonctionner très bien. Ce qui est intéressant (et les grands!), la vue du cadre intérieur est rendue en mode de compatibilité, pourtant des fonctionnalités en mode standard sont disponibles pour son DOM (au moins, lorsqu'on y accède à partir de la page principale). Par exemple: document.getSelection fonctionne (et ne les navigateurs croisés, trop).

Par scénario pris en charge Je veux dire toute approbation par les standards HTML et DOM du W3C. Jusqu'à présent, je n'ai pas trouvé de réponse définitive à cette question. Ce comportement peut aussi bien être juste un bel effet, bien que le fait qu'il fonctionne inter-navigateurs, est prometteuse.

MSDN dit ce qui suit: depuis le mode IE9, les pages web ne peuvent pas afficher plusieurs modes de documents. Par exemple, envisagez une page Web basée sur des normes qui contient un élément de cadre qui affiche le contenu en mode quirks. IE9 mode affiche le cadre enfant en mode standard (parce que le document parent est en mode standard). selon mes tests, ce n'est pas vrai ; mon échantillon fonctionne comme désiré en IE9: la page principale est en mode standard, la page cadre est en mode quirk. [édité] comme indiqué dans les commentaires, il s'agit du Mode presque Standard (c.-À-D. pas le mode quirk classique), avec ses propres règles de rendu .

26
demandé sur Community 2013-09-24 12:11:41
la source

2 ответов

à partir du mode IE9, les pages web ne peuvent pas afficher plusieurs modes de documents. Par exemple, envisagez une page Web basée sur des normes qui contient un cadre élément qui affiche le contenu en mode quirks. Le mode IE9 affiche le cadre enfant en mode standard (parce que le document parent est en mode normes).

selon mes tests, ce n'est pas vrai ; mon échantillon fonctionne comme désiré dans IE9: la page principale est en mode standard, le cadre page est en mode quirk.

pas tout à fait; lorsque votre échantillon fonctionne comme désiré, il est réellement affiché dans un mode d'affichage simple, avec le mode de bizarreries émulé pour le contenu de la trame . Vous ne devriez pas vous soucier de la mécanique sous-jacente aussi longtemps que la sortie résultante correspond à ce que vous étiez après, bien qu'il y ait des preuves anecdotiques de différences entre les modes émulés et natifs (principalement en rapport avec la manipulation de JS DOM).

je serais un peu plus préoccupé par comment IE10+ traiterait de tels scénarios de frange :

commençant par IE11 Preview, les modes de document sont dépréciés et devraient ne plus être utilisés, sauf à titre temporaire. Assurez-vous de mettre à jour les sites qui s'appuient sur les caractéristiques et les modes de documents hérités pour refléter les normes modernes.

Ninja edit: looks like this has already been resolved on SO ; en modifiant la solution acceptée à vos besoins, vous devriez omettre Doctype et ajouter <meta http-equiv="X-UA-Compatible" content="IE=5" /> ; X-UA-Compatibility correctement défini selon MSDN spec

"
8
répondu o.v. 2017-05-23 14:45:35
la source

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

en ce qui concerne votre appréhension de compter sur cette fonctionnalité IE pour" rétrocompatibilité", je ressens la même chose. Microsoft a fourni cette option, car il ya beaucoup d'entreprises là-bas qui prennent beaucoup de temps pour mettre à jour leur contenu web. Cette option est destinée à leur permettre d'avoir un stop-gap rapide et sale, pas une solution permanente.

alors, qu'est-ce que le permanent la solution? Si c'est votre question, alors IMO ceci est la réponse; ne vous fiez pas sur le stop-gap et de développer la sortie correcte pour les rapports.

sans savoir ce que ces rapports sont, il est impossible de vous conseiller correctement sur cette partie, Mais voici un coup dans l'obscurité:

il y a beaucoup d'options pour convertir" HTML " en PDF. (Je mets HTML dans les citations parce que chaque moteur de rendu est lié à exiger différentes versions / normes de HTML et vous aurez besoin connaître ces suppositions avant d'en choisir une.) Si vous voulez une sortie qui formatera 100% le même sur n'importe quel navigateur, alors vous voulez un format qui est censé être statique et ne pas changer; comme PDF. De Plus, alors vous avez également les options d'impression pris en charge.

2
répondu Luke 2013-09-30 19:26:23
la source

Autres questions sur