Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

关于 css 命名过长的一些思考

  今天我们组有个长得超级高的小男孩和我抱怨说元素上的 class 名太长了。我本来还想着不就是 class 名嘛,能长到哪种程度?结果一看就惊呆了,神奇的业务需求导致了很深的层级嵌套。虽然对 JS 方面没什么影响,但 CSS 确实撑不住了。
  关于 CSS 命名规范我之前也纠结过好久,最终搞出了一套比较稳定的「CSS 模块化命名」。虽然这套命名尽可能地避免了冲突以及其它潜在问题,但确实会使 class 名变得很长。特别是在业务存在繁复的层级嵌套时就变得非常纠结。
  但是为什么在同样的结构上使用同样的命名,JS 就没有问题呢?因为 JS 比较容易模块化嘛。CSS 有个硬伤就是所有定义都是全局的,想实现模块化就必须在命名上约定。当然 Shadow DOM 之类的东西也许也可以解决部分问题,不过遗憾的是这些东西目前还处于「不能用」的状态。
  以前也做过很多复杂的项目,从未像现在这样纠结过,于是总结了下原因。以前的项目就算再复杂也是传统的多页 Web,每个页面的 CSS 单独加载,完全不用考虑跨页面的 CSS 冲突问题;现在做的是单页应用,所有 CSS 都是打包在一起的,要考虑业务之间的 CSS 冲突。如果我总结的原因没错的话,只要在单页应用中针对业务动态定义 CSS 即可解决。虽然我一直都很想这么做,但在一些坑没踩平之前还不敢这么作死。
  根据业务动态定义 CSS 大概有两种做法。一种是按需加载 .css 文件,另一种则是统一加载按需设置。前者会导致页面的过度不流畅,后者需要使用本地存储来管理 css 资源。虽然这些情况都比较棘手,但至少是可以实现的。我个人更倾向于「使用本地储存来管理资源」,虽然目前这种技术在很多人眼中还属于黑魔法。但我很有兴趣搞一套可用的「本地静态资源管理方案」,不仅仅是为了解决 css 的问题,还有「差异化加载」的实现也需要一套这样的方案。
网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^