CSS in JS这个命题，是在内部小组的一个简单分享，现在单独拿出来整理一下。 自React流行以来，混写HTML和JS乃至CSS的做法变成日常，虽然CSS在react里只有一个简单JS实现，但只用JS解决所有问题的思路也逐渐为人们所接受。在过往的数年中，各种CSS in JS的框架也层出不穷，这里简单梳理一下，毕竟自己也是个和CSS有着相当缘分的人:) CSS & CSS in JSCSS最初被设计为简单直观的描述性DSL，10年前甚至部分是有设计师直接使用的。不过web的持续发展不可避免的让前端细分到技术领域，我也算是一路看着CSS各种演变，从最开始的避免多类简单直接，到有多类，有原子化描述，有CSS-reset，Normalise，Minimum Page，…
CSSer对text-overflow肯定是非常熟悉的，并且，对于单行文本的截断，包含了text-overflow: ellipsis;的这3行代码，可能也是我们最为惯用的。 text-overflow: ellipsis; overflow: hidden; white-space: nowrap; 这小段CSS甚至兼容至IE6，毕竟text-overflow: ellipsis;原本就是IE的专属，于是早期文本截断的抗争主要是在Firefox上，直到Firefox7.0，我们才抛开对于FF的伎俩而专注使用这段代码。当然多行截断还是没戏，在一些跨浏览器兼容要求较高的场合，前端一度需要后端帮忙截断内容。 虽然也不是没有其他方式实现多行的文本截断，但对于当时的浏览器形式而言不可能全部照顾到位。比如现在可以用伪元素:after定位在多行的结尾，并施加一个渐变过渡来模拟截断。 .clamp{…
十年前，当百度空间在06年7月正式上线的时候，我写了自己的第一行CSS样式。我清楚地记得那是一行指定百度空间background图片的代码。而CSS就是这么简单的东西，一个刚入大学的学生，只是希望为自己的空间稍稍装点一下而单凭猜测和模仿就能够写上几句的代码。百度空间在运行八年后正式关闭，而自己也决然不会想到，十年之后自己依旧在写CSS并以此度日。 CSS理应是简单的东西，它就是这么被设计出来的“简单的描述”，只是这十年里的前5年IE6的存在俨然使其成为梦魇，而后5年却又随着各种新兴扩展而变得越加复杂。如今的CSS已经不再是当初的设计中“设计师能够控制的东西”，复杂的布局，精巧的维护结构，各种框架，动画过渡...好在IE67时代已经过去，现在我们只需要将注意力集中在CSS本身而非各种hack技巧。 读的第一本关于CSS的书是《Eric Meyer谈CSS》，共2卷，以现在的眼光看来，是一本浅的过头的手把手的教程。之后读了《…
在之前一篇一个IE8的新起点中，我简单列举了一些当前放开枷锁的CSS，其中之一就是伪元素。当然，在使用伪元素的时候依旧会遇到一些问题，我总结了一些，简单陈述，留个印象，那么当再次遇到的时候能够有所回想。 使用伪元素主要遇到的问题集中在IE8，因为IE8只是部分支持伪元素。首先，IE8中设置伪元素的z-index可能无效。这点广为人知，在使用伪元素制作冒泡箭头的时候会遇到，无法通过调节z-index使before置于after之上。 另一个较为常见的问题是，无法以类名触发伪元素content的重绘。如果使用过字体图标那么多半遇到过这个问题。因为大部分字体图标是通过伪元素content插入字符而成，比如在一个当前激活的导航里项上添加.active时，看到图标依旧保持着原来的颜色。其实这个不只是IE8会遇到，移动版Safari同样存在这个问题(偶发)，明明更新了类名，外观却不发生重绘。 另外，使用:…
前段时候有个朋友问我rem需要注意些什么，我回她说这个参考网上一搜一大把。因为如果我没有记错2011年左右这个rem的单位就已经被各大技术博客讨论的铺天盖地。而现在已经快2016年了，不得不感慨时间的流逝。曾经的IE6已经消亡，虽然过程缓慢，但相信IE8最终也会和IE6一样成为历史。到了那个时候，rem就可以真正走上历史舞台了。如是，我觉得自己还是有必要拿rem出来写一写，一来证明一下我这个博客只是诈尸，二来对当前可能没人讨论到的方面做一个补充。不过自己年纪大了，不太适合长篇大论，小标题就不拟了，主要是简短闲谈。 rem是一个好东西。如果没有兼容IE8的顾虑，rem可以说是一个非常理想的单位。rem和em一样是相对单位，只是有别于em相对于父元素，rem相对于根元素html，即root em。这样的设定使得rem天生具备扁平级联的特性。早期IE不支持px单位的缩放，这是人们使用em单位的一个主要原因，但em单位存在过深的级联性，…
目前主流浏览器对CSS3 Media Queries的支持度已经非常好，那么就展望看看Media Query Level 4～前段时间抽空看了一下，就挑选几条感兴趣的说下。由于目前文档并非标准而只是工作草案，所以本文所列内容随时可能过期，只作为一个向导。 更新频度 update-frequency 查询设备的实际更新能力，取值也比较直观： none: 一旦渲染无法更新(比如打印机) slow: 更新缓慢(比如电子墨水) normal: 正常更新(比如我们更为熟悉的电脑屏幕) 这个查询可以为一些带有交互类的内容提供更多的外观控制，因为我们不是指定设备，而是根据设备的实际能力，对最终内容的样式加以优化。比如最简单的例子：…
前段时间我同事对于margin和padding应用百分比值似乎有些误解，觉得可能是个普遍问题，所以觉得有必要拿出来单独写一下。 margin和padding都可以使用百分比值的，但有一点可能和通常的想法不同，就是 margin-top | margin-bottom | padding-top | padding-bottom 的百分比值参照的不是容器的高度，而是宽度。 引用标准(2.1)原来的表达： The percentage is calculated with respect to the width of the generated box's containing…
前些日子，偶然发现zoom在iPhone6里没有起作用，而这之前，iOS7以下的Safari则确实支持zoom。可惜我并没有iPhone来测试这个问题，毕竟自己还在用着老诺的10年前的手机，手中也只有老婆淘汰下来的iTouch4，所以无法比较准确地做过多描述，只能粗糙地得到一个大概的结论。 虽然zoom的初衷是放大和缩小内容，但早期常用于触发IE内部haslayout属性，用做IE6-7的药方。作为一个早期IE的私有属性，其实现在的大部分浏览器也都能支持，故而也就有人使用其完成一些网页功能，比如移动端的网页内容的大小适配——相比对各个元素指定尺寸，一个zoom就能搞定绝对是懒惰开发者的福音。 说实在的，zoom在某些方面堪称实用，原因是CSS Transforms在内容占位上的效果可能非人所愿。用CSS Transforms替代zoom并非不可以，只是还需要关注缩放前后的位置大小，远没有zoom方便。而就是这么一个用法便利的尚未正名的属性，在最新的iPhone6面前不举了...按照iPhone的影响力，想来开发者不多久便会抛弃zoom。…
