Less.js: 多次@importing 时的重复属性(嵌套@import)

创建于 2010-06-25  ·  49评论  ·  资料来源: less/less.js

大师@imports A & B,
B @进口A

在主文件中使用来自 A 的 mixin 时,属性会重复

有关更多信息,请参阅单元测试

配置:ubuntu 10.04 上的lessc cli 版本1.0.21

所有49条评论

我想问题是文件被导入了两次,这是 mixin 的正确行为。

你认为它应该两次导入文件吗? 如果不是,它还应该考虑相对 url。 例如

// in main.less
<strong i="6">@import</strong>: imports/import1.less;
<strong i="7">@import</strong>: imports/import2.less;

// in imports/import1.less
<strong i="8">@import</strong>: import2.less; // don't import this
<strong i="9">@import</strong>: imports/import2.less; // do import this

嗯,我想知道是否有更简单的方法来检查一个文件是否等于另一个文件。 也许标题中的某些内容。

文件大小是一个廉价的指标,并且在任何给定的源文件集中很可能是唯一的。 但是,_可能_有 2 个相同大小的文件。

与修改日期类似。

如果服务器设置了 ETag 标头,您可以/应该使用它。

我们在缓存时使用文件内容的 MD5 哈希作为键,但我个人认为这有点矫枉过正。

嗯,是的,问题是 javascript 没有原生 MD5,或者我会使用它..
ETag 是理想的,但有些服务器没有设置它。 我得考虑一下。

我们似乎同意不应将文件导入两次。 然而,它总是正确的吗? (即在范围的帮助下,在 mixim 中导入可能没问题 - 在这个问题上你可以比我回答得更好)。

许多语言已经以不同的方式解决了这个问题:

  • C -> #ifndef / #define / #endif
  • PHP -> include_once()

“C 方式”可能有点难以实现,但条件可能提供其他很好的可能性。

如果选择“PHP 方式”,我们需要选择一种区分文件的方式。 绝对 URL 似乎是一个不错的选择(我们直接或通过 document.location + 相对 URL 获得它) - 我认为它比 size / length / MD5 更好,因为它不消耗 HTTP 请求。
然而,这可能还不够:每个 URL 映射到单个文件,但每个文件可能映射到多个 URL。 在这种情况下,引入新关键字@<strong i="16">@name</strong>: <unique name>可能会有所帮助。

@import_once算法将是:如果尚未导入绝对 URL,则获取文件并检查 @@ name是否已导入,如果未导入文件。

我同意。 在单个请求的上下文中,您应该能够假设资源不会改变。 所以绝对网址应该足够好。

检查文件更改是另一回事。

我认为我们应该多次保持@import import,因为这就是原始@import 的工作方式,

我喜欢@vicb的类似 php 的解决方案,但我更喜欢“评论”中更好的内容而不是@import_once ,因此它仍然与原始 css 语法兼容。

我们可以在 .less 文件的顶部添加这样的东西吗:
/_! 要求:url (./abc.less)_/

我也遇到这个问题。 我的项目有一个层次结构的 LESS 文件编译成一个 .css 文件。 有一个实用程序 LESS 文件包含在多个文件中,最终所有 mixin 的复制次数与导入该实用程序文件的次数相同。

一个@import_once ,或者@import : once url('url'); 会解决这个问题。

我们在我们的项目中面临与@NielsJanssen相同的问题,知道这个问题什么时候可以解决吗?

也遇到了这个问题。 有人想出解决办法吗?

这里有同样的问题。 找不到简单的解决方案,只是最终重新安排了导入,以免它们被导入两次。

如果您使用 node.js,我真的建议您查看Stylus 。 我用了一段时间 LESS,对它完全缺乏开发感到沮丧,切换到SASS ,然后最后到 Stylus。 它确实突出了功能,语法是可选的(我使用了中间立场),它非常强大,并且 TJ 是一个非常敏感的开发人员。

如果您不使用 node.js,您仍然可以使用带有 ruby​​ 的 Stylus 并在您的机器上进行编译。 如果您因任何原因不喜欢 Stylus,SASS/SCSS 也是一个不错的选择,可以用同样的方式完成。

长话短说:从长远来看,LESS 没有好处。

态度极差的人。

没必要把那个 bs 贴在这里。 您可以通过邮件或类似方式发送它。 你不能有这么高的标准,比如想要一个“真正响应式的开发人员”来免费使用一些东西。

绝对不。

当我第一次发现 LESS 时,我会喜欢这个建议,这样我就不会浪费数周的时间来适应它,并在我最终离开时转换为它和从它转换。 当然,我应该首先自己注意到这一点,因为开放问题比封闭问题多,而且其中大部分都没有得到回应。

这不是关于我可以或不能拥有什么标准。 这是关于在有更好的选择时向人们发出警告。

所以我支持我的“BS”并希望人们发现警告有帮助。

@ianstormtaylor :说一个项目“从长远来看没有好处”有点歇斯底里。

也有同样的问题。

无无

<strong i="7">@import</strong> "bar.less";
<strong i="8">@import</strong> "baz.less";

无酒吧

<strong i="12">@import</strong> "mixins.less";
.bar {
  .mixer
}

baz.less

<strong i="16">@import</strong> "mixins.less";
.baz {
  .mixer
}

mixins.less

.mixer {
  color: 000;
  border: 2px solid #fff;
}
$ lessc foo.less
.mixer {
  color: 000;
  border: 2px solid #fff;
}
.bar {
  color: 000;
  border: 2px solid #fff;
  color: 000;
  border: 2px solid #fff;
}
.mixer {
  color: 000;
  border: 2px solid #fff;
}
.baz {
  color: 000;
  border: 2px solid #fff;
  color: 000;
  border: 2px solid #fff;
}

我早些时候没有参加这个讨论,但现在我遇到了同样的问题...... @wlangstroth我不认为@ianstormtaylor是歇斯底里的。 只需检查此项目的未解决问题列表以及其中一些已打开多长时间。 less 是一个有用的工具,但我认为这是一个公平的评估,即支持是有限的,并且在等待时会非常令人沮丧。

我的印象是@cloudhead基本上忽略了我所做的任何评论(也许我在这方面错了)但最好听到“我很忙”或“我不想解决这个问题”甚至更严厉的话而不是根本得不到回应。

您_可能_只有一个包含所有导入的main.less文件。 参见twitter bootstrap示例(主文件是bootstrap.less )。

我导入的一些较少的文件(从外部库)被编写为能够独立编译,因此它们每个都包含一个共同的variables.less并且我看到的问题发生是因为我导入了每个文件将较少的文件合并到一个主文件中,然后编译该文件,将每个 mixin 应用到包含 mixin 的次数(对于我从外部库中包含的每个文件一次)。

你是对的 -_可以_做你建议的事情,_并不意味着每个人都这样做。

此外,解决方法(_only_,如果我没有使用第 3 方库)不会改变这是一个错误。 我已经非常熟悉如何以更少的方式解决问题,但令人沮丧的是,像这样的错误已经开放了近 18 个月。 ( @wlangstroth我意识到这不是 _your_ 的错)

对于任何感兴趣的人,我有一个蛮力修复(未针对@vicb的测试进行测试,但应该可以工作),我粘贴在 #431 的评论中。 如果我有更多时间,我将尝试找到更好的解决方案。

有同样的问题

也有这个问题,但通过将我的 mixin 库导入我的 bootstrap.less 来修复它。 没有意识到后续导入可以访问它们,但这是有道理的。

仅供参考 #431 是解决此问题的拉取请求

@cloudhead您能否为此应用修复程序。 这可能是仍然开放的最古老的问题之一。 很高兴看到它得到解决。

同样的问题:-(

作为对遇到此问题的任何人的建议,我建议您在 Twitter 上给 Alexis 留言。 亚历克西斯此前曾在几张罚单中表示,他无法监控所有问题,只有在他意识到严重性时才会进行修复。 我认为这是一个严重的问题,但未能在 Twitter 上引起 Alexis 的注意。

也许其他人可能有更多的运气。

推特: https :

并在此问题中添加链接: https :

@Kalyse如果@cloudhead无法充分监控该项目的问题,那么每个人都更有理由避免使用它。 人们建议他应该提名其他人来帮助管理积压的问题,但同样没有回应。

当我在一个问题中提到他们时他们已经可以收到警报,为什么我需要使用 Twitter 来引起他们的注意? 我认为@cloudhead无法对已经公开了 2 年的问题做出回应是可耻的——他至少可以找到几个他信任的人,并让他们开始处理积压的未决问题。 他们至少可以关闭重复项并帮助减少他的未解决问题的数量。

github 通知系统完全没用——我每天收到大约 70-100 条通知,所以我宁愿忽略它们。

我要去看看这个。。

好的,我添加了一个@import-once指令 - 它非常基本,因为它只检查路径是否匹配 - 但它应该涵盖大多数用例。

@cloudhead很高兴您有时间解决这个问题! 为什么不过滤输出中的重复规则?

我个人不明白,如果甚至不考虑拉取请求,为什么这个项目甚至在 Github 上,或者如果问题被忽略,为什么问题跟踪器甚至在运行。

轻松的人! 如果任何人有一个如此受欢迎的项目,他们就会在同一条船上。 @cloudhead做得很好,也许确实需要添加一些值得信赖的人作为管理员。 但是拉取请求和测试的问题比单独的问题更有帮助。 也许在你放松的时候解决一些问题。

人们已经解决了很多问题,有时是几年前。 去检查 74 个未完成的拉取请求之一,但没有响应。 例如,这个问题有很多可以追溯到 2 年前的骗子(比如 #324 #71)。 这是一个可以非常简单地解决此问题的拉取请求: https :

@cloudhead - 亚历克西斯,这是一个太大的项目,不能让它年久失修。 当人们看到上面提到的那种东西时,会给他们留下这个项目不可信或不可靠的印象。 而且没必要! github 的神奇之处在于,您可以轻松找到一些编写出色代码并对项目感兴趣的人。 询问那些好人他们是否会帮助缓和问题和拉取请求。

我们都喜欢你的工作。 社区希望提供帮助。 让我们帮忙!

@jeremyricketts好点。

我同意@jeremyricketts——在我工作的一家公司,我们最终没有选择 LESS(采用 SASS 路线),因为此 repo 中缺少更新/错误修复。

@cloudhead看起来@import-once指令不起作用,这是我的测试用例。

// a.less
.gain-bfc() {
  overflow: hidden;
  *zoom: 1;
}

// b.less
@import-once "a.less";

// c.less
@import-once "a.less";
@import-once "b.less";

div {
  .gain-bfc();
}

编译c.less ,预期的结果应该是

div {
  overflow: hidden;
  *zoom: 1;
}

但我得到了重复的属性

div {
  overflow: hidden;
  *zoom: 1;
  overflow: hidden;
  *zoom: 1;
}

+1 杰里米里克特

需要有一些实际编程能力的人。 我的世界是 PSD、铅笔和纸,以及 html CSS 和轻量级 jQuery 工作。

需要几个人来分类问题和拉取请求,
修剪重复项,确保有错误的测试用例等。我想要
至少自愿提供帮助,我可能可以提供帮助
也关闭较小的错误。
2012 年 3 月 23 日下午 1:28,“杰瑞米·里基茨”<
回复@reply.github.com>
写道:

需要有一些实际编程能力的人。 我的世界是PSD的,
铅笔和纸,以及 html CSS 和轻量级 jQuery 工作。


直接回复此邮件或在 GitHub 上查看:
https://github.com/cloudhead/less.js/issues/49#issuecomment -4667283

@cloudhead万一您正在努力想出一个好的解决方案,您应该看看不久前的@neonstalwart解决方案。

基本上,如果存在与当前属性具有相同值的现有规则,则永远不应将规则添加到选择器中。 您还必须检查属性值,因为对于背景,您可能会添加几个不同的背景,因为它们在不同浏览器中的处理方式不同。

你觉得这个解决方案怎么样@cloudhead
好像是前进的方向?

不修复这意味着:

1) 文件比他们需要的大。
2) 将 CSS 分散到多个文件并导入批次变得不可取,因为每次包含一个也包含 mixin 的附加文件时,您将再次添加该 mixin 的值。 我可能有 80 个 lessCSS 样式,这意味着当我进行 .background() 渐变混合时,会为每个选择器生成 80 * 6 个附加样式。 (6 支持所有不同的浏览器)。
3)它也会减慢页面渲染速度。 由于额外的样式,我的每秒绘制/刷新速度急剧下降。

想法@cloudhead
干杯。

@cloudhead如果我们从最新提交中针对此问题提出拉取请求,您会考虑合并吗?

这是修复: https :

@Kalyse你能给我发一封电子邮件吗? 亚历克西斯@cloudhead.io

干杯

也许需要一些额外的可信开发人员来批准拉取请求?

@cloudhead我使用 WinLess 来编译我的 LESS 代码...... WinLess 附带了 less.js 的最新发行版(请参阅 https://github.com/marklagendijk/WinLess/issues/14),所以任何想法(和其他修复程序) ) 将添加到最新版本?

谢谢(伟大的产品)。

所以,呃呃......我们在这方面做得如何?

@jreading我认为它已通过提交 cb7893在 git 中

似乎已修复(或至少是原始问题),如果没有,我确定还有另一个错误可以解决这个问题。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

MarkSG93 picture MarkSG93  ·  4评论

BrianMulhall picture BrianMulhall  ·  4评论

briandipalma picture briandipalma  ·  6评论

seven-phases-max picture seven-phases-max  ·  6评论

matthew-dean picture matthew-dean  ·  6评论