题主的思路不错,不过实践起来可不容易。
其实类似的实践早已有之,如 Dean Edwards 著名的 IE7 项目(2003年)。但该项目并非预编译,而是在运行时解析 CSS 并实现效果。
我受到 IE7 项目的启发,描述过另一种让IE6浏览器支持多class选择器的方法(
面向未来的CSS实践,2006年),更靠近静态而非运行时,相对更接近题主预编译思路。
CSS 预处理器/后处理器及其库或扩展其实包含了类似的功能,比如将 flex 转换为几种不同草案语法。
今天 ShadowDOM 的 polyfill 方案,是最典型的符合题主预期的样式编译步骤。
但是这些工具要么是用途局限,要么是效果有限,很难完全达到题主期望的目标。原因如下:
1. CSS 与 JS 非常不同。ES6 的新特性许多是语法糖,或者说很容易有语义等价或近似等价的 ES5 形式。但是 CSS 的新特性中,除了极少数(如 hsl => rgb,草案的语法变迁,属性拆解等)有等价或近似等价转换,绝大多数是不可能映射到既有特性上的(如果可以的话,也就没有必要加新特性)。像 flex 写成 float ,只是在满足许多先决条件的情况下效果类似,但实际行为的差别是巨大的。
2. CSS 很复杂,每个特性可能有许多隐含的效果。比如用 float 之后,就产生了 BFC 从而会影响许多其他属性的行为。更不用说你征用了某个属性去达到其他效果之后,与其他需要该属性的需求可能产生冲突。
3. 即使只考虑效果类似,很可能需要牵涉 HTML 和 JS 辅助,单单编译样式表是不够的。这是为什么 IE7 等许多 patch 方案都是基于运行时而不是预编译,而我写的多class兼容方案也是同时需要样式表预编译和运行时的 htc 组件。
4. 有许多特性即使预编译和运行时都用上,也实现不出来,或者性能负担太高,比如 Shadow DOM 的一些样式支持,限制非常多,以至于在工程上不实用 —— 因为使用者需要理解太多实现细节,要考虑多种情况下降级后的效果——这样额外的负担已经消解了引入这样方案的目的(不需要太多考虑老浏览器)。
尽管如此,这样的思路仍然值得嘉许。大部分前端码农苦逼兮兮得搞兼容性好多年,只会骂IE,或者骂标准不实用,却从来没有想过工程上类似解决方案的可能性。题主在境界上已经超过了80%的前端。我本人是在看到IE7项目后才脱胎换骨的,题主如果是自己悟出来的,悟性胜过我当年许多!
所以,少年,努力吧!(欢迎投递简历 johnhax at gmail dot com)