How to use CSS SASS styles

This time I will show you how to use the SASS style of CSS, and what are the precautions for using the SASS style of CSS. The following is a practical case, let's take a look.

As more and more developers use SASS, we need to pay attention to the number of SASS codes. We can start from the syntax of CSS (cascading style sheets) to explain some of the special features of SASS syntax. After all, CSS style guides are very common.

This article mainly introduces some features that I am personally interested in. You may be able to benefit from them and form your own set of SASS usage guides.

Continue to maintain your own commonly used CSS formatting rules and style guides

This article focuses on discussing some content about SASS, but on this basis, developers should maintain their existing and good formatting rules. . If you haven’t developed your own set of formatting rules yet, here’s a review of some style guides that should help you develop your own CSS writing habits. Here are just some of the contents included:

1. Keep line indentations consistent

2. Keep the number of spaces before and after colons/braces consistent
3. Keep one selector per line , one rule per line
4. Try to write related attributes together
5. For class name naming rules, have a plan
6. Avoid using CSS
id selector 7 . Wait

Next we will learn how to write beautiful SASS code, taking writing a .weather class attribute as an example:

First list @extend(s)

.weather {   
  @extends %module;    
  ...   
}

This can enable developers to maintain a clear idea, be able to immediately know the relationship between this class and its attributes and other classes and their attributes, and maintain the consistency of attributes and a clear idea of ​​attribute reuse.

Normal style

.weather {   
  @extends %module;    
  background: LightCyan;   
  ..   
}   
　　@include(s)   
.weather {   
  @extends %module;    
  background: LightCyan;   
  @include transition(all 0.3s ease-out);   
  ...   
}

This allows developers to see the deployment of @extend(s) and @include(s) at a glance, making it easier for themselves and other developers to interpret the code. You may also decide in some cases whether to distinguish between custom @includes and public-source @includes (especially considering code reusability and timeliness)

Selector nesting

.weather {   
  @extends %module;    
  background: LightCyan;   
  @include transition(all 0.3s ease);   
  > h3 {   
    border-bottom: 1px solid white;   
    @include transform(rotate(90deg));   
  }   
｝

Within nested sections, continue to use the above style rules. Nested parts should always come last.

Use @mixins for all vendor prefixes

Vendor prefixes (CSS prefixes) are very time-sensitive. Due to updates to modern browsers, these prefixes will be used less and less. You can adapt to these changes by updating the contents of your mixins (or some libraries used in your mixins will be updated automatically). Even if the mixin is only one line, it doesn't matter.

But when the privatization of some vendor prefixes is very serious, these prefixes will be very difficult to standardize and applying other prefixes or unprefixed versions will not be worth the gain. I will choose to abandon @mixin these vendor prefixes. For example -webkit-line-clamp, -mscontent-zoom-chaining or similar situations.
Don’t nest more than 3 levels

.weather {   
  .<span style="width: auto; height: auto; float: none;" id="14_nwp"><a style="text-decoration: none;" mpid="14" target="_blank" href="http://cpro.baidu.com/cpro/ui/uijs.php?adclass=0&app_id=0&c=news&cf=1001&ch=0&di=128&fv=0&is_app=0&jk=be9ebff1476c47c4&k=cities&k0=cities&kdi0=0&luki=6&n=10&p=baidu&q=06011078_cpr&rb=0&rs=1&seller_id=1&sid=c4476c47f1bf9ebe&ssp2=1&stid=0&t=tpclicked3_hc&tu=u1922429&u=http%3A%2F%2Fwww%2Eadmin10000%2Ecom%2Fdocument%2F2137%2Ehtml&urlid=0" id="14_nwl"><span style="color:#0000ff;font-size:14px;width:auto;height:auto;float:none;">cities</span></a></span> {   
    li {   
      // no more!   
    }   
  }   
}

If you nest more than three times, you are likely to write a cheating (bad?) selector. The reason for the cheating is that the selector relies too much on the structure of HTML (unstable), is too detailed (the function is too powerful and has no flexibility), or the reusability is too poor (not very usable). At the same time, too many nesting levels can easily lead to code that is obscure and difficult to understand.

If sometimes there is too much code related to a class, you have to use the

tag selector. You may need to be very specific about a class to avoid unnecessary cascading. Even if possible, use extend to take advantage of some of the reusability features in CSS.

.weather   
  > h3 {   
    @extend %line-under;   
  }   
}

Nested code should not exceed 50 lines

If there are more than 50 lines of nested code in SASS, it is likely that it will not be fully displayed on one page of the compiler. , this will make the code difficult to read and understand. Nesting is originally intended to facilitate and simplify thinking and code organization. If it violates readability, please do not nest.

The global and regional SASS file sequences are equivalent to the table content

In other words, they do not have any fixed style. Developers should remind themselves to keep the style of all parts consistent and orderly.

List the vendor/global libraries first, then list the custom libraries, then the modes, and finally the libraries used by each division.

The 'directory' will look like the following example, which is clear at a glance:

 /* Vendor Dependencies */  
@import "compass";   
    
/* Authored Dependencies */  
@import "<span style="width: auto; height: auto; float: none;" id="10_nwp"><a style="text-decoration: none;" mpid="10" target="_blank" href="http://cpro.baidu.com/cpro/ui/uijs.php?adclass=0&app_id=0&c=news&cf=1001&ch=0&di=128&fv=0&is_app=0&jk=be9ebff1476c47c4&k=global&k0=global&kdi0=0&luki=9&n=10&p=baidu&q=06011078_cpr&rb=0&rs=1&seller_id=1&sid=c4476c47f1bf9ebe&ssp2=1&stid=0&t=tpclicked3_hc&tu=u1922429&u=http%3A%2F%2Fwww%2Eadmin10000%2Ecom%2Fdocument%2F2137%2Ehtml&urlid=0" id="10_nwl"><span style="color:#0000ff;font-size:14px;width:auto;height:auto;float:none;">global</span></a></span>/colors";   
@import "global/mixins";   
    
/* Patterns */  
@import "global/tabs";   
@import "global/modals";   
    
/* Sections */  
@import "global/header";   
@import "global/footer";

These files are like a compass, colors and mixins are not generated compiled CSS code, they are purely standalone libraries. Patterns were introduced after this to make rewriting safer without specificity conflicts.

Reasonably split SASS into multiple small files

　　这样做没有任何不好。在情况允许的时候，尽量使用小而精的多个文件，这样便于开发者在寻找一些特定文件，而不是在几个拥有冗长代码的大文件中大海捞针。
 

...
@import "<span style="width: auto; height: auto; float: none;" id="9_nwp"><a style="text-decoration: none;" mpid="9" target="_blank" href="http://cpro.baidu.com/cpro/ui/uijs.php?adclass=0&app_id=0&c=news&cf=1001&ch=0&di=128&fv=0&is_app=0&jk=be9ebff1476c47c4&k=global&k0=global&kdi0=0&luki=9&n=10&p=baidu&q=06011078_cpr&rb=0&rs=1&seller_id=1&sid=c4476c47f1bf9ebe&ssp2=1&stid=0&t=tpclicked3_hc&tu=u1922429&u=http%3A%2F%2Fwww%2Eadmin10000%2Ecom%2Fdocument%2F2137%2Ehtml&urlid=0" id="9_nwl"><span style="color:#0000ff;font-size:14px;width:auto;height:auto;float:none;">global</span></a></span>/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中，’//’非常适用于添加注释，’//’使得注释和取消注释变得非常方便。
　　将一些常用的数值和有特殊意义的数值转化成变量

　　如果你发现自己重复使用一个数值（这在前端设计里是很常见的），你最好将它转化成一个变量。这样你可以通过命名来提醒自己这个数值的含义，并且在编写代码时保持一致性，是的你在更改这个数值时不需要逐行调整。

　　若果一个数字有着明显的含义，那么将它转化成变量是必不可少的啦。

相信看了这些案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

相关阅读：

HTML的代码书写有哪些规范

Html+css怎样实现纯文字和带图标的按钮

在XHTML中的标题标签与段落标签有哪些使用方法

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