易于维护CSS还是轻量级HTML？

Question

我负责监督网站的整个IT方面(包括基础设施和开发),而且我与领先的前端开发人员有不同的看法.他的方法是创建单独的类,每个类带来一个功能,并根据需要组合多个类来设置元素的样式:

HTML
<div class="float_left padding_10 width_60_percent"></div>
<div class="float_left width_30_percent"></div>
<div class="float_left padding_10 width_10_percent"></div>
CSS
.float_left { float: left; }
.padding_10 { padding: 10px; }
.width_60_percent { width: 60%; }
.width_30_percent { width: 30%; }
.width_30_percent { width: 10%; }

优点:

- 通过HTML理解CSS:只需查看HTML中的类名,就可以了解CSS的作用.
- 易于创建:一旦定义了一组类,只需将它们组合在HTML中,您就不必经常编写新的CSS.
- 易于维护:与上述相同的原因.
- 可移植性:您可以对您工作的任何网站使用相同的方法(这对他来说是有意义的,因为他是一个从事不同项目的承包商).
- 较小的CSS:只要你的布局达到一定的临界尺寸,同时一次又一次地重复使用相同的类(这将是适当布局的情况,但显然由于简洁性而未在上面反映出来)例).

缺点:

- 更大的HTML.
- 如果您对CSS部分(我的后端开发人员创建视图不感兴趣)不感兴趣,则难以阅读HTML.
- 更难集成基于类选择器的Javascript(我们使用的是jQuery).

我的方法不是由编写/维护CSS本身的容易程度决定的,而是由于担心我们的HTML代码的很大一部分将仅用于集成我们的CSS,这将影响性能:我相信它是最好有一个更大的CSS,它可以提供服务和缓存一次,而更小的HTML可以节省每个页面视图的带宽,而不是相反.因此,我会选择以下方法:

HTML
<div id="column_left"></div>
<div id="column_middle"></div>
<div id="column_right"></div>
CSS
#column_left { float: left; padding: 10px; width: 60%; }
#column_middle { float: left; width: 30%; }
#column_right { float: left; padding: 10px; width: 10%; }

优点/缺点
如上所述.

我觉得拥有轻量级HTML代码对于实现网站的增长至关重要:
-page加载速度会更快,这将有助于SEO和用户体验.
- 可以使用相同的带宽提供更多页面,从而节省基础架构成本.

为了获得事实上的答案,我们扫描了"大"网站,以查看HTML的哪一部分被分配给使用ID和类.这是代码:

<?php
require_once 'simple_html_dom.php';
$pages = array('http://www.amazon.com', 'http://www.ebay.com', 'mywebsite.html', 'http://stackoverflow.com','facebook.html');
foreach ($pages as $page) {
    echo "\n$page\n";
    $html = new simple_html_dom();
    $string = file_get_contents($page);
    $total = mb_strlen($string);
    echo "HTML = " . $total . " characters\n";
    $html->load($string);
    foreach (array('id', 'class') as $attribute) {
        $count = 0;
        $elements = $html->find("*[$attribute]");
        foreach ($elements as $element) {
            // length of id or classes, + id="..." or class="..."
            $count = $count + mb_strlen($element->$attribute) + mb_strlen($attribute) + 3;
            //echo $element->$attribute . "\n";
        }
        echo "  -from $attribute attributes = $count -> " . round($count / $total * 100) . "%\n";
    }
}

以下是结果:

http://www.amazon.com
HTML = 101680 characters
  -from id attributes = 943 -> 1%
  -from class attributes = 6933 -> 7%

http://www.ebay.com
HTML = 71022 characters
  -from id attributes = 1631 -> 2%
  -from class attributes = 4689 -> 7%

ourwebsite.html
HTML = 35929 characters
  -from id attributes = 754 -> 2%
  -from class attributes = 2607 -> 7%

http://www.imdb.com/
HTML = 74178 characters
  -from id attributes = 1078 -> 1%
  -from class attributes = 5653 -> 8%

http://stackoverflow.com
HTML = 204169 characters
  -from id attributes = 3376 -> 2%
  -from class attributes = 39015 -> 19%

facebook.html
HTML = 419001 characters
  -from id attributes = 6871 -> 2%
  -from class attributes = 85016 -> 20%

到目前为止,我们一直在使用"我的"方法,我很高兴看到我们将与id and类别属性相关的代码百分比保持在与其他大型网站相同的比例(分别约为2%和7%).尽管如此,为了验证这一选择,我想问以下问题,希望有经验的开发人员/网站管理员能够回答:

问题1:你是否看到其他优点/缺点支持/反对这两种方法中的任何一种？

Q2:根据您的经验,担心轻量级HTML代码是否至关重要,或者使用压缩和其他标准可以忽略这一点(例如,您将花费更多资金与前端开发人员进行斗争)？

通过查看结果,您将看到与该属性id和class属性相关的代码数量似乎有一个模式(虽然我知道扫描更多的网站会提供更准确的图片):
- 所有网站都有大约1%到2他们的HTML代码的百分比与id属性有关.
其中-4个网站的HTML代码约占7%classes.
- 其他人约有20%的HTML代码与之相关classes.

问题3:这些模式是否有技术解释(例如Facebook和Stackoverflow使用相同的框架来生成CSS)？

Answer 1

我是一个企业 Web 软件项目的前端开发人员，大约有 50 人编写代码，其中大多数是后端。最初我同意使用尽可能少的类来使代码更轻，并在 css 中使用大量继承。所以我们一直在使用“尽可能少的类”的方法。

A1：使用少数类方法，很多 css 定义将使用元素名称来添加样式，这样.left-column section li a 可以让开发人员的生活更轻松，但实际上会使 css 变慢，因为 css 是从右到左分析的。在我的示例中，浏览器首先检查所有链接，然后检查所有列表元素，依此类推。如果我只有a.lc-linkcss，使用起来会更快，需要查找的元素也更少。

我们遇到的另一个问题是缺乏模块化。我可以设计一个漂亮的元素，我们称之为它.flight-dates，它效果很好。然后出现一个新的用例，有人想在表单中间使用，而不是作为主页面模块。但是该表单是为了在表单标记上使用单个类而构建的，而其他所有内容都使用继承。所有继承都会污染 .flight-dates，因此我需要返回并为 css 添加更高的特异性，因此所有 .flight-dates 样式在它们是表单的子级时都有额外的定义。

这样的事情每周会发生三四次。更少的类=更少的灵活性+具有非常高特异性的丑陋样式表，这就是我从中得到的。

A2：随着页面上发生的 javascript 数量增加，使用的类数量现在几乎无关紧要。据我所知，它对 DOM 操作速度没有任何影响。因此，我们已经失去了从少数类方法中获得的任何优势。

参考您的测试，请记住，下载 css 和解析 css 不是一回事。

此外，上述 CSS 修改实际上使后端和前端开发人员的速度变慢。因为我们试图使用尽可能少的类来让后端的事情变得更容易，所以如果你把它们放在一个新的上下文中，后端留下的组件会像婴儿一样哭泣，而前端必须更改他们 6 个月前编写的 css。我个人已经浪费了几周的时间。

我想说这使得工作速度变慢，并且没有值得谈论的性能优势。

A3：像 Sass 和 Less 这样的东西往往会导致 css 中的常见模式。此外，许多优秀的网格和相关 CSS 框架都使用通用的类名。想想 jQuery ui 或 960 网格。

如果您想从我们的错误中吸取教训，请听听您的前端人员的意见。 您的后端人员会更高兴，因为组件将始终按照他们期望的方式运行。您的前端人员会更高兴，因为他们将能够编写健壮的、一劳永逸的 CSS，而不必在每次出现新用例时都重新进行哈希处理。你的 html 会大一点，但老实说差异可以忽略不计，我不相信它会导致任何重大瓶颈。你的 CSS 会运行得更快。工作最终会花费更少的时间来完成。