Safari 在本地比远程更能容忍格式错误的 HTML。为什么？
我今天遇到了一个奇怪的问题。我们有一个通过 CSS 隐藏 body 的网页，然后有一些 JavaScript 将 body 设置为 display: block 以显示它。 （这是我们需要添加的一些 iFrame 破坏逻辑的一部分）。
我们在一个页面上遇到了问题，但仅限于 Safari。在查看事情时，我发现罪魁祸首是调用了一个包含其自己的 body 标记的包含文件，因此我们最终得到了带有 body 的格式错误的 HTML > 标签嵌套在页面现有的 body 标签内。
由于 JS 正在寻找第一个 body 标签，因此我们真正想要显示的内容从未显示，因为它是用第二个 body 标签包裹的。
我认为 Firefox 只是宽容了 HTML 并忽略了第二个 body 标记。当我们查看服务器上的页面时，Safari 并没有这样做。
但是，如果我获取该文件并在本地运行它，Safari 会告诉我：
遇到额外的
。将属性迁移回原始元素并忽略标记。
我很好奇为什么 Safari 可能会采用这种在本地忽略不良 HTML 而不是来自服务器的“策略”。如果重要的话，那就是我们正在访问的 https 网站。也许 Safari 很明智，试图通过允许不良 HTML 来避免任何潜在的安全问题？
I ran into a curious issue today. We have a web page that hides the body via CSS and then there's a bit of JavaScript that sets the body to display: block to show it. (This is part of some iFrame busting logic we are required to add).
We were having issues on one page but only in Safari. In taking a look at things, I found that the culprit was that an include file was being called that contained its own body tag so we were ending up with malformed HTML with a body tag nested within the pages existing body tag.
Since the JS was looking for the first body tag the content we actually wanted to show was never shown, since it was wrapped with the second body tag.
I assume Firefox was just forgiving of the HTML and ignored the second body tag. Safari didn't do this when we looked at the page on the server.
However, if I grab the file and run it locally, Safari does tell me:
Extra
<body>encountered. Migrating attributes back to the original<body>element and ignoring the tag.
I'm curious as to why Safari might have adopted this 'policy' of ignoring bad HTML locally but not from a server. If it matters, it is an https site we're hitting. Perhaps Safari is being wise and trying to avoid any potential security issues with allowing bad HTML?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论