document.head, document.body 附加脚本
我经常使用并看到推荐的 dom-access 结构,如下所示,用于动态向页面添加内容:
loader = document.createElement('script');
loader.src = "myurl.js";
document.getElementsByTagName('head')[0].appendChild(loader);
现在,偶然,我发现这在 Google chrome 中有效:
document.head.appendChild(loader);
再进行一点调查,我发现这有效,显然是交叉的-browser:
document.body.appendChild(loader);
所以我的主要问题是:是否有任何原因我不应该像这样将元素附加到 BODY 上?
另外,您认为 document.head
会得到更广泛的支持吗?
I have often used, and seen recommended, dom-access structures like this for adding content to pages dynamically:
loader = document.createElement('script');
loader.src = "myurl.js";
document.getElementsByTagName('head')[0].appendChild(loader);
Now, by chance, I find that this works in Google chrome:
document.head.appendChild(loader);
A little more investigation, and I find that this works, apparently cross-browser:
document.body.appendChild(loader);
So my primary question is: are there any reasons why I shouldn't attach elements to the BODY like this?
Also, do you think document.head
will become more widely supported?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我不明白为什么在实践中将
元素插入
还是
中会很重要;
元素。从理论上讲,我认为让运行时 DOM 类似于静态 DOM 是件好事。至于
document.head
,它是 HTML5 的一部分,显然已经在所有主要浏览器的最新版本中实现了(请参阅 http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-head)。I can’t see any reason why it would matter in practice whether you insert your
<script>
elements into the<head>
or the<body>
element. In theory, I guess it’s nice to have the runtime DOM resemble the would-be static one.As for
document.head
, it’s part of HTML5 and apparently already implemented in the latest builds of all major browsers (see http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-head).document.body
是 DOM 规范的一部分,我不明白为什么不使用它。但请注意这一点:(来自 https://developer.mozilla.org/en/DOM/document.body)
document.head
目前没有在任何 DOM 规范中定义(显然我错了,请参阅 Daniel 的回答),所以您通常应该避免使用它。document.body
is part of the DOM specification, I don't see any point why not to use it. But be aware of this:(from https://developer.mozilla.org/en/DOM/document.body)
document.head
currently isn't defined in any DOM specification(apparently I was wrong on that, see Daniel's answer), so you should generally avoid using it.我尝试实现这段代码并遇到了一些麻烦,所以想分享我的经验。
首先我尝试了这个:
在 script.js 文件中,我有如下代码:
问题是,当我完成所有这些操作时,代码将无法工作。然而,一旦我将脚本加载器替换为以下内容,它就可以工作:
这对我有用,所以现在问题解决了,但我想了解这两者之间的区别接近。为什么一个有效而另一个无效?
更重要的是,在 script.js 中,我还有如下代码:
无论我以哪种方式在 html 文件中获取脚本,该代码确实都能正常工作。
所以我的窗口大小调整脚本不起作用,但视频内容可以。因此我想知道行为的差异是否与“文档”对象有关......?也许“文档”引用的是 script.js 文件而不是 html 文件。
我不知道。我想我应该分享这个问题,以防它适用于其他人。
干杯。
I tried implementing this code and ran into a bit of trouble, so wanted to share my experience.
First I tried this:
And in the script.js file I had code such as the following:
The problem is, when I did all of this, the code wouldn't work. Whereas it did work once I replaced the script loader with simply this:
That works for me, so problem solved for now, but I would like to understand the difference between those two approaches. Why did one work and not the other?
What's more is that in script.js I also have code such as:
And that code does work fine regardless of which way I source the script in my html file.
So my window resizing script doesn't work, but the video stuff does. Therefore I'm wondering if the difference in behavior has to do with "document" object...? Maybe "document" is referencing the script.js file instead of the html file.
I don't know. Thought I should share this issue in case it applies to anyone else.
Cheers.
目前给出的答案集中在两个不同的方面,并且都非常有用。
如果您对可移植性有要求,那么在不属于您所有权且无法控制 DOM 一致性的文档中,检查必须附加脚本的元素是否存在可能会很有用;这样,当 HEAD 部分尚未显式创建时,它也将起作用:
除了 CORS 策略和其他易于检测的逻辑错误之外,我没有看到此 DOM 操作任务应该失败的情况,因此检查
document在我看来,.body
作为后备是没有必要的。正如其他用户也概述的那样,在发布问题时,
document.head
尚未得到广泛支持,因为它是 HTML5 规范,而document.body
是,这就是为什么您看到后者在所有浏览器上运行的原因。所以你可以通过以下方式获得 HEAD:
但我认为它不是很有用,因为后者永远不会出错,并且是一个可读且标准的 DOM 查询,除非你发现
document.head
从性能角度来看更快。我可以看到这种形式的另一个可能的优点是代码从旧的 JavaScript 转换为更现代的 HTML5 兼容代码,简洁且更具可读性。
如果兼容性是必须的,您可以使用强制可移植性的库采用的技巧(例如 Google、Yandex 等的解决方案):
这样,在不太可能的情况下,HEAD 元素不存在,而 BODY(或其他元素)不存在确实如此,您一定要将脚本附加到其中。
我还添加了一个有用的位:当设置 src 属性并将其附加到 DOM 时,脚本源的 HTTP 请求将从浏览器发送。无论这两个条件以什么顺序满足,这两个事件中的最后一个都会导致调度 HTTP 请求。
The answers given as far as now focus two different aspects and are both very useful.
If portability is a requirement for you, in documents not under your ownership where you can't control the DOM coherence, it may be useful to check for the existence of the element you have to append the script to; this way, it will works also when the HEAD section has not been explicitly created:
Apart of CORS policy and other easily detectable logic errors, I don't see cases in which this DOM manipulation task should fail, so checking for
document.body
as a fallback is not necessary by my point of view.As other users outlined too,
document.head
was not widely supported yet, at the time the question was posted, as it is a HTML5 spec, whiledocument.body
is, that's why you saw the latter working on all the browsers.So you could get the HEAD with:
but I don't see it very useful, as the latter won't ever be wrong and is a readable and standard DOM query, unless you find out that
document.head
is faster from a performance perspective.Another possible advantage I can see about this form is a code transition from older JavaScript to a more modern HTML5 compliant code, brief and more readable.
If compatibility is a must, you could use tricks adopted by libraries for which portability is mandatory (e.g. solutions from Google, Yandex and others):
This way, in the improbable case the HEAD element does not exist while the BODY (or another element) does, you are sure to append the script to it.
I also add a useful bit: the HTTP request of the script source is sent from the browser when the
src
attribute is set and it is appended to the DOM. No matter in which order these two conditions are met, the last of these two events causes the HTTP request to be dispatched.