视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
深度剖析HTML的语意和与其相关的前端框架
2020-11-27 14:44:20 责编:小采
文档


关于语义

语义研究的是标志与符号之间的关系,以及它们所代表的意义。在语言学中,它主要是研究这些标志(如单词,短语,或者声音)在语言中的意义。而在前端开发领域,语义主要涉及的是HTML元素、属性和属性值(包括像Microdata这样的扩展)所约定的意义。这些在规范中常用的正式约定语义,可以帮助程序(以及后来参与开发的人)更好地理解一个网站各方面的信息。然而,即使这些元素、属性和属性值的语义是正式化的,它们依然得服从于开发者的适应程度以及共同选择的结果。这使得正式的约定语义也可能会在今后被修改(而这正是HTML设计原则之一)。
区分不同类型的HTML语义

遵守编写“语义化的HTML”这个原则,是现代专业前端开发的基础之一。绝大多数的语义都与当前或预期的内容性质有关(如:h1元素,lang属性,type属性的email值,Microdata)。

然而,并非所有的语义都需要以内容为导向。类名不能“无语义”。不管是用什么名字命名,它们都必须要有意义与目的。类名的语义可以和那些HTML元素不同。我们可以借助HTML元素、某些HTML属性、Microdata等所具有的“全局性”语义,然后利用网站或应用的“局部性”特定语义加以区分,这些特定语义通常包含在属性值中,比如class属性。

尽管在HTML5规范的class属性这一章节中重申了这个假定的“最佳实践”…

    …鼓励开发者使用class属性值描述实际内容,而不是描述期望展现的内容。

…并没有什么内在的原因非这样做不可。事实上,当这种方法在大型网站或者应用中运用时,它往往会成为一种障碍。

    HTML元素和其它属性已经提供了内容层的语义
    对于机器或访问者来说,类名所能透露的有用的语义信息非常少,甚至没有。除非它是已经约定的那一小部分名称(机器同样可读) —— Mircoformats
    类名的主要用途是成为CSS和JavaScript的钩子。如果你不需要为你的页面添加表现和行为,那么你或许不必在你的HTML里添加类名
    类名应该为开发者传达有用的信息。当你阅读一个DOM片段时,它将有助于理解某个类名的具体作用。尤其是在多人协作的开发团队里,与HTML组件打交道的可不光只有前端开发者。

举一个非常简单的例子:

XML/HTML Code复制内容到剪贴板

  1. <div class="news">  
  2.     <h2>News</h2>  
  3.     [news content]   
  4. </div>  

当内容还不明显的时候,这个类名news不能告诉你任何事情。它没有向你提供关于这个组件整体结构的信息,而且一旦内容不再是“新闻”时,使用这个类名就显得非常不妥。类名的语义过分贴近内容,架构既不容易扩展,也不容易为其他开发人员所用。
与内容无关的类名

从某个设计模式的结构与功能中提取类名的语义是一种更好的方法。那些类名与内容无关的组件可重用性更高。

我们不应该害怕让各层之间的关系变得清晰而明确(这里应该是指结构层、内容层等,译者注),而不是用类名严格地反应明确的内容。这样做不会使类名“无语义”,这只是表明它们的语义并不取决于内容。我们也不应该害怕使用额外的HTML元素,只要它们能帮助你创建更强壮、更灵活且更具重用性的组件。这样做不会使HTML变得“无语义”,这仅仅意味着你标记内容所使用的元素数量超过了最小值而已。
前端架构

组件、模板、面向对象的体系结构的目的是能够开发出一种数量有限的可重复使用的组件,它可以在一定范围内包含不同的内容类型。在大型的应用程序中,对类名语义来说最重要的事情是,能够用实用主义服务于它们的主要目的 —— 提供有意义的、灵活的、可重复使用的表现或行为的钩子供开发者使用。
可重用且可组合的组件

总的来说,可扩展的HTML/CSS必须依赖HTML中的class,以便创建可重用的组件。一个灵活的、可重用的组件,既不依赖DOM树中的某一部分,也不需要使用特定类型的元素。它应该能适应不同的容器,并且可以很容易地更换主题。如果有必要,额外的HTML元素(超出标记内容所必须的元素之外的元素)可以让组件更加强壮。Nicole Sullivan所说的media object就是一个很好的例子。

避免用类型选择器支持class,可以让组件更容易合并。下面这个例子中,btn组件与uilist组件不易于合并。问题在于.btn的权重比.uilist a要小(这将覆盖任何共享属性)。而且ulist组件需要锚点作为子节点。

XML/HTML Code复制内容到剪贴板

  1. .btn { /* styles */ }   
  2. .uilist { /* styles */ }   
  3. .uilist a { /* styles */ }   
  4.   
  5. <nav class="uilist">  
  6.     <a href="#">Home</a>  
  7.     <a href="#">About</a>  
  8.     <a class="btn" href="#">Login</a>  
  9. </nav>  

一种让uilist组件与其它组件轻松组合的方法是,uilist的子级DOM元素用class来添加样式。尽管这会降低权重,但是它的主要好处在于,它为你提供了处理子节点的任何结构样式的选择权。

XML/HTML Code复制内容到剪贴板

  1. .btn { /* styles */ }   
  2. .uilist { /* styles */ }   
  3. .uilist-item { /* styles */ }   
  4.   
  5. <nav class="uilist">  
  6.     <a class="uilist-item" href="#">Home</a>  
  7.     <a class="uilist-item" href="#">About</a>  
  8.     <span class="uilist-item">  
  9.         <a class="btn" href="#">Login</a>  
  10.     </span>  
  11. </nav>  

JavaScript专用类

使用某种形式的JavaScript专用类,可以降低因组件样式或结构的改变导致JavaScript失效的风险。我已经找到了一种非常有效的方法,那就是专为JavaScript的钩子使用一种特定的类——js-*——不要在这个类名上添加任何描述。

XML/HTML Code复制内容到剪贴板

  1. <a href="/login" class="btn btn-primary js-login"></a>  

在你修改组件的结构或样式的时候,可能会不经意间对那些必要的JavaScript行为和复杂的功能造成影响,用这种方法的话,可以降低这种可能性。
组件修改器

组件常常会有一些变体,它们与基本组件只有细微的差别。比如,不同的背景色或者边框。主要有两种创建这些组件变体的模式。我将它们称为“单类名”模式和“多类名”模式。

单类名模式

XML/HTML Code复制内容到剪贴板

  1. .btn, .btn-primary { /* 按钮模板样式 */ }   
  2. .btn-primary { /* 主按钮的特殊样式 */ }   
  3.   
  4. <button class="btn">Default</button>  
  5. <button class="btn-primary">Login</button>  

多类名模式

XML/HTML Code复制内容到剪贴板

  1. .btn { /* 按钮模板样式 */ }   
  2. .btn-primary { /* 主按钮的特殊样式 */ }   
  3.   
  4. <button class="btn">Default</button>  
  5. <button class="btn btn-primary">Login</button>  

如果你使用预处理程序,你可以用Sass的@extend功能,以减少一些在使用“单类名”模式时所涉及的维护工作。然而,即使有预处理程序的帮忙,我依然倾向于使用“多类名”模式,并在HTML中修改类名。

我发现这是一种更具扩展性的模式。比如,要实现一个基本的btn组件,并增加5种类型的按钮与3种额外的尺寸。用“多类名”模式的话只要9个class就可以搞定,用“单类名”模式则需要24个class。

如果需要的话,它也更容易让上下文环境适应组件。你可能想对出现在其它组件中的任一btn做一些细节调整。

输出时的HTTP压缩效果,以及大量使用HTML类的一些事情。

当Twitter Bootstrap刚刚问世的时候,我重写了已编译的CSS,以便更好地与手动操作的文件比较大小。在最小化所有的文件之后,手动操作的CSS文件比预处理程序

输出的小10%。但是当所有的文件都通过gzip压缩后,预处理程序
输出的CSS文件比手动操作的小了5%。

这强调了比较HTTP压缩后文件大小的重要性,因为减少的文件大小并不能说明全部问题。它暗示了有经验的CSS开发者在用预处理程序时不必太过关注编译后的CSS中一定程度的重复,因为它将在HTTP压缩后变得更小。通过预处理程序处理更易于维护的CSS代码所带来的好处,要胜过关注原始CSS和压缩后

输出的CSS的美观或文件大小。

在另一个实验中,我从线上扒了一个60KB的HTML文件(由很多可重用的组件组成),并删除了它的每一个class属性。这样处理之后,文件大小减小到25KB。当原始文件与扒下来的文件都通过gzip压缩后,它们的大小分别变为7.6KB和6KB——只相差1.6KB。自由使用class所导致的实际文件大小的结果已经不值得再去强调了。

下载本文
显示全文
专题