Home  >  Article  >  Backend Development  >  The correct way to write CSS styles

The correct way to write CSS styles

小云云
小云云Original
2018-03-30 10:36:045026browse

This article mainly introduces CSS style writing specifications, including coding settings, namespace specifications and other knowledge. It is very good and has reference value. Friends who need it can refer to it. I hope it can help everyone.

Encoding settings

Using UTF-8 encoding, use in the CSS code header:

@charset "utf-8";

Note that @charset must be defined in front of all characters in the CSS file (including encoding comments) to take effect.

For example, the following examples will invalidate @charset:


/* 字符编码 */
@charset "utf-8";
html,
body {
  height: 100%;
}
@charset "utf-8";

Namespace specification

•Layout: g is the namespace, for example: .g-wrap, .g-header, .g-content.

•State: With s as the namespace, it represents a dynamic and interactive state, such as: .s-current, s-selected.

•Tools: With u as the namespace, it represents reusable tools that are not coupled to business logic, such as: u-clearfix, u-ellipsis.

•Component: m is the namespace, representing reusable and portable component modules, such as: m-slider, m-dropMenu.

•Hook: With j as the namespace, it represents the class name specific to JavaScript calls, such as: j-request, j-open.

Namespace Thought

Instead of choosing BEM, which has too strict naming rules and too long and ugly style names, we adopted a A more compromise solution.

It is not recommended to use underscore_ for connection

•Save operations, press one less shift key when typing

•Can well distinguish JavaScript variable naming

characters are lowercase

The defined selector name, attributes and attribute values ​​are all written in lowercase.

Selectors

When a rule contains multiple selectors, each selector occupies its own line.

, +, ~, > leave one space on each side of the selector.


.g-header > .g-header-des,
.g-content ~ .g-footer {
}

Short naming and good semantics

For the naming of selectors, try to be concise and meaningful Semantic, there should not be semantically ambiguous names like g-abc.

Rule declaration block

•When there are multiple style declarations in the rule declaration block, each style occupies its own line.

•Add a space before the opening brace { of the rule declaration block.

•Add a space after the colon : in the style attribute and no space before it.

•End each style with a semicolon ;.

•The closing brace } of a rule declaration block occupies its own line.

•Each rule statement is separated by a blank line.

•Use single quotes ‘ for all outermost quotes.

•When an attribute has multiple attribute values, separate the attribute values ​​with commas, and add a space after each comma. When a single attribute value is too long, each attribute value occupies its own line.

The complete example is as follows:


.g-footer,
.g-header {
  position: relative;
}
.g-content {
  background:
    linear-gradient(135deg, deeppink 25%, transparent 25%) -50px 0,
    linear-gradient(225deg, deeppink 25%, transparent 25%) -50px 0,
    linear-gradient(315deg, deeppink 25%, transparent 25%),
    linear-gradient(45deg, deeppink 25%, transparent 25%);
  }
.g-content::before {
  content: '';
}

Value and unit

•When the attribute When the value or color parameter is a number between 0 – 1, the 0 before the decimal point is omitted. color: rgba(255, 255, 255, 0.5)color: rgba(255, 255, 255, .5);

•The unit is omitted when the length value is 0. margin: 0px automargin: 0 auto

•Use lowercase and abbreviated hexadecimal color attribute values. color: #ffcc00color: #fc0

Style attribute order

The attributes under a single style rule should be grouped by function when writing. And write in the order of Positioning Model > Box Model > Typographic > Visual to improve the readability of the code.

•If the content attribute is included, it should be placed at the front;

•Positioning Model layout mode, position, related attributes include: position / top / right / bottom / left / z-index / display / float / …

•Box Model box model, related properties include: width / height / padding / margin / border / overflow / …

•Typographic text layout, related properties include: font / line-height / text-align / word-wrap / …

•Visual visual appearance, related properties include: color / background / list-style / transform / animation / transition / …

Positioning comes first because it can take an element out of the normal text flow and override box-model related styles. The box model follows closely behind, as it determines the size and position of a component. Other properties only work inside the component or have no effect on the results of the first two cases, so they come later.

Use quotation marks appropriately

In some styles, there will be some keywords containing spaces or Chinese keywords.

Use quotation marks within font-family

当字体名字中间有空格,中文名字体及 Unicode 字符编码表示的中文字体,为了保证兼容性,都建议在字体两端添加单引号或者双引号:


body {
  font-family: 'Microsoft YaHei', '黑体-简', '\5b8b\4f53';
}

background-image 的 url 内使用引号

如果路径里面有空格,旧版 IE 是无法识别的,会导致路径失效,建议不管是否存在空格,都添加上单引号或者双引号:


p {
  background-image: url('...');
}

避免使用 !important

除去某些极特殊的情况,尽量不要不要使用 !important。

!important 的存在会给后期维护以及多人协作带来噩梦般的影响。

当存在样式覆盖层叠时,如果你发现新定义的一个样式无法覆盖一个旧的样式,只有加上 !important 才能生效时,是因为你新定义的选择器的优先级不够旧样式选择器的优先级高。所以,合理的书写新样式选择器,是完全可以规避一些看似需要使用 !important 的情况的。

代码注释

单行注释

星号与内容之间必须保留一个空格。

/* 表格隔行变色 */

多行注释

星号要一列对齐,星号与内容之间必须保留一个空格。


/** * Sometimes you need to include optional context for the entire component. Do that up here if it's important enough. */

规则声明块内注释

使用 // 注释,// 后面加上一个空格,注释独立一行。


.g-footer {     border: 0;     // .... }

文件注释

文件顶部必须包含文件注释,用 @name 标识文件说明。星号要一列对齐,星号与内容之间必须保留一个空格,标识符冒号与内容之间必须保留一个空格。

/** * @name: 文件名或模块名 * @description: 文件或模块描述 * @author: author-name(mail-name@domain.com) *          author-name2(mail-name2@domain.com) * @update: 2015-04-29 00:02 */

•@description为文件或模块描述。 •@update为可选项,建议每次改动都更新一下。

当该业务项目主要由固定的一个或多个人负责时,需要添加@author标识,一方面是尊重劳动成果,另一方面方便在需要时快速定位责任人。

SASS 使用建议

嵌套层级规定

使用 SASS 、 LESS 等预处理器时,建议嵌套层级不超过 3 层。

组件/公用类的使用方法

组件/公用类使用 %placeholders 定义,使用 @extend 引用。如:


%clearfix {   overflow: auto;   zoom: 1; } .g-header {   @extend %clearfix; }

组件类的思考

使用 SASS ,经常会预先定义好一些常用公用组件类,譬如清除浮动,水平垂直居中,文字 ellipsis。又或者多个元素具有同样的样式,我们希望能够少写这部分代码,公共部分抽离出来只写一次,达到复用。

但是复用的方式在 SASS 中有多种,那么是使用单独使用一个类定义,给需要的标签添加,还是使用 @include 或者 @extend在定义的类中引入一个 @mixin,或者一个 @function 呢?

基于让 CSS 更简洁以及代码的复用考虑,采用上面的使用 %placeholders 定义,使用 @extend 引用的方案。

•%placeholders,只是一个占位符,只要不通过 @extend 调用,编译后不会产生任何代码量

•使用 @extend 引用,则是因为每次调用相同的 %placeholders 时,编译出来相同的 CSS 样式会进行合并(反之,如果使用 @include 调用定义好的 @mixin,编译出来相同的 CSS 样式不会进行合并)

•这里的组件类特指那些不会动态改变的 CSS 样式,注意与那些可以通过传参生成不同数值样式的 @mixin 方法进行区分

尽量避免使用标签名

使用 SASS ,或者说在 CSS 里也有这种困惑。

假设我们有如下 html 结构:


<span>   <p class="g-content">     <ul class="g-content-list"><li class="item"/>         <li class="item"/>         <li class="item"/>         <li class="item"/>     </ul></p> </span>

在给最里层的标签命名书写样式的时候,我们有两种选择:


.g-content {   .g-content-list {     li {       ...     }   } }

或者是


.g-content {   .g-content-list {     .item {       ...     }   } }

也就是,编译之后生成了下面这两个,到底使用哪个好呢?

•.g-content .g-content-list li { }

•.g-content .g-content-list .item { }

基于 CSS 选择器的解析规则(从右向左),建议使用上述第二种 .g-content .g-content-list .item { } ,避免使用通用标签名作为选择器的一环可以提高 CSS 匹配性能。

浏览器的排版引擎解析 CSS 是基于从右向左(right-to-left)的规则,这么做是为了使样式规则能够更快地与渲染树上的节点匹配。

The above is the detailed content of The correct way to write CSS styles. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn