Less.js: 조건부 CSS 코드

http://www.lesscss.org/ 로 이동하여 경비원을 검색하십시오.

믹스인을 사용하지 않으려면 모든 CSS에서 가드를 허용하는 기능 요청을 살펴보세요.

예, 알고 있습니다. 하지만 훨씬 적게 작성하는 경우 수백 개의 .mixin을 작성하고 관리해야 합니다.
나는 mixin이 이 문제를 해결한다고 생각하지 않습니다. 믹스인도 이 기능으로 많은 힘을 얻을 수 있습니다.
적은 CSS는 일부 프로그래밍 언어가 가지고 있는 거의 모든 기능을 가지고 있는데 왜 그렇지 않습니까?

.button-maker (<strong i="8">@style</strong>: 'light') {
    cursor: pointer;
    display: inline-block;
    padding: 5px 10px;

    if(<strong i="9">@style</strong> == 'light'){
        /* adds light styling */
    }

    if(<strong i="10">@style</strong> == 'dark'){
        /* adds dark styling */
    }
}

나는 내가 정말로 놓치고 있는 이 기능에 대해 큰 +1을 추가할 것입니다. 큰 코드베이스로 경비원을 유지하는 것은 정말 악몽입니다. 이렇게 하면 정말 일이 훨씬 쉬워질 것입니다...

switch 문을 추가할 수도 있습니다.

@lukeapage 이 문제를 다시 열 수 있습니까? 이 문제/기능에 대해 논의해야 한다고 생각합니다.

LESS는 스크립팅 언어가 아닙니다. 구문/스타일은 CSS와 유사합니다.

LESS는 선언적이어야 합니다. 즉, 분기 논리, 루프 등을 포함하는 복잡한 상황이 되어서는 안 됩니다.

@pierresforge 가드가 부족한 예가 있습니까?

선택기에 가드를 둘 수 있으면 해결되지 않는 곳은 어디입니까?

토론이 열려 있습니다. 저(또는 핵심 팀의 다른 구성원)가 필요하다고 설득할 수 있다면 문제를 다시 열겠습니다. .

http://lesscss.org/ 의 문장
"LESS는 변수, 믹스인, 연산 및 함수와 같은 동적 동작으로 CSS를 확장합니다."

예 LESS는 스크립팅 언어가 아니지만 여전히 변수, 함수 및 작업과 같은 기능이 있습니다.
빠진 것은 조건부 논리입니다.

CSS 미디어 쿼리는 조건부 논리에 불과하다고 생각합니다.

<strong i="11">@media</strong> all and (max-width: 699px) and (min-width: 520px), (min-width: 1151px) {
  body {
    background: #ccc;
  }
}

CSS가 가드와 같은 조건부 논리를 가질 수 있다면. 그래서 차이점은 무엇입니까. 믹스인으로 확장하기만 하면 됩니다.
Guards는 CSS 코드 블록 외부의 조건만 허용하고 코드 블록 내부는 허용하지 않습니다.
예를 들어 https://github.com/cloudhead/less.js/issues/1293#issuecomment -16929701을 참조하십시오. 경비원은 이러한 요구 사항을 도울 수 없습니다..

HTML에도 조건부 논리가 있습니다. 예, 스크립팅 언어가 아닌 마크업 언어가 있습니다.

<!--[if gte IE 9]><!-->        
    <script src="" />
<!--<![endif]-->

@lukeapage 감사합니다..

경비원은 미디어 쿼리가 하는 일과 유사합니다. 일반 CSS에서는 선택기 내부에 미디어 쿼리를 중첩할 수 없습니다. 문서의 루트에만 둘 수 있습니다.

아니, 경비원이 충분하지 않은 예가 없습니다. 그러나 가드가 유지 관리에 가장 적합하지 않은 곳이 많이 있습니다.

예:

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  if (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="7">@coreBackgroundColor</strong>, 20%);
  }
  else if (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="8">@coreBackgroundColor</strong>, 15%);
  }
  else if (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="9">@coreBackgroundColor</strong>, 8% );
  }
  else {
    background-color: @coreBackgroundColor;
  }
}

내 의미에서 다음보다 더 간결하고 자명합니다(주로 알고리즘이 많은 요인에 의존하기 때문에 코드를 재사용할 수 있도록 만드는 것이 의미가 없는 경우).

.buttonBackground(@color) when (green(@color) > 50%) {
  background-color: darken(<strong i="13">@coreBackgroundColor</strong>, 20%);
}

.buttonBackground(@color) when (red(@color) > 30%) {
  background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 15%);
}

.buttonBackground(@color) when (red(@color) > 25%) {
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 8%);
}

.buttonBackground(@color) {
  background-color: @color;
}

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;
  .buttonBackground(@coreBackgroundColor);
}

나는 이것이 토론의 대상이라는 데 동의하지만 많은 핵심 변경 사항을 포함하지 않는다면 이것은 꽤 좋은 추가 사항이 될 것입니다. 믹스인을 추가하지 않고도 단일 요소에 적용할 대부분의 규칙을 함께 묶을 수 있습니다.

이러한 상황이 내가 대비 기능을 작성한 이유입니다. 다른 방법으로는 사용할 수 없는 일종의 조건부 연산으로 작동하며, 말씀하신 대로 가드를 사용하는 것보다 훨씬 깔끔합니다. 조건에 대한 구문을 추가하는 것보다 일종의 선택기 역할을 하는 일종의 일반 함수를 구현할 수 있다고 생각합니다.

@Soviut Devil의 옹호자 - LESS에서는 실제로 미디어 쿼리를 선택기 내부에 배치할 수 있으며 이는 종종 매우 유용합니다.

나는 코드의 복잡성을 기하급수적으로 증가시키기 시작하고 LESS가 간단하고 직관적으로 설계되었기 때문에 if에 반대했습니다. 현재로서는 새로운 기능을 추가하는 것보다 언어를 안정화하려는 노력이 있습니다.

그러나.... 다시 악마의 옹호자, 미디어 쿼리가 이제 선택자 내에서 표시된다는 논리에 따라 경비원은 이론적으로 동일한 원칙을 따를 수 있습니다.

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;

  <strong i="9">@when</strong> (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="10">@coreBackgroundColor</strong>, 20%);
  }
  <strong i="11">@when</strong> (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="12">@coreBackgroundColor</strong>, 15%);
  }
  <strong i="13">@when</strong> (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 8% );
  }
}

or

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  background-color: darken(<strong i="16">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  background-color: darken(<strong i="17">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

if보다 선언적이며 기존 LESS에 더 가까운 구문이며 각 명령문을 독립적으로 평가합니다(LESS / CSS가 정의된 것처럼).

대안으로(또는 이에 추가하여) 유사하게 믹스인의 평가를 평가 지점에 첨부합니다.

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  .backgroundMixin(<strong i="22">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  .backgroundMixin(<strong i="23">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  .backgroundMixin(<strong i="24">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

틀림없이 문 수준 가드는 믹스인 수준 가드 IMO보다 더/덜 복잡하거나 다른 논리가 아닙니다. 아마도 예제 2와 3은 언어에 덜 확장적일 것입니다. 생각/토론을 위해 그것을 던질 것이라고 생각했습니다.

아무도 내 선언 가드 제안에 대해 많은 말을 하지 않았다고 생각합니다. ;-)

사실 별로 할 말이 없습니다. 그것은 좋은 일이 될 것입니다, IMO :)

예, 이미 믹스인에 있고 미디어 쿼리가 요소 내부에 있을 수 있다면 확장 논리가 합리적인 것 같습니다. @lukeapage 와 @jonschlinkert 그리고 다른 사람들은 어떻게 생각하는지 궁금합니다.

@matthewdl :+1:

그들이 논의한 문제에 대해 이미 그들을 지원했다고 생각하십시오.... :)

@lukeapage #748 문제를 말씀하시는 건가요? 그렇다면 구문에 약간을 추가했습니다. ;-)

if 또는 @when 에 대한 나의 욕구를 표현하면서 차임하고 싶습니다.

나는 가드가 보편적으로 더 좋고 조건문을 사용하는 것보다 덜 복잡한 코드를 만든다는 의견에 동의하지 않습니다. 가드가 실제로 내 LESS 파일을 더 보기 흉하고 읽기 어렵게 만들지만 if / @when 는 실제로 예외적으로 읽을 수 있는 실용적인 상황을 찾고 있습니다. Guards 및 if / @when 조건문은 본질적으로 도구일 뿐이며 둘 다 사물을 아름답거나 추하게 만드는 데 사용할 수 있으며 다양한 상황에 더 적합합니다. 젠장, LESS의 가장 기본적인 선택기 확장 기능만 사용하는 ~300b .less 파일을 생성하여 1GB 이상의 RAM을 소모하고 CPU를 몇 분 동안 휘젓는 상태로 둘 수 있습니다.

최근 프로젝트에서 데스크탑과 모바일 모두에 대한 강력한 지원을 위해 작업하고 있었는데 결국 인라인 미디어 쿼리로 이 작업을 수행하는 것만으로는 충분하지 않다고 결정했습니다. 두 모드 중 어느 쪽이든 사용하지도 않는 추가 CSS를 제공하는 것은 좋은 소리가 나지 않을 뿐만 아니라 배경 이미지를 이중 로드하는 계단식 배열을 시도하고 시간을 낭비하지 않고 데이터 URI를 포함할 수 없는 동안 이 문제를 해결해야 하는 전체 문제 모드에서 사용하지 않는 전체 이미지를 제공합니다. 그리고 두 개의 스타일시트를 계단식으로 배열하여 이 문제를 처리하는 것은 이제 한 클래스에 대한 스타일을 선언하는 두 곳이 있기 때문에 덜 혼란스럽게 만들 것입니다.

내 결정은 하나에서 두 개의 스타일시트를 제공하여 MediaWiki가 RTL을 처리하는 방법에서 페이지를 가져오는 것이었습니다. MediaWiki는 LTR로 스타일시트를 작성한 다음 두 번째 RTL 스타일시트를 생성하기 위해 스타일시트를 뒤집는 방식으로 이를 수행합니다. RTL을 처리하기 위해 LTR에 대해 지정된 모든 항목을 시도하고 재정의할 필요가 없습니다. 마찬가지로 나는 기본 스타일을 main.less(그리고 스타일을 분리하기 위해 참조되는 파일)에 작성하기로 결정했습니다. 이 파일은 직접 컴파일되지 않습니다. 대신 나는 desktop.less와 mobile.less의 두 가지 스타일시트를 가질 것입니다. 이 둘은 모두 <strong i="14">@mobile</strong>: true/false; , <strong i="16">@desktop</strong>: true/false; 와 같은 항목을 설정하고 사물의 크기와 같은 일부 적은 변수를 재정의합니다. 이렇게 하면 내 main.less가 desktop.css와 mobile.css 둘 다로 바뀌고 다른 곳에서 로드할 미디어 쿼리/테스트를 처리할 수 있습니다. 미디어 쿼리를 지원하지 않는 장치에서).

그러나 한 가지 문제는 조건부 블록입니다. "모바일에는 이러한 스타일이 필요하지 않습니다" 또는 "데스크톱에는 이러한 스타일이 필요하지 않습니다"라고 결정한 코드 부분이 있습니다. 현재 내가 이 작업을 더 적게 수행할 수 있는 유일한 방법은 다음을 사용하는 것입니다.
((좋아, 기술적으로 이 스타일은 내가 아코디언 탐색을 사용하지 않기 때문에 가설적이지만 내가 하는 일에 충실합니다))

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  .dummy() when (<strong i="21">@desktop</strong> = true) {
    .accordion-styles();
  }
  .dummy();
}

이 상황에서 @when 와 같은 것을 사용하는 것이 훨씬 더 이해하기 쉽습니다.

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  <strong i="26">@when</strong> (<strong i="27">@desktop</strong> = true) {
    .accordion-styles();
  }
}

저는 실제로 @when 구문과 같은 것을 동적으로 생성된 mixin+guard가 생성된 다음 바로 뒤에 포함되는 해킹으로 바꾸기 위해 더 적은 파일을 사전 처리하는 것을 고려했습니다.
말할 필요도 없이, 전처리기를 전처리한다는 아이디어가 이해하기 쉽게 만드는 좋은 생각처럼 들린다면... 현재 전처리기에 뭔가 문제가 있는 것입니다.

그리고 진실은 이것이 내 데스크탑/모바일 기술에만 적용되는 것은 아니라는 것입니다. 이것은 테마 체계에도 동일하게 적용될 수 있습니다. 당신의 테마와 함께 하나의 메인 레스(less) 파일을 작성하십시오. 그런 다음 더 적은 수의 파일을 포함하고 색 구성표와 같은 항목을 제어하기 위해 더 적은 변수를 설정하기만 하면 됩니다. 색상 조정은 잘 작동하지만 @use_horizontal_nav 와 같은 것을 실제로 사용할 수 있다는 것을 알게 되면 즉시 절벽에서 도망칠 것입니다.

@dantman 1.5.0 및 연결된 CSS 스타일의 경비원은 이것을 할 수 있습니다

.navigation {
  & when (<strong i="7">@desktop</strong> = true) {
    color:red;
  }
}

당신의 예를 들어 설탕입니다.

유일한 단점은 현재 새 선택기라고 생각하여 이전 선택기와 병합하지 않는다는 것입니다. 그러나 이것이 문제를 일으키지 않을 것이며 향후 버전에서 수정될 것입니다.

좋습니다. 기능으로 문서화할 수 있습니까?

솔직히 말해서 @when 와 비교하여 매우 이해할 수 있는지 확신할 수 없습니다. 이전에 .less 파일에서 & when(...) 를 본 적이 있다면 무엇인지 이해했을 것입니다. 한눈에 했다. @when 에 설탕으로 & when() 를 사용하면 좋을 수 있습니다.

나는 @matthew-dean에 이런 종류의 조건부 구조를 추가하면 LESS 코어 파일을 유지 관리하고 테스트하기가 더 어려워질 수 있다는 점에 동의합니다. 그리고 .less 파일은 디버그하기 더 어렵습니다.

우리가 지금 얻은 것은 예술 작품입니다. 사람들은 말 그대로 10분 이내에 LESS의 기본 사항을 이해하고 배울 수 있습니다(나는 중첩 및 혼합에 대해 이야기하고 있습니다). 조건문을 추가하면 디자이너와 애호가. 가드를 사용하여 IF 문을 모방하거나 시뮬레이션하려는 것은 존재하지 않고 솔루션이 필요하지 않은 문제를 악화시키려는 것일 뿐입니다.

개발자가 컴파일하기 전에 LESS 파일에 대한 더 많은 복잡성과 제어가 필요한 경우 더 나은 제어, 유연성 및 복잡성을 달성하기 위해 PHP와 같은 언어를 사용하여 더 적은 수의 파일을 사전 처리하는 것을 막을 방법이 없습니다. 이것을 하는 것은 가장 정확하거나 편리한 방법으로 이것을 하기 위해 상상력을 사용하는 문제일 뿐입니다.

예를 들어 조건부, 스위치, 배열 및 PHP에서 볼 수 있는 모든 멋진 항목이 있는 미친 코드가 있는 "myfile.less.php"라는 파일이 있고 그 ".less.php" 파일에서 다른 파일을 뱉어낸다고 가정해 보겠습니다. 최종 LESS 코드가 있는 "myfile.less"라고 하며, 이렇게 하면 PHP로 모든 서버 변수를 쿼리하고, @imports에서 내 새 .less 파일에 포함하거나 제외할 항목을 결정할 수 있습니다. 더 이상 많은 양의 어리석은 변수를 전달할 필요가 없습니다. LESS 컴파일러를 사용하고 IF 또는 Switch 구조를 시뮬레이션하기 위해 보기 흉하고 읽기 어려운 어리석은 가드를 작성할 필요가 없습니다.

기본 워크플로는 다음과 같을 수 있습니다.

1- 캐시 만료 여부 확인
1- 모든 파일 ".less.php" 파일을 찾아 사전 처리하는 스크립트 호출
2- 모든 ".less" 파일을 컴파일하는 스크립트 호출
3- 업데이트 캐시

@enav 나는 격렬하게 동의하지 않습니다. 문제를 해결하기 위해 2개 언어를 사용하고 싶지 않은 노드의 상단 기반 엔터프라이즈 솔루션에서 더 적은 개발을 사용합니다.

@dantman 문서화되지 않은 사항이 상당히 많이 있으며 예, 문서화해야 합니다. 문서를 확장하고 웹 사이트를 훨씬 더 좋게 만들기 위해 less-docs에서 진행 중인 노력이 있습니다. 거기에 문제를 추가하겠습니다.

@lukeapage , 네, 최근에 깨달았습니다. 나는 변경 로그를 훑어보고 svg-gradient 및 속성 병합과 같은 것을 발견했습니다.

엄밀히 말하면 & when ... 는 문서화된 두 기능 & 과 CSS Guards 의 단순한 조합일 뿐이므로 이미 문서화되어 있습니다. 그러나 헌신적 인 예는 물론 해를 끼치 지 않습니다.

@seven-phases-max, 나는 그 문서를 알지 못했습니다. 보기에는 "이것은 곧 lesscss.org 리포지토리로 이동됩니다! 모든 것이 활성화될 때까지 이 사이트에 연결하지 않는 것이 좋습니다." 논평. 그런 것이 작업 중이라는 것을 아는 것이 좋습니다.

내가 아는 유일한 문서인 lesscss.org의 현재 문서를 참조하고 있었고 현재는 가드를 mixin 기능으로만 문서화했으며 다른 곳에서 사용할 수 있다고 제안하지 않았습니다.

경비원은 이것만큼 좋지 않습니다. :(

이것은 필수 기능이며 scass에도 있습니다.

이것에 대해 +1

오늘 이 댓글이 이 이슈가 공개된 지 몇 년 후에 제기된 것이므로 지금 당장 생각나는 한 가지를 지적하겠습니다.

원래 토론에서 @when 에 대한 저항 중 일부는 추가 규칙입니다. 하지만 지금 생각해보면 그럴 필요가 없었다.

이 두 블록이 같다는 것을 고려하면:

.a {
  & .b { color: blue; }
}
.a {
  .b { color: blue; }
}

그러면 이 두 문장도 파서에 의해 동등하게 받아들여져야 합니다.

.a {
  & when (1=1) { color: blue; }
}
.a {
  when (1=1) { color: blue; }
}

& when 이외의 이유가 없다면 구문상 정말 어색합니다. & 를 생략하여 여전히 부모 선택기와 함께 선택기 조인을 암시하므로 부모 선택기에 대한 보호를 암시하기 위해 & 를 생략하는 것은 도약처럼 보이지 않습니다. 또한 블록 루트 기능은 이제 플러그인과 함께 사용하기 위해 파서에서 허용되므로 더 이상 2013년처럼 이상해 보이지 않습니다.

이것을 다시 열 이유가 없습니다. 결국 우리는 이미 #2072를 가지고 있습니다.

when (1=1) { color: blue; }

두 글자 경제를 위해 거대한 혼란 상자를 여는 것?

경비원은 이것만큼 좋지 않습니다.

뜬금없이 불합리한 댓글을 달 가치도 없다고 생각했습니다. 모든 위치에는 뒤에 무언가가 있어야 합니다(그렇지 않으면 거의 모든 언어에서 단일 조건 없이 _anything_을 작성하는 방법을 알고 있기 때문에 모든 조건부 코드가 절름발이이고 if 가 어리석다고 말하고 싶습니다).

이것을 다시 열 이유가 없습니다. 결국 우리는 이미 when (1=1) { color: blue; } 를 가지고 있습니다.

Errr... 아니 우리는?

그러나 우리가 그래야 하는 것이 합리적입니다. 우리는 그것을 허용하고 끝낼 수 있습니다.

연결해야 하는 기능 요청을 찾을 때까지 기다리세요(미안합니다. 완료하기 전에 실수로 Enter를 클릭했습니다)

그래서 이것을 #2072에 병합합니다.

@seven-phases-max

해당 문제는 "보호된 자체 실행 블록 내에서 변수 재정의 허용"이라고 하며 해당 문제에 대한 맨 아래의 접선 토론에는 select/case 및 vbscript와 유사한 사용 사례가 포함되어 있습니다. iif([ifcond], [then], [else]) 토론을 위한 더 논리적인 픽업일 수도 있지만 알몸일 때 그 이상으로 기능합니다. Buuut... 아마도 when () vs & when () 질문으로 새로운 문제로 제기되어야 할 것입니다.

when() vs & when() 질문만 있으면 됩니다.

당신은 이것에 대해 심각할 수 없습니다, 그렇지 않습니까? 정확히 무엇 때문에? $#$ & 를 제거하면 when 가 if $ 가 되지 않습니다(모든 이유는 #2072 참조). 그러니 그대로 두고 끝내세요.

이봐, 한 단계 낮추어 줄 수 있니? 그것에 대해 화가 난다면 잠시 시간을 내어 나중에 다시 와서 내가 새 호에 게시한 이유를 살펴보십시오. 이러한 최초의 논의 이후 몇 가지 사항이 개선되었습니다.

기분 나쁘게 하거나 그런 건 아니었어요.
나의:

그러니 그대로 두고 끝내세요.

다음과 같은 답변에 불과했습니다.

우리는 그것을 허용하고 끝낼 수 있습니다.

@seven-phases-max 좋아요, 텍스트에서 톤이 손실됩니다. 어쨌든 나는 이 아이디어에 크게 집착하지 않았으며 전반적으로 기존의 @when 제안이 어쨌든 더 낫습니다/더 다재다능합니다.

나는 'sass'가 덜보다 낫다고 생각한다. 이미 if-else가 있습니다. 정말 어렵고 많은 줄의 코딩이 적습니다. 작동하지만 필요를 완전히 채우지 못할 때. 또한 루프를 더 적게 만들 수 있지만 언어에는 고유한 기능이 있어야 합니다.

@aukgit 작업에 적합한 도구를 사용하십시오. SCSS가 당신에게 더 적합하다면 그것을 사용하는 것이 좋습니다. Sass와 Less는 매우 다른 프로젝트입니다.

@matthew-dean은 몇 달 동안 덜 배우고 '적은' 커뮤니티가 더 나은 것을 원하지 않는다면 우리 모두에게 손해입니다. 이것이 부트스트랩이 덜에서 'sass'(https://github.com/twbs/bootstrap/tree/v4-dev)로 이동한 이유라고 생각합니다(초기 이유는 컴파일 속도가 더 빠름). 초기 소스가 'less'에 있는 반면. 이제 그들은 원래 소스를 'sass'로 작성한 다음 less로 변환합니다(반대로 그 반대).

또 다른 한가지 :

"올바른 작업을 위한 올바른 도구"

여기에 적용해서는 안됩니다

덜 | Scss | 스타일러스 유사 프로젝트 . 당시 유행했던 것으로 시작하여 이제는 '적은' 커뮤니티가 스스로를 개선하고 싶어하지 않는 것 같습니다.

'less' 뒤에 있는 아이디어는 적게 쓰고 더 많이 하는 것입니다. 어딘가에서 감소하지만 어딘가에서 더 많은 쓰기가 필요합니다.

귀하의 의견에 감사드립니다.

Fanboyish 구식 선전. 이러한 편향되거나 단순히 잘못된 진술을 모두 주장하는 것은 시간 낭비일 것입니다.

예:

정말 복잡한 조건부 코드를 만들 방법이 없습니다.

네, "스파게티 코드를 작성하기 위한 도구가 필요합니다" - 바로 이렇 습니다 . 이와 같은 코드를 작성한다면 실제로 Less는 확실히 당신의 도구가 아닙니다.

나는 "less"가 sass 및 stylus와 매우 다른 것을 'x'한다고 생각합니다. 다른 모든 것들은 비슷한 일을 하는 반면 'less'는 그것이 비슷한 종류가 아니라고 주장합니다. :)

@aukgit

나는 "less"가 sass 및 stylus와 매우 다른 것을 'x'한다고 생각합니다.

_왜_ 똑같이 해야 합니까? 디자인 간의 주요 차이점을 찾으려면 [1] 및 [2] 예를 참조하십시오. 그래서 당신은 그 개념이 마음에 들지 않을 수도 있지만 아무도 당신이 좋아하지 않는 도구를 사용하도록 강요하지 않습니다.

이제 알겠다. 감사합니다. 정말이지, 정말 가장 잘못 이해되는 언어입니다. Douglas Crockford가 말한 것처럼 자바스크립트도 그렇게 오해받지 않습니다.

사람들은 js에서 실수를 하지만 많은 인식이 있습니다. 'Less'의 경우 첫 페이지(less.org)에 무엇이 더 적고 무엇이 그렇지 않은지 설명해야 합니다.

감사합니다.

mixen을 작성했습니다 :

더 적은:

.if-value-present(@attribute; <strong i="7">@value</strong>: '') {
    .x (@value) when not (<strong i="8">@value</strong> = '') {
        @{attribute}: @value;
    }

    .x(@value);
}

.if-value-present-multi(@attributes; @values) {
    .iter(@i) when (<strong i="9">@i</strong> > 0) {
        .iter(<strong i="10">@i</strong> - 1);
        // loop

        <strong i="11">@attr</strong>: extract(<strong i="12">@attributes</strong>, @i);
        <strong i="13">@value</strong>: extract(<strong i="14">@values</strong>, @i);

        .if-value-present(<strong i="15">@attr</strong>, @value);
    }

    <strong i="16">@len</strong>: length(@values);
    .iter(@len);
}
.x {
    <strong i="17">@var</strong>: c1,c2, c3;
    <strong i="18">@val</strong>: v1, '', 'wddww';
    .if-value-present-multi(@var;@val);
}
.x{
    .if-value-present(content, 'new val');
}

CSS 출력:

.x {
  c1: v1;
  c3: 'wddww';
}
.x {
  content: 'new val';
}

'적은' 커뮤니티가 더 나은 것을 원하지 않는다면 그것은 우리 모두에게 손실입니다.

"내가 원하는 X 기능이 지원되지 않는다" == "더 적은 커뮤니티가 더 나은 것을 원하지 않는다"라고 가정하는 것은 실수라고 생각합니다. 그것은 우리를 어디에도 데려가지 않습니다.

제어 흐름을 개선하기 위해 Github에 대해 몇 가지 논의가 있습니다. 사실, 이 스레드는 거부되지 않고 #2072에 병합되었습니다. 닫힌 3년 된 스레드에 댓글을 남겼습니다. 나는 그것을 #2072와 조금 다르게 만들 수 있다고 생각했지만 본질적으로 그렇지 않다고 생각했던 몇 가지 다른 아이디어가 있었습니다.

이제 더 나은 기능이 없는 것 같습니다

Less에는 _more_ 기능이 없습니다. 이것은 사실입니다. 이것은 의도적으로 설계된 것입니다. 이것은 당신이 하루에 Less를 배울 수 있도록 하기 위한 것이며 Less의 기능은 일반적인 사용 사례의 99%를 커버합니다. Sass는 학습 곡선이 더 가파릅니다. Sass는 기능이 너무 많아 계속 컴파일하려면 저수준 C 기반 컴파일러를 빌드해야 했습니다. 대단한 성과입니다. 그러나 결국 스타일 시트를 만드는 것에 대한 훌륭한 증거는 아닙니다.

이제 그들은 원래 소스를 'sass'로 작성한 다음 less로 변환합니다(반대로 그 반대).

사실이지만 이는 여러 요인을 기반으로 하며 그 요인이 무엇인지 물어볼 수 있습니다. 개인적으로 Less 사용자를 포기하는 것은 실수라고 생각합니다. 오늘날 Less에서 Bootstrap을 사용하는 사람들이 많기 때문입니다.

하루가 끝나면 조건문을 작성하는 데 필요한 후프에 대한 귀하의 불만은 _틀리지 않습니다_. 여기에 제공된 예는 단순히 언어에 적합하지 않습니다. 나는 당신이 #2072의 스레드를 읽을 것을 제안합니다.

(이건 사실 좀 뜬금없지만 그냥 궁금해서요)

<strong i="7">@var</strong>: c1, c2, c3;
<strong i="8">@val</strong>: v1, '', 'wddww';

그리고 .if-value-present-multi 를 호출하는 것 외에 이러한 변수의 용도는 무엇입니까?
(그리고 _if_ 이 변수들은 _are_ 다른 용도로 사용됨) 대신에 단지 속성/값 쌍을 사용하는 것이 말이 되지 않습니까? 예:

<strong i="14">@rules</strong>:
    c1 v1,
    c3 'wddww';
   // no need for c2 since it has no effect

게다가 .x {content: 'new val'} 필요한 경우 .x {.if-value-present(content, 'new val')} 를 작성하는 목적은 무엇입니까? 그리고 아무 것도 하지 않는다면 .x {.if-value-present(content)} 를 작성하시겠습니까?

(솔직히 [1] 을 보았지만 - 글쎄, 단 한 가지를 제외하고는 아무 것도 언급하지 않았습니다. (_시간을 절약하기 위해_) elements 및 lesshat 와 같은 고대 라이브러리를 버리는 것을 고려하십시오 - 그리고 대신 autoprefixer 를 사용하십시오. 당분간 CSS 전처리기에 대해 공급업체 접두사 라이브러리가 필요하지 않습니다.

이것은 일반적으로 대부분의 "기능 요청"이 들어오는 방식입니다: "XY 문제" . (관련 분야에서 유사한 실패의 다른 좋은 예: #1400 및 #1894, 기능이 완전히 쓸모가 없다는 것은 아니지만(따라서 둘 다 열린 상태로 유지됨) 실제 사용 사례를 묻기 시작하면 일반적으로 다음과 같이 표시됩니다. X)를 해결하려는 시도에서 Y가 잘못되었습니다.

다음은 사용 사례입니다.
마지막 매개변수가 주어지지 않은 경우 3개의 매개변수로 mixn을 만들려고 시도했습니다. 그러면 mixn 내부에 속성을 생성해야 하므로 조건이 유용했습니다.

여기에서 https://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/responsive/responsive-placements.less 나는 그것을 달성할 수 있었던 동일한 mixen을 반복해서 구현하려고 시도했습니다. 아주 쉽게 조건.

이제야 알았습니다.. 감사합니다.

@aukgit 이러한 믹스인을 쉽게 접을 수 있어야 합니다.

https://gist.github.com/matthew-dean/e617bc1f71528843ef9fa73d70427bcf

시간을 내어 도와주신 @matthew-dean에게 감사드립니다. :) 나는 당신에게 가득 차 있습니다.

:)

나는 'sass'가 덜보다 낫다고 생각한다. 이미 if-else가 있습니다.

두 언어 모두 고유한 문제가 있습니다.

동적 가져오기가 없고 구현하기를 꺼리는 것이 제가 Sass에서 Less로 전환하고 싶은 주된 이유입니다. Less는 몇 년 동안 이 기능을 사용했습니다!

그러나 FOR 루프 또는 IF-ELSE 문과 같은 기존 제어 구조 의 부족과 징그러운 구문이 제가 이 조치를 취하지 못하게 하는 것입니다.

바위와 딱딱한 곳 사이에 끼어있는 느낌...

@jslegers #249에서와 같은 주석입니다. Less는 v1.x 이후로 다양한 형태의 조건부 제한(최신 버전에서는 점점 더 많이)을 가지고 있습니다.

@seven-phases-max

나는 IF 문에 대한 대안으로 보호된 믹스 인과 Less에서 루프에 대한 대안으로 재귀 믹싱 을 알고 있습니다. 그러나 그것이 Less의 제어 구조에 대한 문서에서 찾을 수 있었던 전부입니다. 그리고 여러 언어에 대한 프로그래밍 경험이 있는 사람으로서, 나는 그들의 구문이 혼란스럽고 솔직히 말해서 상당히 징그럽다고 생각합니다.

언급할 가치가 있는 것 외에 다른 제어 구조가 있는 경우 문서에서 찾을 수 없습니다.

어쨌든, 뭔가 ...

scss a { <strong i="11">@if</strong> $time == morning { color: red; } <strong i="12">@else</strong> if $time == afternoon { color: blue; } <strong i="13">@else</strong> { color: grey; } }

... 또는 같은...

scss <strong i="17">@each</strong> $author in $list .photo-#{$author} background: image-url("avatars/#{$author}.png") no-repeat

... 아니면 이거...

scss <strong i="21">@for</strong> $i from 1 through 8 { $width: percentage(1 / $i) .col-#{$i} { width: $width; } }

... 내 생각에는 Sass에서 보호된 믹스인이나 Less에서 재귀적인 믹스인으로 비슷한 것을 작성해야 하는 것보다 훨씬 더 읽기 쉽고 우아합니다.

그러한 문장의 부족과 (Sass와 비교하여) Less의 전반적으로 읽기 어려운 구문은 내가 Sass를 고수하는 것을 선호하고 내 프로젝트 중 하나에 Less를 고려하는 것조차 꺼리는 두 가지 주요 이유입니다.

그리고 Sass가 Less보다 훨씬 더 인기를 얻었다는 점을 고려할 때, 저만 그렇게 느끼는 것은 아닙니다.

@jslegers 예를 들어 게시하기 전에 이미 사용 가능한 항목을 알아보십시오.
나머지(인기 등) - 너무 단순화된 방식으로 무언가를 논의하는 것은 의미가 없습니다(Stylus에는 이 모든 기능이 있고 무엇입니까?). 게다가 Less는 다른 CSS 전처리기를 대체하거나 복제가 되지 않는다고 선언된 적이 없습니다. 그리고 마지막으로, 가장 흔한 실수는 무언가의 인기가 작가의 일차적이자 유일한 목표라고 생각하는 것입니다.

그것들을 게시하기 전에 이미 사용 가능한 것이 무엇인지 알아보십시오.

더 나은 문서화를 시도하거나 사람들이 찾고 있는 것을 찾지 못하는 경우 직접 알려줍니다.

나머지 (인기 등) - 너무 단순화된 방식으로 무언가를 논의하는 것은 의미가 없습니다 [...] 그리고 마지막으로, 가장 흔한 실수는 무언가의 인기가 작가의 주요 목표이자 유일한 목표라고 생각하는 것입니다.

참고로 저는 인기가 품질이나 유용성을 나타내는 강력한 지표라고 암시한 적이 없습니다. 실제로는 그 반대인 경우가 많습니다.

그래도 사람들이 Less에서 Sass로 이동하는 이유를 보면 매우 간단합니다 .

개인적으로 거기에서 나는 2012년을 계산하지도 않고 일반적인 "나는 내 PHP 스파게티를 원한다"(위의 잘못된 도구에 대한 게시물 참조) 외에는 아무 것도 볼 수 없습니다(이미 대부분의 예제가 현대적인 Less에서는 매우 컴팩트하다고 암시했지만, 일어나고 싶지 않은 것 같습니다).
하지만 신경쓰지 마세요. 보통 저는 명백한 잘못된 정보, 왜 일이 발생하거나 발생하지 않는지에 대한 개인적인 의견에 대한 토론만을 주장합니다.

개인적으로 거기에는 평소의 "PHP 스파게티를 원합니다" 외에는 아무것도 볼 수 없습니다.

Sass 대신 Less를 사용하면 코드가 불가피하게 "PHP 스파게티"처럼 보이게 되는 것 같습니다(PHP가 스파게티 코드의 전형이라고 생각한다면 분명히 ABAP 프로그래밍을 한 번도 하지 않은 것입니다). 기본 변수와 믹스인보다, 하지만 나는 여기서 내가 틀렸다고 기꺼이 생각합니다.

나는 이미 이러한 예제의 대부분이 현대적 Less에서 매우 간결해진다고 암시했지만, 당신은 깨어나고 싶지 않은 것 같습니다.

그렇다면 왜 나를 깨우고 나의 무지에서 벗어날 수 있는 한두 가지 소스를 제공하려고 노력하지 않으시겠습니까?

누군가가 내 잘못을 증명하는 것보다 더 신나는 일은 거의 없습니다. 제 경험상 그게 성장하는 가장 좋은 방법입니다...