这个嵌套的混乱是我的较少样式表的布局（减去任何实际样式）：
#branding {
h1 {
}
#tagline {
}
.ticker {
}
nav {
ul {
li {
a {
}
}
}
}
#search-form {
input {
}
button {
}
}
}
#masthead {
#store-locator {
}
#slider {
ul {
li {
}
}
}
#events {
article {
img {
}
h4 {
}
p {
}
}
}
}
#main {
#buckets {
ul {
li {
img {
}
h3 {
}
.description {
.author {
a {
}
}
p {
}
blockquote {
}
}
.more {
}
}
}
}
#social-feed {
hgroup {
}
#filters {
ul {
li {
}
}
}
#feeds {
.feed-column {
> div {
img {
}
h3 {
span {
}
}
.description {
p {
}
.author {
a {
}
}
}
}
}
}
#feed-amount {
a {
&:before {
}
&:after {
}
}
}
}
}
#summary {
nav {
ul {
li {
a {
}
}
}
}
#newsletter-form {
h4 {
}
input {
}
button {
}
}
#stay-connected {
h4 {
a {
}
}
}
#donation {
}
#contact-info {
#contact-number {
span {
strong {
}
}
}
#contact-details {
address {
strong {
a {
}
}
}
p {
}
}
}
}
这在某些方面对我有意义，因为它模仿了标记的布局，但它有一些严重的缺点，例如过度特定的选择器，IE：
#main #social-feed #feeds .feed-column > div .description p {}
我的问题是，将这份文件列出来的更好方法是什么？
我在这里滥用LESS吗？我搜索了＃34; LESS样式表示例＆＃34;和类似的东西，但我找不到一个完整的样式表的单一例子 - 任何人都可以提供一个精心设计的较少文档的例子吗？
答案 0 :(得分：2)
如果LESS 允许嵌套选择器，那么这并不意味着您必须 这样做。只需做与常规CSS相同的事情。
如果您的目的只是视觉层次结构，那么您可以在没有真正嵌套的情况下执行此操作：
#social-feed {
/**/
}
#feeds {
/**/
}
嵌套id选择器（如#foo #bar）通常没有意义（只要你的元素层次结构在不同的页面上是持久的）。
此外，在适用时使用儿童组合器是有意义的：
nav {
& > ul {
& > li {
& > a {
}
}
}
}
结果选择器（NAV > UL > LI > A）可能比上下文选择器（NAV UL LI A或NAV A）更快地工作。
答案 1 :(得分：1)
像你这样的选择器膨胀是一个“严重的缺点”，这就是为什么我会谨慎使用选择器的嵌套。对我来说，让CSS 完全与标记的布局相匹配并不重要。我可以使用一些稀疏的注释来帮助我知道我在CSS中的“部分”。让我来谈谈我如何改变一切。
示例
/* branding */
#branding {
h1 { }
.ticker { }
nav {
ul { }
li { }
a { }
}
}
#tagline { }
#search-form {
input { }
button { }
}
<强>讨论
首先，请注意如何将评论作为我的部分标题，而不是仅使用#branding对所有内容进行分组。这是我保留的一些“结构”，如html，我按主要的“包装”标题分组并保持它们彼此靠近。
其次，任何id标记都应该有自己的顶级嵌套组，假设您正确构建了您的html 以保持ID对页面的唯一性。我唯一的例外是，如果您在body元素上使用某个类来切换页面上的外观，那么外观更改的一部分包括对id选择的元素上样式的更改（但即使这样也可以通过将id作为最高级别来处理;请参阅下面的“利用&的力量”。所以我从#tagline下的巢中取出了#search-form和#branding。
第三，考虑一下你的设计和最小膨胀的代码。例如，如果页面上有其他nav元素（侧栏中的子导航等），那么将nav嵌套在#branding中是值得的。同样，如果您在该包装器外部使用其他h1或.ticker。但是，我鄙视的常见巢是ul li a巢。如果nav中的唯一列表是ul，则没有理由将li嵌套在其中，并在选择器字符串中以ul li结尾，因为它是给定所有li都在那里。同样，如果a中的唯一nav标记位于列表中，则无需嵌套。有这个css ......
#branding nav ul { }
#branding nav li { }
#branding nav a { }
...在选择器字符串中，与完整的嵌套版本一样干净且不那么臃肿。
I like the idea使用&将关键父代码添加到代码中。回想一下上面的例外情况，即在body元素上添加一个类来控制页面之间的主题（或外观）。你可以将它嵌套在主题类中，或者你可以这样做：
示例
#branding {
.theme1 & { }
.theme2 & { }
h1 { }
.ticker { }
nav {
ul { }
li { }
a { }
}
}
<强>讨论
然后会产生一个像.theme1 #branding这样的选择器来改变主题类#branding的外观。如果你需要这个来改变嵌套在它里面的项的属性，你可以通过各种方式来做到这一点（这在很大程度上取决于你希望最终输出看起来像什么样的结构）。一种方法是仅将其添加到所需内容中：
示例
#branding {
.theme1 & { }
.theme2 & { }
h1 {
.theme2 & { //special code only for theme2 here }
}
.ticker { }
nav {
ul {
//main code here
.theme1 & { //special code here }
.theme2 & { }
}
li { }
a { }
}
}
<强>讨论
缺点是代码中.theme类的一些额外重复，而优点是保持结束点< / em>目标已分组，因此例如上面的ul会产生这样的代码...
#branding nav ul {}
.theme1 #branding nav ul {}
.theme2 #branding nav ul {}
#branding nav li {}
#branding nav a {}
...保持所有各种ul代码彼此相邻。现在，如果li和a元素也需要更改主题，则必须决定是否要将主题向上移动一级，以便ul，{{1} }和li针对特定主题按主题分组，或者如果您将其保持在上面的最低级别，以便每个a，{{1并且ul保持按实际样式化的端点标记分组。
当然，使用li正常追加在嵌套中仍然有用，所以......
a ...生成&信息，无论a {
&:hover {}
}
的嵌套程度如何，都可以很好地使用嵌套和a:hover {}组合。
在这个问题上肯定会有更多的话题。关键是在需要的地方利用预处理器的强大功能，而不仅仅是因为它是可用的。对我来说，mixins是预处理器中更有用的部分，而不是嵌套。