Less.js: 无法创建椭圆形边框半径

我想添加一个类似/相关的问题，该问题在声明行高时与font属性一起发生

.class {
    font: 13px/1.231 arial, helvetica, clean, sans-serif;
} 

它应保持不变，但变为：
。班级 {
字体：10.560519902518276px arial，helvetica，clean，sans-serif;
}

dotless也存在此问题（https://github.com/dotless/dotless/issues/16）。 达成一些协议在这两个方面如何进行将是一件很高兴的事情。

今天开箱即用的最简单解决方案是将其包装在字符串文字中。

 font: ~"13px/1.231 arial, helvetica, clean, sans-serif";

甚至

 font: ~"13px/1.231" arial, helvetica, clean, sans-serif;

我知道，更少的目标之一是与普通CSS语法兼容。 周围的工作违反了这一规则。

我了解您的无奈。 我看不到Less的算术和特定CSS属性之间的简单解决方案。 例如，如果您实际上要指定字体大小的一半，即

 <strong i="6">@example</strong>: 24pt;
 .foo {
     font: normal @example/2 sans-serif;
 }

必须妥协。 诚然，您可以更改Less，以便将所有转换打包。

 font: normal (@example/2) sans-serif;

但这会破坏所有情况下现有的Less样式表，并使之更加冗长，只是为了避免出现那些字体和边框半径速记声明不常见的情况。 如果您担心现有的CSS，可以使用另一种选择，可以将任何现有的CSS导入到Less文件中：

 <strong i="13">@import</strong> "legacy.css";

在这种情况下，导入成功，但是不会更改或转换CSS。

再次，我完全理解您的担心，即Less并不是CSS的严格超集，但是我缺少任何明显更好的想法。 您对此语法问题有任何潜在的解决方案吗？

：+1：关于这个问题，但我也不确定解决该问题的优雅方法，该方法既不需要转义有效的CSS，也不需要括号来触发计算。

@agatronic @cloudhead我正在努力解决此问题，但是在我进一步解决之前，我很乐意听取您的意见。 SASS和Stylus都只允许在括号内进行除法来处理此问题，所有其他数学运算都可以在括号内进行。 此方法还将防止W3C将来对斜杠的任何实现破坏，并消除了对Ratio和Shorthand解析器的需求。 这就是我最初倾向于解决此问题的方式。 这对你们俩来说都是合理的解决方案吗？

请注意，此错误还会破坏CSS3背景速记，后者使用斜杠将背景位置（可以是关键字或尺寸）与背景大小分开。 例如：

.foo {
    background: url(image.png) center / 1px 100px;
}

还要ping @matthewdl @Synchro

先前的建议是“ /”除而“ /”是一个比率。 最好从@cloudhead那里获取输入，因为尽管排序真的很不错，但是如果它破坏了现有的行为，那将非常可怕...

@cloudhead通过Twitter回应，有些微不足道： “ paren解决方案似乎很不错”

space解决方案的问题在于，它仍然会破坏完全有效的CSS。 不幸的是，在不破坏现有行为的情况下有效解决此问题的唯一方法是继续允许普通的旧CSS正确解析失败。

“临时”选项如何使人们可以在宽限期内享受这两者呢？

或者

我们应该在合并此修订之前发布一个版本，并将主要版本号提高到1.4（并希望在include和属性名称插值中添加变量）。

我认为这肯定是一个修复程序，必须将其作为更主要版本的一部分，因为它会破坏现有行为。 考虑到它仍然可能破坏现有代码，并且不确定是否提供任何永久过渡到永久解决方案的方法，我不确定临时解决方案（如果我们在谈论空格）是否合理。 在这种情况下，最好的选择是在发行版上触发触发器，并且可以通过“更改日志”和“文档”来警告人们。

我的意思是保留现有行为的标志..但我同意你的看法。

您有提交权吗？ 即使这样可能最好作为请求请求，所以我们
可以与发布协调（我们没有计划）

就我个人而言，我认为我们应该吞下药丸，并开始将不带括号的数学运算列为不推荐使用的功能。 在太多情况下，它与有效的CSS冲突。 @agatronic-值得与@cloudhead （或其他地方）进行Skype讨论，并且我

作为减轻打击的第1阶段，我们只能在除法不明确的情况下（例如，在斜杠“ /”是该值中的有效记号的地方）停止数学运算。 因此，在边界半径的情况下，如果不确定LESS，则将其保留。 如果作者确定要在两个数字之间进行除法，则可以通过添加括号来覆盖默认行为。

但是，就目前而言，LESS被记录为“有效CSS =有效LESS”，并且由于存在此错误，事实并非如此。 错误地重写了有效的CSS，这使其成为一个明显的错误。 问题在于它也是一个明确记录的数学运算。 两者之间存在冲突，在我看来，第二种情况是应保留CSS的情况下应该更改。

我看到@ttfkam和@ mlms13说的

@matthewdl +1

@agatronic ：我没有提交权，但是我同意无论如何都要通过PR来进行代码审查和潜在的发行协调。

@matthewdl ：出于我的PR的目的，我开始仅允许在括号内进行除法。 认为这是一项权宜之计，可防止LESS破坏有效的CSS。 它不限于特定规则，因此在遇到斜杠且未将其包装在括号中的任何地方，它将作为文字分界符输出。 完成此操作后，我将更多地研究如何将所有操作限制为仅在parens内完成。

好的，我已经在Skype上与@cloudhead进行了讨论。 他同意，所以这是计划：

1）在下一个发行版中，文档将更新，括号内的数学运算已被弃用。 该文档将在括号中演示数学运算。 但是，括号外的非除法数学仍应编译（对于该发行版）。

2）在步骤＃1之后的后续发行版中，所有数学运算都将需要括号。 该文档将从“不推荐使用”更改为“不支持”（或类似的内容-我们可以进行改进的沟通方式）。

听起来不错？ 这意味着我们应该开始计划接下来的两个发行版中的里程碑，但这不在此线程的讨论范围之内。

实际上，为了澄清起见，可以立即更新文档以表示不赞成使用括号外的数学，因为math IN括号可以正常工作。 所以这实际上是第0步：我们现在更新文档以告诉人们a）数学应该放在括号中，否则将来可能会中断，b）在括号中演示所有数学。

为我工作！ ：+1：

所以大概@dmcass应该对
https://github.com/cloudhead/lesscss.org

然后我们应该麻烦@cloudhead提交或授予我们对该项目的提交权？

啊对。 是的，我会尽量记住今天就此烦扰他。

2012年8月21日上午5:19，卢克·佩克（Luke Page） [email protected]写道：

因此大概@dmcass https://github.com/dmcass应该执行拉取请求
反对
https://github.com/cloudhead/lesscss.org

然后我们应该麻烦@cloudhead https://github.com/cloudhead
提交或授予我们对该项目的提交权？

-
直接回覆此电子邮件或在上查看
Gi tHub https://github.com/cloudhead/less.js/issues/146#issuecomment -7899194。

我已经打开公关来更新cloudhead / lesscss.org＃29中的文档

在1.4.0的主版上已修复

就像1.4.0中那样

在less2css.org上查看Alpha

如果使用以下CSS，则在1.4.1中仍会发生此错误：
border- radius：0 0 100％100％/ 0 0 24px 24px;

它输出：
border-radius：0 0 100％Infinity％0 24px 24px;

（我在http://less2css.org上尝试过）

@rubious是否在选项菜单中打开了严格数学运算？ 默认情况下它是关闭的，因此具有旧的行为。

可以，但是我正在使用LiveReload，并且似乎没有在此选项上启用该选项。

抱歉，这是修复它的唯一方法。.或者打开严格的数学运算，以便仅在括号内完成所有数学运算，否则

border-radius:0 0 100% 100% ~"/" 0 0 24px 24px;