当你书写大量的 CSS 代码时, 可能会出现不止一个的错误. 可能需要某个工具来阻止你 CSS 书写的错误.
可能, 有的时候你的错误真的是一个 bug. 也有可能仅仅因为草率造成的不一致或者不明确的代码风格. 可能它们当中的许多看起来微不足道(取决于你的性子), 但是随着代码库的增多以及时间累积, 许多人使用时就会做出有丑陋的东西. 事情的后果不是你可以想象的.
你尝试去控制自己. 你的同事也帮助你, 当你游离及时纠正你的错误. 但是, 你和你的同事都是错误的制造者, 所以最后至少在一定程度上都不可避免的失败了. 后来, 你或者其他人就要解决你页面 CSS 错误造成的问题.
无论是你或者你同事都不喜欢讨论你犯下的错误, 因为这是令人尴尬的事情. 甚至有时会令人沮丧或者产生情感破裂. 一定的规范有时候对于代码库的维护是 有帮助的, 如一致的书写风格, 可能当手动执行时, 看起来有点迂腐乏味. 不然它们就会将你平时喜欢的爱出风头, 固执的元素展现出来.
另外你可能更喜欢可以及时修正错误, 而不是等待代码审查后由别人指出错误后, 自己进行修改并声明自己不会再出现此类错误. 当你的 CSS 出现错误时, 一个及时的反馈会帮助你节省很多时间.
你所需要的是一个防止错误产生的机器
你需要一个防止错误产生的机器, 可以理解 CSS 并且理解你: 你的意图, 喜好, 主意以及弱点.
这种机器将具有局限性. 所有的事物都不是完美的. 但是这种局限和你以及你的同事又有所不同. 只要是它可以阻止的错误它都会持续阻止, 孜孜不倦. 同 时, 你和你的同事可以一直改善机器, 扩展它的功能并且削弱其局限性. 它是开源的, 全世界的人都可以加入其中尽自己的一份力量 - 其他想要阻止自己出现 CSS 书写错误的作者.
和其他一样, CSS 作者也需要 linters
我们将这些防止错误出现的程序称为 "linters".JavaScript 中有几个比较好的 linter. 尤其是 ESLint http://eslint.org/ , 它起到的作用如奇迹般, 向我们展示了一个好的 linter 是如此的有用. 但是在 CSS 中, 我们就没有这么幸运了, 我们的选择十分有限: 基于 Ruby 的, 具有特殊预处理程序的 https://github.com/brigade/scss-lint 和较早的 CSS Lint http://csslint.net/ .
但是这都是在 PostCSS 出现之前. 除此之外, PostCSS http://postcss.org/ 提供了一些方法, 建立更具有良好交互性的 CSS 工具. 它可以将任何类 CSS 语法解析为抽象语法树 (AST) 的插件, 从而进行分析以及操作. 并且利用自定义解析器 https://github.com/postcss/postcss#syntaxes ,PostCSS 甚至可以处理不规范的无效模式(如 // 注释)
成熟的条件已经可以产生一个具有更强大功能的 linter - 基于 PostCSS 的强大功能以及在 SCSS-lint 和 ESLint 最佳功能的启发之下.
我和几个小伙伴一起致力于这个项目, 现在我就要开始介绍一下我们开发的工具: http://stylelint.io/ .
使用 stylelint 你可以做的事情
以下是尝试于 stylelint 的功能总结, 其中规则多达百余条, 并且具有可扩展性.
在这一点, 如果你发现自己已经变得有点不耐烦("Ok,Ok: 我相信 stylelint 将具有奇迹般的工作效果. 不需要过多的总结."). 仅仅跳到下一部分, 在这里我仅仅说明一些问题并提供一些提示.
错误捕获
有些 stylelint 规则旨在找出明显的错误, 如拼写错误或者由于你的心烦意乱或者睡眼惺忪时制造的疏漏. 例如, 你可以禁止空白块, 无效的十六进制值, 重复的选择器, 未命名的动画名称和错误的线性渐变的语法.
其它的规则都是尽自己最大的努力捕捉更细微的错误. 这里有一条规则: 当你使用可以覆盖其属性同行 (如 margin-top) 的速记属性时(如 margin), 就会发出警告, 因为这可能是由于你的疏忽造成的. 另外, 还有一种规则会警告你: 当出现混乱局面时, 如规则A出现在规则 B 之前, 但是实际上覆盖了规则 B, 因为规则 A 的的选择器具有更高的优先级(如, 规则 A 为 .foo.bar{...}, 规则 B 为 .foo{...}). 这是一种十分棘手的情况.
还有一种规则使用了 PostCSS 的 https://github.com/anandthakker/doiuse 插件, 用于检查你的浏览器是否支持此样式. 另外一种则使用了 https://github.com/SlexAxton/css-colorguard 插件用于提示颜色的相似性, 以免造成你的混乱使用.(请注意: 这是基于 PostCSS 之上的 stylelint 的主要优势之一: 相比于其它 PostCSS 插件, 用很少的努力, stylelint 就可以进行提示.)
强制执行最佳实践
如果你在样式表中使用了系统方法, 或者对你的代码设置了一个样式指南, 你应该取缔这些模式了. stylelint 已经提供了这些功能.
首先, 你需要狠狠地控制你的选择器. 使用 stylelint, 你可以禁止超过一定特异性的选择器或者在嵌套深度上设置限制. 你可以禁止类别选择器(例如没有 id 的选择器), 并对其余的选择器使用正则表达式进行命名约定.
你可以禁止! important 的使用, 或者你的浏览器并不支持的 brower hacks. 如果你使用 Autoprefixer https://github.com/postcss/autoprefixer (或者说你应该使用), 你可以禁止在源样式表中使用供应商前缀.
如果你想要更加严谨 - 你可以花费一些时间在配置上, 以保证绝对的一致性 - 你可以强制执行样式表属性的顺序, 并为黑名单, 白名单提供属性, 值, 函数还有单位.
执行代码样式的约定
stylelint 具有自动执行代码样式的约定, 所以你和你的队友无需主动设置. 我们致力于使这些规则更加全面灵活.
这些规则主要针对于空格, 但是同样针对于其它的细节, 如; 引号, 大小写字母, 在小数前写零, 使用关键字以及拼读出值等等.
梦想你和你的队友可以建立一个格式约定(例如我们始终在声明冒号之后留有一个空格), 并在你的 stylelint 配置中进行修改, 之后你们就不会为此再次讨论. 让其执行于机器王国.
制定以及扩展一切
Nicholas Zakas,ESLint(以及 CSS Lint)的创作者, 写到 ESLint 的成功在于它的扩展性. stylelint 试图遵循 ESLint 的领先优势, 并且提供给 CSS 作者一个 linter, 同样具有扩展性.
你可以书写并且发布自己的规则插件. 现在已经具有了一大堆可以使用的; 并且我们渴望看到别人的优秀插件.
配置是可扩展的, 因此可以共享. 至于插件, 我们从 ESLint 了解了这一功能的价值性. 检查其中包括 WordPress 和 SUITCSS 配置的, 并且已经公布的.
如果你不喜欢 stylelint 的内置提示, 你可以手工创建属于你自己的风格, 甚至可以为你的组织进行创建. 你还可以自定义用于提供警告信息的规则.
使用 stylelint 的 API, 你可以创建文本编译器的插件, 并进行测试使 stylelint 融入到你的工作流的每个方面.
如果你有关于 stylelint 扩展的想法, 请让我们知道!
预期问题的答案
在你的心中可能存在几个疑问. 这里有几个最为常见问题的解释:
是否可以在 SCSS 或者 Less 中使用 stylelint?
答案是肯定的, 你可以在 SCSS 中使用 stylelint, 并且在 Less 中也得到了支持! 自从 PostCSS 允许自定义解析器 https://github.com/postcss/postcss#syntaxes ,stylelint 可以很轻松的支持各种各样的非标准语法 - 你可以自定义一个 PostCSS 解析器进行解析.
正因为 PostCSS 解析器 - 因此 stylelint 支持 SCSS https://github.com/postcss/postcss-scss ,Less https://github.com/webschik/postcss-less 以及新 SugarSS https://github.com/postcss/sugarss . 如果你想要实现另外一个自定义语法的支持, 你可以通过 PostLess 得以实现!
当然, 还有一定的规则在你的非标准语法面前得到羁绊(如迷惑于 Sass id 选择器的 #{$interpolation}). 因为 stylelint 试图掩盖我们样式表的样式 - 一些人使用标准 CSS, 一些人使用扩展语言如 SCSS, 一些人使用一些怪异的自定义属性等等 - 这些难免都会产生一些漏洞需要去填补. 但是, 我们一直在处理我们找到的这些错误; 在此期间的任何规则可以完全被关闭或者逐次样式表或者逐次行的进行禁用.
stylelint 是否可以使用未来 CSS 语法?
是的! 类似于上面所述的答案: stylelint 可以理解 PostCSS 所理解的任何东西, 包括启用未来任何的 CSS 语法(可能通过 PostCSS 插件). 事实上, 一些 stylelint 规则专门处理未来 CSS 语法和一些自定义属性.
stylelint 配置是巨大的, 我应该从哪儿开始呢?
我们建议三种配置方式:
扩展一个发布的配置. 我们维持 stylelint - 配置标准, 以便于为用户提供一个固有的基准. 并且许多的配置也已经公布.
从头开始, 一次添加一条规则. 默认情况下, 没有一条规则被开启, 所以通过手动添加规则你就会知道哪一个会被强制执行, 并且可以理解你添加的每条规则.
启动复制粘贴配置 http://stylelint.io/user-guide/example-config/ , 决定使用哪些选项并选择性进行删除.
值得庆幸的是, 你不需要一遍又一遍的书写巨大的 stylelint 配置. 你可以选择一个你喜欢的风格并且可以在任何地方使用它.
运行 stylelint 最简单的方式?
对于大多数人而言, 最简单的方式就是通过它的命令行 http://stylelint.io/user-guide/cli/ .
如果你更偏爱 gulp 插件, 你可以使用 https://github.com/olegskl/gulp-stylelint . 对于 webpack, 这里有很多选择的可能性. 我们希望这些插件可以激励你们创建其它的 stylelint 插件, 例如, 适用于 Grunt 的插件.(你可以在开源项目中去寻找!)
你也可以使用 PostCSS 插件运行 stylelint, 包括插件中所包含的任何东西. 这就意味着你可以在任何可以使用 PostCSS https://github.com/postcss/postcss#runners (几乎涵盖于每一个编译工具)的地方使用 stylelint!
此外, 这里也存在一个适用于 Atom,Sublime Text,VS Code 的 stylelint 文本编译插件, 以提供最快的反馈. 关于更多信息, 请查阅 stylelint 网站上的互补工具列表.
如下所示, 在命令行中, 你所期待看到的结果:
在 Atom 中显示如下;
stylelint 是否可以修补我的错误?
不, 但是另外一个叫做 https://github.com/morishitter/stylefmt 旨在做到这一点. 它需要一个 stylelint 配置 - 十分类似于你在 linting 使用的 - 并且可以修复任何错误. 我们希望随着社区人员的贡献, stylelint 可以发展到自动修补违反 stylelint 规则的错误. 请帮他们实现这个目标 https://github.com/morishitter/stylefmt/issues !
你也可以使用其它的工具, 例如 CSScomb http://csscomb.com/ 或者与 stylelint 联合使用的 perfectionlist https://github.com/ben-eb/perfectionist , 自动修复并自动强制休息.
使用 linting 进行约束补充
在良好的 CSS 中有巨大数额的约束. 这就是为什么我们花费大量的时间讨论 SMACSS, ACSS, BEM, SUITCSS, ITCSS 等等的方法. 我们都知道书写糟糕的 CSS 是十分容易的, 所以, 如果让我们不再畏惧于 CSS 样式的书写, 我们需要在工作中建立一个智能化的战略并 勇敢的坚守下去.
stylelint 的目标是自动执行 -- 提供一套核心规则和一个可插拔的框架以便于 CSS 作者可以使用来执行自己的战略.
试一试, 让我们知道如何为你提供服务. 如果你有相关更好的改进想法, 如贡献规则, 增强功能, 测试, 修复 bug, 文件, 新想法或只是反馈, 请给我们提出! 这样我们所有级别的开发人员就有工作做了.
来源: http://www.webhek.com/post/stylelint-css.html