我懂文件。写作被认为是坏习惯;我希望整理一份理由清单,提交给第三方供应商,告诉他们为什么不应该使用文档。编写分析代码的实现。
请附上申领文件的理由。下面是一个坏习惯。
我懂文件。写作被认为是坏习惯;我希望整理一份理由清单,提交给第三方供应商,告诉他们为什么不应该使用文档。编写分析代码的实现。
请附上申领文件的理由。下面是一个坏习惯。
当前回答
Pro:
这是从外部(到您的主机/域)脚本嵌入内联内容的最简单方法。 你可以覆盖一个frame/iframe中的全部内容。在更现代的Ajax技术广泛可用之前(1998-2002),我经常在菜单/导航部分使用这种技术。
Con:
它序列化渲染引擎,直到加载外部脚本,这可能比内部脚本花费更长的时间。 它通常以这样一种方式使用,即将脚本放在内容中,这被认为是糟糕的形式。
其他回答
一个简单的原因为什么文件。写是一个不好的做法,因为你无法想出一个你找不到更好的替代方案的场景。 另一个原因是您正在处理字符串而不是对象(这是非常原始的)。 它只附加到文档中。 它没有MVC(模型-视图-控制器)模式的美感。 使用ajax+jQuery或angularJS来呈现动态内容要强大得多。
它可以阻止你的页面
文档。写只在页面加载时工作;如果在页面加载完成后调用它,它将覆盖整个页面。
这实际上意味着你必须从一个内联脚本块中调用它——这将阻止浏览器处理接下来页面的部分内容。直到写入块完成,脚本和图像才会被下载。
文档其实没什么问题。写作本身。问题是它很容易被误用。严重,甚至。
对于提供分析代码的供应商(如谷歌analytics)来说,这实际上是他们分发此类代码片段的最简单方法
它使脚本保持较小 他们不必担心重写已经建立的onload事件或包括必要的抽象来安全地添加onload事件 它非常兼容
只要你不尝试在文件加载后使用它,文件。在我看来,写作本身并不是邪恶的。
可以将document.write()(和. innerhtml)看作是对源代码字符串求值。这对于许多应用程序来说非常方便。例如,如果您从某个源获取HTML代码作为字符串,那么只需“计算”它就很方便。
在Lisp的上下文中,DOM操作就像操作一个列表结构,例如通过执行以下操作创建列表(橙色):
(cons 'orange '())
而document.write()就像求值一个字符串,例如通过这样求值一个源代码字符串来创建一个列表:
(eval-string "(cons 'orange '())")
Lisp还具有使用列表操作创建代码的非常有用的能力(例如使用“DOM样式”创建JS解析树)。这意味着你可以使用“DOM样式”构建一个列表结构,而不是“字符串样式”,然后运行该代码,例如:
(eval '(cons 'orange '()))
如果您实现编码工具,例如简单的实时编辑器,那么能够快速计算字符串是非常方便的,例如使用document.write()或. innerhtml。Lisp在这个意义上是理想的,但是你也可以用JS做一些很酷的事情,很多人都在做,比如http://jsbin.com/
我能想到的是:
文档。写需要用在页面加载或正文加载上。因此,如果您想在任何其他时间使用脚本来更新您的页面内容文档。写作几乎毫无用处。 技术文档。write只更新HTML页面,不更新XHTML/XML。IE似乎对这个事实很宽容,但其他浏览器不会。
http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite