这次给大家带来css的sass样式应该怎么使用，css的sass样式使用的注意事项有哪些，下面就是实战案例，一起来看一下。
随着越来越多的开发者使用SASS，我们有必要关注一下SASS的代码的个数问题。 我们可以从CSS（层叠样式表）的语法出发，来解释SASS语法的一些特别之处，毕竟，CSS样式指南是很常见的。
这篇文章主要介绍了我个人比较感兴趣的一些特性，也许能够让你从中受用，形成一套属于自己的SASS使用指南。
继续保持自己常用的CSS格式规则和样式指南
这篇文章着重讨论了关于SASS的一些内容，但是在此基础上，开发者应该保持自己已有并且良好的格式规则。如果你还没有发展出一套属于自己的格式规则，那么这里有一些样式指南的综述，应该可以帮你形成属于自己的CSS编写习惯。这里仅列出一些其中所包含的部分内容：
1. 保持行缩进一致
2. 保持冒号/大括号前后空格数的一致
3. 保持一行一个选择器，一行一个规则
4. 相关的属性尽量写在一起
5. 对于类名命名规则由一个规划
6. 避免使用CSS id选择器
7. 等等
立即学习“前端免费学习笔记（深入）”；
接下来我们就了解一下如何写出美观的SASS代码吧，以编写一个.weather类的属性为例：
首先列出@extend(s)
.weather { @extends %module; ... }
这样做能够使开发者保持一个清晰的思路，能够立刻知道这个类与其属性和其他类及其属性的关系，保持属性的一致和属性重用的清晰思路。
普通样式
.weather { @extends %module; background: LightCyan; .. } @include(s) .weather { @extends %module; background: LightCyan; @include transition(all 0.3s ease-out); ... }
这样做能够使开发者一眼看出@extend(s)和@include(s)的部署，便于自己以及其他开发者对代码的解读。你可能还会对是否区分自定义的@includes和公共来源的@includes在有些情况下做出决定（尤其是考虑到代码的可重用性和时效性）
选择器嵌套
.weather { @extends %module; background: LightCyan; @include transition(all 0.3s ease); > h3 { border-bottom: 1px solid white; @include transform(rotate(90deg)); } ｝
在嵌套部分内，继续使用上述的样式规则。嵌套的部分永远都应该放在最后。
所有厂商前缀使用@mixins
厂商前缀（CSS前缀）具有非常强的时效性。 由于现代浏览器的更新，这些前缀的使用将越来越少。你可以通过更新mixins里的内容（或者在你mixin里用到的一些库将自动更新）去适应这些变化。 哪怕mixin只有短短一行，也没有关系。
但当某些厂商前缀的私有化非常严重时，这些前缀将非常难以标准化并且应用其他前缀或者无前缀的版本会得不偿失，我会选择放弃@mixin这些厂商前缀。比如像-webkit-line-clamp， -mscontent-zoom-chaining或者类似情形。
嵌套的层次不要超过3层
.weather { .cities { li { // no more! } } }
如果你的嵌套多余三次，你很有可能写出一个坑爹的（差劲的？）选择器。坑爹的原因不外乎这个选择器过于依赖HTML的架构（不稳定）， 过于详细（功能过于强大，没有弹性），或者是可重用性太差（不太可用）。同时，过多的嵌套层次容易导致代码处于晦涩难懂的境地。
如果有的时候与类相关的代码真的太多了，使得你不得已使用标签选择器。你可能需对于某个类要写的非常具体，以避免不必要的层叠。 甚至有可能的话，利用extend来使用CSS里一些可重用性的特性。
.weather > h3 { @extend %line-under; } }
嵌套的代码不要超过50行
若果SASS里的嵌套多于50行，那么它很可能不能完整的显示在编译器的一页中，这样会导致代码不易阅读，难以理解。嵌套本来是为了方便和简化思考与代码的组织。如果有违阅读性，请别嵌套。
全局与区域化的SASS文件序列相当于表格内容
换言之，它们并没有任何一种固定样式。开发者要提醒自己保持所有部分的样式风格一致，有序。
首先列出厂商/全局的库，其次列出自定义库，然后是模式，最后是每个分部的用到的库。
这样一来‘目录‘看起来就像下面这个例子一样，一目了然：
/* Vendor Dependencies */ @import "compass"; /* Authored Dependencies */ @import "global/colors"; @import "global/mixins"; /* Patterns */ @import "global/tabs"; @import "global/modals"; /* Sections */ @import "global/header"; @import "global/footer";
这些文件就像是一个指南针，颜色和mixins并不产生已编译好的CSS代码，他们纯粹是独立的库。在此之后引入模式，使得重写变得更安全，不会出现专一性的冲突。
将SASS合理的分割成多个小文件
这样做没有任何不好。在情况允许的时候，尽量使用小而精的多个文件，这样便于开发者在寻找一些特定文件，而不是在几个拥有冗长代码的大文件中大海捞针。
...@import "global/header/header/"; @import "global/header/logo/"; @import "global/header/dropdowns/"; @import "global/header/nav/"; @import "global/header/really-specific-thingy/";
我经常做的就是在一个全局scss文件中逐个引用这些文件，而不是引用一个_header.scss文件，然后再_header.scss文件中在逐个引用。这样做能够降低索引的时间和提高阅读效率。
当这些文件过多导致import序列太长时，你可能会用到 Globbing 。
记得将Partials命名为_partial.scss
这是一个常见对于不能自身编译的文件的命名。这样的文件多少会依赖于其他的文件，使得自身不能独立完成编译。我个人喜欢在文件名之前添加一个下划线，譬如_dropdown-menu.scss
在本地编译时添加行映射
看这里，这意味着开发工具能够告诉你每一条规则的来源，哪怕是一个被引入的partial文件。
在部署时，记得编译已精简的文件
运行中的网页永远都只需要使用精简的CSS。
无需递交.css文件
这可能要花些时间，但是不在文件库中放入.css文件可以是一件非常美妙的事. 文件编译在部署的时候就完成了。 所以唯一可以看见的是那些已经精简的格式美妙的sass文件。 这使得对于文件的描述变得大有用途。文件描述是用于对比由版本发布者所做的一些更改。而对于已经精简的.css文件，文件描述基本不需要了。
大方的使用注释
很少有人会后悔在代码中留下了注释。不论是有用的还是不起眼的注释，他们最终都会在编译成精简的CSS文件时被抹去，对于开发者来说不会有任何附加代价。
.overlay { /* modals are 6000, saving messages are 5500, header is 2000 */ z-index: 5000; }
提到注释，你可能也需要对它做一些标准化的调整。在SASS中，’//’非常适用于添加注释，’//’使得注释和取消注释变得非常方便。
将一些常用的数值和有特殊意义的数值转化成变量
如果你发现自己重复使用一个数值（这在前端设计里是很常见的），你最好将它转化成一个变量。这样你可以通过命名来提醒自己这个数值的含义，并且在编写代码时保持一致性，是的你在更改这个数值时不需要逐行调整。
若果一个数字有着明显的含义，那么将它转化成变量是必不可少的啦。
相信看了这些案例你已经掌握了方法，更多精彩请关注创想鸟其它相关文章！
相关阅读：
HTML的代码书写有哪些规范
Html+css怎样实现纯文字和带图标的按钮
在XHTML中的标题标签与段落标签有哪些使用方法
以上就是CSS的SASS样式应该怎么使用的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1545629.html
微信扫一扫 
支付宝扫一扫 
