Less.js: 条件 CSS 代码

访问http://www.lesscss.org/并搜索警卫。

为避免必须使用 mixins，请查看功能请求以允许对任何 css 进行防护。

是的，我知道，但是如果我们要编写大量的 LESS，我们必须编写和管理数百个 .mixins
我不认为 mixin 解决了这个问题。 甚至 mixins 也可以通过这个特性获得强大的功能。
更少的 CSS 几乎具有某些编程语言所具有的所有功能，那么为什么不这样做呢？

.button-maker (<strong i="8">@style</strong>: 'light') {
    cursor: pointer;
    display: inline-block;
    padding: 5px 10px;

    if(<strong i="9">@style</strong> == 'light'){
        /* adds light styling */
    }

    if(<strong i="10">@style</strong> == 'dark'){
        /* adds dark styling */
    }
}

我会为这个我真的很想念的功能添加一个大 +1。 用庞大的代码库维护守卫真的是一场噩梦。 这真的会让事情变得更容易......

我们甚至可以添加 switch 语句..

@lukeapage你能重新打开这个问题吗？ 我认为我们应该讨论这个问题/功能

LESS 不是脚本语言。 语法/样式类似于 CSS。

LESS 是声明性的，这意味着它不应该具有分支逻辑、循环等的复杂情况。

@pierresforge你有任何警卫不足的例子吗？

以及在任何选择器上都设置警卫无法解决的问题？

讨论是开放的..如果你能说服我（或核心团队的其他成员）他们是必要的，那么我将重新打开这个问题..但是之前已经进行过对话并且已经花费了很多时间.

这句话来自http://lesscss.org/
“LESS 通过变量、mixin、操作和函数等动态行为扩展了 CSS。”

是的，LESS 不是脚本语言，但它仍然具有变量、函数和操作等特性。
缺少的是条件逻辑。

我认为 CSS 媒体查询不过是条件逻辑。

<strong i="11">@media</strong> all and (max-width: 699px) and (min-width: 520px), (min-width: 1151px) {
  body {
    background: #ccc;
  }
}

如果 CSS 可以有条件逻辑，比如守卫。 那么区别是什么呢。 Guards 只是将其扩展到 mixins。
Guards 只允许 CSS 代码块外的条件，而不是代码块内的条件。
请参阅https://github.com/cloudhead/less.js/issues/1293#issuecomment -16929701 获取实例，警卫无法满足此类要求。

甚至 HTML 也有条件逻辑，是的，它是一种标记语言而不是脚本语言。

<!--[if gte IE 9]><!-->        
    <script src="" />
<!--<![endif]-->

@lukeapage谢谢..

守卫类似于媒体查询所做的事情。 请注意，在普通 CSS 中，您不能将媒体查询嵌套在选择器中； 您只能将它们放在文档的根目录下。

不，我没有任何警卫不足的例子。 但是，在很多地方，防护装置并不是最适合可维护性的。

一个例子：

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  if (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="7">@coreBackgroundColor</strong>, 20%);
  }
  else if (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="8">@coreBackgroundColor</strong>, 15%);
  }
  else if (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="9">@coreBackgroundColor</strong>, 8% );
  }
  else {
    background-color: @coreBackgroundColor;
  }
}

在我的意义上，它比：

.buttonBackground(@color) when (green(@color) > 50%) {
  background-color: darken(<strong i="13">@coreBackgroundColor</strong>, 20%);
}

.buttonBackground(@color) when (red(@color) > 30%) {
  background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 15%);
}

.buttonBackground(@color) when (red(@color) > 25%) {
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 8%);
}

.buttonBackground(@color) {
  background-color: @color;
}

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;
  .buttonBackground(@coreBackgroundColor);
}

我同意这有待讨论，但如果它不涉及很多核心更改，这将是一个非常好的补充。 它允许将大多数规则包装在一起以应用于单个元素，而无需添加 mixins。

这种情况就是我编写对比函数的原因 - 它充当一种条件操作，在其他情况下不可用，而且它比使用守卫要简洁得多，正如你所说。 我想我们可以实现某种通用函数来充当一种选择器，而不是为条件添加语法。

@Soviut Devil 的拥护者 - 在 LESS 中，您实际上可以将媒体查询放在选择器中，这通常非常有用。

我一直反对 ifs，因为它开始使您的代码的复杂性成倍增加，而 LESS 的设计目的是简单明了。 在这个时候，有一些推动稳定语言而不是添加新功能。

然而....魔鬼的拥护者，基于媒体查询现在出现在选择器中的逻辑，守卫理论上可以遵循相同的原则。

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;

  <strong i="9">@when</strong> (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="10">@coreBackgroundColor</strong>, 20%);
  }
  <strong i="11">@when</strong> (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="12">@coreBackgroundColor</strong>, 15%);
  }
  <strong i="13">@when</strong> (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 8% );
  }
}

or

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  background-color: darken(<strong i="16">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  background-color: darken(<strong i="17">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

比 ifs 更具声明性，更接近现有 LESS 的语法，并独立评估每个语句（如 LESS / CSS 已定义）。

或者（或除此之外），类似地，将 mixin 的评估附加到评估点：

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  .backgroundMixin(<strong i="22">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  .backgroundMixin(<strong i="23">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  .backgroundMixin(<strong i="24">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

可以说，语句级警卫与混合级别警卫 IMO 没有更多/更少复杂或不同的逻辑。 可能示例 2 和 3 对语言的扩展性较小。 只是想我会把它扔在那里进行思考/讨论。

我想没有人对我的申报守卫提案有太多话要说。 ;-)

其实，不，也没什么好说的。 这将是一件好事，IMO :)

是的，如果它们已经在 mixins 上，并且媒体查询可以在元素内部，那么扩展它们的逻辑似乎是合理的。 好奇@lukeapage和@jonschlinkert和其他人的想法。

@matthewdl :+1:

认为我已经在他们讨论的问题上支持他们...... :)

@lukeapage你在谈论问题#748 吗？ 如果是这样，我在语法中添加了一些内容。 ;-)

我想表达我对某种形式的if或@when的渴望。

我不同意守卫普遍更好并且使 LESS 代码比使用条件更简单的观点。 我发现实际情况是，守卫实际上使我的 LESS 文件更丑陋且更难阅读，但if / @when实际上会非常可读。 Guards 和if / @when条件本质上只是工具，它们都可以用来使事物变得美丽或丑陋，并且更适合不同的情况。 见鬼，我可以创建一个 ~300b 的 .less 文件，它只使用 LESS 最基本的选择器扩展功能来吃掉超过 1GB 的 RAM 并使 CPU 搅动几分钟。

在我最近的一个项目中，我打算大力支持桌面和移动设备，我最终决定用内联媒体查询来做这件事还不够好。 为甚至不会使用的任何一种模式提供额外的 css 听起来并不好，再加上尝试级联背景图像双重加载的整个麻烦，并且必须解决这个问题，同时仍然无法在不浪费时间的情况下嵌入数据 URI提供模式不会使用的整个图像。 通过尝试级联两个样式表来处理这个问题只会让我变得不那么混乱，因为现在会有两个地方为一个类声明样式。

我的决定是从 MediaWiki 如何处理 RTL 中学习一页，方法是从一个样式表中提供两个样式表。 MediaWiki 通过在 LTR 中编写样式表然后翻转样式表以创建第二个 RTL 样式表来做到这一点。 无需尝试覆盖为 LTR 指定的所有内容来处理 RTL。 同样，我决定在 main.less 中编写我的主要样式（以及可能从中引用的文件以分隔样式），该文件不会直接编译。 相反，我将有两个样式表，一个 desktop.less 和一个 mobile.less，这两个样式表都会设置诸如<strong i="14">@mobile</strong>: true/false; 、 <strong i="16">@desktop</strong>: true/false;之类的东西，并且还会覆盖一些更少的变量，例如事物的大小。 这样，我的 main.less 最终变成了 desktop.css 和 mobile.css，我可以处理媒体查询/测试，确定要在其他地方加载哪个（如果我真的想要，我实际上可以确定要加载哪个在甚至不支持媒体查询的设备上）。

然而，一个问题是条件块。 有部分代码我决定“移动不需要这些样式”或“桌面不需要这些样式”。 目前，我能做到这一点的唯一方法是：
（（好吧，从技术上讲，这些样式是假设的，因为我没有使用手风琴导航，但它们对我正在做的事情是正确的））

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  .dummy() when (<strong i="21">@desktop</strong> = true) {
    .accordion-styles();
  }
  .dummy();
}

在这种情况下，使用类似@when的东西会更容易理解。

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  <strong i="26">@when</strong> (<strong i="27">@desktop</strong> = true) {
    .accordion-styles();
  }
}

实际上，我考虑过预处理我的 less 文件，以将类似@when语法的东西变成一个 hack，其中创建了一个动态生成的 mixin+guard，然后直接包含在它之后。
不用说，如果预处理预处理器的想法听起来像是一个好主意，这将使事情更容易理解……当前的预处理器有问题。

事实是，这不仅适用于我的桌面/移动技术。 这同样适用于主题方案。 用您的主题编写一个主文件。 然后有一堆更少的文件，您只需将更少的文件包含到其中，然后设置一些更少的变量来控制诸如配色方案之类的东西。 颜色调整可以正常工作，但是一旦你发现你真的可以使用类似@use_horizontal_nav的东西，你就会立即从悬崖上跑下来。

@dantman从 1.5.0 开始，并且保护链接的 css 样式，您可以执行此操作

.navigation {
  & when (<strong i="7">@desktop</strong> = true) {
    color:red;
  }
}

这是你的例子的糖。

唯一的缺点是目前它认为它是一个新的选择器，所以它不会将它与之前的选择器合并。 但是，我认为这不太可能导致您出现问题，并且将是我/我们将在未来版本中修复的问题。

好的，谢谢，我们可以将其记录为功能吗？

老实说，与@when相比，我也不确定它是否易于理解，我不确定如果我以前在 .less 文件中看到过& when(...) ，我会明白它是什么一目了然。 @when作为& when()的糖可能会很好。

我同意@matthew-dean 添加这种条件结构可能会使LESS 核心文件更难维护和测试。 .less 文件更难调试等等。

我们现在得到的是一件艺术品，人们可以在不到 10 分钟的时间内理解和学习 LESS 的基础知识（我说的是嵌套和混合），添加条件语句只会让其他人更难消化，比如设计师和爱好者。 试图使用警卫来模仿或模拟 IF 语句只是试图加剧一个不存在且不需要解决方案的问题。

如果开发人员在编译它们的 LESS 文件之前需要更多的复杂性和控制，没有什么可以阻止他们使用 PHP 等语言来预处理一些更少的文件以实现更大的控制、灵活性和复杂性，有很多方法可以做到这一点只是用想象力以最正确或最方便的方式做到这一点。

例如，免得说我有一个名为“myfile.less.php”的文件，其中包含疯狂的代码，包括条件、开关、数组以及您可以在 PHP 上看到的所有花哨的东西，然后从那个“.less.php”文件中吐出另一个文件名为“myfile.less”，具有最终的 LESS 代码，这样我可以使用 PHP 查询所有服务器变量，决定@imports我的新 .less 文件将包含或排除什么，不再需要传递大量愚蠢的变量LESS 编译器，无需编写丑陋、难以阅读的愚蠢守卫来模仿模拟 IF 或 Switch 结构。

一个基本的工作流程可能是这样的

1-检查缓存是否过期
1-调用脚本查找和预处理所有文件“.less.php”文件
2-调用脚本编译所有“.less”文件
3-更新缓存

@enav我非常不同意。 除了开发较少，我在基于节点的企业解决方案中使用它，我们不想使用 2 种语言来解决问题。

@dantman有很多事情没有记录在案，是的，我们需要记录下来。 less-docs 正在努力扩展文档并使网站变得更好。 我会在那里添加一个问题。

@lukeapage ，是的，我最近注意到了。 我浏览了更新日志并注意到像 svg-gradient 和属性与 + 合并之类的东西。

严格来说& when ...已经记录在案，因为它只是两个记录在案的功能&和CSS Guards的简单组合。 但是一个专门的例子当然不会有害。

@seven-phases-max，我不知道该文档。 从外观上看，这是一套不完整的新文档来替换旧站点，“这将很快移至 lesscss.org 存储库！我们建议您避免链接到该站点，直到一切正常为止。” 评论。 很高兴知道类似的事情正在进行中。

我指的是 lesscss.org 上的当前文档，这是我所知道的唯一文档，并且目前仅将守卫文档作为混合功能，而不是暗示它在其他任何地方都可用。

守卫没有这个好。 :(

这是一个必需的功能，也存在于 cass 中。

为此 +1

就在今天这个评论是在这个问题被打开几年后提出的，我要指出的一件事是我现在想到的。

最初讨论中对@when的一些阻力是附加的规则。 不过，现在想来，应该是不需要的。

考虑到这两个块是相等的：

.a {
  & .b { color: blue; }
}
.a {
  .b { color: blue; }
}

那么这两个语句也应该被解析器接受为相等的。

.a {
  & when (1=1) { color: blue; }
}
.a {
  when (1=1) { color: blue; }
}

如果没有其他原因， & when在语法上真的很尴尬。 省略&仍然暗示与父选择器的选择器连接一直存在，因此省略&来暗示父选择器上的保护似乎不是一个飞跃。 此外，解析器现在接受块根函数与插件一起使用，因此它看起来不再像 2013 年那样奇怪。

我看不出有任何理由重新打开它。 毕竟我们已经有了#2072

when (1=1) { color: blue; }

只是为了两个字符的经济性而打开一个巨大的混淆框？

守卫没有这个好。

我认为甚至不值得评论一个随机的不合理评论。 任何位置都应该有它背后的东西（否则我会说任何条件代码都是蹩脚的，而if s 很愚蠢，因为我知道如何在几乎所有语言中甚至没有一个条件的情况下编写 _anything_ ）。

我看不出有任何理由重新打开它。 毕竟我们已经有了when (1=1) { color: blue; }

呃……不，我们没有？

但我们应该这样做是合理的。 我们可以只允许它并完成它。

等一下，直到我找到它应该链接到的功能请求（对不起，我在完成之前不小心点击了输入）

所以把它合并到#2072。

@七相最大

该问题称为“允许在受保护的自运行块内重新定义变量”，该问题底部的切线讨论包含与 select / case 和 vbscript iif([ifcond], [then], [else]) 类似的用例功能不仅仅是赤裸裸的时候，尽管这可能是讨论的更合乎逻辑的选择。 Buuut ...也许它应该作为一个新问题提出，只是when () vs & when ()问题。

只是 when () vs & when () 问题。

你不能认真对待这件事，对吗？ 究竟是因为什么？ 如果您删除& ， when不会变成if （所有原因请参见#2072）。 所以保持原样并完成它。

嘿，你能把它调低一点吗？ 如果您对此感到不安，请花点时间稍后再回来查看我在新问题中发布的推理。 自这些最初的讨论以来，一些事情已经发生了变化。

我不是故意冒犯或什么的。
我的：

所以保持原样并完成它。

只是回复：

我们可以只允许它并完成它。

@seven-phases-max 好的，文本中的音调丢失了。 在任何情况下，我都不是很喜欢这个想法，总的来说，现有的@when提案更好/更通用。

我认为'sass'总比less好。 它已经有了 if-else。 这真的很难，而且编码的行数更少。 什么时候可以工作，但不能完全满足需求。 此外，我们可以少做循环，但语言应该有它自己的特性。

@aukgit使用正确的工具来完成这项工作。 如果 SCSS 更适合您，最好使用它。 Sass 和 Less 是非常不同的项目。

@matthew-dean 在几个月的学习和写作量减少之后，如果“更少”的社区不想变得更好，那么这对我们俩来说都是损失。 我认为这就是为什么 bootstrap 从 less 移到“sass”（https://github.com/twbs/bootstrap/tree/v4-dev）（最初的原因是编译速度更快）。 而最初的来源是“少”。 现在他们在“sass”中编写他们的原始源代码，然后将其转换为更少（反之亦然）。

另一件事 ：

“正确工作的正确工具”

不应该在这里申请

减 | 文案 | 手写笔类似项目。 从当时流行的一个开始，现在似乎那个“少”的社区不想提高自己。

“少”背后的想法是少写多做。 在某处它确实减少了，但在某处它需要更多的写作。

谢谢您的意见。

狂热过时的宣传。 争论所有这些有偏见的或只是虚假的陈述将是浪费时间。

例如：

没有办法制作真正复杂的条件代码。

是的，“我需要一个工具来编写我的意大利面条代码”——就像这样。 如果你写这样的代码，确实 Less 绝对不是你的工具。

我认为“less”与 sass 和 stylus 有很大不同。 所有其他人都做类似的事情，而“少”声称它不是类似的事情。 :)

@aukgit

我认为“less”与 sass 和 stylus 有很大不同。

_为什么_它应该做同样的事情？ 请参阅示例[1]和[2]以找到设计之间的主要差异。 所以你可能不喜欢这个概念，但没有人强迫你使用你不喜欢的工具。

现在我懂了。 谢谢你。 确实，它确实是有史以来最被误解的语言。 甚至 javascript 也没有像 Douglas Crockford 所说的那样被误解。

人们在js中会犯错误，但有很多意识。 对于“少”，它应该在第一页（less.org）中描述什么是少，什么不是。

谢谢你。

写了一个 mixen ：

较少的：

.if-value-present(@attribute; <strong i="7">@value</strong>: '') {
    .x (@value) when not (<strong i="8">@value</strong> = '') {
        @{attribute}: @value;
    }

    .x(@value);
}

.if-value-present-multi(@attributes; @values) {
    .iter(@i) when (<strong i="9">@i</strong> > 0) {
        .iter(<strong i="10">@i</strong> - 1);
        // loop

        <strong i="11">@attr</strong>: extract(<strong i="12">@attributes</strong>, @i);
        <strong i="13">@value</strong>: extract(<strong i="14">@values</strong>, @i);

        .if-value-present(<strong i="15">@attr</strong>, @value);
    }

    <strong i="16">@len</strong>: length(@values);
    .iter(@len);
}
.x {
    <strong i="17">@var</strong>: c1,c2, c3;
    <strong i="18">@val</strong>: v1, '', 'wddww';
    .if-value-present-multi(@var;@val);
}
.x{
    .if-value-present(content, 'new val');
}

CSS 输出：

.x {
  c1: v1;
  c3: 'wddww';
}
.x {
  content: 'new val';
}

如果“少”社区不想变得更好，那么这对我们俩都是损失

我认为假设“不支持我想要的 X 功能”==“更少的社区不想变得更好”是错误的。 那不会让我们到任何地方。

Github 上有几个关于改进控制流的讨论。 事实上，这个帖子并没有被拒绝，它已被合并到#2072。 你评论了一个封闭的 3 岁线程。 我有一些其他的想法，我认为它们可能与 #2072 有点不同，但基本上是相反的。

现在似乎没有更好的功能

Less 没有 _more_ 特性，这是真的。 这是设计使然。 这样您就可以在一天内学习 Less，Less 的功能涵盖了 99% 的典型用例。 Sass 的学习曲线更陡峭。 Sass 有太多的功能膨胀，以至于他们必须构建一个基于 C 的低级编译器才能继续编译它。 这是一个伟大的成就。 但对于归根结底只是制作样式表的东西来说，这并不是一个很好的证明。

现在他们在“sass”中编写他们的原始源代码，然后将其转换为更少（反之亦然）。

没错，但这是基于多种因素，你可以问他们会是什么。 我个人觉得放弃 Less 用户是一个错误，因为现在有很多人在 Less 中使用 Bootstrap。

归根结底，您对编写条件语句所需的箍的抱怨_没有错_。 这里提供的示例根本不适合该语言。 我建议您阅读 #2072 中的主题。

（这实际上有点离题，但我只是想知道）

<strong i="7">@var</strong>: c1, c2, c3;
<strong i="8">@val</strong>: v1, '', 'wddww';

除了调用.if-value-present-multi之外，这些变量还有什么用途？
（并且 _if_ 这些变量 _are_ 用于其他用途）是否有意义，改为使用属性/值对，例如：

<strong i="14">@rules</strong>:
    c1 v1,
    c3 'wddww';
   // no need for c2 since it has no effect

此外，如果您只需要.x {content: 'new val'} ，那么编写.x {.if-value-present(content, 'new val')}的目的是什么？ 如果它什么都不做，那就写.x {.if-value-present(content)} ？

（虽然老实说我确实看过[1] - 好吧，除了一件事之外不评论任何东西：（_只是为了节省您的时间_）考虑扔掉像elements和lesshat这样的古老库 - 并且使用autoprefixer代替。我们暂时不需要任何 CSS 预处理器的供应商前缀库）。

这通常是大多数“功能请求”的来源： “XY 问题” 。 （相关领域中其他类似失败的好例子：#1400 和#1894，并不是说这些功能完全没用（因此两者都保持开放），但是当人们开始询问它们的实际用例时，它通常会显示试图解决 X 只是错误的 Y）。

那么这里是用例：
如果没有给出最后一个参数，我尝试使用 3 个参数制作 mixn，那么它应该在 mixn 内创建它的属性，这就是条件有用的原因。

在这里https://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/responsive/responsive-placements.less我试图一次又一次地实现相同的混合，我可以实现它有条件很容易。

我现在明白了。。谢谢大家。

@aukgit您应该能够轻松折叠这些mixin。

https://gist.github.com/matthew-dean/e617bc1f71528843ef9fa73d70427bcf

感谢@matthew-dean 抽出宝贵时间帮助我。 :) 我对你很满意。

:)

我认为'sass'总比less好。 它已经有了 if-else。

两种语言都有自己的问题。

他们缺乏动态导入 -以及他们不愿实施它- 是我想从 Sass 切换到 Less 的主要原因。 多年来，Less 一直拥有此功能！

然而，缺乏传统的控制结构（如 FOR 循环或 IF-ELSE 语句）和令人畏惧的语法是阻止我做出这一举动的原因。

我感觉被困在一块岩石和一个坚硬的地方之间......

@jslegers与 #249 中的评论相同。 自 v1.x 以来，Less 具有各种形式的条件限制（在新版本中越来越多）。

@七相最大

我知道受保护的 mixin可以替代 IF 语句，而递归混合可以替代 Less 中的循环。 但这就是我在 Less 中有关控制结构的文档中所能找到的全部内容。 作为具有多种语言编程经验的人，我发现他们的语法令人困惑，而且 - 老实说 - 非常令人畏惧。

如果除了那些值得一提的控制结构之外还有其他控制结构，我无法在文档中找到它们。

无论如何，像...

scss a { <strong i="11">@if</strong> $time == morning { color: red; } <strong i="12">@else</strong> if $time == afternoon { color: blue; } <strong i="13">@else</strong> { color: grey; } }

...或类似...

scss <strong i="17">@each</strong> $author in $list .photo-#{$author} background: image-url("avatars/#{$author}.png") no-repeat

... 或这个...

scss <strong i="21">@for</strong> $i from 1 through 8 { $width: percentage(1 / $i) .col-#{$i} { width: $width; } }

... 在我看来，在 Sass 中比在 Less 中编写与受保护的 mixins 或递归 mixins 类似的东西更具可读性和优雅得多。

缺少这样的语句和 Less 的整体可读性较差的语法（与 Sass 相比）是我更喜欢坚持使用 Sass 的两个主要原因，我什至不愿意在我的一个项目中考虑使用 Less。

考虑到 Sass 比 Less 更受欢迎，我显然不是唯一一个有这种感觉的人。

@jslegers对于您的示例-在发布它们之前尝试了解已经可用的内容。
对于其余的（流行等） - 以这种过于简单的方式讨论某些事情是没有意义的（Stylus 拥有所有这些，那又怎样？），此外，Less 从未被宣布要取代其他 CSS 预处理器，也不会成为它们的克隆。 最后，最常见的错误是认为某事物的流行是该事物作者的主要和唯一目标。

在发布之前尝试了解已经可用的内容。

尝试更好地记录或将人们直接指向他们正在寻找的东西，如果他们没有找到它。

对于其余的（流行等） - 以这种过于简单的方式讨论某事是没有意义的 [...] 最后，最常见的错误是认为某事物的流行是该事物作者的主要和唯一目标。

仅供参考，我从未暗示流行度是质量或有用性的有力指标。 事实上，很多时候情况正好相反。

不过，如果你看看为什么人们从 Less 转向 Sass，那还是很简单的......

就我个人而言，除了通常的“我想要我的 PHP 意大利面条”（参见上面关于错误工具的帖子）之外，我什么也看不到，甚至没有计算它的 2012 年（我已经暗示这些示例中的大多数在现代 Less 中都非常紧凑，但它看来你不想醒来）。
但没关系，通常我只争辩一个明确的错误信息，关于为什么会发生或没有发生某事的个人意见的讨论完全不符合我的兴趣。

就我个人而言，除了通常的“我想要我的 PHP 意大利面条”之外，我什么也看不到

在我看来，使用 Less 代替 Sass 会使你的代码不可避免地看起来像“PHP 意大利面条”（如果你认为 PHP 是意大利面条代码的缩影，那么你显然从未做过任何 ABAP 编程），只要你想做一些更复杂的事情比基本变量和混合，但我愿意考虑我在这里错了。

我已经暗示这些例子中的大多数在现代 Less 中都非常紧凑，但似乎你不想醒来

那么为什么不努力唤醒我，给我一两个可以让我摆脱无知的消息来源呢？

没有什么比有人证明我错了更让我兴奋的了。 根据我的经验，这是最好的成长方式...