Can't create elliptical border-radius

[marioestrada]

With the revised CSS3 specification it's possible to create elliptical border radius with the following syntax:
-webkit-border-radius: 40px/10px;
-moz-border-radius: 40px/10px;
border-radius: 40px/10px;

But less parses this and it calculates 40/10 so it actually becomes 5, like so:
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
border-radius: 5px;

There should be a way to write this syntax without Less parsing it.

[neonstalwart]

i wanted to add a similar/related problem which happens with the font property when declaring a line-height

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

it should remain unchanged but it becomes:
.class {
font:10.560519902518276px arial,helvetica,clean,sans-serif;
}

[lukeapage]

dotless also has this issue (dotless/dotless#16). It would be nice to come to some agreement how to proceed in both.

[ttfkam]

The simplest solution that works out of the box today is to wrap it in a string literal.

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

or even

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

[ChrisCinelli]

I understood that one of the goals of less was to be compatible with normal CSS syntax. The work around break this rule.

[ttfkam]

I understand your frustration. I can't see an easy solution between Less's arithmetic and specific CSS properties. For example, what if you actually want to specify that the font is half the size, i.e.

 @example: 24pt;
 .foo {
     font: normal @example/2 sans-serif;
 }

Something has to compromise. Admittedly, you could alter Less so that any conversions are wrapped.

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

but that would break and make more verbose any existing Less stylesheets for all cases just to avoid cases which aren't as common for font and border-radius shorthand declarations. Another option if you are worried about existing CSS, you can import any existing CSS into your Less file:

 @import "legacy.css";

In this case, the import succeeds, but does not change or convert the CSS.

Again I fully understand your concern that Less is not a strict superset of CSS, but I lack any obviously better ideas. Do you have any potential solutions to this syntax problem?

[mlms13]

👍 on this issue from me, but I'm also not sure of an elegant way to solve it that doesn't require either escaping valid CSS or requiring parentheses to trigger calculations.

[dmcass]

@agatronic @cloudhead I'm working on a fix for this, but I would love to get your input on how you think this should be handled before I take it any further. SASS and Stylus both handle this by only allowing division inside parentheses, all other mathematical operations can be done outside parens. This method will prevent any future implementations of the slash by W3C from breaking as well, and remove the need for the Ratio and Shorthand parsers. This is how I was first inclined to fix the issue. Is this a reasonable solution for both of you?

Note that this bug also breaks CSS3 background shorthand which uses the slash to separate background-position (which can be keywords or dimensions) from background-size. For example:

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

Also pinging @MatthewDL @Synchro

[lukeapage]

A previous suggestion was that ' / ' divides and '/' is a ratio. It would be good to get input from @cloudhead because though it would be really nice to get sorted, its pretty scary if it breaks existing behaviour...

[dmcass]

@cloudhead responded via twitter, somewhat minimally: "the paren solution seems decent"

The problem with the spaces solution is that still breaks perfectly valid CSS. Unfortunately the only way to address this effectively without breaking existing behavior is to continue to allow plain old CSS to fail parsing correctly.

[lukeapage]

how about an "temporary" option so that people can enjoy both for a grace period?

or

we should do a release just before merging this fix in and go up a major version number to 1.4 (and hopefully add in variables in includes and interpolation of property names etc.

[dmcass]

I think this definitely would be a fix that would have to be part of a more major release, since it would break existing behavior. I'm not sure a temporary solution (if we're talking about spaces) is even reasonable considering that it could still break existing code, and it doesn't provide any kind of clean transition into the permanent solution. This seems like a situation where pulling the trigger on a release is the best option, and people can be warned through the Change Log and Docs.

[lukeapage]

I meant flag to keep existing behaviour.. but I agree with you.

Do you have commit rights? Even if so might be best as a pull request so we
can coordinate with releases (we have no plans I know of)

[matthew-dean]

Personally, I think we should swallow the pill and begin listing non-parenthesized math operations as a deprecated feature. There's too many cases where it conflicts with valid CSS. @agatronic - It's worth a Skype discussion with @cloudhead (or elsewhere), and I hate to ruin anyone's LESS libraries, but LESS should not be ripping out and breaking CSS that the author did not intend. The LESS parser should be provided clear signals that a math operation is needed, and parentheses are a good way to do that. In parentheses: DO MATH. Not in parentheses: LEAVE IT ALONE.

As a phase 1 to lessen the blow, we could STOP doing math ONLY in cases where the division is ambiguous e.g. in places where a slash "/" is a valid token in that value. So, in the case of border radius, if LESS is not sure, it leaves it alone. If the author is sure they want division between the two numbers, they can override the default behavior with adding parentheses.

But, as it stands right now, LESS is documented as "valid CSS = valid LESS", and with this bug, that's not the case. It's falsely re-writing valid CSS, which makes it a clear bug. The problem is that it's ALSO a clearly documented math operation. The two are in conflict, and it seems clear to me that the second case is the one that should be altered, with CSS preserved.

[matthew-dean]

I see @ttfkam and @mlms13 said much the same thing. I think their instinct is correct, and I would strongly vote that LESS begin a slow migration to parentheses being a requirement for operations.