为什么 ie 在遇到时明显会回流 DOM? fbml 元素何时正确使用 fbml xmlns?
我有一个页面,其中包含许多 facebook“喜欢”按钮,使用内联 fbml 技术(而不是 iframe)嵌入。够简单的。页面呈现良好,一切都按预期进行。
但是...
一旦我将 xmlns:fb="http://www.facebook.com/2008/fbml"
命名空间声明添加到文档中,我注意到初始页面渲染时间急剧下降在IE中。仔细检查(使用 ie8 开发人员工具)发现,在页面初始加载后的短时间内,整个 DOM 似乎一遍又一遍地“刷新”或“回流”。进一步的研究表明,回流次数显然与文档中
元素的数量成正比。
删除 xmlns 声明可以使问题消失。
以前有人经历过这个吗?
更新:
一些进一步的挖掘揭示了一些更多细节...问题确实是 IE 正在重新流动页面,包括重新执行任何内联脚本等。原因似乎不是包含 xmlns 本身,而是按钮本身的 xfbml 呈现。添加 xmlns 只是触发了 xfbml 渲染,如果没有 xmlns,按钮从一开始就不会渲染。以下标记说明了该问题。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en" xmlns:fb="http://www.facebook.com/2008/fbml">
<head>
<script type="text/javascript">
alert('some inline js');
</script>
</head>
<body>
<div id="fb-root"></div>
<div>
<fb:like href="http://example.local/1" layout="button_count" show_faces="false" width="80" action="like" font="arial" colorscheme="light"></fb:like>
<fb:like href="http://example.local/2" layout="button_count" show_faces="false" width="80" action="like" font="arial" colorscheme="light"></fb:like>
<fb:like href="http://example.local/3" layout="button_count" show_faces="false" width="80" action="like" font="arial" colorscheme="light"></fb:like>
</div>
<script src="http://connect.facebook.net/en_US/all.js#xfbml=1" type="text/javascript"></script>
</body>
</html>
在 ie 中运行时,上面的示例会生成 3 个警报,我预计只会看到一个。
I have a page containing a number of facebook "Like" buttons, embedded using the inline fbml technique (as opposed to iframe). Simple enough. The page renders fine, everything works as expected.
HOWEVER...
Once I add the xmlns:fb="http://www.facebook.com/2008/fbml"
namespace declaration to the document I am noticing a radical degradation of initial page render times in IE. Closer inspection (using the ie8 developer tools) reveals that the entire DOM appears to be "refreshing" or "reflowing" over and over again, for a short period after the page has initally loaded. Some further mucking about reveals that the number of reflows is apparently proportional to the number of <fb:xxx>
elements in the document.
Removing the xmlns declaration makes the problem go away.
Anyone experienced this before?
UPDATE:
Some further digging has revealed some more specifics... The issue is indeed that IE is re-flowing the page, including re-executing any inline scripts and so forth. The cause does not appear to be the inclusion of the xmlns per se, rather the xfbml rendering of the buttons themselves. Adding the xmlns simply triggered the xfbml rendering, without the xmlns, the buttons never rendered in the first place. The following markup illustrates the issue.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en" xmlns:fb="http://www.facebook.com/2008/fbml">
<head>
<script type="text/javascript">
alert('some inline js');
</script>
</head>
<body>
<div id="fb-root"></div>
<div>
<fb:like href="http://example.local/1" layout="button_count" show_faces="false" width="80" action="like" font="arial" colorscheme="light"></fb:like>
<fb:like href="http://example.local/2" layout="button_count" show_faces="false" width="80" action="like" font="arial" colorscheme="light"></fb:like>
<fb:like href="http://example.local/3" layout="button_count" show_faces="false" width="80" action="like" font="arial" colorscheme="light"></fb:like>
</div>
<script src="http://connect.facebook.net/en_US/all.js#xfbml=1" type="text/javascript"></script>
</body>
</html>
When run in ie, the above example generates 3 alerts, I'd expect to see only one.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您似乎遇到了 facebook bug 9777。它自新的 all.js 出现以来就一直存在。我认为已经尝试过几次修复它,但并没有真正起作用。看起来优先级上周刚刚被提升了一个档次。让我们看看它是否会很快得到修复。
无论如何,您看到的问题不是由修改 DOM 树引起的。事实上,被触发的 JavaScript 甚至不在您的页面中……即您的“顶部”页面。
该脚本位于 facebook 脚本创建的 iframe 中,代替您的
fb:like
元素。如果您的
警报
显示以下内容,而不是“一些内联js”:您将看到它来自哪里。在“此” URL 中,您将看到
fb_xd_fragment
以及附加到您的 URL 的一大堆参数。基本上,facebook 脚本将每个 iframe 窗口重定向到您所看到的 URL,这将启动您的脚本。在 http://developers.facebook.com/docs/reference/javascript/FB .init/ 他们讨论了自定义通道 URL (
channelURL
) init param 作为一种解决方法,但这似乎对很多人不起作用。许多人在他们提供的通道 URL 路径上收到大量请求。只是一个想法...您是否尝试过使用 iframe 方法加载“喜欢” 按钮?是不是更快一点了?
否则你可以尝试延迟加载 all.js 脚本...
You seem to be experiencing facebook bug 9777. It's been around since the beginning of the new all.js. I think there have been a couple of attempts at fixing it, which hasn't really worked. Looks like the priority just got pushed up a notch last week. Let's see if it gets fixed anytime soon.
In any case, the problem you are seeing is not caused by the DOM tree being modified. In fact, the javascript being triggered isn't even in your page ... your "top" page that is.
The script is in the iframes created by the facebook script in place of your
fb:like
elements.Instead of "some inline js", if your
alert
shows the following:you will see where it is coming from. In the "This" URLs you'll see
fb_xd_fragment
along with a whole bunch of parameters appended to your url. Basically the facebook script is redirecting each iframe window to the URLs you are seeing, which is kicking off your scripts.In http://developers.facebook.com/docs/reference/javascript/FB.init/ they discuss the Custom Channel URL (
channelURL
) init param as a workaround, which doesn't seem to have worked for many people. And many people are getting request floods on the path they provide as the channelURL.Just a thought ... Have you tried loading the "like" buttons using the iframe method? Was that any quicker?
Otherwise you could try lazy loading the all.js script ...