Css编码

发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 6,925 | 阅读时长 ≈ 27

CSS 本身并无编程特性，但在其工程化技术的发展中缺不乏很多优秀的编程思想，无论是自定义的 DSL 还是基于 JS，这其中带给我们思考的正是“编译思想”

–> css编码
大象无形

z 实际

2018.1.30 二 16:40

一 css中常见问题

1.1 关于Normalize

可能并不需要引入整个normalize.css，或者reset.css。
最近的项目，单独对chrome做一些样式重写就好了；可以借鉴normalize
（以后要兼容，考虑定制；情况并不会很多，注意定制样式的位置或者文件，引入的方式）

如果做多个浏览器，normalize最合适，浏览器间的样式差异是客观存在的（事实）。

1.2 autoprefix ， postcss 与 mixin

基于上述说明，autoprefix 也是可以省掉的
编辑器可以autoprefix，打包工具也可以实现，（浏览器中加载js渲染也可行，没有试过）

1.3 hack

normalize 解决浏览器默认样式的差异
autoprefix 自动添加浏览器前缀，主要是一些新特性

对于一些不支持的样式，比如圆角、阴影，可以找一些第三方解决方案（pie.htc等）
尽管normalize，不同浏览器还是存在一些不同；又或是真对某个浏览器做一些特殊的设置，需要传统解决方法–属性前缀、后缀、条件注释、特定支持的css（haslayout，zoom，auto，@support,@media）

注意hack的使用方式：就近，单独文件，条件注释

1.4 @media

ie不知道那些版本不支持媒体查询，可能需要HTML5 的response
$_NOTE:没有做过

1.5 less,sass,stylus

实际需求

1.6

二 css风格

2.1 单行/多行

优缺点：略
有些引用的，或者原子类的，可以单行；多行是目前的主流
而且，项目中有许多方式可以压缩代码

如果一定要写在head里，谁也没有办法
但是可以写在html里，加上contenteditable，可以在页面中改变文档样式（当前）

2.2 顺序

  1. 字母顺序
    目前，仍然没有记住26个字母的顺序。（记过几次，仍然是计划中要掌握的必备技能）
  2. 先后性
    定位，显示，字体颜色，背景，其他（动画、content、z-index）
    现在已经没有css4，css5，标准已经按模块划分了。
    找过模块，还是熟悉目前逻辑性的先后性风格

2.3 注释

具体见 [css注释风格.css];

/**
* 多行注释
* 1. Correct the line height in all browsers.
*/

/* 块级注释
========================================================================== */

其它：
在css中什么是最好的注释

2.4 简写

避免过度简写（具体案例忘了，以下只是一个提示性代码）

background:url("./images/icon.png") no-repeat left;
background:#8f3;//背景图被覆盖
div { margin:0;padding:0; }//避免浏览器无关的重新计算
...

2.5 命名

  1. 可以有驼峰：动词短语.fadeOut,多个单词拼接短语.arv_fullscreenButton
  2. 可以有下划线，划分组件元素 .armplaylistControl_bar

有的建议，都小写，用 —连接；但对于我这么复杂的项目，有点难堪
复杂：JS，css中都要区分命名空间，css中公共原子也定义了命名空间

2.6 数值

  1. 0px 后面没有px
  2. 小数点 0 都不需要写
  3. 颜色 尽量一种风格 hls(a)？rgb(a)？; #333等简写

2.7 ID

不推荐ID，即少用ID

2.8 嵌套

层次少对浏览器友好

三 其他规范

前面部分，有些在pdf中是存在的

3.1 残存的pdf

模块（化）思想
同JS三层：base，common，pages
命名空间

  1. 原子层，不需要命名空间（多人协作）；
    只在pages层，做命名空间（多人协作）
  2. 可以驼峰，下划线 (B_E)
    M,应该是给了粒子了

    《编写高质量代码–Web前端开发修炼之道》。该书久远：推单行，reset.css

思考:

  1. 高粒度，一个样式可能需要多个原子类
    可复用 VS 精简，不可兼得
  2. 所以，抽出了common层？？
  3. 单个，className可能会很长

3.2 BEM

.nav{}
.nav__item{}
.nav--blue{}

以下摘：https://www.zhihu.com/question/21935157

  1. 这么长，影响书写效率吧。肯定会影响但这是个很大的问题吗（自动提示会缓解一些）
  2. html和css的size肯定会大一些。size大的顾虑是影响传输，在gzip面前可以忽略
  3. 不爽。的确很违背习惯，但任何个人喜好和习惯作借囗都不职业 风格不重要。

我更关心它的好处：

  1. SCSS嵌套过多。超过3层就很难阅读了。
  2. 嵌套多，选择器的层级就会多，性能不知不觉变差
  3. 复用。这么长的名，想冲突都难
    还有一个代码设计上的原则，不暴露抽象类。举例：

这样更符合编程的特点。重要的是在维护上。假如变样了需要继承另一个抽象类，不需要改html，只要改css。这样SoC更彻底。
风格无非是某种形式，可以约束人做到一致。背后的设计思想才值得应用。如果用BEM的风格，但没做到抽象类的封装，没做到选择器的扁平，那就是失败的应用。
最后，我非常认同这种设计思想。但我还是不会照搬它的命名规则。太TM囧了！

作者：张克军
链接：https://www.zhihu.com/question/21935157/answer/19836373

反对这种命名方式的人，大多举了个例子——如果我想将一个f30的类，改成f35怎么办？是挂羊头卖狗肉的直接将.f30{font-size:30px}改成.f30{font-size:35}吗？还是要进行全局搜索，改动所有的html的class名？
长命名有非常多的好处，“抽象”和“避免冲突”，避免“选择符权重竞赛”等等，上面克军的回答很清晰，我就不赘述了。

css预编译语言配合嵌套的做法好不好我不知道，bem好不好我也不知道，我只是知道如果有人说出“性能问题”四个字，那他已经赢了、而且还是立于不败之地那种……根本没办法讨论。
然后，我不喜欢bem。太长了符号太多辣眼睛。

个人认为如果已经使用了 SCSS 或者 LESS 之类的，再用这种写法就没有意义了。以模块化的命名方式更好，可以参考网易的 NEC 命名方式。

强大的命名规范可以让我们的代码更容易阅读和理解，也更容易控制，虽然这种命名方式看起来有点儿奇怪

NEC相关：略过
http://blog.csdn.net/chen_zw/article/details/47908475
https://segmentfault.com/a/1190000007956424

3.3 OOCSS

3.4 atomic css

3.5 css in js

3.

四 现写项目中的规则

4.1 play.asp 中arvplayer.less

1 videojs 都是 - 连接

.video-js  .vjs-volume-panel.noVolumeContr.vjs-volume-panel-horizontal.vjs-slider-active
.vjs-menu li.vjs-menu-title
  1. 命名空间vjs，
  2. E和M都是 - 连接： vjs-volume-panel-horizontal

2 arvplayer.less

  1. JS中用arv_做命名空间;又用到CSS样式中，分离不同区块内容 

    .arv_fullscreenButton
.arv_setting
.arv_bigPlayButton

  2. arv-做命名空间，也是使用 - 连接；
    这里没有通用样式

    arv-note-control，arv-fullscreen-exit， arv-tip-enabled，

  3. 驼峰，一个是上面JS中.arv_bigPlayButton ；
    另一个是动词短语，所以驼峰写一起了（这里可以接受，《编写高-》没有说不使用驼峰）

    arv-fadeOut

    20:03


    2018.1.31 三 长_天 09:43

4.2 mobile/channel.php channel.less

1 略jj

  1. 移动端一个页面(channel.php),考虑到多页面复用，重构以前样式：用了arm-做命名空间，定义了通用样式
    PS:通用样式不需要命名空间，但是担心现在做的样式会和之前的冲突，使用命名空间写起来方便
  2. 在定义JS中变量，方法名时，使用命名空间/arm[a-z]*/表示移动端变量，方法， ar表示pc端共用移动端的变量或方法。（原始页面(channel.php,playlist.php) 并没有这样的考虑）
    鉴于上述JS中命名空间，使用到了css中

2 具体

  1. arm- 做命名空间，表示可以通用的样式

  2. 修饰符 - 连接

    arm-list，arm-full-top，arm-chevron-up
arm-blink，
#armplayerNote  .armplayerNote-content

  3. #armplayerNote ，ID做了区块划分，-表示了样式 

    .armplayerNote-content 表示 armplayerNote下属的content样式
    1. 为什么没有用 . 做区块划分：怕不明显吧 haha。包括#armchatroom,
    2. #armplayerNote-close：只在JS使用，表示唯一，方便查找元素

  4. 同样的#armplaylistControl定义了区块，_代表元素 

    .armplaylistControl_title，.armplaylistControl_bar 表示该块的title，bar 元素

  5. 同样的,下面这些 -content表示该快下的内容样式 

    .armcomment-content,.armnote-content   
.armstudio-content ,.armsubscribe-content
    1. 这些内容是在search.php中的，之前是使用的.arm_comment,.arm_note,现在变为.armcomment-content;
    2. 这些内容没有使用ID来定义块，即没有#armcomment,#armnote（.armcomment-content是一个列表，有多个comment）;
    3. 还有.armsearchItem这样一个类，和.armplaylistControl_title相同
    4. 原来有.arm-content ，并没有指出属于那一块的content；最开始的时候只是定义了一个通用样式

    .armstudio-content有些符合NEC的味道

  6. 还有一类下划线，抄袭了原来的命名风格，做了区块划分，在channel.php

    #ch_home，#ch_videos，ch_playlists，ch_channels   
#author_uploads，#author_popular_uploads，
#arm_playlists，#arm_channels  
.arm_navs

    11:43


    17:20

  7. 基于原子类，重新定义了.arm-full-top , .arm-full-close

    .arm-full      .arm-full-top        .arm-full-left   
arm-full_close .arm-full_close-top  .arm-full_close-left
    1. .arm-full-top , .arm-full-close 显然考虑了其他全屏方向
    2. 最后介于都是top，才有了最原始的定义
    3. 定义左边全屏后，逻辑也明显有了不同（都是top逻辑也不同，但可复用）。可以整块移动，也提升性能

4.3 chatroom/armchat.less

  1. 虽然可以是新的项目，也使用arm-定义了命名空间，代表公共的可以复用的基本样式

    .arm-li2 li
.arm-tab

  2. 使用- 做连接

    .arm-dot-topLeft
.arm-tab_title-active1

  3. 重新定义了 .arm-tabTitle ,arm-tabContainer

    .arm-tab_title,arm-tab_container

    原来不知道受什么影响，用了驼峰，不能明确表达组件间关系了

  4. 驼峰的使用

    #armchat
#armchatPublic，#armchatParticipate
#armchatInput

  5. 另类，body.arm-chat-full

    1. #armchatroom在上一级页面(aculive.php)定义了iframe；虽然可用，还是为了避免冲突，何况JS中也使用

    2. 也没有很多个页面需要标识本页面。
      所以body无法以#armchatroom ID的形式标识,定义了一个.arm-chat的原子类，-full表示修饰

      body.arm-chat-full

4.4 混合，acuviewer.php和aculive.php中play.asp

  1. 开始只有playerNote全屏，定义了.arm-full,.arm-full-close
  2. 出了全屏聊天，为了复用注释，即使逻辑不同，定义了相同了.arm-full-top,.arm-full-close
  3. 再全屏聊天，pc上要左半边，移动已经全屏了，.arm-full-left,.arm-full-full
    因为开始的.arm-close，又多了.arm-full_close-left,.arm-full_close-full;
    忧伤，有没有太长，？和定义在层级下比较呢

4.5 其它

  1. 即使用了less，也没有依赖嵌套，编译后多于4层的很少
  2. 没有使用mixin，@import
    $_TODO:使用mixin
  3. armchat.php中，响应式 全屏，定义了变量（绝对定位，非fixed）

五 总结

so，css规范：

  1. 驼峰、下划线均可以使用 BA_E-M; BA_E-M BA_E-M1 BA_E-M2; BA BA-M1 BA-M2
  2. 尽量少用ID；除了划分区块，JS中需要
  3. 公共/原子类，是不需要命名空间的；除非命名空间是用来划分作用域，比如：font20,w30,..
  4. 项目需要，是否构建一个原子类css库，或者只是些common层和pages层
  5. 尽量减少层级嵌套

18:10

A [CSS 样式书写规范]

原文

$_PS: 既然md，就都cc；修正标题越级2->4

编码设置

采用 UTF-8 编码，在 CSS 代码头部使用：

1
@charset "utf-8";

注意，必须要定义在 CSS 文件所有字符的前面（包括编码注释），@charset 才会生效。

例如，下面的例子都会使得 @charset 失效：

1
2
/* 字符编码 */
@charset "utf-8";
1
2
3
4
5
6
html,
body {
  height: 100%;
}

@charset "utf-8";

命名空间规范

  • 布局：以 g 为命名空间，例如：.g-wrap 、.g-header、.g-content。
  • 状态：以 s 为命名空间，表示动态的、具有交互性质的状态，例如：.s-current、s-selected。
  • 工具：以 u 为命名空间，表示不耦合业务逻辑的、可复用的的工具，例如：u-clearfix、u-ellipsis。
  • 组件：以 m 为命名空间，表示可复用、移植的组件模块，例如：m-slider、m-dropMenu。
  • 钩子：以 j 为命名空间，表示特定给 JavaScript 调用的类名，例如：j-request、j-open。

命名空间思想

没有选择 BEM 这种命名过于严苛及样式名过长过丑的规则，采取了一种比较折中的方案。

不建议使用下划线 _ 进行连接

  • 节省操作，输入的时候少按一个 shift 键
  • 能良好区分 JavaScript 变量命名

字符小写

定义的选择器名，属性及属性值的书写皆为小写。

在xhtml标准中规定了所有标签、属性和值都小写，CSS 书写也应该遵循此约定。

选择器

当一个规则包含多个选择器时，每个选择器独占一行。

、+、~、> 选择器的两边各保留一个空格。

1
2
3
4
.g-header > .g-header-des,
.g-content ~ .g-footer {
    
}

命名短且语义化良好

对于选择器的命名，尽量简洁且具有语义化，不应该出现 g-abc 这种语义模糊的命名。

规则声明块

  • 当规则声明块中有多个样式声明时，每条样式独占一行。
  • 在规则声明块的左大括号 { 前加一个空格。
  • 在样式属性的冒号 : 后面加上一个空格，前面不加空格。
  • 在每条样式后面都以分号 ; 结尾。
  • 规则声明块的右大括号 } 独占一行。
  • 每个规则声明间用空行分隔。
  • 所有最外层引号使用单引号 ‘ 。
  • 当一个属性有多个属性值时，以逗号 , 分隔属性值，每个逗号后添加一个空格，当单个属性值过长时，每个属性值独占一行。

完整示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
.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: '';
}

数值与单位

  • 当属性值或颜色参数为 0 - 1 之间的数时，省略小数点前的 0 。

    color: rgba(255, 255, 255, 0.5)

    color: rgba(255, 255, 255, .5);

  • 当长度值为 0 时省略单位。

    margin: 0px auto

    margin: 0 auto

  • 十六进制的颜色属性值使用小写和尽量简写。

    color: #ffcc00

    color: #fc0

样式属性顺序

单个样式规则下的属性在书写时，应按功能进行分组，并以 Positioning Model > Box Model > Typographic > Visual 的顺序书写，提高代码的可读性。

  • 如果包含 content 属性，应放在最前面；
  • Positioning Model 布局方式、位置，相关属性包括：position / top / right / bottom / left / z-index / display / float / …
  • Box Model 盒模型，相关属性包括：width / height / padding / margin / border / overflow / …
  • Typographic 文本排版，相关属性包括：font / line-height / text-align / word-wrap / …
  • Visual 视觉外观，相关属性包括：color / background / list-style / transform / animation / transition / …

Positioning 处在第一位，因为他可以使一个元素脱离正常文本流，并且覆盖盒模型相关的样式。盒模型紧跟其后，因为他决定了一个组件的大小和位置。其他属性只在组件内部起作用或者不会对前面两种情况的结果产生影响，所以他们排在后面。

合理使用使用引号

在某些样式中，会出现一些含有空格的关键字或者中文关键字。

font-family 内使用引号

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

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

background-image 的 url 内使用引号

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

1
2
3
div {
  background-image: url('...');
}

避免使用 !important

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

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

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

代码注释

单行注释

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

1
/* 表格隔行变色 */

多行注释

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

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

规则声明块内注释

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

1
2
3
4
.foo{
    border: 0;
    // ....
}

文件注释

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

1
2
3
4
5
6
7
/**
 * @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 引用。如：

1
2
3
4
5
6
7
8
%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 结构：

1
2
3
4
5
6
7
8
<div class="g-content">
    <ul class="g-content-list">
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
    </ul>
</div>

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

1
2
3
4
5
6
7
.g-content {
  .g-content-list {
    li {
      ...
    }
  }
}

或者是

1
2
3
4
5
6
7
.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）的规则，这么做是为了使样式规则能够更快地与渲染树上的节点匹配。

我觉得不同的规范都有各自的长处与缺陷，对待所谓的规范最好的方式不是人云亦云，拿来就用，而是应该结合实际情况及需求，取长补短，取其精华去其糟粕。

B [在 css 中什么是好的注释]

英文：Keith J. Grant 译文：众成翻译/KING
zcfy.cc/article/thoughts-on-self-documenting-css

Robert C. Martin写的《Clean Code》是我读过的最好的编程书籍之一，若没有读过，推荐你将它加入书单。

注释就意味着代码无法自说明 —— Robert C. Martin

不好： 块分隔注释

对CSS而言，块分隔注释是非常特殊的，如下：

/* -----------------
* TOOLTIPS
* ----------------- */

但事实上，很长很长的CSS文件已经不再流行了。若你的项目确实需要这种很大的CSS文件，它应该是由多个小的部分，通过CSS预处理工具组合而成的。

不好：解释语法

注释应该解释“为什么”，而不是“是什么”，即说明原因而不是说明作用（Why, not what）。

此处有一个例外，由于CSS有很多属性，也许有些属性是你完全不知道的，那么你用这种注释是正常的。

不好：对库进行介绍

不好: 过时的注释

有时有用的：有特殊意义的注释

因为有时候代码的意图不是那么显而易见的。

但此时也需要问一个问题：有什么办法能让代码自说明呢？需要可以考虑将这些特定的属性移到第二个选择器中，专门为这些按钮设置的选择器。

好：注解难懂的补丁性的代码

一些工具如KSS , 会在CSS文件中创建一些样式规范。如下：

/*
Alerts
An alert box requires a contextual class to specify its importance.
一个警告信息框需要与语境有关的的类来指定其重要性

Markup:
<div>
Take note of this important alert message.
</div>

alert-success - Something good or successful 好的或成功的
alert-info - Something worth noting, but not super important 不那么重要的
alert-warning - Something to note, may require attention 需要被提示并记录，需要引起注意的
alert-danger - Something important. Usually signifies an error. 非常重要的，常用于错误

Styleguide Alerts
*/

这不仅仅是注释，这是规范，它能被KSS解析并用于生成HTML。这已经算是项目文档的一部分了，而且不得不说，这比手动创建一个分离的HTML文件要好很多，因为其在同一个文件内且始终与代码相匹配。

另外一种指令式注释为许可信息，当使用第三方库并在注释中注明许可信息时，一般都需要包含。

而我贴出Robert Martin关于注释的话时，似乎应该解释一下，但我没有那么做。因为我认为这是一句容易理解的话，若你还在代码中到处写注释，那么请先思考是否合理。

C [这些 CSS 命名规范，将省下你大把调试时间]

原文
译文

使用连字符分隔的字符串

但问题是这种命名法并不适用于 CSS。

这是一种非常标准的 CSS 命名规范。也可以说更易读。
同时，这也和 CSS 属性名称保持了一致。

BEM 命名规范

为何要使用命名规范？

在计算机科学当中只有两类难题：缓存失效和命名 - Phil Karlton

和 JavaScript 关联的 CSS 名称

1. 使用 js- 类名

2. 使用 Rel 属性

一般来说，rel 属性 定义着链接资源和引用它的文件之间的关系。

<link rel="stylesheet"type="text/css"href="main.css">
//
<div class="site-navigation" rel="js-site-navigation"></div>
const nav = document.querySelector("[rel='js-site-navigation']")

我对这种方法持保留态度。

3. 别用数据属性（data attributes）

有些开发者用数据属性（data attributes）作为 JavaScript 钩子。这是不对的。根据定义，data 属性（data attributes）是用来 储存自定义数据（to store custom data） 的。

附加提议：写更多的 CSS 注释

这是因为 CSS 不是最简洁优雅的『语言』，有条理的注释可以让你花更少时间来理解自己的代码。
有益无弊，何乐不为。

你可以看看 Bootstrap 的注释写得有多好。

D [编写现代 CSS 代码的 20 个建议]

原文

  1. 明白何谓Margin Collapse
  2. 使用Flexbox进行布局
  3. 使用CSS Reset
  4. 一切应为Border-box
  5. 以背景图方式使用Images
  6. Better Table Borders
  7. 注释格式优化

  8. 使用Kebab-case命名变量
    对于样式类名或者ID名的命名都需要在多个单词之间添加-符号，CSS本身是大小写不敏感的因此你是用不了camelCase的，另一方面，很久之前也不支持下划线，所以现在的默认的命名方式就是使用-:

    而涉及到具体的变量命名规范时，建议是使用BEM规范，只要遵循一些简单的原则即可以保证基于组件风格的命名一致性。你也可以参考CSS Tricks来获得更多的细节描述。

  9. 避免重复代码
  10. 使用transform添加CSS Animations
  11. 不要重复造轮子
  12. 尽可能使用低优先级的选择器
  13. 避免使用!important
  14. Em, Rem, 以及 Pixel
  15. 在大型项目中使用预处理器
  16. 使用Autoprefixers来提升浏览器兼容性
  17. 在生产环境下使用Minified代码
  18. 多参阅Caniuse
  19. Validate:校验

A- 浏览器默认样式

2018.2.22 二 14:40

https://www.jianshu.com/p/f7018b32ca4a

浏览器都拥有一套自己的默认样式。
浏览器之所以有默认样式表，是为了没有样式表的页面也能凑活着看。
不同浏览器；以及版本不同的浏览器的默认样式一般都是不同的。

重置样式表

为了保证页面在不同浏览器中显示的尽可能的一致，我们会重置不同浏览器默认的样式，称为重置样式表。

有很多别人整理的不错的重置样式表，例如CSS Reset ， strppd.css，normalize.css。我比较喜欢和推荐的是normalize.css。
normalize.css:https://github.com/necolas/normalize.css
css reset:https://meyerweb.com/eric/tools/css/reset/index.html
strppd.css:http://iainspad.com/strppd-css/

一些资源

IE的默认样式:https://www.iecss.com/
Firefox的默认样式:https://hg.mozilla.org/mozilla-central/file/tip/layout/style/html.css
($_PS: Mercurial > mozilla-central / error)
WebKit的默认样式:http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css
浏览器默认样式对比表:http://developer.doyoe.com/default-style/

14:45

knowledge is no pay,reward is kindness
分享到： 收藏夹 复制网址 邮件 微信 QQ空间 腾讯微博 豆瓣 一键分享 更多
0%