Less.js: 수학을 다루는 방법

나는 우리가 일을 크게 바꾸거나 드로잉 보드로 돌아가고 싶다고 생각하지 않습니다.

예, _if_ 3.0에서 일부 "기본" 엄격한 수학을 원하기 때문에 이 작업을 시작하는 것이 좋습니다. 현재 것보다 덜 무거운 것을 발명해야 합니다(그리고 새로운 --alt-strict-math 을 도입하지 않고 모든 문제를 해결할 가능성). font 같은 하드코딩 솔루션 뒤에 숨겨진 문제로 인해 매우 비현실적인 것 같습니다...).

나는 그것이 성장하고 있다는 것을 깨닫지 못했습니다.

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

:(

나는 현재 처음에 strictMaths를 확장하는 것에 찬성한다고 생각합니다.

• 끄다
• 분할
• 켜짐

그런 다음 2.0.0의 경우 기본값을 Division으로 설정합니다.

그래서..

미디어 쿼리 - 꺼져 있는 경우 하위 노드에 대한 분할로 전환
글꼴 - 꺼져 있는 경우 하위 노드의 분할로 전환
calc( - 꺼져 있거나 나눗셈인 경우 하위 노드에 대해 켜짐으로 전환합니다.

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

예, _any_ "shorhand property"에서 "shorthand values"(예: x/y )를 허용하는 방향으로 가고 있다고 생각합니다...

관련: https://github.com/less/less.js/issues/1480

다른 옵션.. 계산 호출을 처리하지만 단위가 가능한 경우에만 예를 들어
계산(1% + 2%) => 3%
calc(100% - 10px) => 변경되지 않음

이렇게 하면 calc 이 수정되지만 #1627 및 관련 항목은 수정되지 않습니다.
예, calc(100% - 10 px) => unchanged 는 calc 대한 솔루션이 될 수 있지만 이것이 less-heavy-than-parens-everywhere 솔루션의 필요성을 취소하지는 않습니다.

엄격한 수학을 다시 검토하는 경우 percentage() 와 같은 Less 함수는 내부에 추가 괄호가 필요하지 않다고 제안하고 싶습니다. 엄격한 수학을 사용하면 인수를 이중으로 감싸야 합니다. 이렇게 하면 percentage(16 / 17) 및 percentage((16 / 17)) 가 모두 유효하므로 혼동과 찾기 힘든 버그의 가능성을 크게 줄일 수 있습니다.

@calvinjuarez V2 는 플러그인이 환경에 임의의 수의 함수를 추가할 수 있는 플러그인 하위 시스템을 제공하며 이러한 의미에서 코어는 이러한 내장 함수가 단일 값 또는 표현식을 예상하는지 결정할 수 없습니다. 16/17 을 수락한 다음 16/17 _before_ 함수에 전달되기 전에 평가하는 것은 올바르지 않을 것입니다.

그 맥락에서 ./ 변화는 내가 그것을 비교하는 경우 (매우 극적인 변화 될 것 이해하지만 내가 가장 좋아하는 것 같다 (/) , 계산하지 그것도 전에 공백 필요합니다 . , 예를 들어 16 ./17 가 아니라 16./17 , 흠).

현재 유효한 CSS를 덜 깨는 또 다른 것은 배경 속기입니다.

background: url(image.png) 50%/300px no-repeat;

나는 현재 처음에 strictMaths를 확장하는 것에 찬성한다고 생각합니다.

끄다
분할
켜짐
그런 다음 2.0.0의 경우 기본값을 Division으로 설정합니다.

죄송합니다. 2.0이 출시되기 전에 이에 응답하지 않았습니다. 좋은 본능이라고 생각합니다. Naked 나눗셈 연산자는 너무 많은 CSS와 충돌하며 사람들이 더 많은 CSS3 기능을 사용함에 따라 점점 더 충돌하게 됩니다. 그리고 많은 경우에 괄호가 필요하지 않기 때문에 모든 수학에 괄호가 필요하지 않다는 사람들의 반발을 이해합니다.

@seven-phases-max

16/17을 허용한 다음 함수에 전달되기 전에 16/17을 평가하는 것은 올바르지 않습니다.

엄밀히 말하면 네, 맞습니다. 이것은 함수에 도달하기 전에, 특히 사용자 정의 함수에 대해 평가되어서는 안 됩니다. 그러나 합리적이라면 함수가 이와 같은 인수를 처리하도록 허용하는 것이 현명할 것이라고 생각합니다. 따라서 백분율은 텍스트 인수로 16/17을 수신하고 백분율 함수는 텍스트가 수학인지 확인하기 위해 일부 도우미 함수를 호출할 수 있습니다. 백분율의 경우 인수가 모호하지 않습니다. CSS3 선언은 여기에서 유효하지 않습니다. 따라서 다른 사용자 정의 함수도 동일한 방식으로 작동할 수 있습니다. 유효한 수학 방정식에 대한 인수를 평가하도록 선택합니다. 따라서 엄격한 수학이 이 경우 이중 괄호를 "강제"한다는 것은 반드시 사실이 아닙니다. 나는 그것이 엄격한 수학의 아이디어에 약간의 반발을 불러일으키고, 필요에 따라 모든 경우에 장황해야 한다고 제안한다고 생각합니다.

--math 옵션은 다음과 같을 수 있습니다.

• 언제나
• 나눗셈(기본값)
• 엄격한

따라서 --strict-math=true를 더 이상 사용하지 않고 --math=strict의 별칭으로 만들 수 있습니다.

그러나 합리적이라면 함수가 이와 같은 인수를 처리하도록 허용하는 것이 현명할 것이라고 생각합니다.

그것들은 이미 허용됩니다( percentage(16 / 17) 및 percentage((16 / 17)) 가 --strict-math=on 와 어떻게 작동하는지 테스트하십시오).
어떤 기능도 사용하지 않지만:

그런 다음 백분율 함수는 텍스트가 수학인지 확인하기 위해 일부 도우미 함수를 호출할 수 있습니다.

단순히 이런 식으로 각 함수는 extra-helpers-conversion-arg-checking-smart-arg-handling-stuff의 ~20개의 추가 라인을 가져야 하는 반면 자체 함수 코드는 대부분의 경우 단 하나(!) 라인이기 때문입니다.

각 함수에는 20개의 추가 줄이 있어야 합니까? 어떻게 생각하세요?

백분율이 이미 단일 괄호 엄격한 수학에서 작동하는 경우 @calvinjuarez 의 문제를 이해할 수 없습니다. 당신은 당신의 응답에서 단일 괄호를 달성할 수 없다는 것을 암시하는 것 같았습니다.

각 기능에는 20개의 추가 줄이 있어야 합니까? 어떻게 생각하세요?

5, 10, 20... 실제 코드/보조 코드 비율 -> 0 경우 정확한 숫자를 누가 신경쓰겠습니까? (실용적인 접근 방식을 취하면 지금처럼 NaN% 를 생성하는 대신 오류를 던지고 percentage(16 / 17) 에서 멈추고 변환을 수행하지 않습니다. 이 방법으로도 여전히 4줄의 추가 코드 - 글쎄, 더 적거나 더 수용 가능한 것 같아요 :)

내 초기 응답은 그가 이 16/17 -> (16/17) 변환이 컴파일러 자체(함수가 아닌)에 의해 암시적으로 수행될 것이라고 가정한다는 의미였습니다.

옵션에 대해 이야기합니다. 완벽한 세상에서 나는 이것에 대한 옵션이 전혀 없다고 꿈꿀 것입니다. -maintainable.. 심지어 한 줄짜리 작은 수정/변경을 위해 예측해야 하고 수행해야 하는 테스트의 수가 기하급수적으로 증가합니다... (거의 이유 없이).

나는 그것이 다음과 같을 것이라고 생각했습니다.

percentage: function(...) {
  Helper.convertMath(arguments);  // a function that doesn't need it doesn't call it
  // ... the rest
} 

옵션에 대해 이야기합니다. 완벽한 세상에서 나는 이것을 위한 옵션이 전혀 없는 꿈을 꿀 것입니다.

나는 동의한다. 그러나 단기적으로는 옵션이 필요합니다. 특히 엄격한 수학 및 레거시 동작에서 벗어나는 경우. "스마트 수학" 옵션을 완성하면 둘 다 더 이상 사용되지 않는 것으로 표시될 수 있습니다.

Helper.convertMath(arguments);

arguments 은(는) 너무 낙관적입니다.
기껏해야 ( percentage 만 계산하는 것이 아니라 어쨌든 쓸모가 없지만 숫자 인수를 기대하는 다른 함수) 최소 요구 사항은 다음과 같습니다.

some: function(a, b, c) { 
    a = convert2number(a, "Error message when fails"); 
    // b is not a number for example
    c = convert2number(c, "Error message when fails"); 
} 

하지만 그건 내 요점이 아니었고, 내가 의미하는 바는 아마도 다음과 같을 것입니다. 이것은 항상 가능하지만 아무도 그런 코드를 작성하는 것을 귀찮게 하지는 않습니다... (와 같은 몇 가지 제한된 예외 는 있음 )...

네, 알겠습니다.

percentage(16 / 17) 오류 발생

확실히 개선이 될 것입니다. ( NaN% 가 유용한 출력이 될 것이라고는 생각할 수 없습니다.)

어떤 함수가 그들의 인수에 대해 현명하게 하려고 하는 한, 모든 것을 예상하려고 할 이유가 없습니다. @matthew-dean이 제안하는 도우미 기능은 기능 요청이 이루어지고 특정 기능이 더 똑똑해지기 위해 논의되기 때문에 상당히 간단하게 구현될 수 있습니다.

사실 처음부터 수학 함수만 인수에 대해 현명해야 한다고 말하고 싶습니다.

편집: 실제로 수학 함수가 하나의 인수만 전달될 때마다.

이에 대한 상태는 어떻습니까? LESS가 잘못된 CSS 속성을 수학으로 구문 분석하려고 한다는 불만 을 lost-column: 1/3; 중단.

또한 http://www.w3.org/TR/css-grid-1/#grid -template-rowcol LESS에서 작동하지 않는 것 같습니다.

누군가가 명시적으로 LESS를 사용하여 속성을 구분하는 데 사용하려는 경우 이를 패치할 수 있습니까?

@corysimmons 이거 #2769 에 물어보고 답을 들은거 아닌가요? 오_오

이 문제가 처음 발생했을 때 논의하지 않은 한 가지. 진정한 수학 갈등은 나눗셈뿐인 것 같습니다. 그리고 우리는 본질적으로 CSS "분리" 문자를 "재사용"하고 있기 때문에 나눗셈은 본질적으로 문제입니다.

여러 가지 방법으로 나눗셈을 "래핑"하려고 하거나 (이 문제에 대한 우리의 첫 번째 해결책으로) 모든 수학을 래핑하려고 하기보다는 왜 우리가 명백한 것에 대해 이야기하지 않았는지 궁금합니다. 그래서 분명히 a) Less 코드를 모호하게 만들고, b) 충돌을 일으킵니다.

이것을 소화할 시간을 갖고 수학을 괄호로 묶은 후, 그것이 단지 나눗셈일지라도 _still_은 수학이 이미 괄호 안에 있는 경우에 모호성을 유발합니다. (이는 괄호가 "수학 래퍼"의 잘못된 선택임을 의미할 수도 있습니다.)

/ 를 나누기 연산자로 사용하지 않는 이유는 무엇입니까? 나는 그것이 일반적인 나누기 기호라는 것을 알고 있지만 CSS를 확장하기 위해 Less가 수행한 다른 구문 절충점이 있습니다. 그리고 우리가 기본적으로 단일 슬래시를 사용하여 처음에 Less가 생성한 문제를 해결하려고 한다는 것이 분명합니다. 우리는 모호성을 만들고 그 모호성을 반전시키려고 합니다.

공정하게 말해서, 다른 수학 기호는 모두 CSS의 다른 부분에서 용도가 변경됩니다. 수학에서의 사용이 모호성을 유발하지 않는다는 것입니다.

몇 가지 아이디어를 제안하려고 했지만, 이미 분할에 대한 표준 대체 문자가 있습니다. 키보드에 없는 ÷ 외에 다음을 찾았습니다.

나눗셈 기호는 또한 일반적으로 콜론(:)으로 표시되고 "~이다"라고 읽는 비율 기호와 수학적으로 동일합니다. 따라서 임의의 실수 x 및 0이 아닌 실수 y에 대해 다음 방정식이 성립합니다.

x ÷ y = x : y

다시 말해:

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 

수학에서 콜론을 사용하려면 약간의 파서 조정이 필요하다는 것을 알고 있지만 수학적으로는 _그렇습니다_. 더 나은 대용품이 될 다른 기호를 생각할 수 없습니다. 두 번째 선택으로 | 가 될까요? 그러나 그것은 더 임의적 일 것입니다.

생각?

_또는_, 다음과 같이 괄호 및/또는 대괄호 내에서 나누기 기호를 계속 지원할 수 있습니다.

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 
lost-column: (1/3);
lost-column: [1/3];

네, 그래서 처음에 ./ 시작했습니다(Matlab vector-div 연산자에서 영감을 받아 두 개의 syms이지만 시각적으로는 가벼운 점 때문에 아마도 가장 덜 무거울 것입니다. 기발한 아이디어).
: - 데이지를 한 번 더 푸시합니다. 이 기호는 너무 많은 CSS 컨텍스트에서 사용됩니다. 사실 이미 충돌하는 구문이 있습니다.

.foo(<strong i="9">@a</strong>: 1, <strong i="10">@b</strong>: 2) {
  result: <strong i="11">@a</strong> @b;  
}

bar {
    <strong i="12">@b</strong>: 4;
    .foo(<strong i="13">@b</strong>:3); // would mean both @second-parameter:3 and 4/3
}

@seven-phases-max 아, 네, 젠장. 키보드가 더 컸더라면. 네, 분할을 위한 2자 시퀀스는 불가피해 보입니다. 전체 스레드를 읽은 지 오래되어서 잊어 버렸습니다. ./ 정말 나쁘지 않습니다. 당신과 @lukeapage 가 모두 참여한다면 그것은 나쁜 타협이 아닐 것입니다. 제안 단계로 옮기고 이의가 있는지 살펴볼까요?

다시 읽어보면 다음과 같습니다.

계산하지 않을 때도 . 앞에 공백이 필요합니다(예: 16 ./17 가 아니라 16./17

동의하는지 잘 모르겠습니다. 예, 16. 는 기술적으로 유효한 숫자이지만 누군가가 그렇게 쓰는 것은 이상할 것입니다. 공백이든 아니든 어떻게 쓰든 16을 17로 나누어야 한다고 생각합니다.

완벽한 옵션은 없지만) 기본적으로 나누기에 / 를 사용하고 b) 항상 괄호를 요구하는 것보다 낫다고 생각합니다. (과거의 내 위치에도 불구하고 나는 또한 예, 특히 다른 괄호 안에는 성가신 일입니다. 특히 나눗셈 때문에 필요한 것이기 때문에 그렇습니다. 예?)

공백이든 아니든 어떻게 쓰든 16을 17로 나누어야 한다고 생각합니다.

네 확실합니다.
더 생각하기는 하지만 ./ 가 파서에 몇 가지 추가 속임수를 넣을 것으로 기대합니다(숫자 구문 분석은 ./ 전에 중지하기 위해 추가 검토가 필요하지만 현재는 항상 . 끝을 먹습니다. ).

특히 내가 아는 한 분할 때문에만 필요하기 때문입니다. 네?)

네, 맞습니다. calc 내부의 코드를 계산하지 않지만 이 경우 @lukepage에서 제안한 솔루션 이 트릭을 수행해야 한다고 생각합니다.

(기술적으로 미래에는 CSS 색상 조작 함수 구문을 그대로 유지하면 +, -, * 대해 약간의 모호성이 추가될 수 있습니다. 그러나 값이 * 20% 형식을 갖기 때문에 이것은 너무 극적이지 않아야 합니다(따라서 그것들은 분명히 덜 평가되지 않은 expr로 감지될 수 있습니다.) 결국 이러한 재미는 (* 20%) 와 같은 현재 값이 구문 분석 오류를 유발하기 때문에 어쨌든 구문 분석 변경이 필요할 것입니다.

어쩌면... 우리가 이 일에 대해 잘못 알고 있었을 수도 있습니다. (내가 "엄격한 수학" 기능의 초기 열렬한 지지자였기 때문에 우리는 분명히 나를 포함합니다.)

우리는 수학이 보편적으로 작동하도록 하려고 노력하고 있지만.... 그렇게 할 필요는 없습니다. 즉, 수학을 수행해서는 안 되는 것이 분명해야 하는 경우에 수학을 수행하려고 합니다.

calc(100% - 10px) 예시가 가장 확실한 예시입니다. 기본적으로 Less가 중단되어야 하는 단위를 캐스팅하지 않는 한 수행할 수 있거나 수행해야 하는 Less 계산은 없습니다. ¹

예제로 사용된 font 속기 속성을 살펴보겠습니다.

font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
font: italic bold 12px/30px Georgia, serif;

이에 대한 현재 해결 방법은 font 속성에 대해 strict-math: on 를 설정하는 것입니다. 하지만... 왜 Less는 처음부터 계산을 해야 합니까? 물론 13px/150% 는 수학에서 유효한 문장이지만 Less에서 유효한 것으로 취급하는 것이 합리적입니까? 12px/30px 당신은 유효한 수학 문장으로 _할 수_ 있지만, 그렇게 해야 합니까? ²

즉: Less에서 단위에 대한 수학 연산은 단위가 아니라 _integers_ 및 _floats_에 의해 수행되어야 합니다. 사람들이 실제로 수학을 이런 식으로 쓰는 것처럼 우리는 이것을 유효한 수학 문장으로 취급합니다. 그러나 그것이 사실일 가능성이 있는지는 알 수 없습니다.

즉, 누군가에게 13px/150% 를 13px/1.5 로 쓰도록 요구하는 것이 합리적입니다. 그리고 12px/30px 가 수학 연산으로 의미가 없다는 사실을 무시하더라도, 그렇지 않다는 것을 알 필요도 없고 font 를 화이트리스트에 추가할 필요도 없습니다. . Less 작성자가 수학 연산을 수행했다면 합리적으로 12px/30 작성했을 것입니다. 그것은 합리적일 뿐만 아니라 _처음에 어떻게 작성하고 있는지-일 가능성이 매우 높습니다.

믹스인을 작성하거나 단일 블록 내에서 다음과 같은 것을 사용하는 것이 일반적입니다.

width: <strong i="5">@size</strong> / 2;
height: <strong i="6">@size</strong> / 2;

내가 왜 이런 식으로 썼을까? _누군가_가 이런 식으로 쓰고 있습니까?

width: <strong i="10">@size</strong> / 2px;
height: <strong i="11">@size</strong> / 2px;

@size 가 px 단위인 경우 _sort of_ 연산은 의미가 있지만, 그럼에도 불구하고 LESS/CSS 영역에서는 제수가 단위가 있는 값입니다. 두 번째는 수학처럼 보이지 않습니다. CSS 값처럼 보입니다.

곱셈이나 제수가 단위가 있는 값일 때 곱셈이나 나눗셈(모호함을 위해서는 나눗셈만 필요하지만 논리적 일관성을 위해서는 곱셈도 필요)에 대한 수학 연산을 중단하면 이 문제가 크게 사라질 것이라고 생각합니다. 대조적으로, 단위는 덧셈과 뺄셈에 대해 논리적이지만 아마도 필요하지 않을 것입니다(지금이 그렇습니다).

<strong i="18">@pad</strong>: 2px;
width: 10px + @pad; 

그러나 하나의 값 w/단위를 다른 단위 w/에 더하거나 뺄 때 Less는 그대로 두어야 합니다.

<strong i="22">@val1</strong>: 100%;
<strong i="23">@val2</strong>: 10px;
width: calc(<strong i="24">@val1</strong> - @val2);

// output
width: calc(100% - 10px);

덧셈/뺄셈(또는 정수/부동)에 일치하는 단위가 필요하고 단위에 대한 수학 연산에서 정수/부동수(단위 곱하기/나누기 단위 없음)는 모호성의 99%를 해결하고 새로운 기호 없이 유효한 수학 연산을 허용합니다. .

예를 들어, 이러한 규칙에 따라 배경 속기는 괜찮을 것입니다.

background: no-repeat 10px 10px/80% url("../img/image.png");

% 는 CSS 단위입니다. px 는 다른 CSS 단위입니다. 따라서 수학이 없습니다. 특별한 예외는 0입니다.

background: no-repeat 0 0/80% url("../img/image.png");

누군가 0을 다른 숫자로 나누거나 숫자를 0으로 나누는 것처럼 보인다면 그대로 안전하게 출력할 수 있다고 생각합니다.

경계 반경, 같은 것:

border-radius: 30% / 20%;

덜 통과할 것입니다. 누군가 수학을 하려는 경우 적절한 작성 방법은 다음과 같습니다.

border-radius: 30% / 0.2;

좋은 점은 이러한 구분을 통해 수학 연산이 CSS 값이 될 수 _없다는 것이 분명해야 한다는 것입니다. border-radius 예제와 같이 유효한 CSS 값은 양쪽에 단위가 필요하기 때문입니다. 중복/모호함이 없을 것입니다.

내가 생각할 수 있는 한 가지 경우를 제외하고 다른 경우가 있을 수 있습니다.

font: 10px/1.5;

라인 높이를 숫자로 나타낼 수 있고 일반적으로 그래야 합니다. (그러나 또한 글꼴 속기를 사용해서는 안 됩니다.) 그러나 한 가지 경우로 줄이면 꽤 좋습니다. font (글꼴 값 내의 내부 함수 제외)에 대해 엄격한 수학을 켜는 것은 괜찮은 해결책입니다. (더 나은 것이 있는지 확실하지 않지만 작동합니다.) 그리고 이러한 글꼴 약식 값은 일반적으로 가져온 UI 스타일 라이브러리, CSS 재설정 또는 사용자 정의 글꼴 스타일 시트에 나타나기 때문에 여전히 가장 피해가 적은 솔루션입니다.

따라서 엄격한 수학을 사용할 수는 있지만 이러한 변경으로 인해 덜 필요하고 향후 옵션으로 필요하지 않을 수도 있다고 생각합니다.

갤러리의 답변/댓글을 환영합니다.

¹ _나는 @lukeapage 의 댓글 과 @seven-phases-max의 링크가 내가 이 방향으로 생각하게 만든 이유임을 분명히 해야 한다는 것을 깨달았습니다.
² _예시를 보면서 알아냈듯이, 글꼴에 대해 엄격수학을 켜는 것은 불가피한 해결책일 수 있지만, 나머지 논리가 적용된다고 생각합니다._

일부 역사적 맥락에서 Less.js가 처음 릴리스되었을 때 단위 캐스팅은 그다지 문제가 되지 않았다는 점에 유의하는 것이 중요합니다. calc() 가 구현되지 않았으며 background 및 border-radius 유효한 값으로 슬래시가 없습니다. 나는 font 가 문제를 일으킨 유일한 장소라고 생각합니다(아이러니하게도 여전히 그럴 수 있음).

내 유일한 관심사는 구현 측면입니다. 예: calc(4px + 2rem + 20%) (실제 단위는 중요하지 않음)의 경우 첫 번째 추가는 더 이상 숫자가 아닌 결과를 가져오므로 두 번째 추가 처리기는 입력을 구별할 수 없습니다. 오류가 발생해야 하는 not-a-number + 20% 문. 아마도 큰 문제는 아니지만(추가 유형/유형 플래그를 넣어 해결할 수 있음), 여전히 약간의 조사가 필요합니다.

그리고 또 다른 관심사는 "재구성"이 확실하지 않다는 것입니다. 즉, 명시적 숫자의 경우 결과가 매우 명확해 보이지만 변수의 경우 매우 모호해 보이기 시작합니다. 예: border-radius: 10px <strong i="8">@a</strong> / <strong i="9">@b</strong> 30px; - @a 및 @b 를 보기 전까지 이것이 의미하는 바를 결코 알 수 없습니다.

그리고 예, font 여전히 문제로 남아 있습니다(아마도 다른 속기 속성은 양쪽에 단위를 사용하는 것 같지만 다시 우리는 다음에 나오는 항목을 알지 못합니다(#2769와 같은 것도 계산)... A font 와 같은 몇 가지 더 좋은 것이 있으면 다시 깨진 것처럼 보이기 시작할 것입니다.

추신: 한 ​​가지 더 문제(사소한 회귀일 수 있음). 다음과 같은 값이 있습니다.

border-radius: 10px / auto;
border-radius: 1px inherit / 2px;
background: ... center / 80% ...;
// etc.

즉, 모든 것이 작동하려면 현재 호환되지 않는 div-operand-errors를 비활성화해야 foo/bar , 1x/bar 및 foo/1x 가 w/oa를 통과할 수 있습니다. 오류.

내 유일한 관심사는 구현 측면입니다. 예: for calc(4px + 2rem + 20%) (실제 단위는 중요하지 않음)

이것은 내가 말하는 것입니다. 실제 단위가 중요해야 합니다. 더 적은 것은 상관없이 그것을 내버려 두어야 합니다. 4px + 2rem 는 브라우저에서는 의미가 있지만 Less에서는 의미가 없습니다. 의미가 없을 때 추가하려고 할 이유가 없으며 이러한 추가 기능 문제가 발생합니다.

예: border-radius: 10px <strong i="10">@a</strong> / <strong i="11">@b</strong> 30px ; - @a 및 @b 정의를 보기 전에는 이것이 무엇을 의미하는지 결코 알 수 없습니다.

이것은 스타일 작성자를 자체적으로 저장할 수 없는 경우입니다(누군가 실제로 어떤 이유로 픽셀에 rems를 추가하려는 경우 첫 번째 예와 동일). 누군가가 자신의 LESS 코드를 작성하여 따라가기 혼란스럽게 만들 수 있는 모든 종류의 기존 예제가 있다고 확신합니다. 그것은 어디에나 존재합니다.

내가 제안하는 이러한 수학 규칙으로 다음을 고려하십시오.
calc(4px + 2rem - 2px)

Less는 그것을 calc(2px + 2rem) 로 계산할 수 있습니다. 실제로는 완벽하게 괜찮고 실제로 올바른 값 출력입니다. 현재 Less는 이를 calc(4px) 로 계산합니다. 이는 정확하거나 유용한 답변이 아닙니다. (예, 현재 단위를 삭제하면 정확하지만 단위는 의미가 없으며 몇 가지 경우를 제외하고는 상호 운용할 수 없습니다.) Less 는 2px + 100% 를 102px 로 계산합니다. 그 결과, 아무도 그것을 결과로 원하지 않을 때.

모든 것이 작동하려면 foo/bar, 1x/bar 및 foo/1x가 w/oa 오류를 전달할 수 있도록 현재 호환되지 않는 div-피연산자 오류를 비활성화해야 합니다.

나는 그것이 실제로 그것을 치료하는 가장 건전한 방법이라고 생각합니다. 함수와 마찬가지로 Less 결과가 없으면 통과해야 합니다. / 는 둘 이상의 속성 값에 대한 유효한 구분 기호이기 때문에 특정 속성에 대해 허용된 값을 추가하지 않는 한 Less는 그것이 _유효하지 않은_ 것을 알 수 없습니다. (아니요.) 그 시점에서 결과는 비극적이지 않습니다. 통과 값이 브라우저에서 유효하지 않으면 시각적으로 분명합니다. Less가 확실하지 않기 때문에 오류를 발생시키는 것보다 유효한 경우 브라우저에 값을 전달하는 것이 더 나은 것 같습니다.

calc(2px + 2rem) 으로 계산할 수 있는 적은

나는 그것이 같은이 잔인한가 (기본적 것이다 아주 새로운 최적화 표현 핸들러 필요가 없습니다 것입니다 결코 두려워 4px + 2rem - 2px 같은 트리에 저장됩니다 (4px + 2rem) - 2px 하려면 지금 2px + 2rem 그것은 떠나, 마음 (이 특정한 경우에 사소하지만 더 피연산자 / 운영자 매우 복잡해지고) 모든 유효한 셔플을 시도하지 않는다. 그러나 결코 할 재정렬 엔진이어야한다 4px + 2rem - 2px 미세 (후는 그대로입니다 4px - 2px + 2rem 하면 모두 최적화됩니다).

그러나 내가 그 말에서 실제로 의미한 것은 다음과 유사한 것입니다.

foo/bar, 1x/bar 및 foo/1x가 w/oa 오류를 전달할 수 있도록 합니다.

expr.evaluator의 (4px + 2rem) - 2px 는 foo + 2px 와 유사하므로 작동하려면 그런 종류의 오류도 생성하지 않아야 합니다.
사실, 나는 foo/bar, 1x/bar, foo/1x 테스트했고 그들은 이미 w/o 오류를 통과했지만(이상하게도 던진다고 생각했습니다), 그러나 다른 연산자는 모든 종류의 이상한 결과를 초래합니다(정말 중요한 것은 아니지만 각 경우를 수정하는 문제일 뿐입니다. 하나씩).

나는 이것이 과잉이 될 완전히 새로운 최적화 표현식 핸들러가 필요하기 때문에 결코 그렇지 않을 것이라고 생각합니다. 모든 유효한 셔플링을 시도하는 재정렬 엔진이 됩니다(이 특별한 경우에는 사소하지만 더 많은 피연산자/연산자에게는 상당히 복잡해짐).

왜 셔플? 동일한 우선 순위 수준에서 연산자를 평면화하고(트리가 Sum(4px, 2rem, -2px) 이므로) 호환 가능한 단위로 용어를 수집하고(아마도 미리 단위를 정규화하여) 각 부분을 단순화합니다. 단위가 독립 변수로 취급되는 기호 대수학입니다.

직접 작성하고 싶지만 더 잘 테스트되고 완성될 가능성이 더 높은 라이브러리 가

요점은 이것이 해결하기 쉬운 문제는 아니지만 더 일반적인 문제는 이미 꽤 잘 해결되었으며 이러한 하위 시스템은 다른 방식으로 Less.js에 유용할 수 있다는 것입니다.

동일한 우선 순위 수준에서 연산자를 병합합니다(트리는 Sum(4px, 2rem, -2px)임).

그리고 어떤 표현식 트리가 실제로 평면화될 수 있다고 생각하도록 코드를 만드는 것은 정확히 무엇입니까? (따라서 내 "suffling"은 특정 공제 알고리즘에 관한 것이 아니라 "flatten"을 포함하여 "모두 시도"에 대한 지름길입니다.)

그러나 더 잘 테스트되고 완성될 가능성이 더 높은 라이브러리가 많이 있습니다.

당신이 진심인지 잘 모르겠습니다. 그래서 Less 트리를 외부 lib 트리로 변환하고 그 반대로 변환하는 모든 코드(JS libs 중 CSS 단위를 처리할 수 있는 것은 제외)가 실제로 최적화할 특정 4px + 2rem - 2p 가치가 있다고 생각하십니까? 흠...

따라서 전혀 문제가 되지 않습니다(나는 그것이 결코 가치가 없을 것이라고 불가능하다고 말하지는 않았습니다) - 시도하고 PR을 환영합니다.
(또한 하위 표현식 최적화가 이 티켓의 목표가 아니며 상위 3위 안에도 포함되지 않는다는 점에 유의해야 할 경우를 대비하여).

그리고 어떤 표현식 트리가 실제로 평면화될 수 있다고 생각하도록 코드를 만드는 것은 정확히 무엇입니까? (따라서 내 "suffling"은 특정 공제 알고리즘에 관한 것이 아니라 "flatten"을 포함하여 "모두 시도"에 대한 지름길입니다.)

구문 분석기는 컨텍스트가 "길이"인지 여부와 하위 트리가 "길이"로 해석될 수 있는지 여부를 결정합니다.

당신이 진심인지 잘 모르겠습니다. 그래서 당신은 Less 트리를 외부 lib 트리로 변환하는 모든 코드가

구문 트리로 구문 분석해야 합니다. 거기에서 대수식을 나타내는 문자열을 출력하는 것은 비교적 간단합니다. 되돌아가기가 더 어려울 수 있습니다. 문자열에서 다시 구문 분석해야 할 수도 있고, 외부 라이브러리의 트리를 가져와야 할 수도 있습니다. 난이도는 선택한 라이브러리에 따라 다릅니다.

(이 JS 라이브러리 중 어느 것도 CSS 단위를 처리할 수 없음을 계산하지 않음)

단위를 대수적 변수로 변환하면 됩니다. 표현식이 기호 형식인 동안에도 대체(예: mm -> px )를 수행할 수 있습니다.

특정 4px + 2rem - 2p 케이스를 최적화할 가치가 실제로 있습니까?

나는 덜 어렵고(Less의 자체 코드가 해결해야 하는 알고리즘 문제로서) 당신이 필요하다고 말한 것보다 더 일반적으로 유용한 표현 최적화에 대한 대안을 제안하고 있습니다.

대수 단순화는 괄호로 묶인 하위 표현식으로 문제를 해결할 수 있으며 Less가 더 많은 수학 기능을 추가할 수 있도록 합니다.

시도하고 PR을 환영합니다.

나는 노력할 것이다. 오늘에서야 Less를 살펴보기 시작했고 프로젝트를 완료하는 데 문제가 있어서 PR을 받지 못할 수도 있음을 인정합니다.

또한 하위 표현식 최적화가 이 티켓의 목표도 아니고 상위 3위 안에도 포함되지 않는다는 점에 유의해야 할 경우를 대비하여

알아요. 나는 이유 중 하나 때문에 여기에 있었다. 왜 그런 물린가?

왜 그런 물린가?

글쎄요, 아마도... 그렇다면 - 죄송합니다 (누군가가 기존에 존재하지 않는 calc(4px + 2rem - 2px) 문제를 해결하기 위해 헌신할 준비가 되어 있는 것 같습니다. 아마도 우리는 매우 다른 개념을 가지고 있는 것 같습니다. 가벼움).

Less가 더 많은 수학 기능을 추가하도록 허용합니다.

몇 가지 이름을 말씀해 주시겠습니까?

거의 존재하지 않는 calc(4px + 2rem - 2px) 문제를 해결하기 위해

뭐? 덜 처리할 수 없습니다. [나머지 설명을 잘못 이해하여 삭제됨]

제안을 단순화/재작성하려면 - 수학 변경 사항은 다음과 같습니다.

1. 덧셈과 뺄셈은 같은 단위로만 계산됩니다. 예: 1px + 2px = 3px , 1px + 1vh = 1px + 1vh
2. 나눗셈과 곱셈은 단위 없는 제수/승수로만 계산됩니다. 예: 10px/2 = 5px , 10px/5px = 10px/5px
3. 단위가 없는 값 비율은 # 2와 유사하게 처리됩니다. 예: 1/3 = 1/3
4. 단순화를 위해 부분적으로 유효하지 않은 하위 표현식이 있는 표현식은 유효하지 않은 수학 표현식으로 처리되어 있는 그대로 출력될 수 있습니다. 예: 1px + 2vh / 2 = 1px + 2vh / 2

이 제안은 다음을 해결합니다(이 스레드에서).

• font: 10px/5px 및 유사(비율) 구문(계산 없음)
• calc(100vh - 30px) (계산 없음)
• lost-column: 1/3 및 유사한 사용자 지정 비율 구문(계산 없음)

동시에 이러한 변경은 일반적인 Less 수학 사용의 99%를 보존합니다. 또한 기존 unit() 및 convert() 함수를 사용하면 사용자가 수학을 위해 호환되는 단위로 값을 캐스팅할 수 있습니다.

덜 처리할 수 없습니다.

당신은 저와 @leewz 가 위에서 말한 것을 읽지 않았을 뿐입니다. calc(100vh - 30px) 와 아무 관련이 없습니다. 그리고 "존재하지 않는 문제를 거의 해결하기 위해"는 " calc 에서 산술 표현식 최적화"에만 전념합니다.

@seven-phases-max 오오 그렇군요. 죄송합니다. 아니요, 최적화할 필요가 없습니다. 수학을 할 때를 알아내십시오.

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 더 이상 활동이 없으면 폐쇄됩니다. 귀하의 기여에 감사드립니다.

문제가 있기 때문에 슬레이트 레이블을 제거하는 것은 여전히 ​​중요하며 CSS가 발전함에 따라 점점 더 악화되고 있습니다.

@matthew-dean
여기서 잠시 악마의 변호인 역할을 하려고 합니다...

12px/30px 당신은 유효한 수학 문장으로 _할 수_ 있지만, 그렇게 해야 합니까?

네; 당신은해야합니다. 두 크기 간의 비율을 나타내는 스칼라 값을 계산하고 em 단위로 변환할 때 매우 유용할 수 있습니다.

알려진 기본 글꼴 크기가 16px이고 알려진 제목 크기가 24px이고 둘 다 변수에 숨겨져 있고 올바른 글꼴 크기로 특정 제목 유형을 지정하고 싶지만 em 단위라고 가정해 보겠습니다.

@fontsize-body    : 16px;
@fontsize-heading : 24px;

// ( ... and then somewhere else ... )

.heading {
  font-size : unit(@fontsize-body/@fontsize-heading, em);

  // Or if dividing compatible unit values is produces a unit-less scalar
  // value ( as it really _should_ -- mind you... ),  you could prefer:
  font-size : @fontsize-body/@fontsize-heading * 1em;
}

그리고 호환 가능한 단위의 분할을 수학 표현식으로 지원해야 하는 경우 각 사례의 절반을 다루기 위해 리터럴 CSS를 Less 수학 표현식에서 명확하게 구분하는 방법을 계속 지원해야 합니다.

이제는 괄호를 사용하여 수학 표현식을 강제 실행하고 기본적으로 CSS 리터럴을 사용하는 것이 허용됩니다. 그러나 그것은 잘못되고 오류가 발생하기 쉬운 것 같습니다. border-radius 및 font 속기에서와 같이 미리 조리된 많은 특수 사례가 필요하며 Less가 이에 대해 지속적으로 최신 상태를 유지해야 합니다. (나누기 기호에 대해 동일한 문제를 발생시키는 일부 새로운 그리드 속성으로 설명된 바와 같습니다.)

그래서...

왜 당신의 추론을 뒤집지 않습니까? 어떤 것이 수학 표현식처럼 보이고 호환 가능한 단위 가 있는 경우 기본적으로 수학 표현식으로 처리됩니다. 그리고 당신이 그런 일이 일어나는 것을 원하지 않는다면 ... 글쎄; 그런 다음 ~"..." 탈출 해치를 사용하십시오. 그것이 정확히 무엇을 위해 존재하는지, 결국...

제안에 대한 나의 현재 비전:

• / 를 단위와 옵션에 관계없이 어디서나 나눗셈으로 취급하지 마세요(선택적으로 - -sm=on과 같은 중복 괄호로 묶인 경우 제외).
  따라서 1anything./3whatever 및 (선택 사항) (1anything/3whatever) 만 Less에서 평가됩니다.
• + , - 및 * 변경되지 않음
• calc 하위 문제는 산술을 평가 하지 않음으로써 해결됩니다. calc(...) 내부의 표현식(하지만 다시 중복 괄호도 영향을 미칠 수 있음).

@seven-phases-max

그것의 문제는 / 가 나눗셈 연산자로 믿을 수 없을 정도로 뿌리 깊게 박혀 있다는 것입니다. 다른 기호를 사용하는 것은 사용자에게 힘든 판매가 될 것입니다. 당신은 일반적인 사용 사례를 취하고 거의 아무도 사용하지 않는 예외적 사용 사례(CSS 속기에서 / )를 위해 그것을 버리고 있습니다.

@rjgotten

그것의 문제는 / 이 나눗셈 연산자로 믿을 수 없을 정도로 뿌리 깊게 박혀 있다는 것입니다.

CSS에는 없습니다.

거의 아무도 사용하지 않는 예외적인 사용 사례(/ CSS 약칭)를 위해.

지금쯤이면 / 가 이미 많이 사용되고 / 보다 훨씬 더 예외적입니다(몇 년 전 CSS / 와 달리 font 에서만 찾을 수 있습니다.

@seven-phases-max 최신 정보를 제공해 주셔서 감사합니다. 문제를 관리하는 데 도움이 되도록 Stale 봇을 추가하고 오래된 것으로 표시하는 데 상당한 시간을 할애했습니다. 또한 "버그"와 "업포용"이라는 두 개의 레이블도 면제했습니다. 화이트리스트에 추가할 다른 레이블과 같은 제안 사항을 환영합니다. 파일은 여기: https://github.com/less/less.js/blob/3.x/.github/stale.yml

문제 스레드로 돌아가기...

@rjgotten
귀하의 사용 사례는 임의의 문제를 생성합니다. 유용하다는 주장입니다. 그러나 그런 식으로 변수를 구성하면 @seven-phases-max가 지적한 것처럼 모호한 구문으로 피할 수 있는 문제가 발생합니다.

CSS를 Less 원칙의 지침으로 삼아 액면 그대로 가져도 계산상 12px를 30px로 나눌 수 없습니다. Less에서 그렇게 하면 모호성 문제가 발생할 뿐만 아니라 (역사적인 경우가 아닌) 정당한 이유 없이 모델에서 분리됩니다. 아마도 Less에서 누락된 것 중 하나는 단위 값의 숫자 값을 추출하여 Less가 나눗셈에 대해 이 수학 마술을 할 필요가 없도록 하는 방법일 것입니다.

따라서 간단한 대답은 귀하의 예가 다음과 같을 것이라는 것입니다.

font-size : @fontsize-body/number(@fontsize-heading) * 1em

하지만 @seven-phases-max의 제안도 괜찮습니다. calc() 에서 _vars_ 는 여전히 평가할 수 있지만 수학은 평가할 수 없습니다. 그리고 괄호 밖에서 나누기를 평가하지 마십시오. 좋은 타협점이라고 생각합니다. 그리고 아마도 단위를 단위로 나누는 마법 나눗셈 수학을 유지하고 단위를 유지하고 싶다면(여전히 이상하지만 괜찮습니다), 괄호 안에서 일어날 수 있습니다.

Less에서 수학 주제에 대해 몇 가지 다른 선호도가 있다는 것을 알고 있지만, 가장 적은 부작용을 일으키고 큰 유지 보수를 일으키지 않고 가장 쉽게 추론할 수 있는 것에 대해 합의에 도달할 수 있다면 정말 좋을 것이라고 생각합니다. 또는 개발 부담.

Less에서 수학에 대한 현재(기본값) 접근 방식이 깨진 것과 같은 페이지에 있다고 생각합니다. 그리고 모든 것을 기본값으로 두는 것이 추론하기는 쉽지만 부담스럽다는 피드백을 받았습니다. 그래서 나는 우리가 곧 기본값으로 넣을 수 있는 좋은 중간 지점을 기대하고 있습니다(아마 4.0에서?)

아마도 Less에서 누락된 것 중 하나는 단위 값의 숫자 값을 추출하는 방법일 뿐입니다.

unit 함수는 두 번째 매개변수를 지정하지 않으면 실제로 그렇게 합니다. 그러나 그것은 스칼라가 현재 정의된 단위가 없는 Dimension 노드 유형으로 구현되어 있다는 사실의 부작용입니다.

부여 된; 그것은 먼 길을 가지만 호환되는 단위가 있는 차원을 나누는 것을 _정말로_ 피하고 싶다면 단위를 떼어내는 것이 효과가 있습니다.

나는 또한 이 특정 맥락에서 "호환되는 단위" 추측(예 a/b 은 나눗셈으로 유지하고 b/c 은 그렇지 않음)에 대해 강력하게 반대합니다.
단순히 다음과 같은 이유로:

• 예외적인 처리는 모든 악의 근원입니다(예: #3047 - 아래 참조, http://stackoverflow.com/questions/19705791- 나는 실제로 모든 줄을 다 밟을 때까지 SO 문제의 원인을 찾을 수 없었다는 것을 기억합니다. 디버거에서 관련된 Less 코드).
• 그리고 가장 중요한 것은 미래에 대비할 수 없다는 것입니다. 즉, 주요 변경 사항이 불가피한 경우 한 번만(이상적으로는 영원히) 만드는 것이 좋습니다... a/b 와 관련된 새로운 CSS 기능을 추가하는 것과는

따라서 나에게 "호환 가능한 단위" 항목은 완전히 관련이 없고 직교하는 것과 같습니다( -su 가 있거나 없는 결과 단위에 대해 약간의 토론이 있을 수 있지만 그건 다른 이야기입니다).

(주제를 벗어:)
그리고 btw., 위의 예에 대해 말하면:
다음이 있는 경우

@fontsize-body/@fontsize-heading * 1em; 

코드 어딘가에 있고 두 변수 중 하나는 실제로 버그를 사용하는 px :)
적절한 코드는 다음과 같습니다.

1em * @fontsize-body/@fontsize-heading;

이는 항상 http://lesscss.org/features/#features -overview-feature-operations에 따라 잘 정의된 단위를 생성합니다(수정해야 할 #3047을 계산하면 버그는 다시 한 번 너무 많이 생성된 버그의 예입니다. 코드 베이스의 "호환 가능한 단위"에 대한 추측 코드). --su , number , unit bla-bla... 현재 -su 동작이 필요하지 않습니다. "호환되지 않는 장치가 보이면 오류를 던지십시오." , 즉 간단한 유효성 검사는 (나에게는) 좋은 것 이상입니다. 1px/2px->.5 및 1px*2px->2px^2 mambo-jambo 과잉 엔지니어링이 필요하지 않습니다. 그러나 이것은 또 다른 관련 없는 이야기입니다).

@seven-phases-max

실제로 버그를 사용하여

음.. 네; 당신 말이 맞아요. 운 좋게도 실제로 프로덕션 환경에는 해당 코드가 없습니다. 요점을 설명하기 위해 함께 던진 간단한 예일 뿐입니다.

나는 또한 이 특정 맥락에서 "호환되는 단위" 추측(a/b는 나눗셈으로 유지하고 b/c는 그렇지 않음)에 대해 강력하게 반대한다고 덧붙입니다.

나는 알몸의 제수를 원하는 사람들에게 올리브 가지로서 더 많이 선상에 있었다고 생각합니다. 하지만 [ 여기 ] 귀하의 의견이 가장 실행 가능한 제안이라고 생각합니다. 모호성을 제거하는 것이 "엄격한 수학"의 원래 의도였습니다. 나는 우려가 믹스인 내의 연산과 괄호 내의 모든 종류의 괄호로 이어지는 함수 호출이 되었다고 생각합니다. 그러나 일반적으로 나는 Less에서 수학을 쉽게 하려는 노력이 아이러니하게도 증가된 모호성 때문에 그것을 매우 어렵게 만들었다는 점에 동의합니다.

또한 나중에 font: 10px/3 가 유효한 속기임을 깨달았습니다. 따라서 실제로 도움이 될 수 있는 알고리즘 솔루션은 없습니다.

질문으로 돌아가려면 @rjgotten...

왜 당신의 추론을 뒤집지 않습니까? 어떤 것이 수학 표현식처럼 보이고 호환 가능한 단위가 있는 경우 기본적으로 수학 표현식으로 처리됩니다. 그리고 당신이 그런 일이 일어나는 것을 원하지 않는다면 ... 글쎄; 그런 다음 ~"..." 탈출 해치를 사용하십시오. 그것이 정확히 무엇을 위해 존재하는지, 결국...

Less to CSS의 아이디어/관계는 TypeScript에서 JavaScript와 유사합니다. 즉, 유효한 .css 을 .less 하고 Less 기능을 추가할 수 있습니다. .js 을 .ts 하고 TypeScript 기능 추가를 시작하는 방법과 유사합니다. 아무 것도 추가하지 않으면 언어가 기본 언어의 상위 집합이기 때문에 동일한 유효한 Less / JavaScript가 출력되어야 합니다.

그러나 CSS의 이러한 비율 또는 기타 / 제수의 경우 Less는 기본적으로 이미 게이트에서 바로 실패합니다. 아무 것도 변경하지 않았더라도 일반 CSS는 임의적으로 다른 결과를 가진 Less 수학 표현식이 됩니다. 그것은 언어의 계약을 위반합니다. .less 를 완전히 다른 Less 표현식으로 변경하여 시작한 원래 CSS를 되돌릴 수 있다는 것은 요점을 놓치는 것입니다. 그 작업은 절대 필요하지 않습니다. Less는 처음에 가지고 있던 유효한 CSS를 다시 얻기 위해 유효한 CSS를 호환 가능한 Less 표현식으로 변경하도록 요구해서는 안 됩니다. 고장난 모델일 뿐입니다.

calc() 에도 동일한 논리가 적용됩니다. 예, 표현식을 문자열로 이스케이프할 수 있지만 그렇게 해서는 안 됩니다. .css 로 이름이 변경된 .less 는 동일한 효과적인 CSS를 생성해야 합니다. 이것은 원래 스타일시트를 간섭/덮어쓰기/과도하게 해석하지 않는 것이 프로젝트의 기본 목표여야 합니다. 다른 모든 것은 처음에 파서/언어를 사용하는 것 외에 다른 죄로 인해 개발자에게 문제를 푸시하려고 합니다.

예, 표현식을 문자열로 이스케이프할 수 있지만 그렇게 해서는 안 됩니다. .less로 이름이 변경된 .css는 동일한 효과적인 CSS를 생성해야 합니다. 이것은 원래 스타일시트를 간섭/덮어쓰기/과도하게 해석하지 않는 것이 프로젝트의 기본 목표여야 합니다. 다른 모든 것은 처음에 파서/언어를 사용하는 것 외에 다른 죄로 인해 개발자에게 문제를 푸시하려고 합니다.

저것.

LESS는 / 가 허용되는 위치와 CSS에서 허용되지 않는 위치를 알고 있습니다. 그렇지 않지만 어쨌든 나타나는 경우 수학이 완료되어야 한다고 가정해야 합니다. 또한 수학이 둥근 괄호로 둘러싸여 있는 경우 CSS에서 둥근 괄호가 허용되지 않는 경우 LESS로 해석해야 합니다.

다시 말해서, LESS는 유효한 CSS에 도달하기 위해 가능한 한 적은 수의 수학을 해석하려고 노력해야 합니다. 출력이 유효하면 더 이상 수학 실행을 중지하십시오.

@thany

컴파일러가 알고 있는 것에 대한 가정이 너무 많습니다(일부는 단순히 틀립니다).
어느 쪽이든 "둥근 대괄호" 모드는 --sm=on 가 하는 것과 거의 같으므로 이를 사용하고 이 스레드는 잊어버리십시오(대부분 calc 외에 프로젝트에서 수학을 사용하지 않을 가능성이 높습니다 Less가 설계된 지 몇 년 후) 그래서 추가 괄호가 얼마나 짜증나는지 알 수 없습니다. 하지만 다른 사람들은 그렇습니다.)

나머지는 https://github.com/less/less.js/issues/1880#issuecomment -345194431을 참조

@seven-phases-max / 는 background 및 border-radius 속기, 그리고 아마도 지금 생각하지 않는 다른 것들에도 의미가 있다는 것을 잊지 마십시오. LESS는 그것들을 하나의 부서로 기쁘게 생각합니다. 엄격한 수학 모드가 있든 없든 LESS는 자체적인 작은 수학을 "멈춰야 할 때를 알아야" 합니다.

@thany
LESS는 자신의 작은 수학을 "멈춰야 할 때를 알아야" 합니다.

아니, 그러면 안 된다. 분할 슬래시가 있는 미래 CSS 약어가 어디에 나타날지 알 수 있는 방법이 없습니다. Less 컴파일러가 이에 대해 '알게' 하는 것은 근본적으로 결함이 있는 접근 방식이며 이 토론에서 솔루션을 찾으려고 시도하는 바로 그 것입니다.

지금까지 나누기 연산자로 / 대해 제정신이고 예측 가능한 두 가지 선택이 있습니다.

• 항상 그렇게 처리하고 다른 용도로 명시적으로 이스케이프해야 합니다.
  이것은 Less 구문이 CSS 구문의 엄격한 상위 집합인 동작을 중단합니다.
• 알려진 수학 컨텍스트에 속하지 않는 한 __만_나누기 연산자로 취급하지 마십시오.
  알려진 수학 컨텍스트는 현재 --strict-math=on 동작에서와 같이 결정될 수/있을 수 있습니다.

_{(또한 Less 이름의 철자가 더 이상 대문자로 표시되지 않습니다.)}

/ 또한 background와 border-radius 속기에서 의미가 있다는 것을 잊지 마십시오.

이것은 기본적으로 이 스레드가 시작하는 것입니다.
그리고 https://github.com/less/less.js/issues/1880#issuecomment -345194431에서 제안된 변경 사항의 요약을 참조하십시오(컴파일러가 알아야 하거나 알아야 하는 가정 없음).

아니, 그러면 안 된다. 분할 슬래시가 있는 미래 CSS 약어가 어디에 나타날지 알 수 있는 방법이 없습니다. Less 컴파일러가 이에 대해 '알게' 하는 것은 근본적으로 결함이 있는 접근 방식이며 이 토론에서 솔루션을 찾으려고 시도하는 바로 그 것입니다.

나는 이것에 완전히 동의합니다. @thany 당신은 내가 쓴 것을 인용한 것에 동의하지만 내가 내린 결론과 다른 결론에 도달하고 있습니다. 적게는 "수학을 중단"해야 할 때와 알 수 없습니다. 내가 말하고 싶은 것은 브레이킹 체인지가 먼저 수학을 시작하는 것에 대해 Less가 더 보수적이어야 한다는 것입니다(미국/캐나다주의를 사용하기 위해).

@rjgotten

알려진 수학 컨텍스트 내에 있지 않는 한 나누기 연산자로 취급하지 마십시오.
알려진 수학 컨텍스트가 현재 --strict-math=on 동작에서와 같이 결정될 수 있거나 결정될 경우.

명확히하기 위해이 부분 (나는 동의합니다) :

알려진 수학 컨텍스트 내에 있지 않는 한 나누기 연산자로 취급하지 마십시오.

실제로 4 가지 가능한 솔루션이 있습니다. 알고 있지만 스레드에 대해 다시 요약하면 다음과 같습니다.

1. 모든 수학은 괄호 안에만 수행하십시오 . 이것은 분명히 커먼즈에 의해 거부되었으며, 이는 여전히 선택적 토글( strictMath )로 사용할 수 있지만 괜찮습니다.
2. 모든 수학을 모든 곳에서 수행하되 괄호로만 나눕니다.
3. 모든 수학을 모든 곳에서 수행하되 괄호로만 나눕니다. 나누기 연산자가 ./ 로 인쇄되지 않는 한
4. 모든 수학을 모든 곳에서 수행하되 12px/4px 인해 나눗셈이 발생하지 않도록 수학을 수정하십시오. (곱셈과 나눗셈은 단위가 없는 값만 사용합니다.) 즉, 모든 곳에서 나눗셈을 수행하지만 훨씬 더 보수적인 규칙을 따릅니다. 문제가 해결되지 않으면 다시 탈출에 의지하십시오. 따라서 완전한 솔루션은 아니지만 현재 상황에 대한 (논증의 여지가 있는) 개선 사항입니다.

사용성 관점에서 저는 #4 에서와 같이 수학을 "더 똑똑하게" 만드는 것을 좋아합니다. 엔지니어링 및 유지 관리 관점에서, 그리고 향후 CSS 변경으로부터 보호하기 위해 저는 #3 가 가장 강력한 솔루션으로 마음에 듭니다.

그러나 실제로는 calc() 를 수정하기 위해 #3 AND #4 를 100vh - 12px 는 Less(괄호 여부)에 의해 건드려서는 안 됩니다. 그러나 IMO도 12px/4px (괄호 여부)를 사용해서는 안 되지만 저는 그 부분에서 소수일 수 있습니다.

그래서 저는 이것을 "CSS 구문과 충돌하는 수학" 문제로 보지 않고, Less가 처음부터 수학 방정식을 조기에 해결하는 데 지나치게 공격적이라고 생각합니다.

단위가 없는 값으로만 ​​곱셈과 나눗셈을 수행합니다.

다음과 같은 것들이 있기 때문에 트릭을 수행하지 않을 것입니다.

font: small-caps bold 24px/3 ...;
lost-column: 1/3;
// etc.

그리고 그들은 div가 아닙니다.

그러나 실제로는 calc() 를 수정하려면 #3 및 #4 를

calc() 는 고통입니다. 아이러니하게도 그것은 _아마도_ 실제 Less 함수로 구현함으로써 가장 잘 해결되며, 이상적으로는 구문 분석된 표현식 트리를 취하고 표현식을 단순화하려고 시도할 것입니다. 즉: 4px + 12px (또는 @a 에 픽셀 값이 있는 것으로 알려진 경우 4px + @a 와 같은 호환 가능한 구성 요소를 미리 계산하고 결합해야 하지만 호환되지 않는 구성 요소는 그대로 둡니다. 호환되지 않는 유닛과 함께, 단독으로.

예

<strong i="17">@a</strong> : 4px;
<strong i="18">@b</strong> : 2;
width : calc(100%/<strong i="19">@b</strong> - 10px + @a);

결국 렌더링해야

width : calc(50% - 6px);

(https://github.com/less/less.js/issues/1880#issuecomment-345345735에서 반복)
그리고 calc 내부의 표현식을 최적화하기 위해 컴파일러를 과도하게 엔지니어링하는 것의 이점을 보지 못했습니다. calc 를 작성하고 있다면 브라우저에서 긴 표현식이 무엇이든 상관없이 작업을 수행할 수 있습니다. 그래서 위에서 이미 언급했듯이 저는 " calc 내부의 아무 것도 건드리지 마십시오"(= 실제로 필요한 것보다 더 똑똑하려고 시도하지 마십시오). 브라우저( 또는 css-minifier 이후 , 내가 올바르게 기억한다면, 그들 중 일부는 이미 calc 하위 표현식 최적화에 꽤 좋은 일을 하고 있습니다.

"smart unit behavior mamabo-jambo"는 min/max 괴물을 떠올리게 합니다(유지할 수 없고 한 번도 사용 하지 않은 코드의 부풀려진 스택) - 당시 "units mambo"에 대해 비명을 지르지 않은 것을 얼마나 후회하는지 , 오 (그래서 나는 "피연산자 단위에 따라 다른 연산자 의미"라는 아이디어가 완전히 사라질 때까지 여기에서 계속 징징거릴 것입니다 :P).

추신 calc 가 산술 평가가 아닌 표현식을 수신하는 함수가 되자 마자(어쨌든 그래야 할 것입니다) 플러그인을 작성하고 원하는 최적화로 이를 대체할 수 있습니다.

@rjgotten
Less 컴파일러가 이에 대해 '알게' 하는 것은 근본적으로 결함이 있는 접근 방식입니다.

근본적으로 옳은 접근이라고 생각합니다. LESS는 CSS에 대한 컴파일러이므로 LESS가 컴파일 대상에 대해 알고 있다는 것은 세상 모든 의미가 있습니다.

@matthew-dean
적게는 "수학을 중단"해야 할 때와 알 수 없습니다. 내가 말하고 싶은 것은 브레이킹 체인지가 먼저 수학을 시작하는 것에 대해 Less가 더 보수적이어야 한다는 것입니다(미국/캐나다주의를 사용하기 위해).

말하자면 다른 쪽에서 생각하는 것이 흥미롭습니다. 제가 제안하는 내용은 다음과 같습니다.

background: url(...) no-repeat 50% 50% / 40px + 10px 40px;

여기서 LESS가 해야 할 일은 나에게 분명합니다.

background: url(...) no-repeat 50% 50% / (40px + 10px) 40px;

를 야기하는:

background: url(...) no-repeat 50% 50% / 50px 40px;

여기서 50% / 50px 부분을 ​​계산해서는 안 됩니다. (1) 호환되지 않는 단위 때문에 불가능하고 (2) background 값에 대해 이미 충분하기 때문입니다. . 여기에서 "수학을 중단"할 것입니다.

그것이 내가 "멈춰야 할 때를 아는 것"이 ​​의미하는 바입니다.

다음과 같은 다른 속성이었습니까?

padding-left: 50% / 10px + 5px;

오류(호환되지 않는 단위)와 함께 중단되어야 합니다. 가능한 출력 중 하나는 이 속성에 대해 유효하지 않은 50% / 15px 입니다. 또 다른 결과는 현재 수행할 5% 수 있으며 이는 모든 방향에서 잘못된 것입니다.
그리고:

padding-left: 50px / 10px + 5px;

결과:

padding-left: 10px;

예상대로. 따라서 이 경우 / 는 padding-left 대해 유효하지 않으며 LESS 로 가져와서 수학을 수행합니다.

@matthew-dean
실제로 4 가지 가능한 솔루션이 있습니다. 알고 있지만 스레드에 대해 다시 요약하면 다음과 같습니다.

하나 더:
5) LESS의 나눗셈에는 \ 연산자를 사용하고 / 사용하여 더 이상 사용하지 않습니다. MATLAB에는 이와 유사한 것이 있으며 BASIC의 특정 맛은 정수 나누기를 강제로 사용하는 데 사용했습니다. 따라서 백슬래시를 사용하는 것이 완전히 들어본 적이 없는 것은 아닙니다.

/편집하다
또한 키보드에 ÷ 키를 포함하도록 로비하고 이를 나눗셈 연산자로 사용할 수도 있습니다. 초등학교 때 배웠던 내용이에요 :)

귀하가 제안한 내용은 이미 여러 번 논의되었습니다(여기에 참조된 스레드를 주저하지 마십시오). 그래서 여기에 약간 게으른 의견이 있습니다.

LESS의 나눗셈에 \ 연산자를 사용하고 / 사용하여 더 이상 사용하지 않습니다.

https://github.com/less/less.js/issues/1872#issuecomment -35245890

background 충분합니다 ... padding-left 에는 유효하지 않습니다

"여러분, 제 브라우저/폴리필/ fnord 속성에 대한 지원이 추가/업데이트/확장된 모든 것, 저를 위해 새로운 Less 버전을 출시해 주시겠습니까?"를 만나보십시오. 문제.
font 문제를 만나보세요.
등 등
글쎄요, @rjgotten은 이미 위에서 왜 그런 종류의 "지식"이 아무데도 가지 않는 길이라고 언급했습니다.

@seven-phases-max
백슬래시는 제안에 불과했습니다. 나누기에 ? 를 사용할 수도 있습니다. 그것은 정말 중요하지 않습니다. 내가 제안하는 것은 매우 다르고 모호한 의미를 가진 하나의 문자( / )를 사용 하지 않는 것입니다.

"여러분, 내 브라우저/폴리필/ fnord 속성에 대한 지원이 추가/업데이트/확장된 모든 것, 저를 위해 새로운 Less 버전을 출시해 주시겠습니까?"를 만나보십시오. 문제.

CSS는 잘 정의된 표준입니다. 표준 이외의 것을 지원해서는 안됩니다. 그것이 당신의 문제입니다. fnord 속성은 표준의 일부가 아니므로 지원해서는 안 됩니다. 이 새로운 지정되지 않은 속성이 발생하면 LESS는 기본 동작으로 폴백할 수 있습니다. 현재 동작이거나, 괄호가 필요하거나, 모호하지 않은 한 무엇이든 됩니다.

글꼴 문제를 만나보세요.

글꼴 문제는 LESS의 절대적인 시작부터 / 문제가 존재했음을 증명합니다. background 에 background-size 값을 포함할 수 있는 기능이 있거나 border-radius 가 발생했을 때 뿐만이 아닙니다. Tbh, 글꼴 문제를 언급함으로써 당신은 당신 자신에 대해 가장 좋은 주장을 펼쳤습니다. :)

Tbh, 글꼴 문제를 언급함으로써 당신은 당신 자신에 대해 가장 좋은 주장을 펼쳤습니다. :)

나는 당신이 뭔가를 잘못 이해하고 있다고 생각합니다. 처음에 / 를 div 연산자로 완전히 제거하자고 제안한 사람은 저 였습니다. 따라서 나머지 항목에 대해서는 귀하가 응답한 내용에 주의를 기울이지 않는 것과 동일한 문제라고 생각합니다.

CSS는 잘 정의된 표준입니다.

TR 수준에서 완전히 성숙해진 사양 부품을 고수하려는 경우 그럴 수도 있습니다.
그렇지 않으면? 아니요. 새로운 CSS '모듈'의 위성 사양과 매주는 아니더라도 새로 추가된 기존 모듈의 수정 버전이 표시됩니다.

@seven-phases-max

다음과 같은 것들이 있기 때문에 트릭을 수행하지 않을 것입니다. font: small-caps bold 24px/3 ...

아니, 알겠어. 내 요점은 바로 다음과 같습니다. unit-less only div/multiplication은 문제를 줄이지만 문제를 해결하지는 못합니다.

그리고 일반적으로 모든 부문에 대한 ./ 의 제안은 여전히 ​​매우 논리적으로 보입니다.

@thany 모든 구체적인 예에 ​​응답하기 보다는 일반적으로 Less Math를 더 똑똑하게 만들려는 노력이 공을 다른 야드 라인으로

그리고 calc 내부의 표현식을 최적화하기 위해 컴파일러를 과도하게 엔지니어링하는 것의 이점을 보지 못했습니다. calc를 작성하고 있다면 브라우저에서 긴 표현식이 무엇이든 상관없이 작업을 수행할 수 있습니다. 그래서 위에서 이미 언급했듯이 나는 "calc 내부에 아무 것도 만지지 마십시오"(= 실제로 필요한 것보다 더 똑똑해지려고 시도하지 않음)하고 브라우저를 위해 남겨두었습니다(또는 내가 올바르게 기억한다면 css-minifier를 위해 , 그들 중 일부는 이미 calc 하위 표현식 최적화에 꽤 좋은 일을 하고 있습니다.

나는 이것에 전적으로 동의합니다. calc() 허용 목록에 추가하면 새로운 수학 관련 문제의 99%를 제거할 수 있습니다. Less가 calc() 문제를 피하기 위해 수학을 더 현명하게 수행할 수 있는 몇 가지 방법을 제안했지만(당연히 그래야 할 수도 있음) 이것이 이 아이디어에 대한 논쟁으로 해석되었다면 사과드립니다. 저도 이것을 지지합니다.

유일한 주의 사항(여기/다른 곳에서 논의됨)은 개발자가 필연적으로 calc() 변수를 사용하기를 원할 것이므로 vars를 계속 교체하도록 주의해야 하지만 하지 마십시오. 수학. 얼마나 어려운 일인지 모릅니다. 그렇게 할 수 있다면 오늘 calc() 처리 변경을 지원하겠습니다.

@thany

글꼴 문제는 LESS의 절대적인 시작부터 / 문제가 존재했음을 증명합니다.

이것은 사실일 수 있고 정당한 지적이지만 많은 적절한 해결 방법이 있었고 font 속성 약식을 사용하는 것이 반드시 표준 관행은 아니었습니다. Less가 시작된 후 여러 배경과 calc() 가 도착했기 때문에 이것이 더 문제가 되었습니다. 이제 CSS Grid 구문은 이제 일상적인 실제 용어에서 처음에는 존재하지 않았던 많은 충돌이 있음을 의미합니다.

덧붙여서, 이것이 Sass가 문제를 해결하는 방법이며 이 예에서 설명합니다.

p {
  font: 10px/8px;             // Plain CSS, no division
  $width: 1000px;
  width: $width/2;            // Uses a variable, does division
  width: round(1.5)/2;        // Uses a function, does division
  height: (500px/2);          // Uses parentheses, does division
  margin-left: 5px + 8px/2px; // Uses +, does division
  font: (italic bold 10px/8px); // In a list, parentheses don't count
}

Less 함수에 대한 인수 내에서 (현재) 수학을 할 수 있고 Less 함수는 픽셀 값을 반환할 수 있기 때문에 font: print10px()/8px 아닙니다. 어떤 종류의 제안이 아니라 설명을 위해 붙여넣는 것뿐입니다. 그들이 어떻게 문제에 접근했는지 흥미롭습니다.

개인적으로, 나는 개발자들이 마법 표현식의 존재를 기반으로 수학이 어떤 경우에 발생하는지 기억하도록 만드는 것은 일종의 미친 짓이라고 생각하지만(예: + ?) .

개인적으로, 나는 개발자들이 마법 표현의 존재를 기반으로 수학이 어떤 경우에 발생하는지 기억하게 만드는 것은 일종의 미친 짓이라고 생각합니다.

+1

_{"솔루션"이 lessc --sm 가 이미 수행하는 것 외에 여기에서 논의된 문제 중 어느 것도 해결 그리고 1/2 와 $var/2 대한 다른 결과는 정말 놀랍습니다 ... ~바보 ~ "즐거운 디버깅, 패자!"}

@matthew-dean
덧붙여서, 이것이 Sass가 문제를 해결하는 방법이며 이 예에서 설명합니다.

이는 다른 운영자에게 의지하지 않고도 훌륭한 솔루션입니다.
표현식이 유효한 CSS일 경우 그대로 두십시오.

개인적으로, 나는 개발자들이 마법 표현의 존재를 기반으로 수학이 어떤 경우에 발생하는지 기억하게 만드는 것은 일종의 미친 짓이라고 생각합니다.

동의하지 않는다. 이것은 단순한 규칙 집합으로, 기억해야 하는 다른 규칙 집합과 다르지 않습니다.

수학이 의미 없이 발생하는 몇 가지 극단적인 경우가 있지만 괄호만 적용하면 끝입니다.

"솔루션"이 lessc --sm이 이미 하는 것 이상으로 여기에서 논의된 문제 중 어느 것도 해결하지 못한다는 것을 계산하지도 않습니다. 내가 원하는 것이 나눗셈일 때 (1/2) 대신 0 + 1/2를 쓰는 이유는 무엇입니까? 그리고 1/2와 $var/2에 대한 다른 결과는 경이적으로 훌륭합니다... 어리석음 "해피 디버깅, 패자!" 메세지.

하, 예, 이것입니다.

@thany

이는 다른 운영자에게 의지하지 않고도 훌륭한 솔루션입니다.
표현식이 유효한 CSS일 경우 그대로 두십시오.

잡초에 빠지지는 않지만 구문상의 이유와 언어 일관성 때문에 Less에서는 작동하지 않습니다. 그것은 논쟁의 여지가 있다고 말할 수 있는 Sass에게는 훌륭할 수 있지만 디자인 관점에서 개인적으로 그 프로젝트에 관여하지 않으므로 누가 말할 수 있습니다. 내가 아는 것은 테이블에 있는 옵션이 시작하기에 가장 좋은 장소라는 것입니다. 이 문제와 관련된 메시지 스레드를 살펴보고 언어에 대해 많은 시간을 할애했다면 같은 결론에.

우리가 피할 수 없는 한 가지 관찰: 유효한 바닐라 CSS를 가져오면 출력이 기능적으로 동일해야 합니다. 따라서 내가 그릴 수 있는 유일한 결론은 LESS가 이미 유효한 CSS일 가능성이 있는 표현식을 건드려서는 안 된다는 것입니다. 이 작업을 수행하는 방법은 나에게 달려 있지 않습니다. 그러나 바닐라 CSS를 가져오는 것은 신뢰할 수 없다는 사실이 남아 있습니다. 대부분 LESS가 분할을 너무 열성적으로 실행하기 때문입니다.

Sass에서 바닐라 CSS를 가져오는 것은 사실상 완벽하게 작동합니다. 말했듯이 Sass는 몇 가지 간단한 구문 규칙에 따라 컴파일러에게 가서 작업을 수행하도록 지시하지 않는 경우 / 연산자를 그대로 둡니다. 이 구문 규칙은 유효한 바닐라 CSS에서 발생할 수 없는 분할을 강제하는 방법을 설명하며 이것이 뛰어난 이유입니다.

당신은 여전히 ​​자신의 상상이 아니라 그들이 말하는 것과 논쟁합니다. 간단한 질문에 대답 : "어떻게 0 + 1/2 아마도보다 더 잘 할 수 있습니다 (1/2) ?". 100%-CSS 호환성이 관심 있는 유일한 경우 -sm 하고 이 스레드는 잊어버리십시오.

우리가 피할 수 없는 한 가지 관찰: 유효한 바닐라 CSS를 가져오면 출력이 기능적으로 동일해야 합니다. 따라서 내가 그릴 수 있는 유일한 결론은 LESS가 이미 유효한 CSS일 가능성이 있는 표현식을 건드려서는 안 된다는 것입니다. 이 작업을 수행하는 방법은 나에게 달려 있지 않습니다. 그러나 바닐라 CSS를 가져오는 것은 신뢰할 수 없다는 사실이 남아 있습니다. 대부분 LESS가 분할을 너무 열성적으로 실행하기 때문입니다.

이 부분은 내가 본질적으로 동의하고, 이 스레드에서 그 점에 대해 많은 동의를 찾을 것이라고 생각합니다. 대부분의 불일치는 솔루션에 관한 것이며 각 솔루션에는 다양한 부작용이 있습니다.

저는 다음과 같은 주요 변경 사항을 우선적으로 적용할 것입니다.

1. 필요로하는 수학 외부 괄호 ./ 대신 나체의 / . 12px./10px 여전히 조금 이상해 보입니다.

@seven-phases-max - 백슬래시를 다시 찾고 싶습니다. 이와 관련하여 https://github.com/less/less.js/issues/1872#issuecomment -35245890에 대해 언급한 것으로 알고 있습니다. 수학 표현의 일부. 아니면 내가 틀렸습니까? 이름의 일부로 이스케이프 문자가 포함된 함수 이름과 같은 이론적인 경우를 생각해낼 수 있다고 생각하지만 실제 사례보다 지적인 연습에 더 가깝습니다. 이스케이프된 선택자는 여러 가지 이유로 일반적으로 사용되지만 속성 값에서는 그럴 가능성이 거의 없는 것처럼 보이거나 극단적인 경우 역사적(이 텍스트를 이스케이프 처리) 해결 방법으로 중단/해결하는 것이 좋습니다.

나눗셈에 단일 백슬래시를 사용하면 실제 충돌이 발생할 수 있다는 점을 조금 더 살펴볼까요? 내 본능는 점이다 \ 주변의 현재 상황보다 문제가 / , 그리고 더 dev에 친화적 인 이상입니다 ./ . 우리가 조사를 하고 그것이 가능하다는 것을 발견했다면, 괄호 안에 / 를 허용하는 컨텍스트 전환 대신 모든 곳에서 사용하도록 주요 변경을 할 수 있습니다. 그런 다음 레거시 스위치로 / 를 지원할 수 있습니다.

1. (두 번째 우선 순위) calc() 는 변수 교체를 수행할 수 있지만 수학 표현식을 평가하지 않도록 특수 케이스입니다.

나눗셈에 단일 백슬래시를 사용하면 실제 충돌이 발생할 수 있다는 점을 조금 더 살펴볼까요?

글쎄, \anycharacter 가 유효한 CSS이고 나름의 의미가 있다는 문제. 물론 실제 프로젝트에서는 그런 코드를 거의 찾을 수 없습니다(예: \9 같은 해킹 제외). 하지만... 우리가 그 사자에게 먹이를 주고 싶습니까? "어-오, 내 100% 유효한 CSS가 컴파일되지 않음"을 수정하여 동일한 소리의 다른 "어-오"를 도입하여 약간 이상하게 들립니다. :)

calc 관해서는 우리가 처음부터 합의가 있었던 것 같습니다. 따라서 기본적으로 자원 봉사자가 그것을 구현하기를 기다리는 것뿐입니다. 이것은 정말로 용감한 사람에 관한 것입니다 - 사소한 구현 세부 사항은 다를 수 있지만 프로세스에서 결정하는 것이 좋다고 생각합니다.

음, \anycharacter가 유효한 CSS이고 고유한 의미가 있다는 문제입니다. 물론 실제 프로젝트에서는 그런 코드를 거의 찾을 수 없습니다(예: \9와 같은 해킹 제외). 하지만... 우리가 그 사자에게 먹이를 주고 싶습니까? "어-오, 내 100% 유효한 CSS가 컴파일되지 않음"을 수정하여 동일한 소리의 다른 "어-오"를 도입하여 약간 이상하게 들립니다. :)

들어보니 트레이드 오프 가능성이 있습니다. 그리고 예, \anycharacter 가 유효한 CSS라는 것을 알고 있습니다. 나는 그것이 더 나은 트레이드 오프 세트인지 궁금합니다. 단지 12px./10px 썼을 때 문법적으로 이상하게 느껴졌을 뿐입니다. Less는 충돌을 일으키지 않고 가능한 한 CSS의 용도를 변경하려고 시도한 것 같습니다.

예를 들어 ./ 는 구문 명확성을 제공하고 충돌을 완전히 방지하지만 수학에 대한 모든 곳에서 괄호를 적용했기 때문에 지원했지만 반발이 있었고 여기에서 걱정됩니다. 그렇다면 \10 를 탈출하려는 개발자의 의도로 10px\10 를 오인하는 합법적인 경우가 있습니까? 나는 그것이 어려운 이론이라는 것을 알고 있고, 당신의 요점은 아마도 우리가 정말로 모른다는 것입니다.....그것은 복잡한 질문이고, 새로운 구문을 추가하는 것은 항상 어려운 일입니다. 특히 우리가 모든 CSS를 알지 못하기 때문에 Less를 사용하는 경우 야생 또는 미래 CSS.

계산에 관해서는 우리가 처음부터 합의가 있었던 것 같습니다. 따라서 기본적으로 자원 봉사자가 그것을 구현하기를 기다리는 것뿐입니다. 용감한 사람 - 사소한 구현 세부 사항은 다를 수 있지만 프로세스에서 결정하는 것이 좋다고 생각합니다.

좋은! 가시성을 높이기 위해 별도로 추적해야 합니까?

@seven-phases-max:

물론 실제 프로젝트에서는 그런 코드를 거의 찾을 수 없습니다(예: \9 같은 해킹 제외).

맞아 . 오, 그 거친 "서양인"... :)

@seven-phases-max
"어떻게 0 + 1/2가 (1/2)보다 더 나을 수 있습니까?"라는 간단한 질문에 답하십시오.

나는 당신이 그것을 가지고 어디로 가는지 볼 수 없습니다. (1/2) 는 유효한 CSS가 아닐 수 있으므로 LESS로 실행해야 하므로 LESS로 의미해야 합니다. 0 + 1/2 는 1/2 가 되어야 합니다. 여기서 LESS는 0 + 1 부분을 ​​실행합니다. 왜냐하면 그것이 유효한 CSS가 될 수 없는 부분이기 때문입니다. 1/2 부분 은 유효

@thany
좋아, 이제 (1/2) 이 Less와 Sass에서 모두 예상대로 작동한다는 것을 깨닫습니다.
그리고 0 + 1/2 (및 1 * 1/2 등)은 위에서 bright라고 부르는 솔루션의 일부이며 "brilliant soution" 결과는 0.5 입니다.
여기에서 무슨 일이 일어나고 있는지 아직 모르십니까?
위의 모든 내용(첫 번째 게시물부터 시작)을 다시 한 번 읽고 "내가 정확히 무엇에 대해 불평하고 있는 겁니까?"라고 스스로에게 답해 보세요.

@seven-phases-max
그리고 0 + 1/2(1 * 1/2 등도 포함)는 위에서 bright라고 부르는 솔루션의 일부이며 "brilliant soution" 결과는 0.5입니다.

아니,이 솔루션은 것 1/2 하지 0.5 , 이후 1/2 유효한 CSS 수 있습니다. 슬래시가 언제 유효한지 LESS가 알기를 원하지 않는 것 같으므로 항상 그럴 수 있다고 가정하십시오. 따라서 1/2 가 유일한 논리적 결과입니다. 같은 방식으로 2 * 1/2 는 2/2 * 가 됩니다. 그렇지 않으면

여기에서 무슨 일이 일어나고 있는지 아직 모르십니까?

나는 여기서 무슨 일이 일어나고 있는지 완벽하게 분명합니다. LESS는 수학 나눗셈을 열심히 실행하고 맹목적으로 단위를 무시합니다.

위의 모든 내용(첫 번째 게시물부터 시작)을 다시 한 번 읽고 "내가 정확히 무엇에 대해 불평하고 있는 겁니까?"라고 스스로에게 답해 보세요.

인신공격은 필요없습니다.

LESS는 수학 나눗셈을 열심히 실행하고 맹목적으로 단위를 무시합니다.

이것은 당신이 오른쪽에 대하여 신고 할 것입니다 그래서?

인신공격은 필요없습니다.

그럼 대신 어떻게 해야 할까요? 원래 두 개의 게시물 을 계속해서(그리고 다시) 반복합니까? 명확해질 때까지:
@커뮤니티 :

-sm 옵션 사용

@thany :

그러면 기본적으로 켜져 있어야 합니다.

@seven-phases-max:

수 많은 프로젝트가 즉시 중단될 것이기 때문에 불가능합니다. 따라서 기본 동작을 문제로 취급하는 경우 문서화된 옵션을 설정하기만 하면 됩니다.

그래서 "해야 한다", "해야 한다", "해야 한다"를 반복하면서 무엇을 기대하고 있습니까? 당신이 제안한 것이 작동하지 않거나 일반적으로 말이 되지 않는 이유에 대해 자세히 설명하는 데 시간을 낭비하는 대신 "아니요, 해서는 안 됩니다"라고 대답하는 것이 더 쉽습니다. 이해하거나 단순히 할 수 없음).

이 스레드의 내용은 무엇입니까? " -sm 와 같은 행동을 기본값으로 만드는 궁극적인 주요 변경은 피할 수 없지만 우리는 무서운 것 외에 더 편안한 산술을 위한 시설을 제공해야 한다는 것을 깨닫는 것입니다. margin: (1/2) (3/4) (5/6) (7/8); 산술을 많이 사용하십시오."
여기에 게시하는 것은 이미 존재하는 -sm 행동보다 낫지 않은(또는 완전히 똑같은 행동을 하는) 무언가를 제안하거나 처음부터 의문의 여지가 없는 것에 대해 논쟁합니다( 거기 처럼). 즉, 임의의 노이즈 .

@seven-phases-max @thany 온도를 한 단계

나는 대부분의 사람들이 이 두 가지에 대해 같은 페이지에 있다고 생각합니다. Less는 수학 표현식으로 이상적으로 해석하지 않습니다.

font: 12px/10px;
width: calc(100% - 20px);

따라서 이러한 점에 대해서는 대부분 동의가 있으며 대부분의 주장은 가능한 솔루션에 관한 것입니다. calc() 문제는 앞으로 나아갈 수 있는 충분한 합의가 있는 것 같습니다. 기본적으로: calc를 건드리지 말고 calc() vars를 문자열 보간과 같이 취급하십시오. calc() 의 보간 구문이 필요하긴 하지만 Sass가 수행하는 방식과 비슷합니다. 필요하지 않다고 생각합니다.

font 부분에 대한 솔루션은 훨씬 더 복잡해졌으며 주요 솔루션은 다음과 같습니다.

1. 기본적으로 모든 것에 괄호가 필요함(첫 번째 시도 - 거의 구현되었지만 커뮤니티에서 거부됨)
2. strictMath 스위치(기본값으로 만드는 대신 추가되었으며 @seven-phases-max의 제안)를 뒤집은 다음 명시적으로 모든 계산을 수행합니다. 기술적으로 현재 대부분의 사람들에게 가능한 솔루션이지만....문제가 너무 자주 발생하고 심리적으로 어떤 시스템을 처음 접하는 사람도 기본값을 유지할 가능성이 있다는 것을 알고 있으므로 문제가 됩니다. 또한 모든 개발자가 특히 팀에서 빌드 설정을 변경할 수 있는 것은 아닙니다.
3. 기본적으로 Less에서 나누기 연산자를 변경합니다. 스레드의 선두 경쟁자는 ./ 로 작동하지만 보기에는 조금 이상합니다. \ 는 연구 없이 현재로서는 알 수 없습니다. 작동할 수 있고 이스케이프와 알 수 없는 충돌을 일으킬 수 있습니다. (잠재적이지만 알려지지 않은) 더 높은 위험에서 더 깨끗한 구문입니다. 누군가가 시간을 내어 이것이 충돌을 일으키지 않을 것이라는 것을 시연한다면, 즉 파서가 둘을 명확하게 구별할 수 있는 방식으로 혼합된 탈출과 수학의 예를 제공한다면, 여전히 가능성이 있습니다. 따라서 작업이 필요합니다. @thany , 당신이나 다른 누군가가 이것의 팬이라면 이것이 필요한 작업입니다. 마지막으로 원하는 것은 휴식 시간을 다른 곳으로 옮기는 것입니다.

이 스레드를 단순화하려면 여기에서 #3 에만 집중해야 한다고 생각합니다. 나는 대부분 호기심으로 Sass 예제를 게시했지만 이러한 솔루션이 훌륭하거나 문제를 완전히 해결한다고 생각하지 않으며 개념적으로 Less와 호환되지 않습니다. 0 + 1/2 요구의 타당성에 대해 논쟁하는 것은 우리를 아무데도 얻지 못할 것입니다.

따라서 테이블에 calc() 에 대한 좋은 솔루션이 있어 대부분의 게시된 문제에 대해 50%의 기회를 얻을 수 있으므로 단기적으로 이 질문에만 집중하는 것이 좋습니다.

Less 나눗셈 연산자를 변경해야 하는 경우 무엇으로 변경해야 합니까?

• ./ - 이것이 내가 느끼는 것처럼 어색합니까, 아니면 사람들이 괜찮다고 생각합니까?
• \ - 연구와 증명, 따라야 할 파서를 위한 의사 코드 없이는 앞으로 나아갈 수 없습니다. 나는 개인적으로 그것이 안전하다고 입증될 수 있다면 그것을 선호한다.
• 다른 대체품?

솔직히 calc() 를 변경하고 / 변경하면 Less에서 수학 주변의 소음을 99% 줄일 수 있다고 생각합니다.

안녕하세요, calc() - https://github.com/less/less.js/pull/3162

많은 추가 코드 없이도 작동하는 솔루션을 찾았을 때 나는 다소 놀랐습니다. 기본적으로, 우리는 이미 strictMath 스위치에 대한 코드를 가지고 있었고, 괄호 밖에 있는 경우 수학을 평가하지 않도록 표현식을 체크인하므로 calc() 를 평가하는 동안 수학을 끄는 호출에 추가 스위치를 추가했습니다

https://github.com/less/less.js/pull/3162/files#diff -a94aaffd78b1d3c5eda7a42d5be1ca0d 및 https://github.com/less/less.js/pull/3162/files#diff -4e6969271823c91을 확인

테스트가 충분합니까?

@matthew-dean :커피:

테스트가 충분합니까?

PR의 의견에 따라 다음과 같은 테스트를 추가하십시오.

foo: 1 + 2 calc(3 + 4) 5 + 6; // expected result: 3 calc(3 + 4) 11;

그리고 사소한 설명: 이 수정은 분명히 #1627에서와 동일한 문제를 소개합니다. 즉,

<strong i="13">@a</strong>: floor(1.1);
<strong i="14">@b</strong>: floor(1 + .1);

div {
    foo: calc(<strong i="15">@a</strong> + 20%); // ok
    bar: calc(<strong i="16">@b</strong> + 20%); // error: invalid floor arguments
    baz: @b;             // ok
}

하지만 calc 경우 괜찮습니다(게으른 평가 개념을 다시 실행 하지 않고 문제를 해결할 수 있는 다른 간단한 방법은 calc 내에서 vars를 사용할 때 lazy-eval을 염두에 두도록 문서에 알림을 넣는 문제라고 생각합니다.

그리고 사소한 설명: 이 수정은 분명히 #1627에서와 동일한 문제를 소개합니다.

좋은 캐치!

호출당 컨텍스트 mathOn 속성을 전환하면 PR의 귀하의 의견과 유사하게 이 문제가 해결됩니다. 통과하는 float(1 + .1) 에 대한 테스트를 추가했습니다!

호출당 컨텍스트 mathOn 속성을 전환하면 PR의 주석과 유사하게 이 문제가 해결됩니다. 나는 > 통과하는 float(1 + .1) 테스트를 추가했습니다!

:) 아니요, -sm: off 일 때 "바닥" 오류가 있어야 합니다 . PR에서 내 최신 의견을 참조하십시오.
복원은 1 + 2 calc(3 + 4) 5 + 6 같은 것들만 처리합니다.

:) 아니요, -sm: off일 때 "floor" 오류가 있어야 합니다.

왜요? calc() 내부의 모든 함수는 Less 함수여야 합니다. 그렇지 않은 경우에도 calc() 내부에는 원시 수학 표현식을 사용할 수 있는 CSS 네이티브 함수가 없습니다. 예상되는 결과는 vars 및 Less 함수를 평가하는 것이지만 calc() 내부의 원시 함수는 그대로 두십시오.

참고 사항: Less에서 나눗셈 연산자로 / 를 \ 로 전환하는 분기 실험을 했습니다. 이스케이프에 대한 테스트가 이미 많이 있으며(주소: #3160에 더 추가했습니다), 모두 여전히 잘 작동하고 연산자를 전환해도 수학이 잘 작동합니다. 나는 본질적인 갈등을 보지 못했습니다. 분기는 여기 내 포크에 있습니다: https://github.com/matthew-dean/less.js/commit/509d34fff7e234846afa150b099cd259755a39d0

Re: 중첩 함수

이를 위해:

div {
    bar: calc(floor(1 + .1) + 20%);
}

개발자로서 예상되는 결과는 다음과 같아야 합니다.

div {
    bar: calc(1 + 20%);
}

그것이 바로 지금 일어나는 일입니다(이러한 변경 사항으로). 오류가 발생하지 않아야 합니다.

@matthew-dean
아니요, 당신이 쓴 방법은 다음과 같습니다.

foo: unit(1/2, px);

-sm:on 를 사용하면 다음과 같이 컴파일됩니다.

foo: .5px;

^- 틀렸습니다.
중첩 함수도 마찬가지입니다. 또한 대부분의 함수가 일반적으로 산술 표현식을 인수로 사용할 수 없다는 사실이 -sm: on 위반 이유가 아닙니다.
따라서 -sm: on 두 줄:

foo: floor(1 + .1);
bar: calc(floor(1 + .1) + 20%);`

오류가 발생해야 합니다(이것이 커밋에서 중단됨).

무슨 얘기를하는 건가요?

unit(1/2, px) -sm:on :

ERROR: error evaluating function `unit`: the first argument to unit must be a number. Have you forgotten parenthesis?

calc(floor(1 + .1) + 20%) -sm:on

ERROR: error evaluating function `floor`: argument must be a number

지점을 확인하세요. 시도해보십시오.

코드 검토에 더 도움이 될 수 있는 한 가지는 잘못된 출력을 생성할지 확신이 서지 않는 경우 확인하십시오. 또는 특정 입력을 시도하여 예상대로 작동하는지 확인하도록 요청하십시오. 또는 작동 방식/이유가 확실하지 않은 경우 질문하십시오. 도움이 되지 않는지 모른 채 잘못 부르는 것입니다.

죄송합니다. 이 부분 의 간접적인 통제를 놓친 것 같다.

지점을 확인하세요. 사용해보기

죄송합니다.

죄송합니다. 이 부분에 대한 간접적인 통제를 놓친 것 같아요.

걱정 마. 이 문제가 해결되면 예상한 대로 작동하는 것처럼 보입니까?

이 문제가 해결되면 예상한 대로 작동하는 것처럼 보입니까?

예, 지금까지 그곳에서 다른 수상한 것은 상상할 수 없습니다.

@matthew-dean
기본적으로 Less에서 나누기 연산자를 변경합니다. 스레드의 선두 경쟁자는 ./로 작동하지만 보기에는 조금 이상합니다. \ 은(는) 연구 없이 현재로서는 알 수 없습니다 [...] @thany , 귀하 또는 다른 누군가가 이것의 팬이라면 이것이 필요한 작업입니다. 마지막으로 원하는 것은 휴식 시간을 다른 곳으로 옮기는 것입니다.

실제로는 전혀 아닙니다. 나는 \ 연산자를 통과하지 못한 후 최후의 수단으로 제안했습니다. LESS가 자체 수학 만 하도록 하려고 했습니다. 새로운 나눗셈 연산자가 필요한 것이라면... 음, calc() 도 덧셈, 뺄셈, 곱셈을 할 수 있습니다. 새로운 연산자? 비현실적이라고 생각합니다. 새로운 나누기 연산자는 글꼴, 배경 및 테두리 반경과 같은 것에 대한 솔루션일 수 있지만 CSS 수학에 대한 솔루션은 아닙니다.

나는 여전히 진정한 해결책은 LESS가 컨텍스트에 대해 아는 것이라고 생각합니다. (예, 여기서 다시 "~해야 합니다"로 이동합니다. 다른 단어를 사용해야 하나요?...) calc() 는 CSS 함수이며 CSS가 수행할 수 없는 수학만 평가해야 합니다. . 그러나 floor() 는 CSS에 존재하지 않으므로 유효하지 않은 CSS를 분출하지 않도록 (완전히) 평가해야 합니다. 나는 이것이 이전에 다른 표현으로 언급되었다고 생각합니다.

나는 여전히 진정한 해결책은 LESS가 컨텍스트에 대해 아는 것이라고 생각합니다. (예, 여기서 다시 "~해야 합니다", 어떤 단어를 사용해야 할까요?...) calc()가 CSS 함수이고 CSS가 할 수 없는 수학만 평가해야 한다는 것을 알아야 합니다. 그러나 floor()는 CSS에 존재하지 않으므로 유효하지 않은 CSS를 분출하지 않도록 (완전히) 평가해야 합니다. 나는 이것이 이전에 다른 표현으로 언급되었다고 생각합니다.

공정하게 다시: \ , 그러나 컨텍스트에 관한 한 귀하의 다른 게시물을 기반으로 하면 귀하가 생각하는 것보다 훨씬 더 복잡한 문제임을 보장할 수 있습니다. 정말 다음과 같이 줄여야 합니다.

12px/10px  // Is this division, or not?
10px/1.5 // is this division, or not? 

당신은 확실히 남겨 둡니다 / 모방에, 나누기 연산자로 calc() , 그리고 당신이 절대적으로 있는지 확인해야합니다, 그것은 모호 할이 / 에 괄호( calc() 예외 제외). 이는 예측 가능한 컨텍스트를 제공합니다.

이 스레드의 시작 부분에 있는 그 제안도 여전히 가능성이 있으며 강력한 지원을 받았습니다. 기본적으로 기본 설정은 모든 수학 부문을 제외하고 외부 괄호를 지원 (다시 제외되는 것이 calc() 입니다 3.0 이상에서 지금의 경우). 어쩌면 그것이 갈 길입니다. 그러면 다음이 가능합니다.

font: 10px/1.5;   // not division
font: (10px/10);  // division, result is 1px
font: 10px+15px/1.5;   // addition but not division, result is 25px/1.5
font: (10px+15px/1.5);  // result is 20px

문제는 10px+15px/1.5 대한 결과가 괄호 안에 있지 않는 한 "절반 평가"되는 것처럼 보이는 표현식을 사용하여 개발자가 여전히 괴로워하기 어려울 수 있다는 것입니다. 기본적으로 엄격한 수학을 설정했다면 괜찮았을 것입니다. 덜 모호합니다. [shrug] 어느 쪽이든, 어떤 종류의 컨텍스트에서 수학을 래핑하는 것은 모호성을 제거하는 방법이며, 나누기 연산자를 변경하는 것 외에는 나눗셈을 위한 유일한 방법입니다.

커뮤니티는 본질적으로 방향을 결정해야 합니다. 이 스레드에는 실행 가능한 옵션이 있습니다. 각각 단점이 있습니다. 각각의 고통점이 있습니다. 어느 누구도 완전한 합의를 얻지 못할 것입니다. 그러나 IMO는 현재 시나리오보다 더 좋습니다. 그 알약을 삼키면 됩니다.

결정을 위한 마지막 요청

그래서 불가능한 일을 하기 위한 노력의 일환으로 저는 이것을 제안하고 싶습니다(3년 전의 의견 을 다시 참조).

--strict-math 3개 설정 제공

1. 끄다
2. 분할
3. 엄격함(이전 버전과의 별칭 on )

논쟁을 해결하려면 --strict-math=division 스위치가 다음을 수행하도록 허용하십시오.

1. 괄호 밖에서 / 문자만으로 나누지 마십시오. 예: border-radius: 55px / 25px; --> 수학 없음(예, 유효한 CSS입니다)
2. 두 가지 다른 방법으로 나누기를 허용합니다.
   ㅏ. . 접두사 - border-radius: 55px ./ 25px;
   비. 괄호 - border-radius: (55px / 25px);
3. 두 형식 모두 괄호 안에 유효합니다. 예를 들어 border-radius: (55px ./ 25px); 가 유효합니다.

따라서 개발자로서 한 버전이 선호하지 않는다고 생각되면 다른 버전을 사용할 수 있습니다. 일부는 괄호를 사용하지 않는 것을 선호할 수 있습니다. 일부는 수정된 나눗셈 연산자를 사용하지 않는 것을 선호할 수 있습니다. 모두를위한 무언가. 그리고 / 가 font , background , border-radius 에서 사용되는 CSS에서 현재 널리 사용되는 구문을 사용하는 Less를 처음 사용하는 사람들에게는 더 이상 불쾌한 놀라움이 없습니다 @media 쿼리, CSS Grid 속성, 그리고 아마도 앞으로 더 많을 것입니다.

다음 단계

나는 이것을 옵션으로 PR에 넣은 다음 논의한 대로 향후 주요 버전의 기본값으로 전환하는 것이 좋습니다.

@matthew-dean

즉 마침표는 이스케이프 시퀀스의 역과 같은 역할을 합니까?
나쁜 생각이 아니야, 정말로...

그리고 모든 것을 고려했을 때 _아마도_ 가장 깨끗한 가능한 솔루션 중 하나입니다.

@rjgotten 여기서 시작: https://github.com/matthew-dean/less.js/tree/strict-math-division

테스트 중 하나에서 여전히 이상한 오류가 발생합니다. 여기에서 차원 노드 중 하나를 작업 노드로 바꾸는 것 같습니다(그런 다음 작업 노드에서 작업을 수행할 수 없기 때문에 오류가 발생합니다. strictMath: division 에서 실행되지 않는 다른 테스트가 제대로 작동하기 때문에 구문 분석 문제인 것 같습니다. 확인해보고 도움을 줄 수 있는지 확인하시겠습니까?

내가 하고 싶은 것은 이 문제를 닫고 나머지 수학 문제를 처리하는 새 문제를 만드는 것입니다. 구체적으로:

1. 분할 처리 및 strictMath: 'division' 기능.
2. 혼합 단위의 수학 처리. 참조: https://github.com/less/less.js/issues/3047