eslint-plugin-unicorn 的 no-nesting-with-mixed-specificity消除 CSS 嵌套选择器列表中的特异性陷阱【免费下载链接】eslint-plugin-unicornMore than 300 powerful ESLint rules项目地址: https://gitcode.com/GitHub_Trending/es/eslint-plugin-unicorn导读CSS 原生嵌套语法Nesting中嵌套选择器的特异性并非来自字面父选择器而是遵循与:is()相同的语义——取父选择器列表中的最高特异性。这意味着在#dialog, .dialog这类混合特异性选择器列表下嵌套的子规则会在两个分支上都被 ID 级特异性放大从而悄然改变级联结果。eslint-plugin-unicorn 的no-nesting-with-mixed-specificity规则正是为此而生它在 ESLint 的 CSS 语言插件eslint/css环境中静态检测这类写法提示开发者拆分父规则或均衡各分支特异性。读完本文你将理解该规则背后的 CSS 特异性机制、掌握标准的修复姿势并了解其在media、scope等 at-rule 边界下的行为与局限。问题根源继承的是父选择器列表的最高特异性CSS 给嵌套选择器赋予了父选择器列表中最具体的那一项的特异性这与:is()的行为完全一致。于是当父规则是一个混合了不同特异性的选择器列表时嵌套进去的子规则会「平均」地获得最高特异性即便某些分支原本并不具备该特异性。以规则文档中的经典反例docs/rules/no-nesting-with-mixed-specificity.md为例/* ❌ 触发报告 */ #dialog, .dialog { .close {} }这段嵌套代码的行为等价于:is(#dialog, .dialog) .close {}由于:is()取参数列表的最高特异性.dialog这一分支也连带获得了来自#dialog的ID 级特异性。也就是说 .close在两个分支上都被提升为#dialog .close的级联权重覆盖了样式作者原本可能预期的「.dialog .close应该更弱」的层叠关系。混合特异性让嵌套规则的权重比其部分匹配分支所暗示的要高这正是规则文档中强调的核心危害。规则概览与启用方式该规则在 rules/index.js 中以no-nesting-with-mixed-specificity导出元信息声明于 rules/no-nesting-with-mixed-specificity.jstype: problem、schema: []无任何配置选项、languages: [css/css]仅在 CSS 语言插件下生效。需要注意文档头明确标注该规则在recommended与unopinionated两个预设配置中均为禁用状态✅与☑️均未勾选需要手动开启。启用前必须先引入eslint/css语言插件并像 readme 中 Non-JavaScript files 一节展示的那样用files限定 CSS 文件范围import css from eslint/css; import unicorn from eslint-plugin-unicorn; import {defineConfig} from eslint/config; export default defineConfig([ { files: [**/*.css], plugins: { css, unicorn, }, language: css/css, rules: { unicorn/no-nesting-with-mixed-specificity: error, }, }, ]);一旦命中规则会在**子规则的 prelude选择器列表**上报告错误消息为Do not nest rules under selector lists with mixed specificity.见 test/snapshots/no-nesting-with-mixed-specificity.js.md 的快照输出。标准修复拆分父规则规则文档给出的第一种修复方案是把混合特异性的父规则拆开让每个分支各自独立持有子规则/* ✅ */ #dialog { .close {} } .dialog { .close {} }拆分后在#dialog分支内继承 ID 特异性在.dialog分支内只继承类特异性级联权重与视觉意图一致不再有「隐性放大」。允许的情形父选择器列表特异性一致并非所有选择器列表嵌套都会被报告。规则文档明确指出各条目特异性相等的选择器列表是允许的/* ✅ */ .dialog, .modal { .close {} }.dialog与.modal同为类选择器特异性均为[0, 1, 0]无论继承哪一个分支的特异性结果都相同不存在被放大或漂移的问题。测试用例test/no-nesting-with-mixed-specificity.js也验证了#dialog, #modal { .close {} }、.dialog, [open] { .close {} }等均属于合法写法。由此引申出第二种修复思路——均衡化父选择器的特异性只要让选择器列表中所有分支的特异性对齐例如都改成 ID、或都改成类嵌套规则的特异性就稳定可预期了。规则文档将其列为与拆分父规则并列的可行补救手段。源码视角特异性如何被计算与比较规则的核心逻辑位于 rules/no-nesting-with-mixed-specificity.js它用eslint/css-tree对选择器做 AST 解析并将特异性建模为三元组[a, b, c]对应 CSS 规范的 ID、类/属性/伪类、类型/伪元素三层权重IdSelector→[1, 0, 0]第 153-155 行ClassSelector、AttributeSelector→[0, 1, 0]第 157-160 行TypeSelector→[0, 0, 1]但*与|*通配符为[0, 0, 0]第 162-165 行PseudoElementSelector与旧式伪元素:before、:after、:first-letter、:first-line→ 元素级[0, 0, 1]第 140-141 行伪类的处理最有讲究getPseudoClassSpecificity第 112-144 行:where()的特异性恒为零:is()、:has()、:not()这类接收选择器列表的伪类SELECTOR_LIST_PSEUDO_CLASSES第 19-23 行取参数内各选择器特异性之和的最大值——这与浏览器对:is()的处理一致:nth-child、:nth-last-childof子句、:host、:host-context在自身[0, 1, 0]之上再叠加参数的最大特异性第 129-138 行。具体到判断流程create回调第 217-238 行规则遍历每个Rule向上查找最近的父样式规则用父规则各分支特异性的最大值作为的特异性getMaximumSpecificity第 48-58 行再计算当前规则各分支的特异性一旦发现父规则各分支特异性不一致hasMixedSpecificity第 193 行即对当前嵌套子规则报错。值得注意的是子规则不带时如{ .close {} }会被视为隐含嵌套选择器同样叠加父特异性参与比较第 185-191 行因此这类写法一样会被拦截测试中的#dialog, .dialog { .close {} }即为佐证。边界与局限什么场景下检查会「失效」规则文档对边界行为有明确交代这些行为在源码中都有对应实现伪元素分支被忽略无法表示::before这类伪元素因此规则只检查「能被嵌套选择器表示的」父分支canBeRepresentedByNestingSelector第 71-74 行。测试中的dialog, ::before { .close {} }被判定为合法而#dialog::before, .dialog { .close {} }也合法——因为混入伪元素的分支不参与比较。嵌套可穿透透明 at-rulemedia、supports、container、layer被归为「透明分组规则」TRANSPARENT_GROUP_RULES第 13-18 行嵌套规则可以穿过它们继续与最外层父规则比较。getParentStyleRule第 195-212 行在向上回溯时遇到这些 at-rule 会继续上溯快照中#dialog, .dialog { media (...) { layer components { .close {} } } }层层穿透后仍被报告的案例即是证明test/snapshots/no-nesting-with-mixed-specificity.js.md。scope与其他 at-rule 是边界getParentStyleRule遇到非透明的 at-rule 便停止上溯嵌套无法越过边界与更外层比较。不过边界之内的规则仍照常检查例如scope (.root) { #dialog, .dialog { .close {} } }依然会被报告测试第 63 行。函数式伪类内部不做情境有效性分析且由于eslint/css将嵌套的supports、container内容暴露为**原始文本Raw**而非结构化 AST规则无法解析其中的规则因此这类深层嵌套无法被检查——源码中hasNestingSelectorInRawArgument第 76-87 行仅能通过 tokenize 判断原始文本里是否出现过而非完整解析。为什么没有自动修复fixer规则文档在结尾明确说明该规则没有 fixer。原因在于无论是拆分父规则还是改写选择器都必须知道作者预期的文档结构与层叠意图——同样的代码在不同场景下「应该拆」还是「应该改特异性的某一侧」机器无法替人决定。这也是meta中未声明任何fixable标记的原因。因此实际工作流是让 ESLint 报告问题由开发者依据#dialog与.dialog各自的语义决定采用拆分还是均衡特异性的方案。建议与总结在项目 CSS 中使用原生嵌套时建议显式开启unicorn/no-nesting-with-mixed-specificity它不在recommended预设中并在持续集成中保持error级别。遇到报告时优先问一句「这两类选择器的特异性是否本就该一致」据此选择拆分父规则或均衡特异性两种方式规则文档与测试均认可。关注规则的四条边界伪元素分支豁免、透明 at-rule 穿透、scope截止、Raw 文本不可达——它们决定了该规则能覆盖的检查范围避免对其产生超出能力的预期。该规则的完整实现、测试用例与快照分别位于 rules/no-nesting-with-mixed-specificity.js、test/no-nesting-with-mixed-specificity.js 与 test/snapshots/no-nesting-with-mixed-specificity.js.md可供进一步对照研读。【免费下载链接】eslint-plugin-unicornMore than 300 powerful ESLint rules项目地址: https://gitcode.com/GitHub_Trending/es/eslint-plugin-unicorn创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
eslint-plugin-unicorn 的 no-nesting-with-mixed-specificity：消除 CSS 嵌套选择器列表中的特异性陷阱
eslint-plugin-unicorn 的 no-nesting-with-mixed-specificity消除 CSS 嵌套选择器列表中的特异性陷阱【免费下载链接】eslint-plugin-unicornMore than 300 powerful ESLint rules项目地址: https://gitcode.com/GitHub_Trending/es/eslint-plugin-unicorn导读CSS 原生嵌套语法Nesting中嵌套选择器的特异性并非来自字面父选择器而是遵循与:is()相同的语义——取父选择器列表中的最高特异性。这意味着在#dialog, .dialog这类混合特异性选择器列表下嵌套的子规则会在两个分支上都被 ID 级特异性放大从而悄然改变级联结果。eslint-plugin-unicorn 的no-nesting-with-mixed-specificity规则正是为此而生它在 ESLint 的 CSS 语言插件eslint/css环境中静态检测这类写法提示开发者拆分父规则或均衡各分支特异性。读完本文你将理解该规则背后的 CSS 特异性机制、掌握标准的修复姿势并了解其在media、scope等 at-rule 边界下的行为与局限。问题根源继承的是父选择器列表的最高特异性CSS 给嵌套选择器赋予了父选择器列表中最具体的那一项的特异性这与:is()的行为完全一致。于是当父规则是一个混合了不同特异性的选择器列表时嵌套进去的子规则会「平均」地获得最高特异性即便某些分支原本并不具备该特异性。以规则文档中的经典反例docs/rules/no-nesting-with-mixed-specificity.md为例/* ❌ 触发报告 */ #dialog, .dialog { .close {} }这段嵌套代码的行为等价于:is(#dialog, .dialog) .close {}由于:is()取参数列表的最高特异性.dialog这一分支也连带获得了来自#dialog的ID 级特异性。也就是说 .close在两个分支上都被提升为#dialog .close的级联权重覆盖了样式作者原本可能预期的「.dialog .close应该更弱」的层叠关系。混合特异性让嵌套规则的权重比其部分匹配分支所暗示的要高这正是规则文档中强调的核心危害。规则概览与启用方式该规则在 rules/index.js 中以no-nesting-with-mixed-specificity导出元信息声明于 rules/no-nesting-with-mixed-specificity.jstype: problem、schema: []无任何配置选项、languages: [css/css]仅在 CSS 语言插件下生效。需要注意文档头明确标注该规则在recommended与unopinionated两个预设配置中均为禁用状态✅与☑️均未勾选需要手动开启。启用前必须先引入eslint/css语言插件并像 readme 中 Non-JavaScript files 一节展示的那样用files限定 CSS 文件范围import css from eslint/css; import unicorn from eslint-plugin-unicorn; import {defineConfig} from eslint/config; export default defineConfig([ { files: [**/*.css], plugins: { css, unicorn, }, language: css/css, rules: { unicorn/no-nesting-with-mixed-specificity: error, }, }, ]);一旦命中规则会在**子规则的 prelude选择器列表**上报告错误消息为Do not nest rules under selector lists with mixed specificity.见 test/snapshots/no-nesting-with-mixed-specificity.js.md 的快照输出。标准修复拆分父规则规则文档给出的第一种修复方案是把混合特异性的父规则拆开让每个分支各自独立持有子规则/* ✅ */ #dialog { .close {} } .dialog { .close {} }拆分后在#dialog分支内继承 ID 特异性在.dialog分支内只继承类特异性级联权重与视觉意图一致不再有「隐性放大」。允许的情形父选择器列表特异性一致并非所有选择器列表嵌套都会被报告。规则文档明确指出各条目特异性相等的选择器列表是允许的/* ✅ */ .dialog, .modal { .close {} }.dialog与.modal同为类选择器特异性均为[0, 1, 0]无论继承哪一个分支的特异性结果都相同不存在被放大或漂移的问题。测试用例test/no-nesting-with-mixed-specificity.js也验证了#dialog, #modal { .close {} }、.dialog, [open] { .close {} }等均属于合法写法。由此引申出第二种修复思路——均衡化父选择器的特异性只要让选择器列表中所有分支的特异性对齐例如都改成 ID、或都改成类嵌套规则的特异性就稳定可预期了。规则文档将其列为与拆分父规则并列的可行补救手段。源码视角特异性如何被计算与比较规则的核心逻辑位于 rules/no-nesting-with-mixed-specificity.js它用eslint/css-tree对选择器做 AST 解析并将特异性建模为三元组[a, b, c]对应 CSS 规范的 ID、类/属性/伪类、类型/伪元素三层权重IdSelector→[1, 0, 0]第 153-155 行ClassSelector、AttributeSelector→[0, 1, 0]第 157-160 行TypeSelector→[0, 0, 1]但*与|*通配符为[0, 0, 0]第 162-165 行PseudoElementSelector与旧式伪元素:before、:after、:first-letter、:first-line→ 元素级[0, 0, 1]第 140-141 行伪类的处理最有讲究getPseudoClassSpecificity第 112-144 行:where()的特异性恒为零:is()、:has()、:not()这类接收选择器列表的伪类SELECTOR_LIST_PSEUDO_CLASSES第 19-23 行取参数内各选择器特异性之和的最大值——这与浏览器对:is()的处理一致:nth-child、:nth-last-childof子句、:host、:host-context在自身[0, 1, 0]之上再叠加参数的最大特异性第 129-138 行。具体到判断流程create回调第 217-238 行规则遍历每个Rule向上查找最近的父样式规则用父规则各分支特异性的最大值作为的特异性getMaximumSpecificity第 48-58 行再计算当前规则各分支的特异性一旦发现父规则各分支特异性不一致hasMixedSpecificity第 193 行即对当前嵌套子规则报错。值得注意的是子规则不带时如{ .close {} }会被视为隐含嵌套选择器同样叠加父特异性参与比较第 185-191 行因此这类写法一样会被拦截测试中的#dialog, .dialog { .close {} }即为佐证。边界与局限什么场景下检查会「失效」规则文档对边界行为有明确交代这些行为在源码中都有对应实现伪元素分支被忽略无法表示::before这类伪元素因此规则只检查「能被嵌套选择器表示的」父分支canBeRepresentedByNestingSelector第 71-74 行。测试中的dialog, ::before { .close {} }被判定为合法而#dialog::before, .dialog { .close {} }也合法——因为混入伪元素的分支不参与比较。嵌套可穿透透明 at-rulemedia、supports、container、layer被归为「透明分组规则」TRANSPARENT_GROUP_RULES第 13-18 行嵌套规则可以穿过它们继续与最外层父规则比较。getParentStyleRule第 195-212 行在向上回溯时遇到这些 at-rule 会继续上溯快照中#dialog, .dialog { media (...) { layer components { .close {} } } }层层穿透后仍被报告的案例即是证明test/snapshots/no-nesting-with-mixed-specificity.js.md。scope与其他 at-rule 是边界getParentStyleRule遇到非透明的 at-rule 便停止上溯嵌套无法越过边界与更外层比较。不过边界之内的规则仍照常检查例如scope (.root) { #dialog, .dialog { .close {} } }依然会被报告测试第 63 行。函数式伪类内部不做情境有效性分析且由于eslint/css将嵌套的supports、container内容暴露为**原始文本Raw**而非结构化 AST规则无法解析其中的规则因此这类深层嵌套无法被检查——源码中hasNestingSelectorInRawArgument第 76-87 行仅能通过 tokenize 判断原始文本里是否出现过而非完整解析。为什么没有自动修复fixer规则文档在结尾明确说明该规则没有 fixer。原因在于无论是拆分父规则还是改写选择器都必须知道作者预期的文档结构与层叠意图——同样的代码在不同场景下「应该拆」还是「应该改特异性的某一侧」机器无法替人决定。这也是meta中未声明任何fixable标记的原因。因此实际工作流是让 ESLint 报告问题由开发者依据#dialog与.dialog各自的语义决定采用拆分还是均衡特异性的方案。建议与总结在项目 CSS 中使用原生嵌套时建议显式开启unicorn/no-nesting-with-mixed-specificity它不在recommended预设中并在持续集成中保持error级别。遇到报告时优先问一句「这两类选择器的特异性是否本就该一致」据此选择拆分父规则或均衡特异性两种方式规则文档与测试均认可。关注规则的四条边界伪元素分支豁免、透明 at-rule 穿透、scope截止、Raw 文本不可达——它们决定了该规则能覆盖的检查范围避免对其产生超出能力的预期。该规则的完整实现、测试用例与快照分别位于 rules/no-nesting-with-mixed-specificity.js、test/no-nesting-with-mixed-specificity.js 与 test/snapshots/no-nesting-with-mixed-specificity.js.md可供进一步对照研读。【免费下载链接】eslint-plugin-unicornMore than 300 powerful ESLint rules项目地址: https://gitcode.com/GitHub_Trending/es/eslint-plugin-unicorn创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
