本篇内容主要讲解“CSS的SASS样式怎么使用”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“CSS的SASS样式怎么使用”吧!
创新互联专注于皇姑企业网站建设,自适应网站建设,商城网站建设。皇姑网站建设公司,为皇姑等地区提供建站服务。全流程按需定制网站，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务
以编写一个.weather类的属性为例：
首先列出@extend(s)
CSS Code复制内容到剪贴板
.weather {
@extends %module;
...
}
这样做能够使开发者保持一个清晰的思路，能够立刻知道这个类与其属性和其他类及其属性的关系，保持属性的一致和属性重用的清晰思路。
普通样式
CSS Code复制内容到剪贴板
.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在有些情况下做出决定（尤其是考虑到代码的可重用性和时效性）
选择器嵌套
CSS Code复制内容到剪贴板
.weather {
@extends %module;
background: LightCyan;
@include transition(all 0.3s ease);
> h4 {
border-bottom: 1px solid white;
@include transform(rotate(90deg));
}
｝
在嵌套部分内，继续使用上述的样式规则。嵌套的部分永远都应该放在最后。
所有厂商前缀使用@mixins
厂商前缀（CSS前缀）具有非常强的时效性。 由于现代浏览器的更新，这些前缀的使用将越来越少。你可以通过更新mixins里的内容（或者在你mixin里用到的一些库将自动更新）去适应这些变化。 哪怕mixin只有短短一行，也没有关系。
但当某些厂商前缀的私有化非常严重时，这些前缀将非常难以标准化并且应用其他前缀或者无前缀的版本会得不偿失，我会选择放弃@mixin这些厂商前缀。比如像-webkit-line-clamp， -mscontent-zoom-chaining或者类似情形。
嵌套的层次不要超过3层
CSS Code复制内容到剪贴板
.weather {
.
li {
// no more!
}
}
}
如果你的嵌套多余三次，你很有可能写出一个坑爹的（差劲的？）选择器。坑爹的原因不外乎这个选择器过于依赖HTML的架构（不稳定）， 过于详细（功能过于强大，没有弹性），或者是可重用性太差（不太可用）。同时，过多的嵌套层次容易导致代码处于晦涩难懂的境地。
如果有的时候与类相关的代码真的太多了，使得你不得已使用标签选择器。你可能需对于某个类要写的非常具体，以避免不必要的层叠。 甚至有可能的话，利用extend来使用CSS里一些可重用性的特性。
CSS Code复制内容到剪贴板
.weather
> h4 {
@extend %line-under;
}
}
嵌套的代码不要超过50行
若果SASS里的嵌套多于50行，那么它很可能不能完整的显示在编译器的一页中，这样会导致代码不易阅读，难以理解。嵌套本来是为了方便和简化思考与代码的组织。如果有违阅读性，请别嵌套。
全局与区域化的SASS文件序列相当于表格内容
换言之，它们并没有任何一种固定样式。开发者要提醒自己保持所有部分的样式风格一致，有序。
首先列出厂商/全局的库，其次列出自定义库，然后是模式，最后是每个分部的用到的库。
这样一来‘目录‘看起来就像下面这个例子一样，一目了然：
CSS Code复制内容到剪贴板
/* Vendor Dependencies */
@import "compass";
/* Authored Dependencies */
@import "
@import "global/mixins";
/* Patterns */
@import "global/tabs";
@import "global/modals";
/* Sections */
@import "global/header";
@import "global/footer";
这些文件就像是一个指南针，颜色和mixins并不产生已编译好的CSS代码，他们纯粹是独立的库。在此之后引入模式，使得重写变得更安全，不会出现专一性的冲突。
将SASS合理的分割成多个小文件
这样做没有任何不好。在情况允许的时候，尽量使用小而精的多个文件，这样便于开发者在寻找一些特定文件，而不是在几个拥有冗长代码的大文件中大海捞针。
CSS Code复制内容到剪贴板
@import "
@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中，’//’非常适用于添加注释，’//’使得注释和取消注释变得非常方便。
将一些常用的数值和有特殊意义的数值转化成变量
如果你发现自己重复使用一个数值（这在前端设计里是很常见的），你最好将它转化成一个变量。这样你可以通过命名来提醒自己这个数值的含义，并且在编写代码时保持一致性，是的你在更改这个数值时不需要逐行调整。
若果一个数字有着明显的含义，那么将它转化成变量是必不可少的啦。
CSS Code复制内容到剪贴板
$zHeader: 2000;
$zOverlay: 5000;
$zMessage: 5050;
.header {
z-index: $zHeader;
}
.overlay {
z-index: $zOverlay;
}
.message {
z-index: $zMessage;
}
这些数字可能会被储存在单个文件中以@imported形式导入。这样的方式使得你能够对于所有的z-index或者其他变量做一个统一管理
将色彩转化成变量
除了黑与白。很多色彩都不会只是用一次，哪怕你认为你不会再用到它了。但如果你将它转化成一个变量，你可能发现在其他地方也会用到。对于色彩的变量，在sass中有color functions 可以处理他们，例如 lighten()和darkern()。这使得你对于整体的色彩控制变得简易（一次修改，一劳永逸）
嵌套并命名你的媒体库
在sass里嵌套媒体库的功能意味着1.你不必要在其他地方重写选择器而引发不必要的错误；2.你所重写的规则规则变得清晰明了，而当这些代码在你css代码的末端或其他文件中时，这将会变得非常混乱。
CSS Code复制内容到剪贴板
.sidebar {
float: rightright;
width: 33.33%;
@include bp(mama-bear) {
width: 25%;
}
}
将Shame放在最后
在你的全局样式表中，在最后引入一个_shame.scss文件。
CSS Code复制内容到剪贴板
@import "compass"
...
@import "shame"
到此，相信大家对“CSS的SASS样式怎么使用”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！