1. 变量的问题
1.1变量的表示
sass有个$var, less有@var, stylus 的var直接就是var=值, 也可以使用$var
1.2 变量的赋值
sass, $var: value,
less: @var: value
stylus: var=10
2. 缩进的问题
sass, less均不需要缩进, 缩进无关
stylus也可以不用缩进, 使用默认的css花括号, 也可以使用缩进, 如果缩进不匹配就麻烦了
3. 宿主的问题
sass, 原来是用在ruby界的, 是haml的衍生品.
less,倒是原生的nodejs货
stylus, 也是nodejs的东西, 但是语法明显抄袭Python的感觉.
4. if条件判断的问题
sass的if和stylus的if引入很早了
但是less的if就没出现过, 渣一样的when, 让人蛋疼
stylus的if 类似与python的语法, if a is ‘unit‘
5.学习的难度
sass和less估计sass最好用了, less稍差, 也不是不能用, 就是感觉差了一点点, 连条件控制都没有
stylus的缩进, 开始给人耳目一新的感觉, 连 width: 100px; 这种, 冒号和分号都可以省略, 感觉, 哇哦, 还能这么省啊!
时间一长, 就觉得坑爹了, 我以前写的几十K的css, 难道都要按照你这个语法重新写一遍吗? 所以觉得, 这种省略花括号({}括号), 冒号(:号)甚至分号(;号), 只是一个噱头, 实际上是很坑爹的做法. 好在stylus及时弥补了, 支持原生的css写法. 那回过头来说, 你缩进个毛啊, 该不是嫌的蛋疼吧.
我觉得学习的难度, sass<less<stylus
功能上 sass不是最强的, stylus应该是最强的, 我看好stylus, 但是stylus这个名字不好拼写. 只能说less还有潜力可挖.
6. 关于函数
sass, less, stylus各自都有内置的函数, 尤其是关于颜色方面的函数, 都是很丰富的.
值得一提的是stylus的函数可以自己定义, 可以有一些数学运算啥的. 另外还支持python的列表一样的索引, 比如a=[1,2,3] a[0]是1, a[-1]是3
我觉得可以自定义函数是stylus的优点, 比sass和less都强.
7. 在自由度上
我觉得less最不自由了, 没有if判断, 函数又不能自己定义, 只能反复写mixin了, 想要less更好, 只能期待官方添加了, 可是都发展了这么久了, 到如今还不是那么令人满意, 真不知道啥时候能爽.
sass的if比less强多了.
stylus的if有点python风格. 如果纯粹前端用, 还是不太好, 没js的好.
8. 周边工具
sass是ruby界的, gem啥的我不懂, 就不瞎扯了
less, 和grunt, cssmin, contat?配合还是很好的
stylus也是nodejs的, 周边工具和less想当, 不占优势
9. 集成方案
现有的一个集成方案是 fireshell, 看我写的文章: Fireshell的使用说明 http://blog.csdn.NET/huyoo/article/details/41013989
作者是toddmotto, 这个FireShell主要是集成了sass, 项目地址在 https://github.com/toddmotto/fireshell
主要的工作就是你编写sass格式的scss文件, 然后搭配grunt-contrib-sass(要求安装ruby和sass 的gem包), 就可以实现自动编译sass/scss为css文件, 并最后合成并且压缩成一个style.min.css文件.
同时在http://localhost:9000端口开启了一个web服务, 可以方便的在本地查看你的网页的效果(在你的网页中引用这个style.min.css即可).
由于sass是分散的, 按照功能或者模块来分解一个网站所需要的css, 具有模块化的思维, 是很好的开发方式, fireshell就提供 了这个集成的方案.
这个集成方案中可以被替换的就是 sass 编译scss 替换成 less编译less文件, 或者stylus编译*.styl文件, 最后还是组合压缩.
因此, 一个fireshell中是可以实现集成sass, less, stylus的.
当然, 很多人可能只需要一个, 那么, 在fireshell的基础上, 做个分支就是很好方式了.
我就把sass替换为less了, 怎么替换的, 以及最终的代码, 请看:
把Fireshell中的sass模块替换为less编译css http://blog.csdn.net/huyoo/article/details/41016175
过几天再整 stylus的分支.
10. 对这种模块化, 编译型的css来说, 我希望的有
1. 支持原生css的解析, 别在搞啥花花肠子了, 如果不是比现有方式更方便的东西, 就不要弄了, 比如缩进
2. 变量的问题, 目前为止, 我比较认同变量有个标记, 不管是$var还是@var, 直接var, 我有时候分不清到底是css的内置tag, 还是变量.
3. if条件控制, less太不给力了
4. 代码替换的问题, 一个要求, 好用
5. 自有特性, 别太饶, 简单点
6. 还是期待nodejs的版的编译型css, 因为周边工具很多, 尤其是grunt, 光是这三个东西grunt-contrib-sass, grunt-contrib-less, grunt-contrib-stylus, 就让我觉得很好了, 满足了
另外, nodejs里的 autoprefixer 更是一个让人觉得很爽的东西. https://github.com/nDmitry/grunt-autoprefixer
就是你能不能在某个浏览器上使用某个css特性 在这里有个很全的数据库 http://caniuse.com/
autoprefixer 就是基于这个数据库来给你的css代码自动添加 -webkit- -moz- -ms- -o-等前缀, 是结合grunt的task, 就是一个全自动化的工具, 真的是很方便.