发表于: 2019-10-11 23:14:25

2 1069


参考:Sass开发指南:(https://www.sasscss.com/sass-guidelines/

一、编写原则

  1. 1. Sass原则https://www.sasscss.com/sass-guidelines/syntax/

尽量远离Sass中介绍@extend的一般经验法则——他们有些是迷惑人

避免不必要的嵌套,只有限制样式在后代选择器才要;

理想上,每行保持为80个字符宽度,对于值列表,尽量为一行,如超过80个字符,则每个值占一行;

强力建议在入口文件中通过 @charset 指令使用 UTF-8 编码格式,即@charset 'utf-8';

Sass 中字符串应该始终被单引号(')或双引号所包裹,css的标识符无需引号,如字符串里面有单引号或双引号,需要在引号前面加个\,如@warn 'You can\'t do that.';

当数字小于 1 时,应该在小数点前写出 0. 永远不要显示小数尾部的 0

当定义长度时,0 后面不需要加单位,赋予单位用乘法,如*1px,去除单位用除法;

最高级运算应该始终被包裹在括号中;

不需 @content 的混合宏在放在其他声明之前,需要 @content 的混合宏在嵌套选择器后声明;

建议嵌套不要超过三层,也建议尽量避免使用嵌套,但如伪类可以,相同子元素在不同父元素可以,相同前缀可以用&(父选择器)配合嵌套;

⑩① 列表可以使用圆括号进行分类,增加可读性;

 

  1. 2. css原则(https://codeguide.bootcss.com/#css-operators):

所有声明语句都应当以分号结尾;

以逗号分隔的属性值,每个逗号后面都应该插入一个空格;

十六进制值应该全部小写,例如,#fff

④ css声明顺序以类型(position, display, colors, font, miscellaneous...)顺序排列;

Positioning

Box model

Typographic

Visual

Misc

css相关联的选择器写在同一行,不相关联选择器分行书写,组成选择器的元素不要超过3个,只有在必要的时候才将 class 限制在最近的父元素内(也就是后代选择器);

将媒体查询放在尽可能相关规则的附近,sass则是放在内部;

对于只包含一条声明的样式,为了易读性和便于快速编辑,建议将语句放在同一行(包括大括号),多行声明则每个声明占一行;

尽量限制使用简写形式的属性声明,如margin、padding,要明确后缀;

尽量在样式表中添加注释,好的代码注释能够传达上下文关系和代码目的。不要简单地重申组件或 class 名称,要明确定义了什么样式,最好在代码完成之时立即注释;

    基本上,任何不能明显看出意义的地方都应该注释,但不要随处注释。记住不要注释太多,掌握尺度让每一处注释都有意义

在样式中避免使用#id,尽量不使用!important,通过添加和使用类名,比如.hidden类名;

对于经常出现的组件,避免使用属性选择器(例如,[class^="..."])。浏览器的性能会受到这些因素的影响,尽量使用重复的类;

 

  1. 3. class命名规则:

class 名称变量中只能出现小写字符和破折号(dashe)(不是下划线,也不是驼峰命名法)。破折号应当用于相关 class 的命名(类似于命名空间,最好增加项目名称简写做前缀)(例如,.btn 和 .btn-danger)。

避免过度任意的简写。.btn 代表 button,但是 .s 不能表达任何意思。

class 名称应当尽可能短,并且意义明确,如结构:css属性值-组件(元素)名称

使用有意义的名称。使用有组织的或目的明确的名称,不要使用表现形式(presentational)的名称。

基于最近的父 class 或基本(base) class 作为新 class 的前缀。

使用 .js-* class 来标识行为(与样式相对),并且不要将这些 class 包含到 CSS 文件中;

取名尽量和Bootstrap框架的组件接近;

尽量不要使用*这样的全局选择器;

常量则用全大写字符区分;

 

  1. 4. html原则:

不要在自闭合(self-closing)元素的尾部添加斜线 HTML5 规范 中明确说明斜线是可忽略的;

任何时候都要尽量使用最少的标签并保持最小的复杂度,减少多余的父标签,尽量避免JS生成的标签;

属性应用顺序,id要慎用:

class

id, name

data-*

src, for, type, href, value

title, alt

role, aria-*

布尔型属性可以在声明时不赋值;

根据 HTML5 规范,在引入 CSS JavaScript 文件时一般不需要指定 type 属性,因为 text/css text/javascript 分别是它们的默认值;

不要省略可选的结束标签,例如,</li> </body>

 

二、文件组件化(https://www.sasscss.com/sass-guidelines/architecture

  1.  1.  按bootstrap的文件分类,分为basemodulespages等文件并进一步细分,以_名称.scss文件保存,再在宿主sass文件通过@import引用,如在宿主sass文件头部加入注释;

 

  1. 2. 7-1模式,在一个sass文件夹里,应该包含7 个子文件夹,1 个宿主sass文件,:

abstracts/

包含了整个项目中使用到的 Sass 辅助工具,这里存放着每一个全局变量、函数、混合宏和占位符,如果项目比较大,可以以主题分类,即相关的分在其他文件夹里;

base/

存放项目中的模板文件。在这里,可以找到重置文件、排版规范文件或者一个样式表——定义一些 HTML 元素公认的标准样式,动画文件也放在其中;

components/

存放局部组件,包含各类具体模块,基本上是所有的独立模块,比如一个滑块、一个加载块、一个部件……由于整个网站或应用程序主要由微型模块构成;

layout/

存放构建网站或者应用程序使用到的布局部分。该文件夹存放网站主体(头部、尾部、导航栏、侧边栏...)的样式表、栅格系统甚至是所有表单的 CSS 样式;

pages/

如果页面有特定的样式,最好将该样式文件放进 pages/ 文件夹并用页面名字。例如,主页通常具有独特的样式

themes/

在大型网站和应用程序中,往往有多种主题。虽有多种方式管理这些主题;

⑦ vendors/

存放所有外部库和框架(Normalize, Bootstrap, jQueryUI, FancyCarouselSliderjQueryPowered……)的 CSS 文件,可以脱离责任;

如果你重写了任何库或框架的部分,建议设置第 8 个文件夹 vendors-extensions/ 来存放,并使用相同的名字命名

main.scss

作为宿主文件,唯一开头不用下划线命名的 Sass 文件,该文件不应该包含任何其他代码,通过@import来引用其他文件夹,按以下顺序,并编译为一个css文件;

abstracts/

vendors/

base/

layout/

components/

pages/

themes/

引用时遵循的规范:

每个 @import引用一个文件;

每个 @import单独一行;

从相同文件夹中引入的文件之间不用空行;

从不同文件夹中引入的文件之间用空行分隔;

忽略文件扩展名和下划线前缀,如:

@import 'vendors/bootstrap';

@import 'vendors/jquery-ui';

 

也可以:

每个文件夹只使用一个@import

每个@import之后都断行

每个文件占一行

新的文件跟在最后的文件夹后面

文件扩展名都可以省略,如:

@import

  'vendors/bootstrap',

  'vendors/jquery-ui';

 

如果文件夹里的文件增删比较多,则可以用通配符*一次性引入一个文件夹,如:

@import 'abstracts/*';

 

 

  1. 3.  组件遵循规范:

每个组件都应该拥有自己的文件夹,每个组件的样式应该包含以下内容:

组件本身的样式

和组件样式有关的变量、修饰器以及状态

如有需要,设置组件的子级样式

应该包含所有与组件相关的混合宏、变量、样式等,但应该避免对其他组件样式的引用;

 

制定一致的注释规范,如C语言注释,如下;

/**

 * Helper class to truncate and add ellipsis to a string too long for it to fit

 * on a single line.

 * 1. Prevent content from wrapping, forcing it on a single line.

 * 2. Add ellipsis at the end of the line.

 */

.ellipsis {

  white-space: nowrap; /* 1 */

  text-overflow: ellipsis; /* 2 */

  overflow: hidden;

}

 

使用一致的空白符将代码分隔成块;

 

几乎所有的接口都可以被视为小组件,都要符合以下要求:

可以做一件事,只做一件;

在整个项目中可以重用,具有可复用性;

各自独立。

 

三、响应式设计和断点

  1. 1. 命名断点:

不针对特定设备是安全可靠的做法。特别要指出的是,不应该赞成专门针对 iPad 或黑莓手机设计媒体查询;

媒体查询应该关注屏幕尺寸,直到当前设计遇到阻断而将所有工作过继给下一个媒体查询,尤其组件变形的临界点;

断点不应该用设备来命名,而应使用更通用的方式或者有意义的名称,如small、medium、large、huge;

  1. 断点管理:

使用maps来建立断点地图,通过map-get() 函数读取相应的断点,如:

$breakpoints: (

  'medium': (min-width: 800px),

  'large': (min-width: 1000px),

  'huge': (min-width: 1200px),

);

2. 建立断点应用的混合宏:

@mixin respond-to($breakpoint) {

  $raw-query: map-get($breakpoints, $breakpoint);

 

  @if $raw-query {

    $query: if(

      type-of($raw-query) == 'string',

      unquote($raw-query),

      inspect($raw-query)

    );

 

    @media #{$query} {

      @content;

    }

  } @else {

    @error 'No value found for `#{$breakpoint}`. '

         + 'Please make sure it is defined in `$breakpoints` map.';

  }

}

  1. 3. 媒体查询应用,应放在相关选择器里面,如:

.foo {

  color: red;

 

  @include respond-to('medium') {

    color: blue;

  }

}

 

 

四、工具https://www.sasscss.com/sass-guidelines/tools/

  1. 1. 最小程度的依赖于各种工具。管理依赖可能会是你特别不想面对的事情。此外,在 Sass 中很少需要外部依赖;

  2. 2. Compass不适合的原因:

很大程度上拖慢了 SassRuby Sass 本身就比较慢,所以在此之上增加更多功能并无益处;

完整的 Compass 是庞大的。混合宏的跨浏览器兼容功能也只是冰山一角。数学函数、图像辅助、幽灵图……使用这个优秀的工具有太多的好处了;

没有一个是杀手级的特性,精灵图生成器虽然非常优秀,但也会报出一两个错误。不过 Grunticon Grumpicon 就运行的很好,而且它们还有可以被插入到构建过程的优势;

不建议使用 Compass,但我也不会禁止使用它,特别是当它不兼容 LibSass 的时候(即使它正朝这个方向努力)。如果你感觉使用起来还不错,这当然可以,但是我认为最终你也不会从中收获更多;

 

  1. 3. 栅格系统

如果你正在项目中使用类似 Bootstrap Foundation CSS 框架,我建议善用它们来避免额外的依赖;

如果你尚未依赖于特定的栅格系统,那么也许会乐意了解这里介绍的两个由 Sass 支持的栅格引擎:Susy Singularity。它们都可以满足你的需求,所以只需从中挑选喜欢的一个来用即可并且可以放心即使是你的苛刻需求—哪怕是最多变的—也可以被实现;

或者你可以处理地更轻松些,就像使用 CSSWizardry Grids 的感觉。总而言之,任何选择都不会对你的代码风格有过多影响;

 

  1. 4. SCSS-lint(https://github.com/sds/scss-lint)

SCSS-lint 是一个帮你保持 SCSS 文件简洁而又具有可读性的工具。它是完全可定制化的,并且非常易于和其他工具集成;

建议阅读以下文章:《使用 SCSS-lint 审查你的 Sass 代码》, 《通过 theguardian.com 改善你的 Sass 代码质量》 和 《一份强制实施的 SCSS 代码规范》.

如果你想将 SCSS-lint 插入到 Grunt 构建过程中,那么 Grunt 插件 grunt-scss-lint 一定会对你有所帮助。

此外,如果你在寻找一个运行 SCSS-lint 的简洁工具,那么 Thoughtbot (Bourbon, Neat...) 正在开发的 Hound 也会对你有所帮助;


、总结

简而言之,本文主要包括以下几个方面的内容:

核心原则

  • 创建编程规范的目的就是为了保证协作开发的一致性。即使你对本文有不同的意见,也要保证整体开发的一致性。
  • 尽可能让 Sass 代码保持简洁。除非是绝对需要,否则绝没有必要构建复杂的系统。
  • 请记住,有时候保持简洁(KISS,Keep It Simple, Stupid)比减少重复(Don't Repeat Yourself)更重要。

语法 & 格式

  • 使用两个空格代表缩进,而不是使用tab键。
  • 理想上,每行保持为 80 个字符宽度。
  • 根据 CSS Guidelines 正确书写 CSS 属性。
  • 有意义的使用空格。

字符串

  • 强烈建议在样式表顶部使用 @charset 指令声明字符集。
  • 除非用作 CSS 标识符,否则应该使用单引号包裹字符串和 URL。

数值

  • 数字尾部不使用 0 ,并且强制在小于 1 的数字前使用 0。
  • 长度样式属性值为 0 时不要添加单位。
  • 使用括号包裹运算表达式。
  • 不使用幻数。

颜色

  • 颜色表示法的先后顺序:关键字 > HSL > RGB > 十六进制。
  • 当减淡或加深颜色时,最好使用 mix(..) 替代 darken(..)lighten(..)

列表

  • 使用逗号分隔列表。
  • 使用圆括号增加可读性。
  • 列表尾部不要添加逗号(当它们是内联状态时)。

Maps

  • 当 map 内部包含多个键值对时,将它们分成多行。
  • 为了增加可维护性,map 内部的最后一个键值对应该添加一个逗号。
  • 如果 map 的键是字符串,应该使用引号包裹起来。

声明顺序

  • 只要保持开发的一致性,无论哪种声明顺序(根据字母表或者类型排序)都是可以接受的。

选择器嵌套

  • 减少选择器嵌套。
  • 对伪类和伪元素使用选择器嵌套。
  • 媒体查询也可以嵌套到相关的选择器当中。

命名约定

  • 坚持连字符分隔的命名方式。

注释

  • CSS 中充满了机巧,当你有所疑问的时候,就应该写下相关的注释。
  • 对于变量、函数、混合宏和占位符创建的公开 API,使用 SassDoc 来注释。

变量

  • 在公开 API 中使用 !default 标志变量,让后期的修改更安全。
  • 不要在顶层使用 !global 标志,应为这可能会在未来和 Sass 语法有冲突。

扩展

  • 坚持扩展占位符,而不是扩展既有的 CSS 选择器。
  • 尽可能少地扩展占位符,避免潜在的副作用。



返回列表 返回列表
评论

    分享到