CSS 嵌套 再次成为热门话题。还记得今年早些时候 Adam 和 Miriam 提出三种语法选项进行投票 吗?这些结果已经统计出来,结果几乎毫无悬念。
现在,您又有了另一个机会来表达您对嵌套未来的看法,这次是在 WebKit 博客上。Adam 和 Miriam 调查的结果引发了进一步的讨论,并增加了两个新的想法。这项新的调查让您从五个选项中选择。
Jen Simmons 对这些选项进行了全面概述,包括嵌套的回顾,我们如何得出五个选项的详细信息,以及大量示例,展示了这些选项在各种用例中的应用。让我们以这份简短的单题调查来回报他们为我们所做的努力。
我尝试投票,但看不到任何投票方式,只能看到目前的结果。也许投票已经结束?不过,投票开放时间似乎并不长。
真可惜,因为我会选择第 5 个选项,而它目前并不是最受欢迎的选项。我喜欢第 3 个选项的简洁性及其与 SASS 的相似之处,但潜在的奇怪错误和边缘情况让我有点担心。毕竟,这是关于选择 CSS 未来方向的。
第 4 个选项让我头疼,所以至少它不是最受欢迎的选项,我很高兴。
我看到 Jen 提到了最初的三个选项(1、2 和 3),第三个选项是“将嵌套语句括在方括号中”。我没看到这篇文章中使用该选项。怎么回事?我是不是遗漏了什么?
顺便说一下,我认为不应该由开发人员来决定这些事情。是的,我相信这是因为当前的获胜者是第 3 个选项。该语法有时会迫使您使用
:is()
,在我看来,这是一种最不成熟的方式,说实话,是对这种语言的侮辱。优雅已荡然无存,而a:b
问题可以通过查看后面的内容来解决——分号(它是规则)或方括号(它是选择器,我们正在嵌套)。但也许是我的天真在作祟,我之前没有参加过这些讨论,也许在我的示例中也遗漏了一些细节。
我认为,目的不是由开发人员来决定,而是 Jen 在最后提到的内容。
我不明白为什么他们说:“在以下许多示例中,& 是可选的。”
没有包含“.foo.bar”的示例。
但我认为第 3 个选项还可以——。
我也看不到任何投票方式。
如果我能投票,我会投反对嵌套 CSS 的票。每个示例都比使用非嵌套 CSS 更易于阅读、复制和调试。我认为嵌套应该留给预处理器或后处理器,这样它就是可选的。
我不明白为什么还要将此提出来投票。直接使用与 Less 和 Sass 多年来一直使用的相同嵌套样式——这是前端开发人员已经了解并期望的样式。
我很高兴普通的 @nest 获胜。
您可能需要仔细阅读 Jen 的文章,因为它涵盖了为什么我们无法使用与 Sass 或 Less 相同的语法。
最让我困惑的是,为什么人们会选择与 SASS 完全相同的语法,如果要选择这种语法,直接使用预处理器就行了。
在我看来,
@nest
与 CSS 语法更加一致,或者干脆不引入任何嵌套。CSS 不需要遵循预处理器的脚步,而应该专注于改进不受其控制的功能。
我不明白为什么第 4 个选项获得的票数最少。它比第 5 个选项干净得多,而且不像获胜的选项那样存在不允许在选择器中使用字母作为第一个字符的问题(:is() 解决方案并不优雅)。
我特别喜欢这一点。
这也很好用。