CSS

CSS 发展史 上图是20 世纪 90 年万维网刚出现时，由于当时并没有可以装饰网页的方法，原始的 Web 页面呈现的效果，随着 CSS（层叠样式表，Cascading Style Sheets）的诞生与发展，Web页面的样式有了翻天覆地的变化。 CSS的发布过程 CSS1.0 19912月W3C发布了第一个有关样式的标准CSS1.0。这个版本中，已经包含了的相关font的相关属性、颜色与背景的相关属性、文字的相关属性、box的相关属性等。 CSS2.0 1985年5月，CSS2.0正式推出。这个版本推荐的是内容和表现效果分离的方式，并开始使用样式表结构。 CSS2.1 2004年2月，CSS2.1正式推出。它在CSS2.0的基础上略微做了改动，删除了许多不被浏览器支持的属性 CSS3 从2011年开始CSS被分为多个模块单独升级。这些模块统称为CSS3 包含有： CSS 选择器level3 CSS 媒体查询level3 CSS color level3 CSS4 设计中 CSS 标准的制定大概有下面几个步骤 下面主要介绍的是与我们日常工作有关联的一些新特性，其中一些已经在主流浏览器中得到了支持，还有一些特性还在草案阶段，可能还会有一些变化。 CSS 伪类选择器 is()和where() 在编写css时，有时会需要使用很长的选择器列表来定位具有相同样式的子元素，比如对所有H元素下的span设置为block，之前会这么写: 这样写选择器看起来很长，可读性差。 此时，可以使用is()来提高易读性，同时避免使用长选择器 浏览器支持: :is() Chrome 88/ Firefox 78/ Edge 88 /Safari 14 :where() Chrome 88/ Firefox 78/ Edge 88 /Safari 14 注意： is()和where()在使用方法上和其他的伪类选择器一样，可以任意组合排列。 is()和where()的功能大体上是一样的，他们的差异性体现在选择器的权重上 where()选择器没有权重，也就是权重是0 is()选择器的权重由它的选择器列表中的最搞权重决定 规则示例: ...

导读 移动端适配，是我们在开发中经常会遇到的，这里面可能会遇到非常多的问题： 1px问题 UI图完美适配方案 iPhoneX适配方案 横屏适配 高清屏图片模糊问题 … 上面这些问题可能我们在开发中已经知道如何解决，但是问题产生的原理，以及解决方案的原理可能会模糊不清。在解决这些问题的过程中，我们往往会遇到非常多的概念：像素、分辨率、PPI、DPI、DP、DIP、DPR、视口等等，你真的能分清这些概念的意义吗？ 本文将从移动端适配的基础概念出发，探究移动端适配各种问题的解决方案和实现原理。 一、英寸 一般用英寸描述屏幕的物理大小，如电脑显示器的17、22，手机显示器的4.8、5.7等使用的单位都是英寸。 需要注意，上面的尺寸都是屏幕对角线的长度： 英寸(inch,缩写为in)在荷兰语中的本意是大拇指，一英寸就是指甲底部普通人拇指的宽度。 英寸和厘米的换算：1英寸 = 2.54 厘米 二、分辨率 2.1 像素 像素即一个小方块，它具有特定的位置和颜色。 图片、电子屏幕（手机、电脑）就是由无数个具有特定颜色和特定位置的小方块拼接而成。 像素可以作为图片或电子屏幕的最小组成单位。 下面我们使用sketch打开一张图片： 将这些图片放大即可看到这些像素点： 通常我们所说的分辨率有两种，屏幕分辨率和图像分辨率。 2.2 屏幕分辨率 屏幕分辨率指一个屏幕具体由多少个像素点组成。 下面是apple的官网上对手机分辨率的描述： iPhone XS Max 和 iPhone SE的分辨率分别为2688 x 1242和1136 x 640。这表示手机分别在垂直和水平上所具有的像素点数。 当然分辨率高不代表屏幕就清晰，屏幕的清晰程度还与尺寸有关。 2.3 图像分辨率 我们通常说的图片分辨率其实是指图片含有的像素数，比如一张图片的分辨率为800 x 400。这表示图片分别在垂直和水平上所具有的像素点数为800和400。 同一尺寸的图片，分辨率越高，图片越清晰。 2.4 PPI PPI(Pixel Per Inch)：每英寸包括的像素数。 PPI可以用于描述屏幕的清晰度以及一张图片的质量。 使用PPI描述图片时，PPI越高，图片质量越高，使用PPI描述屏幕时，PPI越高，屏幕越清晰。 在上面描述手机分辨率的图片中，我们可以看到：iPhone XS Max 和 iPhone SE的PPI分别为458和326，这足以证明前者的屏幕更清晰。 由于手机尺寸为手机对角线的长度，我们通常使用如下的方法计算PPI: iPhone 6的PPI为 ...

1. 什么是原子化CSS 1.1 基本概念 原子化CSS(Atomic CSS) 近年来热度逐渐增加，与原子化CSS相关的库在Github上也收获上万的Star。那么什么是原子化CSS呢，引用文章 Let’s Define Exactly What Atomic CSS is 中定义：“原子化CSS是一种CSS架构方式，其支持小型、单一用途的类，其名称基于视觉功能。” 更加通俗的来讲，原子化CSS是一种新的CSS编程思路，它倾向于创建小巧且单一用途的class，并且以视觉效果进行命名。举个简单的例子： <!-- 原子化类定义 --> <style> .text-white { color: white; } .bg-black { background-color: black; } .text-center { text-align: center; } </style> <!-- 原子化类使用 --> <div class="text-white bg-black text-center">hello Atomic CSS</div> 1.2 VS 行内样式 看到以上的示例，你可能很快就想到，直接使用行内样式不是更好吗，还省去了原子类的定义。这个问题可以从样式编写、一致性、功能、和缓存四个方面来回答。 在样式编写层面，CSS预处理和后处理器很大程度上依赖单独的样式表，原子化CSS可以充分利用Sass、Less等CSS预处理器功能进行样式的编写，同时可以借助PostCSS进一步增强CSS的功能。而对于行内样式，虽然在技术上支持使用预处理和后处理器对其进行处理，但很少有成熟的工具对此提供支持和维护。 在一致性层面，原子化CSS框架一般有预定义的设计系统，开发者仅能在设计系统中选择要设置的值。而对于行内样式或者传统CSS类定义来说，可设置的值是没有任何限制的。对于行内样式或者传统的CSS类设置来说，一个标签的字体大小可能是14px或0.875rem，当产品（or 客户）说需要调小一点时，开发者A可能调整为13px，开发者B可能调整为12px。但对于原子化CSS框架来说，调小一点意味着设置的类从text-sm变为text-xs。 以下为部分采用传统CSS类编写的网站样式统计数据（统计来源）： 掘金官网：283种背景颜色 471种字体颜色 264种字体大小 GitLab：1199种背景颜色 1351种字体颜色 450种字体大小 CSDN：585种背景颜色 1190种字体颜色 504种字体大小 在功能方面，原子化CSS本质上还是CSS类，因此支持媒体查询功能，也支持对元素的悬停、聚焦等状态进行处理，而内联样式缺少这部分的能力。 在打包方面，内联样式包含在JS文件中，样式的修改会导致整个bundle的改变，原子化CSS样式定义和JS逻辑分离，修改元素的class属性可能并不影响（在没有新CSS类的情况下）最终打包输出样式文件。 2. 谁在使用原子化CSS 截至目前已经有部分网站借鉴或者使用原子化CSS的思想重构了自己的web网站，比较知名的网站有Facebook、Twitter、Github、swipperjs等。根据网上公开的信息，Facebook在使用原子化CSS思想重构之后，仅登录页面的413KB样式文件，减少为整个站点的74KB。 Facebook ...

BFC 是前端面试中经常会被问到的一个知识点，今天就来带大家深入了解下什么是 BFC 以及它的作用。 文档流 在介绍BFC之前，需要先给大家介绍一下文档流。 我们常说的文档流其实分为定位流、浮动流、普通流三种。 绝对定位(Absolute positioning) 如果元素的属性 position 为 absolute 或 fixed，它就是一个绝对定位元素。 在绝对定位布局中，元素会整体脱离普通流，因此绝对定位元素不会对其兄弟元素造成影响，而元素具体的位置由绝对定位的坐标决定。 它的定位相对于它的包含块，相关CSS属性：top、bottom、left、right； 对于 position: absolute，元素定位将相对于上级元素中最近的一个relative、fixed、absolute，如果没有则相对于body； 对于 position:fixed，正常来说是相对于浏览器窗口定位的，但是当元素祖先的 transform 属性非 none 时，会相对于该祖先进行定位。 浮动 (float) 在浮动布局中，元素首先按照普通流的位置出现，然后根据浮动的方向尽可能的向左边或右边偏移，其效果与印刷排版中的文本环绕相似。 普通流 (normal flow) 普通流其实就是指BFC中的FC。FC(Formatting Context)，直译过来是格式化上下文，它是页面中的一块渲染区域，有一套渲染规则，决定了其子元素如何布局，以及和其他元素之间的关系和作用。 在普通流中，元素按照其在 HTML 中的先后位置至上而下布局，在这个过程中，行内元素水平排列，直到当行被占满然后换行。块级元素则会被渲染为完整的一个新行。 除非另外指定，否则所有元素默认都是普通流定位，也可以说，普通流中元素的位置由该元素在 HTML 文档中的位置决定。 BFC 概念 先看下MDN上关于BFC的定义： 块格式化上下文（Block Formatting Context，BFC） 是Web页面的可视CSS渲染的一部分，是块盒子的布局过程发生的区域，也是浮动元素与其他元素交互的区域。 具有 BFC 特性的元素可以看作是隔离了的独立容器，容器里面的元素不会在布局上影响到外面的元素，并且 BFC 具有普通容器所没有的一些特性。 通俗一点来讲，可以把 BFC 理解为一个封闭的大箱子，箱子内部的元素无论如何翻江倒海，都不会影响到外部。 除了 BFC，还有： IFC（行级格式化上下文）- inline 内联 GFC（网格布局格式化上下文）- display: grid FFC（自适应格式化上下文）- display: flex或display: inline-flex 注意：同一个元素不能同时存在于两个 BFC 中。 ...

大家可能觉得，z-index 是一个很简单的属性，你给它设置哪个值，元素就会位于 y 轴的哪个位置。但它实际上并没有我们想象的这么简单，这个属性背后是一系列决定元素所在层级的规则。 在进行今天的介绍前，我们先列出三个问题，如果你能一眼看出它们的解决方案，那么恭喜你掌握了z-index，也就不需要阅读本文了；如果不行，那么耐心看完本文，相信能找到答案。 三个自测问题 问题一：为什么z-index 数值更大，但 Content 没有在 Box 2 之上？ <div id="box1"> Box 1 </div> <div id="content"> Content <br/> z-index: 2; </div> <div id="box2"> Box 2 <br/> z-index: 1; </div> div { padding: 25px; font-size: larger; } #box1 { background-color: chocolate; width: 200px; height: 100px; margin-bottom: -50px; } #content { background-color: gold; width: 300px; height: 200px; z-index: 2; } #box2 { background-color: cyan; width: 200px; height: 100px; margin-top: -50px; z-index: 1; } 问题二：明明 z-index 数值更小，为什么 Content 这次反而在Box 2 之上了？ <div id="box1"> Box 1 </div> <div id="content"> Content <br/> transform: rotate(90deg); <br/> z-index: 1; </div> <div id="box2"> <br/> Box 2 <br/> z-index: 2; </div> div { padding: 25px; font-size: larger; } #box1 { background-color: chocolate; width: 200px; height: 100px; margin-bottom: -10px; } #content { background-color: gold; width: 250px; height: 200px; z-index: 1; transform: rotate(90deg); } #box2 { background-color: cyan; width: 200px; height: 100px; margin-top: -10px; z-index: 2; } ...

如果问，CSS 中 position 属性的取值有几个？大部分人的回答大概是 static、relative、absolute、fixed，实际上MDN上还有一个 sticky。 今天我们就来给大家介绍这个容易被忽视的position属性值 sticky。 先来看看MDN上对于 sticky 的介绍： 粘性定位元素（stickily positioned element）是计算后位置属性为 sticky 的元素。 粘性定位可以被认为是相对定位和固定定位的混合。 什么是结合两种定位功能于一体呢？ 元素在跨越特定阈值前为相对定位，之后为固定定位。 也就是元素先按照普通文档流定位，然后相对于该元素在流中的 flow root（BFC）和 containing block（最近的块级祖先元素）定位。 元素定位表现为在跨越特定阈值前为相对定位，之后为固定定位。 这个特定阈值指的是 top、right、bottom 或 left 之一，换言之，指定 top、right、bottom 或 left 四个阈值其中之一，才可使粘性定位生效。否则其行为与相对定位相同。 示例 上面的文字描述估计还是很难理解，看看下面这张 GIF 图，想想要实现的话，使用 JS + CSS 的方式该如何做： 按照常规做法，大概是监听页面 scroll 事件，判断每一区块距离视口顶部距离，超过了则设定该区块 position:fixed，反之去掉。 而使用 position:sticky ，则可以非常方便的实现： <div class="container"> <div class="sticky-box">内容1</div> <div class="sticky-box">内容2</div> <div class="sticky-box">内容3</div> <div class="sticky-box">内容4</div> </div> .container { background: #eee; width: 600px; height: 1000px; margin: 0 auto; } .sticky-box { position: sticky; height: 60px; margin-bottom: 30px; background: #ff7300; top: 0px; } div { font-size: 30px; text-align: center; color: #fff; line-height: 60px; } 看看上面的 CSS 代码，只是给每个内容区块加上 ...

前言 随着互联网发展至今，对于网站来说，性能显的越来越重要了，CSS作为页面渲染和内容展现的重要环节，影响着用户对整个网站的第一体验。所以，我们需要重视与CSS相关的性能优化。 项目开发初期我们可能因为各种原因（很大一部分原因是因为项目工期，产品往往把项目上线时间卡的死死的，根本不听你说的什么性能优化），怎么写的舒服就怎么来，对于性能优化我们常常在项目完成时才去考虑，经常被推迟到项目的末期，甚至到暴露出严重的性能问题时才进行性能优化。 为了更多地避免这一情况，首先要重视起性能优化相关的工作，将其贯穿到整个产品设计与开发中。其次，就是了解性能相关的内容，在项目开发过程中，自然而然地进行性能优化。 css渲染规则 想要优化CSS的性能，我们首先需要了解CSS的渲染规则，CSS选择器是从右向左进行匹配的 来看个例子🌰： .nav h3 a{font-size: 14px;} 渲染过程大概是：首先找到所有的a，沿着a的父元素查找h3，然后再沿着h3，查找.nav。中途找到了符合匹配规则的节点就加入结果集。如果找到根元素html都没有匹配，则不再遍历这条路径，从下一个a开始重复这个查找匹配（只要页面上有多个最右节点为a）。 Tips：为什么CSS选择器是从右向左匹配的？ CSS中更多的选择器是不会匹配的，所以在考虑性能问题时，需要考虑的是如何在选择器不匹配时提升效率。从右向左匹配就是为了达成这一目的的，通过这一策略能够使得CSS选择器在不匹配的时候效率更高。这样想来，在匹配时多耗费一些性能也能够想的通了。 内联首屏关键CSS（Critical CSS） 性能优化中有一个重要的指标——首次有效绘制（First Meaningful Paint，简称FMP）即指页面的首要内容（primary content）出现在屏幕上的时间。这一指标影响用户看到页面前所需等待的时间，而 内联首屏关键CSS（即Critical CSS，可以称之为首屏关键CSS） 能减少这一时间。 很多人都喜欢通过link标签引用外部CSS文件。但需要知道的是，将CSS直接内联到HTML文档中能使CSS更快速地下载。而使用外部CSS文件时，需要在HTML文档下载完成后才知道所要引用的CSS文件，然后才下载它们。所以说，内联CSS能够使浏览器开始页面渲染的时间提前，因为在HTML下载完成之后就能渲染了。 但是我们不应该将所有的CSS都内联在HTML文档中，因为[初始拥塞窗口]存在限制（TCP相关概念，通常是 14.6kB，压缩后大小），如果内联CSS后的文件超出了这一限制，系统就需要在服务器和浏览器之间进行更多次的往返，这样并不能提前页面渲染时间。因此，我们应当只将渲染首屏内容所需的关键CSS内联到HTML中。 ⚠️还有一点需要注意的是内联CSS没有缓存，每次都会随HTML的加载而重新下载，但我们将内联首屏关键CSS控制在 14.6kB以内，它对性能优化还是起到正向作用的。（凡事有利也有弊） 异步加载非首屏CSS 我们需要知道两点内容：（具体可以看我之前的文章：这些浏览器面试题，看看你能回答几个？） CSS不会阻塞DOM的解析，但会阻塞DOM的渲染 CSS会阻塞JS执行，但不会阻塞JS文件的下载 由于CSS会阻塞DOM的渲染，所以我们将首屏关键CSS内联后，剩余的非首屏CSS内容可以使用外部CSS，并且异步加载，防止非首屏CSS内容阻塞页面的渲染。 CSS异步加载方式 第一种方法是动态创建 // 创建link标签 const myCSS = document.createElement( "link" ); myCSS.rel = "stylesheet"; myCSS.href = "mystyles.css"; // 插入到header的最后位置 document.head.insertBefore( myCSS, document.head.childNodes[ document.head.childNodes.length - 1 ].nextSibling ); 第二种方法是将link元素的media属性设置为用户浏览器不匹配的媒体类型（或媒体查询） 对浏览器来说，如果样式表不适用于当前媒体类型，其优先级会被放低，会在不阻塞页面渲染的情况下再进行下载。在首屏文件加载完成之后，将media的值设为screen或all，从而让浏览器开始解析CSS。 <link rel="stylesheet" href="mystyles.css" media="noexist" onload="this.media='all'"> 第三种方法是通过rel属性将link元素标记为alternate可选样式表 <link rel="alternate stylesheet" href="mystyles.css" onload="this.rel='stylesheet'"> 第四种方法是使用rel=preload来异步加载CSS <link rel="preload" href="mystyles.css" as="style" onload="this.rel='stylesheet'"> 注意，as是必须的。忽略as属性，或者错误的as属性会使preload等同于XHR请求，浏览器不知道加载的是什么内容，因此此类资源加载优先级会非常低。as的可选值可以参考上述标准文档。 看起来，rel="preload"的用法和上面两种没什么区别，都是通过更改某些属性，使得浏览器异步加载CSS文件但不解析，直到加载完成并将修改还原，然后开始解析。 但是它们之间其实有一个很重要的不同点，那就是使用preload，比使用不匹配的media方法能够更早地开始加载CSS。所以尽管这一标准的支持度还不完善，仍建议优先使用该方法。 CSS文件压缩 这应该是最容易想到的一个方法了，通过压缩CSS文件大小来提高页面加载速度。现在的构建工具，如webpack、gulp/grunt、rollup等也都支持CSS压缩功能。压缩后的文件能够明显减小，可以大大降低了浏览器的加载时间。 CSS层级嵌套最好不要超过3层 一般情况下，元素的嵌套层级不能超过3级，过度的嵌套会导致代码变得臃肿，沉余，复杂。导致css文件体积变大，造成性能浪费，影响渲染的速度！而且过于依赖HTML文档结构。这样的css样式，维护起来，极度麻烦，如果以后要修改样式，可能要使用!important覆盖。尽量保持简单，不要使用嵌套过多过于复杂的选择器。 删除无用CSS代码 一般情况下，会存在这两种无用的CSS代码：一种是不同元素或者其他情况下的重复代码，一种是整个页面内没有生效的CSS代码。 对于前者，在编写的代码时候，我们应该尽可能地提取公共类，减少重复。对于后者，在不同开发者进行代码维护的过程中，总会产生不再使用的CSS的代码，当然一个人编写时也有可能出现这一问题。而这些无用的CSS代码不仅会增加浏览器的下载量，还会增加浏览器的解析时间，这对性能来说是很大的消耗。所以我们需要找到并去除这些无用代码。 那么我们如何知道哪些CSS代码是无用代码呢？ 谷歌的Chrome浏览器就有这种开箱即用的功能。只需转到查看>开发人员>开发人员工具，并在最近的版本中打开Sources选项卡，然后打开命令菜单。然后，点击Coverage，在Coverage analysis窗口中高亮显示当前页面上未使用的代码。 慎用*通配符 我们有时候可能会写下面这种代码来消除一些标签的默认样式或统一浏览器对标签渲染的差异化： *{ margin：0； padding：0; } 这样虽然代码量少，但它的性能可不是最佳的，我们最好还是写对应的标签选择器： ...

大部分 Web 开发者都知道 CSS 中有一个盒模型，但很少有人知道在 CSS 的世界中还有另一个模型，他就是 CSS 的视觉格式化模型。 CSS 视觉格式化模型（英文称之Visual Formatting Model）。该模型主要是用来处理在视觉媒体上显示文档时使用的计算规则。仅从这一句话来描述，估计很多同学都会感到困惑，视觉格式化模型到底是什么鬼？大家先不用急着知道视觉格式化模型是什么，只需要知道它是 CSS 中很重要的一部分，如果理解了该部分所涉及到的知识点，将有助于你更好的理解和学习 CSS，特别是 Web 布局 什么是视觉格式化模型 在盒模型中我们了解到，在 CSS 的世界中，任何一个元素都是一个盒子，它具有一个专业术语，即盒模型。而视觉格式化模型会根据 CSS 盒模型将文档中的元素转换为一个个盒子。看到这里，很多同学可能更会感到困惑，“任何元素都是一个盒子，视觉格式化模型将元素转换为盒子，那这盒子是不是都是一样的盒子呢”？ 首先要声明一点：视觉格式化模型和CSS盒模型不是同一个东西！ 简单点说呢。Web 页面（文档树）是由很一个个盒子组成（因为任何元素都可以被视为是一个盒子），而视觉格式化模型却是一套规则，用来计算元素转换为盒子的规则。而页面的布局都由这些盒子的所处的各处位置组合而成。那么理解了元素怎么转成盒子的规则，就理解了 Web 页面是怎么布局。而每个盒子的布局主要由以下几个因素决定： 盒子的尺寸：精确指定、由约束条件指定或没有指定 盒子的类型：行内盒子（inline）、行内级盒子（inline-level）、原子行内级盒子（atomic inline-level）和块盒子（block） 定位方案：普通流定位、浮动定位或绝对定位 文档树中的其它元素：即当前盒子的子元素或兄弟元素 视窗尺寸与位置 所包含的图片的尺寸 其他的某些外部因素 先来看一张图，这个图是由下面的 HTML 结构构造出来的： <body> <header> <nav></nav> </header> <article> <p></p> <figure></figure> <p></p> </article> <aside></aside> <footer></footer> </body> 每个元素都是一个盒子，盒子中可以包含另一个或多个盒子。也正如上图所示，CSS 的视觉格式化模型会根据盒子的包含块（Containing Block，即包含其他盒子的块）的边界来渲染盒子。通常，盒子会创建一个包含其后代元素的包含块，但是盒子并不会被包含块限制住，盒子的布局会撑破包含块（即跑出包含块的边界），对于这种现象，在 CSS 中常被称为溢出。 溢出是一个很有意思的东东，在 Web 布局中时常会碰到，但在这一章中不做方面的阐述。 ...

前言 在项目中经常存在如下问题： 1.模块拆分不合理 2.变量和函数命名不知所云 3.缺少注释或者是写了一堆描述不清的内容 4.重复的代码遍布各个角落等 因为这些不良的编程习惯，导致了项目越来越难以维护，程序性能越来越低，大大降低了日常的工作效率以及提高了公司的开发成本。 下面就以CSS在Vue3项目中的架构为切入点，通过减少CSS代码的冗余度和增强CSS代码的维护性、扩展性来提高我们的编程能力和项目架构能力。 CSS的设计模式 在学习CSS架构之前，我们先简单看一下常见的5种CSS设计模式，这些设计模式都为我们的CSS架构提供了一定的开发思路。 1.OOCSS模式 OOCSS(Object-Oriented CSS)字面意思是面向对象的CSS，在开发中它有如下的规范约定 减少对 HTML 结构的依赖 # bad # 1.匹配效率低，影响css性能 # 2.和html耦合度高，维护性和扩展性低 .container-list ul li a {} <div class="container-list"> <ul> <li> <a>...</a> </li> </ul> </div> # good .container-list .list-item {} <div class="container-list"> <ul> <li> <a class="list-item">...</a> </li> </ul> </div> 增加样式的复用性 .label { # 公共代码 } .label-danger { # 特定代码 } .label-info { # 特定代码 } <div> <p class="label label-danger"></p> <p class="label label-info"></p> </div> 2.BEM模式 BEM 是进阶版的OOCSS，是一个分层系统，它把我们的网站分为三层，这三层正好对应着 BEM 三个英文单词的简写 block, element, modifier，分为为 块层、元素层、修饰符层。 ...

前言 花样不断的前端，貌似多技术方案并行，已经成了家常便饭。 从大的框架开始，已经分裂react与vue派系。两者思维上虽然有相互不断的借鉴，但在大的方向思维上却是截然不同。而在react与vue的竞争以及相互较量的过程中，往往把其他的对手都干倒了，现在市场angular，jQuery等都逐步没落。 预编译css也同样，曾经也有多个派系。而后在sass与less的不断竞争中，stylus等其他的编译器也逐步退出市场。本文的重点，对比预编译css，scss与less对比。 基本介绍 先一起看看官方是如何定义或者介绍他们。 Sass 官方定义： Sass是一种基于Ruby的CSS预处理器，它可以扩展CSS语言，并添加许多其他功能，如变量、嵌套规则、Mixin、函数等。Sass文件以“.scss”扩展名保存，与标准CSS文件兼容，并且可以使用普通CSS代码和语法。Sass也有一个较早的语法格式，以“.sass”扩展名保存，使用缩进的语法来代替括号和分号，但它现在已经不那么流行了。 个人理解： sass是第一个流行的CSS预处理器，在2006年产生，这也为后续他用户量第一埋下伏笔。 Scss 官方定义： Scss也是一种基于Ruby的CSS预处理器，它与Sass有很多相似之处，但是它的语法更接近标准CSS，使用花括号和分号。它是一种非常流行的CSS预处理器，与Sass相比，它更容易学习和使用，并且与现有的CSS代码更兼容。 个人理解： Scss是Sass的一种语法格式，由2007推出。这还要从sass的规范语法说起，最典型的就是Sass使用缩进来表示代码块。这使部分使用者比较别扭。而产生了Scss，基于花括号和分号的CSS语法格式，使得它更易于阅读和理解。随着时间的推移，Scss逐渐取代了Sass作为Sass的主要语法格式。 Less 官方定义： Less是一种基于JavaScript的CSS预处理器，它与Sass和Scss有很多相似之处，但它使用类似CSS的语法，并且更容易学习和使用。Less支持变量、Mixin、嵌套规则等功能，并且可以在客户端和服务器端使用。 个人理解： Less由2009推出，也是提供了一套完整的生态链。它的语法跟sass不同。Less的学习成本更低，更容易理解和编写。此外，Less的编译速度比Sass更快。 Stylus 官方定义： Stylus是一种基于JavaScript的CSS预处理器，它与Less、Sass和Scss有很多相似之处，但它的语法非常灵活，可以自由选择使用缩进或花括号来表示嵌套和块。Stylus还支持变量、Mixin、函数等功能，并且具有非常强大的插件系统，可以轻松地扩展其功能。 个人理解： Stylus也是曾经一个比较完善的预编译语言。 但市场份额却原来越少。个人的观点，一是的学习成本高一些，有入门的门槛。而是生态链的问题，sass跟less的有较完善的生态链，而Stylus更像一个独立的东西。 PostCSS 官方定义： PostCSS不是一种独立的CSS预处理器，而是一个CSS处理工具集合，可以通过各种插件扩展其功能。PostCSS可以用于转换CSS语法、提供自动前缀、压缩CSS代码、处理嵌套规则、优化图片等。它不像其他预处理器那样提供自己的语言，而是基于现有的CSS语法。使用PostCSS可以通过插件来实现更多的自定义和灵活性，使其成为一个强大的CSS处理工具。 个人理解： 跟上述的其他的处理器不同，PostCSS不应该算是一个预处理器，但却是我们做适配，压缩等处理时的一个选择。 数据分析 市场占有率分析 我们借助npm官网统计工具对比，查看less与scss的数据量对比： 链接： npm-stat.com/charts.html… npm-stat.com/charts.html… 如上图，左侧为less的数据，右侧为scss的数据。 我们可以通过统计清晰的看到。单单一个sass的下载量，基本达到less的两倍以上。此处还不包含sass阵营的其他工具，包括node-scss，dart-scss的下载量。 可以得出结论：sass的使用量约为less的几倍。（但此处有个值得一提的地方：统计为全球的用户量的统计，并非针对国内） 组件库选择分析 从上述的数据中，我们了解到sass的使用量较多，但是国内出名的组件库，却是less居多。毕竟组件库，也代表我们的使用习惯之一。我们一起看看组件库的选择。 ant design 选择了Less，地址：www.antdv.com/docs/vue/cu… element 选择了scss，地址：element.eleme.io/#/zh-CN/com… varlet 选择了Less，地址：varlet.gitee.io/varlet-ui/#… vant 选择了Less，地址：vant-contrib.gitee.io/vant/v3/#/z… 结论：关于组件库的选择，Less还是占大多数，当然Scss也是部分组件库的选择。 个人分析 相同点 都属于css语法编译的工具。 工具提供的方法也很多雷同。如都支持嵌套，都支持混合器（Mixin），都支持扩展（Extend），都支持颜色函数，都支持变量等等。 生态链都一致丰富，常用构建工具都基本支持，如webpack，vite, rollup等。 社区支持都强，提供了大量的插件、工具和资源，可以帮助开发者更好地使用Sass。 目的性也一致，都提高了CSS编写的效率和可维护性而产生。 不同点 部分语法不同，如Sass 和 SCSS 中的变量使用 $ 符号进行定义和引用，而不是 Less 中使用的 @ 符号 Sass 和 Scss 还提供了一些 Less 没有的特性，例如控制流语句和继承等。 Sass 和 Scss 是基于Ruby或者Dart，Node的预处理器，他需要借助机器安装这些环境来支持。而Less, 是基于JavaScript的CSS预处理器，引入一段JS即可编译，有浏览器还是服务端，他都能编译。 虽然都有强大的社区，生态链。但总体还是Scss更丰富一些。 特性分析 Node-Sass 在国内有一定的兼容性问题，但是基于Dart 语言编写的 Dart Sass以及解决了这个问题。还在使用Node-Sass的建议切换Dart Sass。 Less 的语法相对于 Sass 更加简洁，易于学习和理解。这使得 Less 在国内开发者中更受欢迎，尤其是对于那些不太熟悉预处理器语言的开发者来说。 Sass的阵营更丰富，使用量更高一些，市场份额也更加稳定。除了发家早，这也得益于生态圈，例如 Bootstrap、Foundation、Bulma、Vue.js 等，都在曾经的版本自带了Sass。 国内组件库，还是Less居多，很多"高级前端"， 都觉得less 一直都比 sass 要稳定。至少不会出现Node版本，Python版本不一致等问题。 结语 所以Sass与Less谁更强？估计短期还是分不出成败。 ...