在 LESS CSS 中使用通用选择器作为 mixin

Posted 2023-03-06

【中文标题】在 LESS CSS 中使用通用选择器作为 mixin

【英文标题】：Using a general purpose selector as a mixin in LESS CSS

【发布时间】：2012-11-12 02:33:09

【问题描述】：

我知道混合和参数混合。我们正在寻找一种将 CSS / LESS 中的任何通用选择器变成 mixin 的方法。

例如在Twitter BootStrap，我们有here

.navbar .nav > li 
  float: left;
 

如果我必须在课堂上使用它，比如 .mynavbar，我希望能够做到这一点

INPUT->
.mynavbar 
  .navbar .nav >li;

---

OUTPUT->
.mynavbar 
  float:left;

现在我知道当前版本的 LESS 无法做到这一点，因为编译器会标记解析器错误。我希望有人帮助我稍微更改一下 less.js 的源代码，以便它可行。

我已成功联系到the source code for the mixin parser。我尝试在那里更改 RegExp，但它会干扰解析器的其他部分。我知道我们只需要进行一些更改，因为我们不仅要接受 .mixin 和 #mixin，还必须接受任何 mixin，例如标签/属性选择器，例如 input[type=text]。

目前是开发使用 Bootstrap 的 UI 框架所需要的。不幸的是，bootstrap 中的许多地方都充斥着直接标签选择器，而不是 id 和类。

【问题讨论】：

你为什么要这个？为什么不为你想要的样式制作一个 mixin，并在你需要的地方包含 mixin？例如... 取 Twitter Bootstrap 中具有直接标签选择器的位置，复制其中的代码，并为该代码创建一个新类。然后将 mixin 应用到直接标签选择器。

@JohnKurlak 是的。这就是我们为内部 LESS 代码所做的事情，但是对于具有非常快的发布周期的 Bootstrap，每次他们发布新版本的代码时，我们都必须通过继续复制代码来更改我们的类混合。

【参考方案1】：

这是可能的 since version 1.4.0 (2013-06-05) 的 LESS 包括 extend 功能。基于原始示例

.navbar .nav > li 
  float: left;


.mynavbar:extend(.navbar .nav > li) 

编译成

.navbar .nav > li,
.mynavbar 
  float: left;

文档here 以及原始问题here 的讨论和示例使用

编辑：添加代码示例

【讨论】：

您之前的答案已被删除，因为它只不过是一个链接。如果链接中有示例代码，请在此处添加。

【参考方案2】：

首先，我强烈反对这样做。相反，请尝试使用 CSS 的强大功能并构建您的 html，以便应用引导规则。无论如何，既然你要求它，这里就是解决方案。

问题不在于选择器或子规则的复杂性，而是标签名称选择器部分（即li）。所以，我们必须解决的是 mixin 解析器只匹配类和 id。我想我们不想篡改the first class or id test，因为这可能需要将 mixin 与正常的 CSS 规则区分开来（尽管测试运行良好，该检查已被注释掉）。（实际上，有运行中的解析器首选项，在 mixins 之后唯一尝试的是 cmets 和指令，因此我们也可以安全地删除该检查）。但是，我们可以通过在匹配的正则表达式中 [#.] 之后添加一个问号来轻松地在 mixin 选择器的后面部分中允许标签名称。所以

while (e = $(/^[#.](?:[\w-]|\\(?:[A-Fa-f0-9]1,6 ?|[^A-Fa-f0-9]))+/)) 

–i。 e. line 825 - 变成

while (e = $(/^[#.]?(?:[\w-]|\\(?:[A-Fa-f0-9]1,6 ?|[^A-Fa-f0-9]))+/)) 

之后，测试用例仍然可以正常运行，但会出现细微的损坏，所以要小心。

编辑：有一个GitHub Issue 可以解决同样的问题。显然，更少的人更希望 mixin 功能更窄和更类似于函数，而不是允许更灵活的……嗯……混合规则。关于 CSS 输出，这可能是合理的。

【讨论】：

我完全同意你的看法。对于我们的“原生”网站，我们会修改 HTML 以使其与引导程序同步。实际上，我们希望将 Bootstrap 集成到 javascript 框架及其 CSS 品牌中。 HTML 标签是我们无法控制的。话虽如此，您不认为在任何情况下直接设置标签选择器的样式都是不好的做法吗？

非常感谢您的回答！如果可能，您能否详细解释一下 RegExp？你认为它会在哪些边缘情况下失败？我不太了解“头等舱或身份证测试”。这是一个有效的观点。 Tag Selector 将充当 mixin 还是将成为该选择器所有样式的 Computed 输出。我们还没有完全测试它。会尽快给你反馈。

好的，所以我又看了一下解析器。有一个 explicit order 尝试解析事物，而现在 mixin 调用仅在 cmets 和指令之前尝试，因此这些是过度热心的 mixin 调用解析器可能错误地接受的唯一事物。由于两者都经过严格解析，我们可能会将 mixin 调用 parse 移到 prio 列表中。我推了一个more robust version，顺便说一句。