前端html小技巧—前端框架详解

今天分享下”前端html小技巧—前端框架详解“这篇文章，文中根据实例编码详细介绍，或许对大家的编程之路有着一定的参考空间与使用价值，需要的朋友接下来跟着云南仟龙Mark一起学习一下吧。

关于语义

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

区分不同类型的HTML语义

遵守写作语义化HTML这一原则是现代专业前端发展的基础之一。绝大多数语义都与当前或预期的内容性质有关（如：h1元素，lang属性，type属性的email值，Microdata）。

然而，并非所有的语义都需要以内容为导向。类名不能无语义。无论命名是什么名字，它们都必须有意义和目的。类名的语义可以与H相匹配TML不同的元素。我们可以使用H。TML一些H元素，一些H元素，TML属性、Microdata具有全局语义，然后用网站或应用的局部特定语义进行区分，通常包含在属性值中，如class属性。

尽管在HTML5规范的class本章重申了该假设的最佳实践…

…鼓励开发者使用cclass属性值描述实际内容，而不是期望显示的内容。

…没有内在有内在原因。事实上，当这种方法应用于大型网站或应用程序时，它往往成为障碍。

HTML内容层的语义提供了元素和其他属性

对于机器或访问者来说，类名可以披露的有用语义信息非常少，甚至没有。除非它是约定名称的一小部分（机器也可读） —— Mircoformats

类名的主要用途是成为CSS和JavaScript钩子。如果你不需要为你的页面添加性能和行为，你可能不需要在你的HTML里添加类名

类名应该向开发者传达有用的信息。阅读D时OM在片段中，它将有助于理解某个类名的具体功能。特别是在与H合作的多人开发团队中TML不仅前端开发者可以处理组件。

举一个非常简单的例子：

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

<div class="news">  
    <h2>News</h2>  
    [news content]   
</div>  

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

与内容无关的类名

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

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

前端架构

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

可重用且可组合的组件

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

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

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

.btn { /* styles */ }   
.uilist { /* styles */ }   
.uilist a { /* styles */ }   

<nav class="uilist">  
    <a href="#">Home</a>  
    <a href="#">About</a>  
    <a class="btn" href="#">Login</a>  
</nav>  

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

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

.btn { /* styles / }
.uilist { / styles / }
.uilist-item { / styles */ }

<nav class="uilist">  
    <a class="uilist-item" href="#">Home</a>  
    <a class="uilist-item" href="#">About</a>  
    <span class="uilist-item">  
        <a class="btn" href="#">Login</a>  
    </span> http://www.qlyl1688.com 
</nav>  

JavaScript专用类

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

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

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

组件修改器

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

单类名模式

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

.btn, .btn-primary { /* 按钮模板样式 / }
.btn-primary { / 主按钮的特殊样式 */ }

<button class="btn">Default</button>  
<button class="btn-primary">Login</button>  

多类名模式

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

.btn { /* 按钮模板样式 / }
.btn-primary { / 主按钮的特殊样式 */ }

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

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

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

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

/* “多类名”样式调整 /
.thing .btn { / 相应的样式调整 */ }

/* “单类名”样式调整 /
.thing .btn,
.thing .btn-primary,
.thing .btn-danger,
.thing .btn-etc { / 相应的样式调整 */ }
“多类名”模式意味着，你只需要用一个单独的组件内部选择器，便可以改变所有类型的btn元素的样式。“单类名”模式意味着，你必须顾及所有可能的按钮类型，并在创造一个新的按钮变体时调整这个选择器。

结构化的类名

当创建一个组件时——并为之添加了“主题”——其中一些class被用来区分各个组件，一些class被当做组件的修改器，其它的class则被用来关联DOM节点，它们一起被包含在一个较大的抽象组件中。

很难去判断btn（组件）、btn-primary（修改器）、brn-group（组件）和btn-group-item（组件子对象）之间的关系，这是因为这些名字不能清晰地表现class的目的。没有一致的模式。

在过去的一年中，我一直在尝试命名模式，目的是能帮助我快速理解在一个DOM片段中节点的表象之间的关系，而不用为此来回切换HTML、CSS与JS文件拼凑网站的架构。这种模式主要受到BEM系统的命名方法的影响，但被改编成一种我认为更容易浏览的形式。

复制代码代码如下:

t-template-name

t-template-name–modifier-name

t-template-name__sub-object

t-template-name__sub-object–modifier-name

component-name

component-name–modifier-name

component-name__sub-object

component-name__sub-object–modifier-name

is-state-type

js-action-name

js-component-type

我将一些结构当做抽象的“模板”来处理，其它的则视为更清晰的组件（通常建立在“模板”上）。但是这种区分并非总是必要的。

这仅仅是我目前发现的一种有用的命名模式。命名模式可以采用任何形式。但这种命名模式的好处在于消除了模糊的类名，只依赖（单）连接符，或者下划线，或者是驼峰格式。

原始文件大小和HTTP压缩的注意事项

任何关于模块化和可扩展的CSS讨论讨论了对文件大小和膨胀的担忧。Nicole Sullivan文件大小的存储(和维护改进)经常在言论中提到，并提到Facebook这样的公司采用这种方法的经验。此外，我想我将在预处理输出时分享HTTP压缩效果和大量使用HTML一些类的东西。

当Twitter Bootstrap刚出版的时候，我重写了已经编译的CSS，以便更好地比较手动操作文件的大小。最小化所有文件后，手动操作CSS文件比预处理程序输出小10%。但当所有文件都通过g时zip压缩后，预处理程序输出CSS文件比手动操作小5%。

这强调了比较HTTP压缩后文件大小的重要性，因为减少的文件大小并不能解释所有的问题。它暗示了经验丰富的CSS在使用预处理程序时，开发人员不必太注意C的编译SS它会在一定程度上重复，因为它会在H中重复TTP压缩变小。C更容易通过预处理程序进行维护SS代码的好处胜过关注原始CSS以及压缩后输出的CSS美观或文件大小。

在另一个实验中，我从网上挑了一个60KB的HTML文件(由许多可重用的组件组成)，每个c都被删除lass属性。这样处理后，文件的大小减小到25KB。当原始文件和摘下的文件通过g时zip压缩后，它们的大小分别变为7.6KB和6KB——只相差1.6KB。自由使用c自由使用c。lass实际文件大小的结果不值得强调。以上是云南仟龙Mark给大家介绍的所有内容,希望对大家有所帮助，如果大家有任何疑问请在脚本之家留言，如果你觉得本文对你有帮助，欢迎转载，烦请注明出处，谢谢！