CSS-in-JS,向Web组件化再迈一大步

简介

CSS-in-JS是什么,看到这个词就能大概猜到是在JavaScript里写CSS,那为什么要在JavaScript里写CSS呢,像之前一样写在css文件里哪里不好么?

在介绍这个概念之前,先来回顾一下在日常编写CSS代码时都有哪些痛点:

  • 全局污染 – CSS的选择器是全局生效的,所以在class名称比较简单时,容易引起全局选择器冲突,导致样式互相影响。
  • 命名混乱 – 因为怕全局污染,所以日常起class名称时会尽量加长,这样不容易重复,但当项目由多人维护时,很容易导致命名风格不统一。
  • 样式重用困难 – 有时虽然知道项目上已有一些相似的样式,但因为怕互相影响,不敢重用。
  • 代码冗余 – 由于样式重用的困难性等问题,导致代码冗余。

进化史介绍

在CSS的进化历史上,出现过各种各样的框架致力于解决以上的问题:

  • SASS, LESS – 提供了变量、简单函数、运算、继承等,扩展性、重用性都有了很大的提升,解决了一些样式重用冗余的问题,但是对于命名混乱问题的效果不大。
  • BEM (.block__element–modifier) – 比较流行的class命名规则,部分解决了命名混乱和全局污染的问题,但class定义起来还是不太方便,比较冗长,而且和第三方库的命名还是有可能冲突。
  • CSS Modules – 模块化CSS,将CSS文件以模块的形式引入到JavaScript里,基本上解决了全局污染、命名混乱、样式重用和冗余的问题,但CSS有嵌套结构的限制(只能一层),也无法方便的在CSS和JavaScript之间共享变量。

可以看一个简单的CSS Modules例子了解一下:

生成的dom结构如下图,基于css文件中的class名称生成了唯一的class名称,样式会定义到生成的class上。

styles打印出来如下图,定义了css中的class名字和生成的唯一class名字的对应关系。

可以看出,以上框架都解决了不少痛点,但也还是各有一些不足,当然CSS-in-JS也并不是完美的解决了所有问题,我们先来详细介绍一下。

流行框架介绍

现在随着组件化概念的流行,对从组件层面维护CSS样式的需求日益增大,CSS-in-JS就是在组件内部使用JavaScript对CSS进行了抽象,可以对其声明和加以维护。这样不仅降低了编写CSS样式带来的风险,也让开发变得更加轻松。它和CSS Modules的区别是不再需要CSS样式文件。

来看一下几个流行的CSS-in-JS框架六个月内的下载趋势

我们来看看几个下载量靠前的框架的风格是什么样的:

styled-components

先来看看下载量最高的styled-component的代码风格:

从上图可以看出,Title和Wrapper都是框架包装好的component,可以直接在react的jsx语法中使用,在包装component的时候还定义了标签分别是h1和section。此段代码产生的html dom如下图所示:

可以看到section和h1上分别生成了唯一的class名称,样式也对应的定义在生成的class上了。

这样就可以解决命名混乱和全局污染的问题。组件相关的代码都在一起,可以统一查看,也可以方便的重用样式。

glamorous

再来看看glamorous,这个框架是PayPal开发的。(前两个logo看下来,恍惚间感觉进了化妆品专柜)。

和styled-component不同的是,glamorous的样式直接以attribute的形式定义在了dom上,之后虽然也为其生成了class名称及样式,但这种以attribute定义的方式对伪类选择符(如 :hover)支持的不好,会带来一些不方便,而且需要再记住一套attributes名称和值与真正的css样式代码的对应关系。

JSS

和上面两个框架类似,jss也是会定义styles对象,并附到component上,最后生成的dom也是会有生成的唯一class名称,并有对应的样式,但样式并不是真正的css语法,而是对象的属性和值,这样也是对伪类选择符支持的不好,而且也需要记住属性和css样式代码之间的对应关系。

Radium

Radium在定义样式对象上看似和其他相似,但在生成dom结构的时候并没有生成唯一的class名称,而是直接把样式放到了style属性上,这样会带来诸如可读性差、CSS权重过大、不支持伪类选择符等问题。

测试

下面再来看一个styled-component提供的基于jest的测试框架:

jest-styled-components

这个框架主要是通过生成Snapshot并比较的方式来保证component样式的每次更改都会被检测到,并且样式是期望的样式。这样就又降低了重构CSS样式带来的风险。

优劣势总结

看了这些框架后,可以发现CSS-in-JS的优势还是挺多的:

  • 因为有了生成的唯一class名称,避免了全局污染的问题
  • 唯一的class名称也解决了命名规则混乱的问题
  • JavaScript和CSS之间可以变量共享,比如一些基础的颜色和尺寸,这样再当需要在JavaScript里计算一些高度的时候,可以取到和dom相关的一些padding,margin数值,统一管理
  • 只生成页面需要用到的代码,缩减了最终包的大小,提升了性能
  • CSS的单元测试增加了样式重构的安全性

但是CSS-in-JS也存在着一些不足和争议:

  • 有些观点觉得JS和CSS的关系没这么近,把CSS写进JS里引入了新的一套依赖,增加了复杂度,新人加入项目后需要学习的东西就更多了,也让学习曲线更加陡了
  • 对前端框架确实有些依赖性,更适合于组件化的框架,如React等
  • Debug的时候需要花更多的功夫才能找到对应的样式代码
  • 覆盖第三方插件样式时会有权重不够的问题
  • Lint工具对于JavaScript内部的CSS代码样式支持的还不够

最后

在ThoughtWorks最新一期的技术雷达(CSS-in-JS | Technology Radar | ThoughtWorks)里,它的等级是Assess,表示的是:“值得追求。重要的是理解如何建立这种能力。企业应该在风险可控的项目中尝试此技术。” 所以最后想说的是,虽然它还是有些不足和争议,在应用之前需要多角度衡量一下对项目的适合度。但它的优点也很多,确确实实解决了很多痛点,而且与web组件化的方向高度一致,希望大家在条件合适的情况下多多尝试,多多反馈,这样也能促进整个CSS编码体验的继续进化~


更多精彩洞见,请关注微信公众号:思特沃克

Share

前端不止:Retina屏幕下两倍图

所见不一定即所得

眼睛是心灵的窗户,也是蒙蔽你的一种途径。

假设,我给你一张图片,你觉得肉眼可以观察到全部的细节吗?

屏幕上一张清晰的图片

肉眼在屏幕上看到图片的清晰度由三个因素决定,一是图片像素本身是否精细,二是屏幕分辨率,三是屏幕大小。

我们来逐步分析它们之间的关系:

屏幕分辨率

屏幕分辨率也就是设备分辨率,设备像素,它是物理的像素,比如,新的iPhone7,屏幕分辨率是1334 x 750像素分辨率,326 ppi。

图像大小

如果你学过《数字图像处理》这门课,那你对下面的解释就是非常熟悉了。

位图是由像素(Pixel)组成的,像素是位图最小的信息单元,存储在图像栅格中。每个像素都具有特定的位置和颜色值。按从左到右、从上到下的顺序来记录图像中每一个像素的信息,如:像素在屏幕上的位置、像素的颜色等。位图图像质量是由单位长度内像素的多少来决定的。单位长度内像素越多,分辨率越高,图像的效果越好。

假设,以上这个logo的图像大小是1334 x 750像素和iPhone7屏幕分辨率一样,那么,一位图像素对应的就是一个设备像素,这就是会是一个完全保真的显示。因为一个位置像素不能进一步分裂,我想这一点应该大家非常容易理解,也就是一个萝卜一个坑。

屏幕分辨率和屏幕尺寸

相信大部分人对上面这个设置肯定特别熟悉,有些人可能对XP,甚至98系统的样式更熟悉(一不小心暴露了年龄),在Windows系统下,提高屏幕分辨率一般都需要提高屏幕尺寸。

因为在固定屏幕的情况下,提高屏幕分辨率(如上图),图像和文字显示目标会相应缩小,原因是系统并不会自动根据屏幕尺寸和分辨率关系相应的调整文字和图标的大小,这是Windows系统自身的行为。

我相信,如果家里有年长的人使用电脑,肯定屏幕分辨率调的很低,因为这样文字和图标才会比较大,我家06年买的台式机就是这样。

也因此,我们很容易有一个错觉,那就是屏幕越大,分辨率就能越大(在单位面积内像素数量固定的情况下,尺寸越大,单个屏幕拥有的像素就越多,分辨率自然就越大)。

直到,苹果Retina屏幕的出现,原来小屏幕也可以拥有大分辨率。

PPI的概念

PPI,像素密度,即每英寸所拥有的像素数目(比如:上面iPhone 7的PPI是326),PPI数值越高,代表显示屏能够以越高的密度显示图像,画面的细节就会越丰富。

以Retina屏幕为例,它并不是像普通显示器那样通过增大尺寸来增加分辨率,而是靠提升屏幕单位面积内的像素数量,即像素密度来提升分辨率,这样就有了高像素密度屏幕。

根据上面的分析,分辨率提升了,那么图标和文字尺寸就会变小,但是Mac的操作系统不同,它自动采取相应的模式(如Mac下的HiDPI)进行适配,将缩小后的字体(苹果一直采用矢量字体)和图标重新放大,这样苹果用了更多的像素数来显示同样的内容,所以显示尺寸仍然不变。

苹果将“高像素密度屏幕”的概念营销出一个专业的术语“Retina”,将其称为双密度显示,声称人类的肉眼将无法区分单个像素。

当一个显示屏像素密度超过300ppi时,人眼就无法区分出单独的像素。这也是讲:显示设备清晰度已达到人视网膜可分辨像素的极限。因此,行动电话显示器的像素密度达到或高于300ppi就不会再出现颗粒感,而手持平板类电器显示器的像素密度达到或高于260ppi就不会再出现颗粒感,苹果电脑Mac的Retina显示器像素密度只要超过200ppi就无法区分出单独的像素。

好,说了这么多,都是谈屏幕的问题,貌似和前端开发没有什么关系,我又不是要买新手机(呵呵),那么现在,我们现在来谈谈前端的问题。

Web中的像素(CSS像素)

CSS像素是一个抽象概念,设备无关像素,简称-“DIPS”,device-independent像素,主要使用在浏览器上,用来精确的度量(确定)Web页面上的内容。

在标准情况下一个CSS像素对应一个设备像素。

.box {
  width: 200px;
  height: 300px;
  font-size: 12px;
}

上面的代码,将会在显示屏设备上绘制一个200×300像素的盒子,在标准屏幕下,它占据的就是200×300设备像素。但是在Retina屏幕下,相同的div却使用了400×600设备像素,保持相同的物理尺寸显示,导致每个像素点实际上有4倍的普通像素点。

对于图片来说也是如此:

这个时候,屏幕会怎么处理呢?其实,有点类似图像软件的放大图片功能,采用自有的算法(图像处理算法)计算放大方式。只不过,这里是苹果Retina屏幕的计算方法,一个CSS像素点实际分成了四个,造成颜色肯定会存在偏差(非全保真的显示),于是,我们看上去就变得模糊了(特别是图片,非常的明显)。

开发当中遇到这样的事情,我们应该怎么处理呢?这时,我们需要引出devicePixelRatio的概念。

devicePixelRatio设备像素比

window.devicePixelRatio是设备上物理像素和设备独立像素(device-independent pixels (dips))的比例。

公式表示就是:window.devicePixelRatio = 物理像素 / dips

  • 普通密度桌面显示屏的devicePixelRatio=1
  • 高密度桌面显示屏(Mac Retina)的devicePixelRatio=2
  • 主流手机显示屏的devicePixelRatio=2或3

举例说明,一张100×100的图片,通过CSS设置它{ width:100px; height:100px }。在普通密度桌面显示屏的电脑上打开,没有什么问题,但假设在手机/或者Retina屏幕的Mac,按照逻辑分辨率来渲染,他们的devicePixelRatio=2,那么就相当于拿4个物理像素来描绘1个电子像素。这等于拿一个2倍的放大镜去看图片,图片可能因此变得模糊。

代码如何解决呢?

原理我们明白了,那么从代码层面,我们应该如何实现呢?

一个常见的做法是把图片换成200×200的,CSS宽高不变,仍然是{ width:100px; height:100px },这样,CSS宽高换算成物理像素是200×200,图片也是200×200,就不会变糊了。可以采用媒体查询和JS操作的方式

CSS Media Queries

#element { background-image: url('hires.png'); }

@media only screen and (min-device-pixel-ratio: 2) {
    #element { background-image: url('hires@2x.png'); }
}

@media only screen and (min-device-pixel-ratio: 3) {
    #element { background-image: url('hires@3x.png'); }
}

JS查询

retinajs库

是不是适配Retina屏幕所有的图片都需要切换呢?

不是,一般情况下,不需要针对网站上的所有图片都提供两个版本(非Retina屏幕和Retina屏幕),大部分图片缩放并不会太多的影响用户的体验。

常常需要被处理的图片有:网站的logo、彩色图片图标,因为他们的图像大小都偏小,在Retina上物理像素放两倍显示就会出现模糊情况,这个时候,你就需要通过媒体查询或者JS操作来替换图片。

最后

眼睛是心灵的窗户,也是蒙蔽你的一种途径,带上知识的眼镜,将世界看个清楚。


参考资料:

  1. http://www.w3cplus.com/css/towards-retina-web.html
  2. http://www.jianshu.com/p/bb76c606f0b4
  3. https://developer.mozilla.org/zh-CN/docs/Mobile/Viewport_meta_tag
  4. http://caniuse.com/#search=devicePixelRatio
  5. https://www.web-tinker.com/article/20590.html

更多精彩洞见,请关注微信公众号:思特沃克

Share

用“五个为什么”写CSS

相信大多数人都有过关于CSS的痛苦经历,从我加入公司到现在,不到两年的时间里,听到最多CSS相关的讨论就是‘很难调’。所以我也一直在探究这其中有怎样的问题,为什么很多人觉得CSS很难写,如何才能让其他人更优雅的写CSS。在Code Review的时候,我渐渐的发现了问题所在,其实很多人已经掌握了丰富的CSS知识,但却不知道如何分组属性写成class。最后只好在需要改变样式的元素上随意起个名字做class然后把所有要写的属性丢进这个class里,如果优先级不够,再把前面的选择器都加上。结果就是CSS代码不断堆积,重复和冗余不断增多,维护也变得举步维艰。

问题找到了,但如何解决呢,虽然我在项目组内做了几次分享,还经常在Code Review的时候提出一些问题,却还是收效甚微。有时候知道什么是正确的很容易,但知道如何才能做到正确却很难。直到最近,看了几本书之后,发现了一个很适合指导设计CSS的方法,那就是五个为什么或者叫五问法。五问法来自丰田的精益生产,后来自然衍生到了精益创业中,在DDD以及UX相关书籍中都会见到这个方法,其主旨是深入发觉大量现象的背后所隐藏的真正原因。乍一看它是一个管理方法,其实我觉得它是一种思维方式,即刨根问底的找到问题的根本原因并解决。所以被应用于各个领域,自然对于CSS所面临的问题也正恰如其分。

举个例子

先来举个例子吧,某天Code Review发现了一条CSS代码是这样写的:

.max-width {
  max-width: 300px;
}

由此产生了以下对话(纯属虚构):

UI Dev:“不应该这样写,这和直接写内联样式有什么区别呢?”

Dev:“如果我不加最大宽度,页面上那个元素左边就会多出一部分,不然加个margin外边距可以吗?”

UI Dev:“这个…我也不确定,我从没遇到过这样的问题,一定是哪里有问题。”

Dev:“确实这样写也挺不好的,过一段时间就不知道这行代码什么意思了,也不敢修改它。但究竟应该如何写呢?”

UI Dev:“呃,这样吧,我们来试试五个为什么,找找问题的根本原因。”

Dev:“好啊,CSS的问题也困扰我好久了,能解决就最好了。”

UI Dev:“首先问问,为什么要给元素加最大宽度呢?”

Dev:“因为不加就就会多出一部分呀。”

UI Dev:“那为什么这个元素会多一部分呢?”

Dev:“因为没加最大宽度,开个玩笑,别生气,其实我也不确定,不过用DevTools看了一下,好像它的父元素的宽度也不对。”

UI Dev:“已经接近了,为什么父元素的宽度不对?”

Dev:“因为父元素的内边距两边不一样。”

UI Dev:“为什么父元素的内边距不一致?”

Dev:“啊,我知道了,原来为父元素的父元素写了一个last的伪选择器,它是用来把padding-right设为0的,因为父元素现在正好是最后一个,所以被影响了。”

UI Dev:“别急,为什么要把最后一个元素的padding-right设为0?”

Dev:“因为原先最后面的那个元素里面是一个无法修改样式的控件,需要把padding-right设为0才能放得下。”

UI Dev:“所以这才是问题所在,我们的意图是给空间的容器加上padding-right为0的属性对吗?而不是给最后一个元素加,所以应该写一个class,也许叫做‘widget-container’之类的,放在那个容器上,然后把last伪选择器删掉,如此一切就正常了。原先出问题的地方其实是没问题的。”

Dev:“原来是这样,太好了,我学到了,样式出问题的地方不一定是代码有问题的地方,五个为什么太有用了。”

这样反复问多次“为什么”可以让我们找到问题的根本所在,如果仅仅从表面现象去解决问题很可能导致南辕北辙的后果。而且在例子中的last伪选择器就是因为没有找到根本原因而简单粗暴的写了这样一行代码而导致的。这个例子还很好的展现了五个为什么对于CSS的益处,不仅是找到问题的根本原因,还使得我们在写CSS的时候意图更加明确。如此一来,class命名难的问题也迎刃而解,padding-right应该为的0的元素是那个控件的容器,所以很容易想出“widget-container”这样的名字,因为通过五个为什么的方法找到了真正的意图,此时,class叫什么和应该放在哪都是水到渠成了。

按比例投入

但有时候我们所面对的项目不会这么善良,“为什么”的层级越多,说明CSS的关系也越复杂,所以现在我们来谈谈五个为什么中的一个重要原则,按比例投入。其主旨是小问题小投入,大问题大投入,问题等级越高,投入也应该越大。在CSS中来讲,就是当发现样式异常时,使用五个为什么深入找到的根本原因所在之处的重复次数越多,说明问题越严重,对问题的解决方案也应投入的更多。

再回到上面的例子中,通过一个元素位置异常的问题,找到根本原因来自一个控件需要内边距为0的容器元素,由于第一次发现,所以选择投入较小的解决方案,针对该控件加一个class用来去掉内边距。目前看来是很正确的,但如果接二连三的从不同的问题上深入找到这个控件上,那就说明问题等级提升了,不应该仅仅是在每个调用控件的容器上添加该class。此时我们可以考虑其他方式,比如把所有容器内边距都设为0,而有针对性的对内部元素添加外边距,如果问题等级继续提升,还可以修改甚至替换控件,或者重构其他部分来适应该控件。总之就是要按问题等级选择解决问题的手段,这样的好处不仅仅是原先在精益中那样可以自动调节效率,还可以等样式需求更明确的时候作出相应的重构。

由于CSS的描述性,使得它很自由,所以同一个需求,往往一百个开发者有一百种实现。在第一次碰到一个需求时,更是很难写出最佳实现,只能有针对性的写一个专属class把需要的属性扔进去。其实问题不在于此,而在于之后是否能在相同问题出现时重构原先的代码,根据所有相关问题写出更具普适性的class。有经验的UI Dev有时会通过经验来判断,直接写出这种class,Bootstrap这类框架就是这样的,但没有或较少经验的开发者就会产生疑惑。五个为什么的按比例投入原则可以很好的驱动CSS的开发,用深入的根本原因连接不同元素甚至不同页面上出现的问题,这样使我们能够安心的以目前的问题等级来组织代码,等到再次碰到问题并找到这里,才再次重构以解决问题。

Share