未来样式篇:不断被挑战的预编译工具

未来样式篇:不断被挑战的预编译工具

技术杂谈小彩虹2021-07-14 21:43:4150A+A-

未来不近不远,前端稍纵即逝

摘要

前端的未来必然离不开正在不断进化的样式处理,每一次的进化都为开发者和用户带来了优异的体验。这里要谈谈预编译器,现在的这项技术为我们的前端开发带来了极大的便捷和极方便的管理,然后这项技术在未来的标准中收到了一定的挑战,这也印证了一点,最终未来技术的趋势必然是现在开发者们所趋向使用的优秀的技术。

区别和关联

既然谈到CSS和预编译器,那么这里就会以未来的CSS及预编译器来作为一组参考,来看下他们的区别和关联。

我会以一个简单的样式写法,来阐述一下我的一下看法,这个简单的样式写法我相信大多数前端开发者都是熟练使用的。

CSS写法:

:root {    --primary-color: white;}.block__element {    background-color: var(--primary-color);}

Sass写法:(其他预编译器类似)

$primaryColor: white;.block__element {    background-color: $primaryColor;}

需要说明一下:这里的变量申明与实际引用的代码是分别在两个文件中的

就是这么一个简单的变量申明,你们是否会觉得没啥区别嘛,这么简单的东西也能拿来做例子?我们接着看下去。

当我们遇到一个需求,需要添加一套配色(或者布局,这里以配色为例),方案有很多种,因人而异,这里会有很多奇思妙想可以做到,但是通常的做法是我们会新建一个变量申明文件,将我们想要的新的配色方案写进去,然后在预编译阶段,通过一下代码调整让其输出多套配色方案的css文件,然后在业务端通过一些变量动态加载对应主题的样式文件,很简单对吧?没错,不论是用CSS还是Sass都可以这么做。

那么接下来,做一些从调整,我希望仅仅只是一个样式文件来完成这个事情呢?你会用什么方案呢?方法也有很多种,我这里会以html上的class来控制一个全局的样式改变,这样我们仅需一套样式表就可以完成多种主题了,大概的代码标示如下:

<html class="theme-default">    <!-- other --></html><html class="theme-default theme-custom-a">    <!-- other --></html>

用更高权重的类样式来对默认样式进行一次覆盖,这种方式也是Modernizr这个浏览器能力检测库的重要实现部分。

好了,我们已经用一个样式文件但是不同的主题类来实现了需求,不过这种方案是否存在一点点的不足呢?首先基于权重的样式覆盖,其实还是会有一定的风险,需要在设计架构阶段对样式有一个比较好的抽象和管理。其次还是存在一定的样式冗余。但是它最大的好处依然是无论怎么样,CSS和Sass都是可以做到的。

说了这么多都是一样的,那来点不一样的吧!

好,那么我们接下来的需求是仅需要一套无冗余的样式,并且支持多主题切换,怎么做?

第一个想到的是不是就是如果在浏览器端这些变量可以重新赋值,那么我只需要给变量重新赋值就可以实现这个功能了啊?没错,就是这样,幸运的是这个事情并不遥远,来看下以下的代码:

document    .documentElement    .style    .setProperty('--base-color', 'red');

好了,到这里是不是可以看出差别了?利用CSS以及浏览器所提供的API我们可以做到在运行时就进行各种有趣的操作,而Sass等预编译工具是永远做不到的。

所以整篇文章我最想突出的区别也就在这里!面向未来的CSS是既可以有编译时的策略,也可以有运行时的策略,而预编译工具只能有编译时策略

而将来很有可能在运行时我们可以创造出更多意想不到的东西。

华山论剑,无胜败

虽然在上面强调了运行时和编译时的差别,但也不要以为我在误导你们说未来的CSS就强于Sass。

不是这样的!强调!CSS是标准,Sass是标准的拓展,未来的CSS依旧是标准,Sass依旧可以成为它的拓展!

实际上他们并不冲突,未来的CSS仍然是CSS,而Sass的本质仍然是CSS的预编译语言,它所提供的一些预编译特性函数仍然是很强大的,那么他所能提供的职能依然可以结合未来的CSS。

之所以提到上面的内容,那是因为现在预编译工具的职能正在一步步的受到挑战,比如字体图标和SVG图标在设计中的广泛应用慢慢消灭了原本强大的

Sprite图生成能力,再比如上面说的变量申明能力将来也有可能会被CSS4替代,甚至如Http2的上线也甚至会一定程度上改变我们对预编译工具的使用习惯。未来的环境正在挤压这些工具的能力。

另外诸如Houdini之类的标准(会在之后的文章中介绍),W3C已经在起草,将来我们会有更多自定制化的CSS属性,那么这些都有可能在将来进一步的挤压预编译器的空间,是不是感觉到了压力不能呼吸了?

即便如此,预编译工具中目前诸如Mixin之类的函数也依然很好用,所以一定要找准项目的定位,适当的做好这块的架构和设计。

自由创造

事实上很多前端并不重视样式这块的设计与架构,基本就是随众,预编译工具拿来就用,知道了某一种命名规则后,随手就写,那么最终我们的系统其实对于用不用工具,有没有命名规则就显得很苍白。

其实以上做了那么多的分析,在这个部分中想进行一个简单的组合演示,来展现一下他们的相辅相成,取长补短的特点。

来看下如下代码:

:root {    --base-width: 20px;    --calc-width: {        width: calc(var(--base-width) * 2)    }}@mixin calc-width($width) {  width: $width * 2;}body {  @include calc-width(10px);  @apply --calc-width;}// 伪代码body {  @include calc-width(var(--base-width))  // width: calc(20px * 2) 期望转成运行时}

这样的写法其实本身并没有真正应用于项目过,但是这样的组合我们其实是可以联想一下的,也许很多人会质疑这些东西毫无意义,华而不实,这些都不重要。

这里重要的是我想通过这些代码来说明一下我们在样式的架构中其实是可以自由组合职能的,当我们既需要一些强大的编译时功能又需要一些运行时功能时,这样的组合无疑不是一种不错的选择。

当然如果需要做低版本浏览器兼容,又希望保留这样的写法,在经过第一次Sass编译后,还是需要postcss-nextcss来帮助辅助编译,这么做的话也就会丢掉运行时能力,那么有人会说既然如此只用Sass写就只需要编译一次了啊?没错,如果未来没有别的需求完全可以只用Sass来写。所以我这里会假设下,如果将来你有可能需要放弃低版本浏览器,然后用上运行时特性,那么我上面的这种写法中,你只需要移除postcss-nextcss的编译部分,其他什么都不需要做,这就是一种拥抱未来的思想。

最后的伪代码是我的一种遐想,让Mixin函数接受一个CSS变量而不是固定值或者Sass变量。(想想而已 ...)

在这最后要说的是,样式的设计和架构通常是一个既简单又复杂的事情,简单来说几乎每个人不需要花费多久就可以做到,复杂就不用多说了,让一个项目的样式变得可维护、可拓展、可响应、可兼容、灵活应变不是一件轻松的事情,在当下这个开发者们更关注javascript应用的时代下,更需要在样式的设计上多一些考量,毕竟除了强大功能外视觉与交互是吸引用户的一个重要因素。


点击这里复制本文地址 以上内容由权冠洲的博客整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!

支持Ctrl+Enter提交

联系我们| 本站介绍| 留言建议 | 交换友链 | 域名展示
本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除

权冠洲的博客 © All Rights Reserved.  Copyright quanguanzhou.top All Rights Reserved
苏公网安备 32030302000848号   苏ICP备20033101号-1

联系我们