【问题标题】:Main web page in standard mode, iframe in compatibility mode: any issues?标准模式下的主网页,兼容模式下的 iframe:有问题吗?
【发布时间】:2013-09-29 08:24:54
【问题描述】:

我们有一些遗留的 HTML 内容,我们必须以兼容模式呈现。我们的客户要求他们的基于 HTML 的报告(其中一些是在 IE6 时代创建的)外观和打印完全相同,而不管浏览器版本或底层技术如何。同时,我们希望在我们的网络应用程序的其余部分使用标准模式和 HTML5。

一个明显的解决方案是以兼容模式在<iframe> 中托管旧内容。以下似乎可以跨浏览器工作:

ma​​in.html(在标准模式下):

<!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(在兼容模式下):

<!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>

注意使用相同 CSS 渲染 table 的区别:


我对有经验的网络开发人员的问题:这是一个受支持的场景,可以在生产环境中使用(主要是 IE8+,但偶尔是 Safari/Chrome/Firefox)? 有更好的方法吗?

我偶然发现了一个相关的,虽然是相反的question,这让我百感交集。

[UPDATE](基于 cmets):

所有 JavaScript 都驻留在主页面中,并且看起来运行良好。有趣的是(而且很棒!),内部框架的视图以兼容模式呈现,但其 DOM 可以使用标准模式功能(至少在从主页访问时)。例如。 document.getSelection 有效(也可以跨浏览器)。

支持的场景我指的是 W3C HTML 和 DOM 标准的任何认可。到目前为止,我还没有找到一个明确的答案。这种行为也可能只是一个很好的副作用,尽管它跨浏览器工作的事实很有希望。

MSDN 表示:在 IE9 模式下,网页无法显示多个文档模式。例如,考虑一个基于标准的网页,该网页包含一个以 quirks 模式显示内容的框架元素。 IE9 模式以标准模式显示子框架(因为父文档处于标准模式)。 根据我的测试,这不是真的;我的示例在 IE9 中按需要工作:主页处于标准模式,框架页面处于 quirk 模式。 [EDITED] 正如 cmets 中所指出的,它是 Almost Standard Mode(即,不是经典的怪癖模式),带有 own rendering rules

【问题讨论】:

  • 我不明白为什么这个组合会造成任何麻烦。但是,不确定不同版本的 javascript 环境将如何交互。
  • @JanDvorak,所有的 JavaScript 都驻留在首页,看起来运行良好。有趣的是(而且很棒!),内部框架的视图以 quirk 模式呈现,但其 DOM 仍然可以使用标准模式功能(至少,从主页访问它时)。例如。 document.getSelection 有效(也可以跨浏览器)。
  • 有趣 - 现在你让我想自己运行一堆测试。当我得到一些结论时,我什至可能会在这里报告。
  • 您的内页以一种称为“几乎标准模式”的方式呈现,请参见此处:msdn.microsoft.com/en-us/library/ff405912(v=vs.85).aspx。所以你可能会在你的内部框架中获得标准模式 DOM 和更正 CSS 行为而不是怪癖。
  • @Noseratio,我很高兴它有效。我很遗憾为我们提供的用于在 IE 上运行的文档通常不是在测试中产生的。然而,他们所说的与实际执行方式之间的不一致通常表明某些内容会在新版本中发生变化,因此不应依赖。祝你好运,谢谢!

标签: javascript html iframe compatibility


【解决方案1】:

从 IE9 模式开始,网页无法显示多种文档模式。例如,考虑一个包含框架的基于标准的网页 以怪癖模式显示内容的元素。 IE9 模式显示 标准模式下的子框架(因为父文档位于 标准模式)。

根据我的测试,这不是真的;我的样品 在 IE9 中按需要工作:主页处于标准模式,框架 页面处于怪异模式。

不完全;当您的示例按需要工作时,它实际上以单一显示模式显示,with quirks mode emulated for the frame content。只要结果输出与您所追求的相匹配,您就不必关心底层机制,尽管有一些轶事证据表明模拟模式和本机模式之间存在差异(主要与 js DOM 操作有关)。

我会更关心how IE10+ would handle such fringe scenarios

从 IE11 Preview 开始,文档模式已被弃用,应该 不再使用,除非是临时使用。确保更新 依赖旧功能和文档模式来反映的网站 现代标准。

忍者编辑:看起来像this has already been resolved on SO;根据您的需要修改接受的解决方案,您应该省略 Doctype 并添加 &lt;meta http-equiv="X-UA-Compatible" content="IE=5" /&gt;X-UA-Compatibility 按照msdn spec 正确定义

【讨论】:

  • 我赞成这个答案,因为我刚刚在我的答案中发表了评论。如果您的主要目标是互联网,那么最好使用 HTML 解决方案。我个人不喜欢用这种特定的敏捷性来躲避 IE 错误。但你的语气暗示 IE 是主要目标。我建议收集使用数据以确定如果您没有更正旧 IE 版本的输出,将会影响多少流量。它可能小到不值得投入时间。
【解决方案2】:

这是对您稍微不具体的问题的伪答案;

关于您担心依赖此 IE 功能来实现“向后兼容性”,我也有同感。微软提供了这个选项,因为那里有很多公司需要很长时间来更新他们的网络内容。这个选项是为了让他们有一个快速而肮脏的权宜之计,而不是永久的解决方案。

那么,永久的解决方案是什么?如果这是您的问题,那么 IMO 这就是答案;不要依赖权宜之计,而是为报告制定正确的输出。

如果不知道这些报告是什么,就不可能在这方面为您提供适当的建议,但这里是在黑暗中刺探:

有很多选项可以将“HTML”转换为 PDF。 (我将 HTML 放在引号中,因为每个渲染引擎都必然需要不同的 HTML 版本/标准,您需要在选择一个之前了解这些假设。)如果您想要在任何浏览器上格式 100% 相同的输出,那么您需要一种静态且不会更改的格式;像PDF。此外,您还可以处理打印选项。

【讨论】:

  • 此答案假定您有可用的服务器端脚本。如果你不这样做,那么你真的只有 HTML 可以转向,这个答案是不适用的。
  • 这个答案很有用。我们确实在研究 PDF 渲染,但我们还没有找到合适的服务器端工具,它可以提供从现有的传统 quirk-mode HTML 到 PDF 的 1:1 渲染(目前已经考虑过 MSHTML 和 Awesomium)。跨度>
  • 我没有反对,但是当我阅读 html-to-pdf 建议时,我内心已经死了一点。还不如使用silverlight /s,如果更新“in-frame”应用程序模板可行的话,也许应该这样做?
  • @o.v.,您能否详细说明为什么 html-to-pdf 不可行?
  • HTML 不是网络格式。这是 100% 正确的。它是一种打印 文档格式(PDF)。使用它来显示报告,因为这些报告是历史性的并且不会更改,只有当这些报告打算打印和/或保存时才是合理的。如果网络是主要的消费媒介,我的建议就失去了相关性。
猜你喜欢
  • 1970-01-01
  • 2014-10-31
  • 2023-03-23
  • 2014-09-13
  • 1970-01-01
  • 2013-09-27
  • 2022-07-19
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多