【问题标题】:W3C and/or accepted standards for loading non-visual web page resourcesW3C 和/或用于加载非可视网页资源的公认标准
【发布时间】:2014-11-11 11:01:48
【问题描述】:

几年前,我受雇为符合 W3C/AA 标准的客户端应用程序开发 Web 前端。有人告诉我 CSS、JS 和其他非视觉/非展示内容应该始终保留在 head 标记中。

示例

<!DOCTYPE html>
<html>
<head>
    <link type="text/css" rel="stylesheet" href="site.css" />
    <script type="text/javascript" src="jquery.js"></script>
    <script type="text/javascript" src="site.js"></script>
    <script type="text/javascript">
        $(document).ready(function() {
            // Code here...
        });
    </script>
<head>
<body>
    <div class="container">
        ...
    </div>
</body>
</html>

这种方法一直对我有用,但在我目前的角色中,出于性能/执行原因,我被要求将 CSS 和 JS 引用全部移至文档底部

示例

<!DOCTYPE html>
<html>
<head>
    ...
<head>
<body>
    <div class="container">
        ...
    </div>
    <link type="text/css" rel="stylesheet" href="site.css" />
    <script type="text/javascript" src="jquery.js"></script>
    <script type="text/javascript" src="site.js"></script>
    <script type="text/javascript">
        $(document).ready(function() {
            // Code here...
        });
    </script>
</body>
</html>

有人告诉我,这样做并没有违反任何合规性或可接受性标准,并且在某些情况下可以让网站加载速度更快,但是这导致的问题比解决的问题要多。

因此,我想知道我是否应该坚持将这些资源保留在 head 标签中的决定,或者另一方面,是否有任何令人信服的论据支持将资源标签放在底部,或者分散在文档中?

【问题讨论】:

  • 第二个例子造成了什么样的问题?我通常把scripts 放在底部,就像第二个例子一样。还有header 上的stylesheets。不过,我不知道最佳做法是什么。
  • @azhpo,将脚本文件移动到底部会导致页面上的所有功能中断。我对 jQuery 的 .ready() 函数的理解是允许脚本仅在 DOM 完全加载后执行,从而允许脚本保留在头脑中。至于 CSS 样式,当 CSS 应用于文档末尾时,SVG 元素会出现可怕的故障。
  • “任何合规性或可接受性标准”:这是否包括或排除正式/句法 HTML5 规则(即,文档是否无效是否重要)?
  • @unor 包括正式/语法 HTML5 规则...我猜 :-/

标签: javascript html css w3c w3c-validation


【解决方案1】:

link elements 不能出现在 body 元素 (unless they are used for Microdata or RDFa) 中。所以你的&lt;link type="text/css" rel="stylesheet" href="site.css" /&gt; 必须是head 元素的子元素。

script elements 可以出现在body 中。将script 元素作为body 的最后一个子元素是否有意义,这取决于脚本和您的文档。例如,查看问题

如果script 元素具有src 属性(即脚本是从外部文件导入的),您可以使用asyncdefer 属性来控制其执行:

  • async:

    脚本将在可用时立即异步执行

  • defer:

    页面解析完成后执行脚本

  • 默认(即既不是async也不是defer):

    在用户代理继续解析页面之前立即获取并执行脚本

  • async + defer:

    导致仅支持 defer(而不支持 async)的旧版 Web 浏览器回退到 defer 行为,而不是默认的同步阻塞行为

【讨论】:

  • 显然,尽管与当前规范相反,浏览器将链接元素作为 body 的子元素处理得很好。见this recent discussion on the whatwg mailing list
  • @steveax - 当然可以,但是浏览器可以很好地处理大量无效内容。不这样做的建议是合理的(请参阅该线程上的 Simon Pieters 的 cmets),因此反对该建议是一个滑坡。
  • 是的,我同意如果你要发布不符合规范的代码,你需要非常小心,但考虑到许多浏览器实现者,我认为该线程与讨论相关参与其中。
猜你喜欢
  • 2019-09-30
  • 1970-01-01
  • 2016-11-04
  • 1970-01-01
  • 2019-12-19
  • 1970-01-01
  • 1970-01-01
  • 2015-04-09
  • 2013-07-21
相关资源
最近更新 更多