CSS 的缩进写法没有普及令我感到诧异

[autoxbc]

CSS 作为一种编程语言，自然有与其对应的缩进写法，类似这样

这个写法暗示了选择器命中元素在 DOM 中的位置，也给维护对应语句提供了定位路径

如果没有缩进，所有语句胡乱堆砌在一起，就是一座屎山。无数人抱怨 CSS 不可维护，就是找不到应该从哪里入手修改，只能碰运气搜索一下，不久就放弃了，然后在文件末尾新启一行，糊上新的屎

我自己给常用的 200 个网站编写 UserCSS ，其中最长的(刚好是本站)有近 700 行，短的也有几十行，如果没有缩进，维护这些 CSS 不可想象

这种写法如此自然，以至于我想象不出为什么很少有人这么写，不是本该如此吗

[dcsuibian]

Sass （新版 Scss 更好），Less

[ddcc]

我是说，有没有一种可能，有别的方式已经做到了这一点，并且更好，比如说 scss

[thedrwu]

vim 的 folding marker 可解

[autoxbc]

@dcsuibian #1
@ddcc #2
预处理器因为要实现嵌套语法，于是引入了缩进。我说的是，哪怕不用预处理器，直接写原生，也应该有缩进，因为这是 CSS 这种语言的自然属性

[autoxbc]

@thedrwu #3 这种缩进需要开发者对照 DOM 结构来写 CSS ，应该不是某种工具能自动实现的，当然我并不知道你提到的工具具体怎么工作

[Pastsong]

有没有一种可能，开发者可以不对照 DOM 结构来写 CSS ，你准备把 CSS 那些花里胡哨的选择器放在什么地方

[autoxbc]

@Pastsong #6 您是想说 tailwind 那种准内联写法么，那种抹除 CSS 选择器抽象层的做法不在这个讨论的语境里，这里是说有选择器抽象层的情况下，怎么处理这个抽象层的结构化

[eason1874]

CSS 并不认识缩进，你这样缩进只是方便人眼看，还有同名污染问题。其实 CSS 也有几种规范，代码可读的同时没有污染问题，以前比较流行的两种：

子选择器 .more2-item > .more2-block > .more2-img {}
双下划线 .more2-item__block__img {}

只是 CSS 规范不强制，而且容错性极强，小学生折腾几天都会改，所以 CSS 代码氛围像 PHP ，花里胡哨的占多数，规规矩矩写的少

[thedrwu]

@autoxbc 不是自动，而是手动插入一个折叠的标记，可以嵌套折叠。这种情况下多层折叠比多层缩进好用。

[yyfearth]

@autoxbc SCSS/LESS 都可以嵌套 比你这样缩紧要明了的多

.root {
a.link {
...
}
}

[autoxbc]

@yyfearth #10 我也用预处理器，也用预处理器提供的嵌套，不过在非嵌套的部分，我继续保持按照 DOM 结构缩进的做法，这里既没有矛盾也没有替代关系

[qeqv]

.more2_item {}
.more2_item > a.more2_lk {}
.more2_item > a.more2_lk > .more2_img {}
.more2_item > a.more2_lk > .more2_img > .more2_info {}
.more2_item > a.more2_lk > .more2_img > .more2_info > .more2_info_name {}

[releaseme]

https://drafts.csswg.org/css-nesting/

在做了在做了

[kaiki]

我认为能把同一个元素的 css 写在一起并且和其他的分割开来就已经是最大的仁慈了，看别人 CSS 代码的时候他这么做我就觉得谢天谢地了，改一个地方能搜出好几个文件里都有，覆盖得乱七八糟的简直头疼。

[cssk]

楼主这种缩进才叫恶心

[Procumbens]

CSS 并不是编程语言……

[herozzm]

缩进只是写的人方便，换人来也是屎山，对照 dom 也难得理明白，而且缩进难看

[herozzm]

关键有些缩进属性也可能被其他 dom 共用，逻辑也没法体现

[retrocode]

有没有一种可能, 我是说可能, 元素位置你不用暗示, 加个 cv 下父元素名和一个空格就可以做到
进来前我以为是小白正准备推荐 scss, 结果你这个缩进方法直接把我灵魂都干碎了

[wonderfulcxm]

scss 生成的 css 是选择器之间有层次的，你这样写形式上有层次，逻辑上是没有层次的，很容易坑到自己。

[cslive]

直接用 less 完事，浏览器直接可用

[ymcz852]

vscode 有 css peak 插件，在 html 属性里点击类名、ID 等可直接跳到对应的 css 定义

[rioshikelong121]

我挺讨厌这种缩进写法的。而且编辑器比较难帮你自动进行这种缩进。

[justfindu]

可是 class 都是平级的 为啥你要分层 而且这个缩进也不对啊 你要用 scss 或者 less 倒是可以理解

[machunning9843]

这样写 css ，代码多了一样不好维护，应该在组件级拆分，保证组件 css 样式不过多。

[yaphets666]

绝对不能有缩进这种东西

[netnr]

是的，分模块是最好的办法
另外 VS 支持 CSS 缩进排版

[sujin190]

丑，说明大家还是有点审美的

[digimoon]

这缩进也太恶心了，要表明关系我都是用#12 这种

[adoal]

CSS 是没有层级的，有层级的是 DOM

[yyf1234]

你这种写法才令别人感到诧异，看的累的要死

[marcong95]

首先 CSS 不是编程语言，只是样式表，没有任何控制结构。

你这种写法没有语义，但是又营造了一种有语义的错觉，这目测就是这种写法不普及的原因吧。

你这 .more2_info 是对整个页面有效，而不是仅对 .more2_item .more_info 有效那你万一再写了一个 .more3_item .more_info 呢？从你这命名来看，我也不奇怪会有这种情况的发生了，虽然没有根据，但是我总感觉变量名或者类名这种出现编号性质的数字，就差不多是屎山的标志了

[MAGA2022]

你是怎么做到这么自信的

[weixiangzhe]

less/scss 编译出的层级太深了，我同意 op 的意见

[cmdOptionKana]

综上所述，楼主提出的缩进并非显然、一致认可的好方式，而是属于见仁见智的“偏好”而已，因此没有普及这种写法不需要诧异。

[phxsuns]

css 是要讲究样式复用的。你这样写，那复用的样式怎么办？

[Me7426]

CSS module ，CSS inJS ，#8 提到的选择器规范，以及#
13 提到的原生嵌套，哪个不比你这缩进好，Python 写多了吧？

[XCFOX]

css in js 的写法没有普及令我感到诧异
jsx 作为一种编程语言，自然有与其对应的样式写法，类似这样: https://emotion.sh/docs/css-prop

这个写法明示了样式目标元素在 DOM 中的位置，也不用给维护对应语句提供定位

如果样式与结构分离，所有 css 胡乱堆砌在一起，通过 className 与 element 绑定，就是一座屎山。无数人抱怨 CSS 不可维护，就是找不到应该从哪里入手修改，只能碰运气搜索一下，不久就放弃了，然后在文件末尾新启一行，糊上新的屎

我自己给常用的 200 个网站编写 UserCSS （不是），其中最长的(刚好是本站)有近 700 行，短的也有几十行，如果没有 css in js ，维护这些 CSS 不可想象

这种写法如此自然，以至于我想象不出为什么很少有人这么写，不是本该如此吗

[XCFOX]

个人感觉在现代前端应用把 html 结构和 css 样式分离就是个错误。
Flutter 、SwiftUI 、WPF 都是直接在 element 上加样式的。

关注点不分离之后开发和维护轻松多了。
目前使用 Utility-first 的 tailwind 、windi 或者 css in js 的 emotion 等库都能轻松做到关注点不分离。

[Blacate]

可能你想要的是嵌套写法？

[Jooooooooo]

怎么同级的东西缩进还不一样...

令人迷惑

[dNib9U2o8x]

这缩进看的我浑身难受

[musi]

你缩进到最后一行都不够你缩进的

[MarquesMa]

其实这种想法是个陷阱：很多人发现有嵌套就觉得很好用，结果导致大部分 SCSS 嵌套很多的项目都不好维护。

为什么？

因为 HTML 本身有嵌套，CSS 再重新写一遍完全一样的嵌套关系，其实就是隐形地把同一套逻辑写了两遍，是一种没有益处的高耦合做法。当你需要改 HTML 的时候，就发现 CSS 各种挂，而且优先级也特别混乱要么重复叠类名，要么 important 。

虽然 Tailwind 和 Styled 之类的方案已经解决了这个问题，其实只说 CSS 的话 BEM 也解决了这个问题：不管 HTML 嵌套多少次，BEM 只嵌套一次，也就是只有一层 namespace 加上一个 selector 。这样既解决了冲突问题，又解决了上述的嵌套问题。因此移动元素的时候样式就很少挂，非常灵活，而且优先级就那两三个，一目了然。

[davin]

能 show 下 OP 的 HTML 对应结构么？这种 more1, more2, more3 ... moreN 在 HTML 中的结构是逐层嵌套呢，还是顺序使用的？如果始终自己一个人开发，怎么玩都开心。但涉及到多人协作的时候，人家可能随手复制 class 就去用了，结果发现样式没起作用，心里那会是什么酸爽滋味😭

[SilentDepth]

因为大多数情况下嵌套缩进并不是刚需。HTML 结构和样式定义有时并不是同一视角。当然有胜于无，多一个选择总是好事。

另外，楼主有没有考虑过匹配优先级的问题

[TomatoYuyuko]

那为什么不用更完善的 scss 呢，再说 css 完全可以和 dom 结构解耦啊

[libook]

一个 class 被不同层级的 dom 使用，这种写法可能就不适合了。

有可读性优化的意识是好的。

[iamzuoxinyu]

CSS 全称 Cascading Style Sheet ，不是 Cascading Style Tree 。

[autoxbc]

@kaiki #14 这种写法可以解决代码散乱问题，因为模仿 DOM 结构决定了相关的代码必然聚集在一起

[autoxbc]

@cssk #15 展示一小段代码你们可能感觉不到好处，当代码规模大了会发现有种结构化的美感

[autoxbc]

@herozzm #17 不不，只要遵守这个约束，换人来写会得到一样的结构，这是可维护的基础

[autoxbc]

@herozzm #18 共用的 class 一般都在类似的层级，实践中写在哪个部分都可以，不用复制多处。而且因为故意没有用嵌套语法，所以写在哪都能正常发挥作用

[autoxbc]

@wonderfulcxm #20 就是故意避开嵌套的，嵌套会导致选择器链严格化，class 被嵌套会使作用范围变小。而且嵌套和非嵌套可以混写，使严格化成为可选项

[autoxbc]

@ymcz852 #22 这个不仅仅提供了定位路径，还是一种代码组织约束，使得相关代码必须聚集在一起，那么会减少非常多的 important 乱象

[autoxbc]

@rioshikelong121 #23 如果编辑器可以分析 DOM 结构，理论上可以自动生成这个缩进

[autoxbc]

@justfindu #24 实践当中很多用 class 的场景实际应该用 id ，这个写法对 id 这种唯一结构比较有效。对 class 的场景，应该说也不是所有 class 都是平级的，还是会体现某种结构的，可以按照个人喜好细化约定

[autoxbc]

@machunning9843 #25 这个不矛盾吧，我也没说有结构了就不要拆分，改搞组件还可以搞，组件里也有结构，还是有缩进的需要

[autoxbc]

@digimoon #29 什么鬼，#12 那种不是要写到吐血

[autoxbc]

@adoal #30 CSS 也是有层级的，只是大多数人用扁平化来写，丢失了层级结构

[autoxbc]

@yyf1234 #31 我日常维护 200 个 CSS ，要是真的累的要死也坚持不住吧

[autoxbc]

@marcong95 #32 如果你感觉到了语义，那么就是有语义，这不是错觉

[autoxbc]

@MAGA2022 #33 因为我这么写好多年了。你看这么多人看一眼就开喷，我一点不急，好用不好用那是真实的感觉，伪装不来

[autoxbc]

@cmdOptionKana #35 不认可没关系，我就这么一说，大家这么一看，等下次维护 CSS 抓狂时想起这个来，愿意试一试就行

[autoxbc]

@phxsuns #36 这里没用嵌套包起来，复用的代码写在哪里都行，实践当中我会写在靠前的位置，复用的位置留一个只有选择器语句的空段落

[autoxbc]

@Me7426 #37 我这个是代码组织约束，和你说那几个都不矛盾，而且我这个只是缩进风格，不用引入任何东西

[autoxbc]

@Blacate #40 嵌套是嵌套，缩进是缩进

[autoxbc]

@Jooooooooo #41 如果缩进不一样，那就不是同级的

[guzzhao]

https://www.w3.org/TR/css-nesting-1/
你这么缩进感觉前后关系不清楚,css nesting 感觉就不错,用 postcss 插件转换,但是不知道为什么 vscode 还不支持,文件格式时 css 的话 vscode 飘红

[autoxbc]

@musi #43 我写很多年了，实践当中末级元素很少缩进到右半个屏幕

[autoxbc]

@davin #45 这个例子不是从头开发，是京东首页猜你喜欢部分的代码，我刚好要适配这个瀑布流到宽屏，写了一段 UserCSS ，随手就截图了。more2 不是我命名的，我本意是介绍这种缩进风格，没想到很多人纠结这个命名

[autoxbc]

@SilentDepth #46 因为这个缩进风格或者说代码组织约束不改变任何语义，所以应该不涉及优先级问题，除了因为更优良的组织结构协助维护者定位代码，可以少写很多 important

[autoxbc]

@TomatoYuyuko #47 用 scss 也可以用这个缩进风格啊，难不成用了 scss 就必须全部嵌套，我本来也是用 postcss 的，嵌套和非嵌套混写的

[autoxbc]

@libook #48 一个 class 共用时，我会把主体写在靠前的部分，后面共用的位置放上一个只有选择器的空段落占位

[autoxbc]

@iamzuoxinyu #49 Tree 是不是更好

[SilentDepth]

@autoxbc #72 哦，我刚注意到你这只是缩进，不是嵌套。那……何必呢，className 本身不一定要还原 HTML 结构的

[autoxbc]

@guzzhao #69 这个缩进描述的就是前后关系，怎么又不清楚了，楼上都理解了这里就是一棵 Tree ，还有比 Tree 更好的描述前后关系的么

嵌套是另一回事，嵌套会导致选择器链严格化，而且是强制的。非嵌套的缩进和嵌套混写使得严格化成为可选项

[autoxbc]

@SilentDepth #76 还原 DOM 结构使得新增的语句有准确的放置位置，代码就不会轻易腐败。层叠样式表一旦层叠失控，后面就是不归路

[Jooooooooo]

@autoxbc 敲错一个空格查问题岂不是查半天?

[autoxbc]

@Jooooooooo #79 我是 Tab 派的，没敲错过

[SilentDepth]

@autoxbc #78 BEM 有什么不好吗

[autoxbc]

@SilentDepth #81 BEM 是种命名方式，不是组织方式。对于 BEM 的 Block ，和其他 Block 的组织关系，还应该用这里的缩进来描述； BEM 中的 Element ，和 Block 中的其他 Element 的组织关系，可以继续用这里的缩进来描述

[Jooooooooo]

@autoxbc 显然不是一个好的代码格式管理方案. 不小心敲到了得 debug 多久呀.

[SilentDepth]

我不理解。

首先，CSS 用缩进忠实地体现 DOM 结构并没有什么好处。一来，CSS 选择器所表达的层次结构并不总是与 DOM 渲染结构相符，如果你使用 Atomic CSS 几乎没有层次的问题，而如果你使用 BEM 则选择器本身就体现了层次，用不着缩进。二来，纯静态的样式就罢了，伪类选择器怎么办，它算什么层次呢？如果使用 BEM ，两种 block 互有嵌套的时候要怎么缩进？

其次，「如果没有缩进，所有语句胡乱堆砌在一起」，但缩进了只是改变了水平位置，没改变垂直位置啊。相同业务主题的样式放在一起，它们左边有多少空格能造成什么本质区别呢。「无数人抱怨 CSS 不可维护，就是找不到应该从哪里入手修改」，这……是不是应该学习一下开发者工具怎么用。

以及，所有 CSS 方言都实现了嵌套语法，甚至 CSS 自己的嵌套特性也已在路上。这种情况下，你这种「不表达嵌套的缩进」是否会干扰对匹配优先级的判断呢（以 Sass 的话来说，相当于所有 ruleset 都隐含了一个 @at-root ）。现在大多数编辑器都有结构树显示功能，这种缩进在结构树里是平铺呢还是折叠呢？如果和正儿八经的嵌套语法放在一起，还要怎么表示呢？

[autoxbc]

@SilentDepth #84 一种解决方法不是解决所有问题的，只要解决希望解决那部分就可以了。就像英语语法只能解释一半的语言现象，另一半不合语法也不用强拗。拿出几个边界例子来说一个简单的缩进风格无法匹配所有情况，所以干脆完全不要缩进了，这是不可取的

CSS 的结构不总是与 DOM 完全一致，但是大多数情况的一致性是很好的，这是我长期实践的结论。准内联的 tailwind 风格我并不反对，只是不在这个语境里。BEM 的层次是个局部的层次，整个 DOM 显然比 Block 复杂多了，需要一个整体结构。伪类是同级结构，一般用嵌套写法放入选择器所在语句块的内部，重复一下，缩进写法不是反对嵌套，我自己就是该嵌套就嵌套，不该嵌套照常缩进。如果两个 Block 互有嵌套，可以随意按照自己的喜好来写，约束是提高可维护性的，不是难为人的

显然这里没有人不熟悉开发者工具，但是你见过那种同一个选择器在文件 10 行写了一堆，又在 100 行写了一堆，又在 500 行写了一堆，然后在另一个文件里又写了一堆么。用我的缩进写法，你只能写在同一个位置，这就是代码组织约束

嵌套给了你严格化的选择器链，但你不会总是希望这种严格化，当和缩进混写时，只要简单的把语句拿出嵌套就行了，一个子元素的语句块，在嵌套里缩进到什么位置，在嵌套外就缩进到什么位置，一个字符都不用修改

编辑器是为人服务的，人不用为编辑器考虑。实践当中，我完全不折叠任何代码块，不管是嵌套的还是仅缩进，我需要一眼看出代码的整体结构。如果有需要，相信也是可以做出折叠插件的，毕竟这里的层级逻辑是很清晰的

[gaodeng]

楼主，你这根本不是在写 CSS ，你的缩进太美了，你是在写诗歌，这是艺术。你简直就是个天才。这帖子可千万别被歪果仁看到，我怕他们学去了 🐶

[hackfly]

vs 就是这样缩，老难搞，每次都要手动对齐； CSS 根据迭代器就可以，为啥要搞锁紧来表明层级

[x86]

你这缩进个 10 行以上看的头都要炸裂了

[autoxbc]

@x86 #88 我给本站写的样式表的最大缩进就是 10 Tab ，全依赖这种缩进我才能持续维护

[learningman]

有个经典类名 clearfix ，不知道楼主打算放在哪

[autoxbc]

@learningman #90 对结构无关的抽象 class ，一般集中放在文件开头，这种很少超过 20%。剩下 80% 在 DOM 中有固定位置的，适合按照这个方法组织代码

[autoxbc]

@learningman #90 统计了一下，我自己维护的本站 UserCSS 一共 643 行，抽象 class 占 78 行，约为 12%

[kchum]

那 minified 时该怎样体现？

[GeruzoniAnsasu]

我不理解

tag 另算，class 完全是多对多、无层次的

<item class="margin-horizon-10 margin-vertical-20" >
<item2 class="margin-horizon-20 margin-vertical-10" />
</item>
<item class="margin-horizon-20 margin-vertical-10" >
<item2 class="margin-horizon-10 margin-vertical-20" />
</item>

是完全有可能出现的，那这 4 个 class 该怎么缩进？

[GeruzoniAnsasu]

如果这算那种「抽象 class 」，那就会与「 DOM class 」分开写在不同位置，要在脑子里同时处理这两个部分就很困难

而且就算这种方式只用来组织那些「与 DOM 绑定的 class 」，那当 DOM 是动态的时候也不一定能保证写对啊，意义何在呢

我绝不会试图把本来就 mesh 结构的东西写成树形

[GiantHard]

楼主的主要使用场景是维护 UserCSS ，通常需要写大段样式，但是现在更多人的使用场景是编写 component scoped css ，再加上各种 UI 库的使用，基本上就很少写大段的样式表了。

[chnwillliu]

如果 class 和 DOM 有唯一对应性，其实利用 SASS 的嵌套结构或者直接 css 的后代选择器重复 parent 路径也未尝不可，啰嗦了一点罢了，但也是体现了 DOM path ，额外增加的权重也无所谓啊反正你是一一对应不是。

如果不想嵌套选择器，那 BEM 命名就很好呀，也不用缩进了。

我觉得这不成问题的主要原因还是，前端都在搞组件化，样式都变成 scoped 的，随组件一起管理。全局样式文件里就最基本的 reset, typography 相关的。你说的 class 和 DOM 对应的样式，都在组件里放着，组件拆得细，单个样式表就非常小。组件范围内要定位 class 对应的 DOM 就非常简单啊。稍微大一点的组件，BEM 或者 SASS 嵌套就搞定了。

缩进体现层级的方案在传统的多页应用里可以实践，但 Vue, Angular, React 里完全没必要。

[lneoi]

与 DOM 结构保持一致的麻烦在于 DOM 结构一旦更改， 需要花大力气同步 CSS 。
如果强调复用性或者原子化，就很难与 DOM 结构保持一致，做到部分片段结构一致大部分项目代码还是有的吧。

[ACVV]

less 做到了，我一个产品狗都知道

[lneoi]

想了一下，Tailwind 方案不就是解决楼主的这种需求。与 DOM 结构一致，也省去了同步 CSS 。普通方案可能还要反复看 CSS ，原子化的写法可以从 DOM 上直接可读可改了。