Less.js: : 믹스인 확장

나는 그것을 좋아하지만 명확히하기 위해 .. 이것은 당신이 전에 할 수 없었던 것을 허용하지 않습니다. 그것은 당신이 얻는다는 것을 의미합니다..

.navbar,
.banner {
    // clearfix stuff
}

보다는

.navbar {
    // clearfix stuff
}
.banner {
    // clearfix stuff
}

아니면 내가 잘못 이해 했습니까?

파라메트릭 믹스인과 일반 믹스인을 모두 갖고 싶습니다.

.navbar,
.banner {
    // clearfix stuff
}
.....

또는

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}
....

필요할 때마다 이것이 믹스인이 이미 작동하는 방식과 유사한 방식이라는 것을 알고 있으므로 최적화 측면에서 최종 CSS 출력을 더 잘 처리할 수 있는 유연성과 방법이 대부분입니다.

확실히

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}

보다 짧다

 .clearfix {
    // clearfix stuff
  }
 .navbar{
    // clearfix stuff
 }
.banner {
    // clearfix stuff
}

그리고 중요할 수 있는 더 복잡한 예의 경우 일부 사람들이 이러한 부족 때문에 SASS로 전환했다는 것을 알고 있습니다.

일반 믹스인은 변경할 수 없습니다. 그것들은 거의 Less의 고정 장치입니다. @agatronic , 네 저도 그렇게 봅니다. 하지만 여기에는 매개변수 믹스인을 확장할 수 있는 것과 같은 문제가 있습니다. 그렇다면 어떻게 작동할까요? 이것이 지원된다고 가정하고 매개변수 믹스인을 두 번 확장하지만 다음과 같이 매번 다른 변수를 사용한다고 가정해 보겠습니다.

.transition(@transition) {
  -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}
.navbar {
    &:extend(.transition(opacity .2s linear));
}
.banner {
    &:extend(.transition(opacity .3s linear));
}

나는 그것이 두 개의 mixin 사본을 생성할 수 있다고 상상합니다. 이것은 코드도 적지 않고 일반 mixin에 비해 이점도 없습니다.

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

그러나이 특정 믹스 인을 많이 사용할 수 있습니다, 그래서 당신은 다시의 믹스 인을 사용하는 경우 .dropdown 와 같은 변수 .banner ,이 발생할 수 있습니다

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner,
.dropdown {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

그리고 이것이 저를 흥미롭게 만드는 것입니다. 다른 분들의 피드백도 들어보시면 좋을 것 같아요

@jonschlinkert 예, 더 나은 그림입니다. 감사합니다. 내가 말했듯이 그것에 두 손을! 그러나 그것이 다른 수준의 공모를 추가하고 있으며 신중하게 수행해야 하거나 수행하지 않아야 함을 이해합니다.

참조하는 방법의 확장은 다음 패턴을 사용하여 매우 쉽게 달성할 수 있습니다.

.transition(@transition) {
    -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}

.quickOpacity1(){
    .transition(opacity .2s linear);
}

.quickOpacity2(){
    .transition(opacity .3s linear);
}

.navbar{
    .quickOpacity1();
}

.banner,
.dropdown{
    .quickOpacity2();
}

위의 내용은 2개의 새로운 선언에 반 확장 믹스인을 주입하는 것입니다.

clearfix의 경우 아래의 유사한 패턴을 사용하기 쉽습니다. 이는 clearfix를 클래스로 생성할 뿐만 아니라 해당 clearfix 스타일을 새 선언에 삽입합니다.

.clearfix{
  //clearfix stuff
}
.navbar,
.banner {
    .clearfix;
}

@krisister 이것에 대해 혼란이 있을 수 있다고 생각합니다. 설명하는 패턴은 실제로 중첩된 믹스인 또는 믹스인 상속 패턴입니다. 그 역으로 작업을 확장합니다.

@jonschlinkert Mixin 상속 - 훌륭한 이름입니다. 위의 두 예제 모두 확장의 핵심 기능인 부모로부터 출력을 상속하려고 시도하는 것처럼 보였습니다. 내 예제의 출력이 예상한 출력이라는 데 동의할 것입니다.

그러나 귀하의 원래 의견을 다시 읽으면 이해합니다. 출력을 하나의 CSS 규칙으로 결합하기를 원합니다. 원래 2로 작성되었지만.

실제로 :extend 는 꽤 굉장합니다. 나는 완전히 괴상한 사람이 될 것이지만 모든 것은 "무엇이 어디로 옮겨지는가"에 달려 있습니다. "믹스인의 속성을 그것을 사용한 선택기로 전달하는 것"과 같은 믹스인을 생각하십시오. 그리고 :extend 를 "믹스인 자체까지 사용한 셀렉터 빔"을 역으로 생각해 보세요. _selector의 속성이 아니라 선택자 자체입니다. 그래서 당신이 이것을했다면 :

.some-mixin() {
    padding-top: 100px;
    background: #f7f7f7;
}


// a selector that is extending the mixin
.alert:extend( .some-mixin() ) {
    border: 1px solid #e5e5e5;
}
// another selector extending the mixin
section:extend(.some-mixin()) {
    margin: 20px 0;
}

결과는 다음과 같습니다.

// The selectors that extended the mixin are now where the mixin used to be.
.alert,
section {
    padding-top: 100px;
    background: #f7f7f7;
}

// And the properties of the mixin did not get copied down below
// so we saved a line or two of code.
.alert {
    border: 1px solid #e5e5e5;
}
section {
    margin: 20px 0;
}

그것이 더 의미가 있기를 바랍니다. 언제든지 도와드리겠습니다.

@agatronic , @matthewdl , @DesignByOnyx , 생각만 해도 이것이 특이한 접근 방식이라는 것을 알고 있지만 이에 대한 기술적인 문제가 없다고 가정하고 쉼표로 구분된 선택기 목록을 허용한다고 가정하면 확장 _should_가 배열처럼 느껴질 수 있습니다. . 구문을 :extend[N] 변경하는 것에 대해 어떻게 생각하십니까?

믹스인이 확장되면 눈에도 더 쉽게 보입니다.

section:extend[.some-mixin(), .another-mixin()] {
    margin: 20px 0;
}

어느 쪽이든 괜찮습니다. 하지만 대괄호에 대해 뭔가 제대로 된 느낌이 듭니다.

@jonschlinkert - [] 는 배열이 아닌 css의 속성을 의미합니다. 여기서 :extend() 는 의사 선택기에 대한 링크로 인해 선택되었으므로 일반 대괄호가 유지되어야 한다고 강력하게 생각합니다.

좋은 지적, 동의합니다.

대괄호가 보기 좋고 읽기 좋다는 데 동의하지만, 이미 선택한 구문을 고수해야 합니다.

확장(N) 구문에 대해 엄지손가락을 치켜들고 @agatronic과 같은 이유로 자연 CSS처럼 더 많이 느껴집니다.

믹스인을 확장하는 것은 나쁜 생각이 아닙니다. 예제 구문 @jonschlinkert가 확실하지 않습니다. 내가 그것을 좋아하지 않는 것은 아닙니다. 나는 당신이 쓴 것을 실제로 이해하지 못합니다.

당신이 의미하는 바는 동일한 믹스인 콘텐츠를 "가져오기"하지만 결과 CSS에서 실제로 반복하지 않는 클래스를 정의하고 싶다는 것입니다. 나는 그것을 확장 믹스인이라고 부르지 않을 것입니다. 즉, 확장 정의가 선택기에 대해 수행하는 것과 동일한 방식으로 mixin 정의를 변경하는 것이 아니라 결과 클래스를 실제로 변경(확장)하는 것입니다.

따라서 내가 틀렸다면 수정해 주세요. 하지만 navbar/banner/dropdown 예제는 다음에서 지원되지 않습니다.

.navbar {
  .transition(opacity .2s linear);
}
.banner {
  .transition(opacity .3s linear);
}
.dropdown:extend(.banner) { }

즉, 평소처럼 클래스를 확장하시겠습니까? 나는 단지 당신의 사용 패턴에 대해 머리를 싸매려고 노력 중이며, 믹스인에 확장을 사용하는 것은 선택자를 확장하기 위한 사용 및 명명법과 모순되는 것 같습니다. 확장 호출에서 믹스인을 참조해야 하고 믹스인을 참조한 선택기를 확장하지 않아야 하는 이유에 대한 추가 세부정보를 제공할 수 있습니까?

그게 내가 그것을 얻는 방법

원하는 최종 CSS 출력

.sometingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.anotherClass,
.anotherYetClass {
    // did something dynamic with a
}

.yetClass {
    // did something dynamic with b
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

원하는 출력을 얻기 위해 현재 버전을 사용하는 방법

.somethingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass,
.anotherYetClass {
    .someMixin(a);
}

.yetClass {
    .someMixin(b);
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

제안된 덜 구문

.somethingShared {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass:extend(.sometingShared, .someMixin(a)) {
    // native another class code
}

.anotherYetClass:extend(.sometingShared, .someMixin(a)) {
    // native another yet class code
}

.yetClass:extend(.sometingShared, .someMixin(b)) {
    // native yet class code
}

확장은 공유 코드의 양이 정말 많을 때만 유용할 수 있지만 다른 경우에는 일반적인 믹스인 사용이 유리합니다.

그리고 약간, 그냥 놀기 위한 라이브 더미 샘플

http://jsbin.com/opekon/1/edit
http://jsbin.com/opekon/2/edit
http://jsbin.com/opekon/3/edit
http://jsbin.com/opekon/4/edit

말했듯이, 나처럼 게으른 사람들을 위해 특정 상황에서 실제로 성능 향상이 있을 수 있습니다 :) 추가 유연성에 영향을 받기 때문에 LESS 코드 최적화

다음은 SASS가 확장을 처리하는 방법과 관련된 몇 가지 사항을 다루는 확장에 대한 멋진 블로그 게시물입니다. 다른 사람들이 이 작업을 수행한 방법에서 배우는 것이 현명할 것입니다. http://designshack.net/articles/css/semantic-grid-class-naming-with-placeholder-selectors-in-sass-3-2/

특히 믹스인 확장에 대한 내 제안은 본질적으로 SASS "자리 표시자"와 동일한 최종 결과를 얻을 수 있지만 쓸모없고 불필요한 자리 표시자 전용 클래스를 만들 필요가 없다고 생각합니다.

편집: 예, 여기에 자리 표시자를 멋지게 요약한 또 다른 게시물이 있습니다. 믹스인 확장 http://maximilianhoffmann.com/article/placeholder-selectors 와 함께 제안하는 바로 그것입니다

나는 개인적으로 이것을 다른 모든 확장 관련 기능보다 선호합니다. 질문없이. 이것은 강력한 진술이지만 다른 사람들이 동의하지 않는다면 나는 그것을 잘 설명하지 못하고 있다고 생각합니다. 이것은 꽤 강력한 물건입니다.

SASS가 느껴집니다.

 %tile {
  width: 200px;
  height: 200px;
  margin-right: 20px;
}

확장 전용으로 설계된 매개변수 믹스인과 동일하며, 관심사 분리 측면에서 그리 나쁘지 않을 것입니다. 하지만 예, 그것은 CSS이며 가능한 한 간단하다고 가정하지 않습니까?

@agatronic에 대해 이야기하는 동안 https://github.com/agatronic/less.js/blob/master/lib/less/tree/extend.js 가 확장되어야 하는 것은 무엇입니까? 이미 main less 브랜치에 있다고 언급했습니다. 멍청한 질문 죄송합니다.

@dmi3y 1.4.0에 대해 준비된 pull 요청에서 가져온 확장의 첫 번째 버전입니다. 확장 노드를 나타냅니다.

@agatronic 감사합니다. 이제 내가 얼마나 놓쳤는지 알 수 있습니다 ;)

@dmi3y 대화에 계속 추가해 주시기 바랍니다. 이 문제를 더 높은 수준에서 유지하여 결론을 내릴 수 있도록 합시다. 또한 개인적으로 이메일을 보내주십시오. mixins 및 extends 작업 방법에 대해 논의하게 되어 기쁩니다(연락처 정보는 프로필에 있습니다). 또한 이 스레드에 대한 추가 혼란을 피하기 위해 빠른 설명을 제공합니다. 귀하의 예:

%tile {
    width: 200px;
    height: 200px;
    margin-right: 20px;
}

이것은 SCSS 사양에서 구현된 SCSS "placeholder"의 구문으로, 믹스인 확장으로 제안하는 것과 유사한 작업을 수행합니다. 그러나 이것은 매개변수화와 관련이 없습니다. 매개변수 믹스인은 단순히 _매개변수를 허용하는 믹스인이며, 이는 사용할 때마다 값이 변경될 수 있음을 의미합니다.

@matthewdl

당신이 의미하는 바는 동일한 믹스인 콘텐츠를 "가져오기"하지만 결과 CSS에서 실제로 반복하지 않는 클래스를 정의하고 싶다는 것입니다.

그리고

navbar/banner/dropdown 예제가 지원되지 않습니까?

아니요, 작동 지점을 놓치고 있습니다. 완전히 반대입니다. 내 예제에서 파라메트릭 믹스인에 초점을 맞추는 실수를 했기 때문에 혼동이 발생한 것일 수 있습니다.

그래서 먼저 모든 믹스인이 매개변수가 아니라는 점을 설명하는 것이 중요하다고 생각합니다. 많은 믹스인이 매개변수를 허용하지 _않도록_ 생성됩니다. clearfix와 같은 일부 믹스인은 사용될 때 변수를 변경하지 않고 계속해서 사용됩니다. 이것은 mixin 확장이 유리한 이유에 대한 완벽한 사용 사례입니다.

파라메트릭 여부에 관계없이 모든 영광 믹스인에는 사용할 때마다 속성이 복제 된다는 단점이 있습니다. 그래서 믹스인 확장이 "일반 믹스인"만 사용하여 작동하는 방법을 설명하고 위에서 사용한 예제를 계속하겠습니다.

귀하의 예를 보면 완전히 독립적이고 관련이 없는 두 가지 사항이 필요합니다.

1. 배너 클래스는 확장 여부에 관계없이 컴파일된 CSS에 계속 표시되지만 배너 클래스가 믹스인인 경우 사용(확장 또는 혼합)된 경우에만 결과 CSS에 표시됩니다. 이것만으로도 가치가 있습니다. 그리고
2. 믹스인을 확장할 때 동일한 속성을 계속해서 복제하는 대신 실제 선택기 자체를 믹스인 위치에 복사합니다.

그러나 이것은 하나의 예일 뿐입니다. Twitter Bootstrap의 한 지점에서 .clearfix() mixin 단독으로 다른 선택기 내에서 20번 이상 사용되었으며 .container-fixed() , .make-row() 와 같은 4개 또는 5개의 다른 구조적 mixin 내부에도 중첩되었습니다. #grid > .core() . 이는 해당 믹스인 이 사용할 때마다

이게 더 말이 되나요? 따라서 clearfix 믹스인의 속성을 20번 이상 복제하는 대신 믹스인 자체의 위치에 clearfix 믹스인을 사용하는 선택자를 그룹화하고 속성은 한 번만 선언됩니다. 다시 말하지만, 이것은 하나의 믹스인에 불과합니다. 일반 믹스인의 손실을 확장하고 속성을 복제할 때의 순 이익을 상상해 보세요. 위에서 어딘가에 언급했듯이 일반 믹스인은 특수성과 재정의를 위해 때때로 확장하지 않고 사용해야 하지만 그렇지 않은 믹스인을 확장하는 가치가 줄어들지는 않습니다. 사실, 나는 개인적으로 확장과 함께 특별히 사용할 추가 믹스인을 만들 것입니다. 그렇지 않으면 사용하지 않을 것입니다.

그리고 위의 두 번째 예는 확장이 매개변수 믹스인과 어떻게 작동하는지에 초점을 두었으므로 이것이 그림을 완성하고 이제 더 이해가 되기를 바랍니다. 그렇지 않은 경우 위에 링크한 기사를 통해 혼란을 해소할 수 있습니다. 믹스인을 확장하는 것은 매우 강력하고 유용하며 중첩된 선택기를 확장하는 것과 동일한 결과를 얻을 수 있지만 특히 중첩된 선택기 대신 믹스인을 사용하면 됩니다. 이를 통해 원하는 결과를 제공할 가능성이 가장 높은 방식으로 선택기를 구성하고 의도하지 않은 결과를 방지할 수 있습니다. @DesignByOnyx , @agatronic , @matthewdl , 여기서 내가 놓치거나 잊어버린 것이 있습니까? 혼란을 없애기 위해 우리가 할 수 있는 일이 있습니까?

감사 해요. 나는 유스 케이스를 이해하고 있다고 생각하며 다음 줄이 가장 잘 설명되어 있다고 생각합니다.

배너 클래스는 믹스인으로 사용된 경우에만 결과 CSS에 표시됩니다(확장 또는 혼합).

그것은 나에게 의미가 있습니다. 아마도 내가 끊고 있는 것은 전체 :extend 구문이 아직 최종적이지 않다는 것입니다. 그러나 당신은 설득력 있는 사례를 만듭니다.

선택기 블록을 완료하면 믹스인을 확장하는 동작이 선택기를 확장하는 동작과 일치하게 되면 초기 사용법이 없는 한), 그것은 나에게 직관적입니다.

즉, 다음과 같은 작업(또는 동등한 구문)을 수행할 수도 있습니다.

.facebook-button:extend( .button() all ) {
    border: 1px solid #e5e5e5;
}

... 그럼 나에게서 엄지손가락을 치켜세워라. 하지만 저에게 있어 모든 것은 선택자에 대해 :extend 를 무엇을/어떻게/어떻게 해결하는지에 달려 있습니다. 그러나 구문은 제쳐두고 기능 아이디어로서 당신의 말이 옳습니다. 건전합니다.

@jonschlinkert 감사합니다. 귀하의 지지에 감사드리며, 분명히 제 생각을 가능한 한 명확하게 전달하기 위해 최선을 다할 것입니다. 나는 미래의 발전과 예, 들을 수 있는 것에 대해 듣는 것이 상당히 재미있다고 생각합니다. 여러분, 멋진 일을 하십시오.

예, 이 예에서는 이전 게시물에서 명시적이어야 했습니다.

%tile {
   width: 200px;
   height: 200px;
   margin-right: 20px;
 }

Jon이 제공한 SASS 자습서에서 가져왔으며, 그 주요 목표는 사용하지 않을 클래스의 CSS 출력을 폐기하는 것을 방지하는 것입니다. 따라서 이 특정 각도에서는 LESS의 빈 매개변수 믹스인처럼 보일 수 있습니다. 사용하고 싶지만 최종 스타일시트에 출력되지 않을 때.

나는 이 토론에 뛰어들어 다음 의견에 대해 명확하게 설명하고 싶습니다.

배너 클래스가 믹스인인 경우 사용된 경우(확장 또는 혼합) 결과 CSS에만 표시됩니다.

더 일반적인 clearfix 예제를 사용하면 이것이 더 적고 결과 CSS입니까?:

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }

    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.clearfix:before,
.clearfix:after,
.something:before,
.something:after {
    content: " ";
    display: table;
}
.clearfix:after,
.something:after {
    clear: both;
}
*/

원래 .clearfix 클래스가 컴파일된 CSS에서 생략된 상태로 유지될 것으로 예상했습니다. 개인적으로, 나는 마크업에서 그것을 사용하지 않을 것이고 내 CSS에 여분의 바이트가 있기 때문에 컴파일된 CSS에서 클래스를 _필요로 하지 않을 것입니다. 어느 쪽이든 강한 의견은 없지만 이 점에 대한 설명은 앞으로 더 나은 의견을 제시하는 데 도움이 될 것입니다. 감사 해요.

이것은 ... 결과 CSS입니까?:

나는 당신이 물어 기쁘다,하지만 더 만 .something 클래스는 결과 CSS에 표시됩니다. 그래서 당신은 원래 예상이 맞았습니다.

그냥 자리 표시자 링크를 읽으십시오. 예, 믹스인을 확장하는 것이 작업을 수행하고 동일한 기능을 얻는 더 좋고 더 적은 방법이라고 생각합니다.

위의 점을 수정하려면

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }
    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.something:before,
.something:after {
    content: " ";
    display: table;
}
.something:after {
    clear: both;
}
*/

그리고 아마도 .clearfix() { 정의가 .clearfix { 이면 확장 정의 내에서 대괄호를 사용하거나 사용하지 않고 호출해도 출력에 차이가 없을 것입니다.

확장 기능에 의사 클래스 구문을 사용하는 것은 완전히 잘못된 것입니다.
"extend sth"는 "match sth"와 같지 않기 때문에 선택자가 해야 하는 DOM 구조에 대해서는 아무 의미가 없습니다.

당신은 적은 사람들이 많은 나쁜 아이디어를 "발명"했습니다. 가장 유명한 것은 "재사용' .xxx(클래스 선택기)를 mixin 표기법으로 사용하는 것입니다. 최소한 일반 CSS에서 전처리기로 쉽게 마이그레이션할 수 있습니다. 그러나 :extend 구문은 내가 들어본 것 중 최악의 아이디어입니다.

우리 문제에 대해 이런 종류의 호언장담을 하고 싶지는 않지만 이런 말을 들은 것이 이번이 처음이 아니므로 CSS에 대해 이야기하고 공기를 맑게 합시다.

당신은 적은 사람들이 많은 나쁜 아이디어를 "발명"했습니다. 가장 유명한 것은 mixin 표기법으로 "재사용' .xxx(클래스 선택기)입니다. .... :extend 구문은 내가 들어본 것 중 최악의 아이디어입니다.

.xxx 는 암시적 믹스인이라고 합니다. 작동하며 이해하기 쉽습니다. 사실, 이 구문은 CSS 사양에서 예를 들어 실제 스타일을 지정하기 위해 at-규칙을 사용하는 것처럼 "침습적"이 아닙니다. @keyframes 는 스타일 지정에 가장 가깝고 CSS 구문에서 식별자 생성과 일치하는 식별자가 사용되기 때문에 내가 말하는 것의 예외로 간주될 수 있습니다. 키프레임 외에도 일반적으로 CSS at-rules는 문자 인코딩( @charset )과 같이 스타일 자체 외부를 의미하는 "외부" 정보를 기반으로 하는 더 높은 수준의 구성 및 스타일 또는 스타일시트 조작을 위해 예약되어 있습니다. 장치별 조건( @media )에 응답합니다.

게다가, 나는 더 나쁜 아이디어를 생각할 수 있습니다. 스타일링에 at-rules를 사용하는 것과 마찬가지로 동일한 기능에 대해 두 개의 at-rules를 사용하는 것은 다른 것입니다. 물론, 그것은 모두 목표에 달려 있습니다. 스타일을 개인적으로 건드리지 않고 프로그래밍 방식으로 조작하려는 경우 파서가 선택하기 더 쉬울 수 있는 더 둔하고 분명한 문법 구성을 사용하는 것이 아마도 이점이 있을 것입니다. Stylus를 사용하는 것 같으니 다른 구문이 유리한 이유에 대한 귀하의 견해를 듣고 싶습니다.

"extend sth"는 "match sth"와 같지 않습니다. 선택자가 해야 하는 DOM 구조에 대해서는 아무 의미가 없습니다.

옳은. nth _something_이 있는 의사 클래스는 CSS 사양에서 " 구조적 " 의사 클래스로 설명됩니다. 그러나 의사 클래스에는 "동적", "부정", "대상", "공백", "UI 요소 상태" 및 "언어"의 6가지 유형 이 있습니다. CSS 사양이 실제로 "확장" 기능을 설명했다면 "부정"과 "타겟" 의사 클래스 사이의 범주로 매우 우아하게 자리할 수 있습니다.

의사 클래스는 문서 트리의 정보를 기반으로 선택을 허용하지만 확장 기능을 최적으로 사용하는 것은 아닙니다.

완전히 틀렸다

다른 모든 전처리기를 합친 것보다 더 큰 커뮤니티는 잘못될 수 없습니다. 또 무슨 할 말이 있습니까?

@hax - :extend 스레드에서 다른 모든 사람들처럼 자신만의 솔루션을 제안하면 마음 없는 조롱 이 교육적인 토론으로 바뀔 수 있습니다. 경험이 풍부한 프론트엔드 개발자와 LESS를 많이 사용하는 사용자 사이에서 몇 주 동안 다양한 제안과 숙고 끝에 :extend 구문을 사용하여 만족스러운 솔루션에 도달했습니다. 더 나은 제안이 있으면 저를 믿으십시오. 우리는 모두 귀입니다.

@jonschlinkert 에 추가하려면 .this:not(.that) { } 및 .this:matches(.that) { } 및 .this:extend(.that) { } 가 범주적으로 유사합니다. 즉, "선택자 'this'가 주어지면 특정 방식으로 선택자 'that'과 연결됩니다." LESS는 종종 CSS에 도입된 개념과 구문을 확장하기 때문에 언어의 꽤 논리적인 확장입니다. 우리는 CSS 사양에 세심한 주의를 기울이고 결과적으로 그 특성을 반영합니다. 개념에 이상한 점이 있으면 CSS에서 먼저 시작되기를 바랍니다. 이것이 우리 믹스인 가드에서 "AND"가 "and"라는 단어로 표시되고 "OR"이 쉼표로 표시되는 이유입니다. 왜냐하면 이것이 미디어 쿼리의 방식이기 때문입니다. 우리의 목표는 CSS를 수정하거나 변경하는 것이 아니라 CSS를 작업하기 훨씬 쉽게 만들고 CSS 작성자에게 LESS를 완전히 친숙하게 만드는 것입니다. :extend 가 그 예입니다. :not 를 사용하는 방법을 알고 있다면 :extend 를 사용하는 방법을 알고 있습니다.

중첩된 괄호를 피하고 매개변수 믹스인을 더 쉽게 확장하기 위해 더 "암시적" 구문을 사용하면 어떻게 될까요?

오늘날 우리는 다음과 같이 파라메트릭 믹스인을 사용합니다.

.square {
  .border-radius(9px);
}

다음과 같이 믹스인을 확장하는 대신(일반 클래스를 확장할 수 있음):

.square {
  &:extend(.border-radius);
}

다음과 같이 확장할 수 있습니다.

.box {
  .border-radius:extend(9px);
}
.square {
  .border-radius:extend(9px);
}
.rectangle {
  .border-radius:extend(4px);
}

차이점은 "extended mixin"이 괄호 안에 확장할 클래스를 나열하고 중괄호로 새 선택기 블록을 시작하는 대신 세미콜론으로 끝나고 괄호 안에 값 또는 값을 선언한다는 것입니다. .border-radius:extend(9px); .border-radius:extend(.some-class) {} . IMHO, 이것은 LESS의 가장 멋진 기능 중 하나인 암시적 믹스인( .border-radius; )보다 덜 미묘합니다. 다시 IMHO입니다.

렌더링된 출력에서 ​​"확장된 매개변수 믹스인"은 다음과 같이 원래 믹스인 위치에 렌더링됩니다.

.box, 
.square {
    -webkit-border-radius: 9px;
    -moz-border-radius: 9px;
    border-radius: 9px;
}
.rectangle {
    -webkit-border-radius: 4px;
    -moz-border-radius: 4px;
    border-radius: 4px;
}
.some-other-class, 
.another-class, 
.and-another {
    -webkit-border-radius: 2px;
    -moz-border-radius: 2px;
    border-radius: 2px;
}

그래서 저는 개인적으로 이것을 좋아합니다. 선택기 블록 내부의 "정상적인" 확장 구문에서 충분히 벗어나서 무슨 일이 일어나고 있는지 충분히 명확하게 할 수 있고, 무엇을 과도하게 설명할 필요가 없는 기존의 적은 규칙의 미묘함과 함께 가기 때문입니다. 당신은 코드에서 달성하려고합니다. 이 기능은 확실히 내 개인 위시리스트의 맨 위에 있습니다.

원래 요청에서 제공한 clearfix 예제를 사용하면 다음과 같이 수정된 구문을 사용할 수 있습니다.

.clearfix() {
    // ...
}
.navbar {
    .clearfix:extend(); // instead of &:extend(.clearfix());
}
.banner {
    .clearfix:extend();
    &:extend(.some-class); // "implicit mixin" being extended
}

나는 당신이 이것을 가지고 가는 곳을 좋아합니다. 더 친숙한 접근 방식은 다음과 같이 _existing_ mixin 구문 끝에 :extend 를 사용하는 것입니다.

.box {
  .border-radius(9px):extend;
}
.square {
  .border-radius(9px):extend;
}
.rectangle {
  .border-radius(4px):extend;
}

:extend 뒤에 괄호를 생략하면 기존 확장 구문과 다른 용도로 사용되는 것처럼 느껴집니다.

나는 이것으로 어떤 식 으로든 갈 수 있지만 확장 구문과 일치하기 때문에 .border-radius:extend(9px); 선호합니다. IMO는 여전히 믹스인이지만 매개 변수/값이 확장되고 있음을 의미합니다. 설명하는 데 도움이 됩니다. 출력이 "그룹화"되는 이유.

@jonschlinkert - 이 시점에서 저는 귀하의 의견을 매우

@DesignByOnyx 친절한 말씀 감사합니다. 당신이 말하는 것은 많은 의미가 있습니다. extends (Less)의 "렌즈"는 다음과 같습니다.

.this:extend(.that) {}

그래서 당신의 요점은 내 자신의 견해와 일치합니다. @matthewdl 또는 @lukeapage 둘 중 하나가 이에 대한 견해/의견이 있습니까? 두 구문 모두(아마도 다른 구문도) 작동할 수 있다고 생각하지만 두 구문 모두 "미래 보장"에 중점을 두지 않았으므로 둘 중 하나에 문제가 있을 수 있습니다. 나는 이것이 일어나는 것을 보고 싶다. 나는 믹스인을 확장하는 것이 Less를 위한 흥미로운 기능이라고 생각한다. 그것은 내가 현재 생각할 수 있는 어떤 다른 기능보다 DRY 코드를 생성하는 데 더 많은 일을 할 것이다.

Less 컴파일러가 자동으로 "올바른 작업을 수행"할 수 없는 이유는 무엇입니까? 즉, 내 코드에 이 믹스인을 선언했다면:

.someMixin {
    color: red;
}

그런 다음 나중에 다음과 같이 사용합니다.

#someElement {
    .someMixin;
}

컴파일러가 이 Less 코드를 이 CSS에 최적화할 만큼 충분히 똑똑할 수 없는 이유는 다음과 같습니다.

.someMixin,
#someElement
{
    color:red;
}

내가 사용자로서 이 동작을 얻기 위해 수동으로 :extens 키워드를 추가해야 하는 이유는 무엇입니까? 컴파일러는 이 최적화가 수행될 수 있다는 것을 깨닫고 수행할 수 있을 만큼 충분히 똑똑해야 합니다.

개인적으로, 나는 this :Extended 아이디어가 혼란스럽다고 생각합니다. "확장" 키워드의 전체 개념은 "이 X에 A, B 및 C를 추가하십시오."라는 의미입니다. 그러나 이 컨텍스트에서 확장을 재정의할 것을 제안합니다. "이 X는 실제로 Y와 같으므로 Y와 X가 같다고 선언하고 한 번만 쓸 수 있습니다." 이것은 무언가를 "확장"한다는 표준 개념에 위배됩니다.

네, 저도 예전에 똑같은 생각을 하고 포스팅을 하려고 했는데 생각해보니 자동으로 믹스인에 "동작 확장"을 적용하는 것은 Less.js에서는 너무 독단적이라는 생각이 들었습니다. 특히 선택기 상속(확장)이 코드 축소에 매우 유익한 멋진 개념이지만 이 기능에 대해 읽은 대부분의 불만 사항은 코드를 통해 빗질하기 어렵게 만드는 추상화 계층을 추가한다는 것입니다. 문제가 있을 때 디버그합니다.

훌륭한 사람들은 비슷하게 생각하지만 개인적으로 그 아이디어에 반대 투표를 합니다. 왜냐하면) extend 기능이 완전히 안정되고 사양이 더 완전해질 때까지 "일반" 믹스인을 전혀 엉망으로 만들어서는 안 되기 때문입니다. b) 많은 개발자들이 스스로 이 요청을 하기를 원한다고 생각합니다. 그리고 c) 종종 상황이 너무 명백하고 잘려나간 것처럼 보이지만, 문제는 우리가 믹스인에 대해 이 제안은 최소한 구현하기 어렵고 구현하기가 불가능할 수도 있지만 개발자는 우리가 알고 있는 모든 "mixin 핵"을 사용할 수 있습니다. 헴, 그들은 알게 되었고 사랑하게 되었습니다.

:extents() 구문은 여전히 ​​직관적이지 않고 새로운 사용자에게 설명하기 어려운 매우 서투른 해킹입니다.

더 나은 솔루션은 사용자가 적절한 출력 스타일(압축, 최적화 등)을 선택했을 때 위에서 설명한 대로 컴파일러가 CSS를 자동으로 최적화하도록 하는 것입니다. 사용자가 압축되지 않은 출력 스타일을 선택하면 컴파일러는 이러한 최적화를 피하고 더 적은 DRY 코드를 생성해야 합니다.

또한 소스 맵을 사용하여 디버깅 문제를 해결할 수 있습니다. Less mixin에서 가져온 컴파일된 CSS의 위치를 ​​쉽게 지적할 수 있습니다.

@bdkjones 는 코드에서 이를 수행하는 방법에 대한 제안과 함께 "CSS 자동 최적화"에 대한 새로운 기능 요청을 생성하십시오. 이런 입력은 언제나 환영입니다.

요점을 알았어! 나는 나의 마지막 코멘트에서 아주 가혹한 것을 의도하지 않았다; 나는 때때로 도취된다.

코드에 관해서는 CodeKit으로 완전히 바빠서 유감입니다. 나는 너희들에게 언어를 해시하게 해!

별말씀을 요! 정말로, CodeKit에 참여하고 있는 것을 보았고 계속해서 의견을 주셨으면 합니다. 모든 기능이 모든 사람을 만족시키는 것은 아니지만 피드백과 강력한 의견이 바퀴를 돌게 만드는 유일한 것입니다!

@bdkjones 문제는 캐스케이드입니다. 사용 사례에서는 작동하지만 선택기를 덮어쓰는 선언을 방지하는 문서에서 선택기를 "더 일찍" 이동시킬 수 있기 때문에 선택기 그룹화는 모든 경우에 원하는 결과를 얻지는 못합니다.

그러나 여기에서 발전한 mixin 확장 구문에 대한 귀하의 진술에 동의합니다. Selector X는 Selector 또는 mixin Y를 확장해야 하므로 이상하게 보입니다.

.border-radius(9px):extend;

나는 우리가 확장 구문을 잘못 사용하고 있다고 생각합니다. 존재하는 확장 구문이 믹스인에 맞지 않으면(완벽하게 그럴듯합니다), @bdkjones가 가리키는 것처럼 은유를 만드는 방식으로 확장 구문을 확장하기보다는 믹스인에 대한 올바른 구문을 찾는 것이 좋습니다. 밖.

나는 우리가 확장 구문을 잘못 사용하고 있다고 생각합니다.

나는 동의하지 않는다. 작동하면 사용하십시오. 이유 없이 새로운 구문을 만드는 이유는 무엇입니까? 나는 우리가 제안된 구문에 대한 훌륭한 선례를 가지고 있다고 생각합니다. 제 제안 뒤에 많은 예와 뒷받침하는 이유를 제시하지만 제안된 구문에 대한 귀하의 의견은 매우 주관적인 것 같습니다. 그리고 당신은 최근에 그 진술을 몇 번 했기 때문에 구문이 남용되고 있다고 생각하는 이유를 설명할 수 있습니까? 또는 구문이 남용되는 시점을 설명합니까? 또는 "확장" 구문 없이 믹스인을 확장하는 방법에 대한 생각을 공유하시겠습니까?

사용 사례에서는 작동하지만 선택기를 덮어쓰는 선언을 방지하는 문서에서 선택기를 "더 일찍" 이동시킬 수 있기 때문에 선택기 그룹화는 모든 경우에 원하는 결과를 얻지는 못합니다.
...
나는 우리가 확장 구문을 잘못 사용하고 있다고 생각합니다. 확장 구문이 존재하는 그대로 믹스인에 맞지 않는다면(완벽하게 그럴듯합니다), bdkjones가 지적한 것처럼 은유를 엉망으로 만드는 방식으로 확장 구문을 확장하기보다는 믹스인에 대한 올바른 구문을 찾는 것이 좋습니다. .

아니요. 그는 아무 것도 지적하지 않았고 Less를 사용하기 쉽게 만들 것을 촉구했습니다. 이것이 그의 결론이었습니다. 그가 제안한 방법은 잘못 인도되었지만 의도는 좋았습니다. 그가 생각하지 않은 것은 당신이 방금 지적한 폭포입니다. 일반적으로 확장을 사용할 때는 캐스케이드를 고려해야 합니다. mixin 대신 extend를 사용하는 사람은 누구나 알고 있다고 생각합니다. 따라서 Less.js가 합리적일 때 사용하거나 그렇지 않을 때 사용하지 않는 _not_ 선택권을 제공하는 이유입니다. CSS의 첫 번째 "C"가 cascading을 의미한다는 사실은 cascade가 중요하지 않을 때 중복 스타일을 통합하는 이점을 무효화하지 않습니다. 내가 여기서 무엇을 놓치고 있습니까?

그래서 당신의 감정을 명확히 할 수 있습니까? 이 기능에 반대하십니까, 아니면 구문에 반대하십니까? 구문에 반대하는 경우 계속 진행되도록 다른 것을 제안하십시오. 그렇지 않으면 언어에 대해 이렇게 유망한 기능의 진행을 방해하지 맙시다.

이 기능에 반대하십니까, 아니면 구문에 반대하십니까?

나는 기능을 위해, 절대적으로. 이것은 분명한 방향입니다. 이 스레드에서 구문을 다시 검토했습니다. 몇 가지 생각:

첫째, 이것은 나에게 어색합니다.

.something:extend( .clearfix() ) { }

이중 괄호가 이상합니다. 그러나 이는 기존 확장 구문을 충실히 채택한 것이므로 충분히 공평합니다. 그래서 제가 다른 것, 아마도 확장이 아닌 다른 것을 옹호하고 있었던 것입니다.

그런 다음 당신이 제안한 것이 있습니다. 비슷한 이유로 생각합니다.

.border-radius(9px):extend;

...기존 확장 사양과 반대되는 것 같아서 알레르기 반응이 있었습니다. 그래서 그것은 나에게 오용처럼 보였습니다.

하지만

나는 거기에 실제로 두 가지 옵션이 있다는 것을 깨달았습니다. 하나는 믹스인에 대해 다른 작업을 수행한다는 것입니다. 그러나 다른 옵션은 다음과 같은 믹스인을 포함한 모든 것에 대해 기존 확장 사양을 수정하는 것입니다.

#namespace {
  .box-template {
    .subelement {
      // we'll add the all flag to extend everything here
    }
  }
}
.clearfix() {
  // a clearfix mixin
}
.text-shadow(@shadow) {
  -moz-text-shadow: @shadow;
  text-shadow: @shadow;
}
.some .random .selector {
  // with properties
}
.mybox {
  .clearfix:extend;
  #namespace > .box-template:extend !all;
  .text-shadow:extend(2px 2px #ff0000);
  .some .random .selector:extend;
}

하지만.... 전체 선택기( .some .random .selector )를 사용하면 잘못 읽기 시작합니다. .selector에 확장 기능이 있는 것 같습니다. 그리고 "extend"라는 단어는 이 선언에서 중요한 단어일 때 길을 잃기 시작합니다. &:extend() 로 작성되었을 때는 그렇지 않았지만(처음에 나타났기 때문에), 해당 구문은 믹스인으로 인해 분해되는 것 같습니다.

따라서 다음 옵션 중 하나를 제안합니다.

// Migrating existing syntax, but ommitting a parens requirement when used with &:

.mybox {
  &:extend .clearfix;
  &:extend #namespace > .box-template !all;
  &:extend .text-shadow(2px 2px #ff0000);
  &:extend .some .random .selector;
}

// Adopting something similar to the SASS approach

.mybox {
  <strong i="24">@extend</strong> .clearfix;
  <strong i="25">@extend</strong> #namespace > .box-template !all;
  <strong i="26">@extend</strong> .text-shadow(2px 2px #ff0000);
  <strong i="27">@extend</strong> .some .random .selector;
}

믹스인 및 미디어 쿼리 확장에 대한 논의에서 :extend 대한 원래 구문 접근 방식이 유연하지 않다는 점을 강조했다고 생각합니다. 특히 다중 선택기 및 믹스인을 확장하려는 경우에 그렇습니다.

나는 그것을 얻는 것이 중요하다고 생각합니다 :extend right. 믹스인에 "extend"를 사용하려면 확장 구문을 수정해야 한다고 생각합니다.

나는 .border-radius(9px):extend; 를 제안 하지 않았고 .border-radius:extend(9px); 제안

그러나 어느 구문이든 저에게는 괜찮습니다. 또는 .border-radius(9px) !extend; 또는 .border-radius:shamallamadingdongscoobiedoo(9px):extendmyass (jk)를 수행할 수 있습니다. 믹스인의 동작으로 변경되거나 확장되는 것이 전혀 없기 때문에 저에게는 중요하지 않습니다.

그래서 나는 당신이 그 모든 것을 할 필요성을 어떻게 생각하고 있는지 잘 모르겠습니다. 당신은 아마도 당신 자신을 위해 일을 지나치게 복잡하게 만들고 있을 것입니다.

이 기능 요청은 믹스인의 상속된 속성을 믹스인의 위치로 복사하는 기능을 갖는 것에 대한 것이며, 현재 믹스인 동작으로 이미 잘 확립된 규칙을 따를 것이며, 이제 믹스인과 동일한 동작 과 우선 순위를 갖습니다. <strong i="14">@import</strong> (reference) 기능(btw, 연습과 사랑에서 꽤 많이 사용했습니다). 간단히 말해서:

• 믹스인을 사용하면 믹스인을 호출하는 선택기의 위치에 속성이 복사됩니다.
• 확장을 사용하면 _extending_ 선택기가 _extended_ 클래스 위치에 복사됩니다.
• 따라서 믹스인을 확장하면 호출하는 선택기가 믹스인 위치에 복사됩니다.

2년 간의 토론, > 100개의 게시물, 많은 연구 및 @extend 보다 _훨씬 더_ 유연하다는 사례가 이미 확인된 후 확장 구문에 대한 토론을 다시 시작하려는 이유가 확실하지 않습니다

Btw, 나는 당신이 여기서 무엇을 의미하는지 잘 모르겠습니다.

전체 선택기(.some .random .selector)를 사용하면 잘못 읽기 시작합니다. .selector에 확장 기능이 있는 것 같습니다. 그리고 "extend"라는 단어는 이 선언에서 중요한 단어일 때 길을 잃기 시작합니다.

그것이 지금 실제로 작동하는 방식이기 때문에 그것이 혼란스럽다는 것에 동의하지 않습니다. "CSS 개발자는 그룹화된 선택기의 작동 방식을 모릅니다"라고 말하는 것과 같지 않습니까? :hover 또는 :after 어떻습니까? CSS 개발자는 이것을 잘 알아낼 수 있다고 생각합니다. 다른 의사와 동일한 방식으로 작동하기 때문입니다.

.some .random .selector:extend(.something) {}

나는 .some .random .selector 가 아닌 .selector .some .random .selector 인 선택자에 확장을 적용하거나 선택자 블록 안에 넣을 수 있기 때문에 이것이 제공하는 유연성을 좋아합니다.

믹스인 및 미디어 쿼리 확장에 대한 논의

믹스인을 확장하면 해결할 수 있다는 것을 깨달았기 때문에 미디어 쿼리 문제를 닫았습니다. "모든 도로는 _____로 연결됩니다" 확장 믹스인. ;-)

저는 :extend( .some-mixin() ) 안에 있는 괄호 안에 있는 괄호가 그다지 신경쓰이지 않는다고 말하고 싶습니다. 특히 :extend( .some-selector ) 가 이미 설정되어 있고 구역질나는 것으로 논의되었기 때문입니다. 나는 이중 괄호가 어떤 의미에서도 이상적이지 않고 그것이 좀 이상하게 느껴진다는 데 동의합니다. 그러나 믹스인과 선택기가 "확장"이라는 측면에서 동일하게 취급되는 것이 중요하다고 생각합니다.

header {
    .some-selector;
    .some-mixin;
    .some-mixin();
}

따라서 다음과 같이 하여 그다지 나쁘게(또는 제한적으로) 느끼지 않습니다.

header {
    &:extend( .some-selector );
    &:extend( .some-mixin );
    &:extend( .some-mixin() );
}

그러나 나는 mixin과 selector가 "확장"이라는 측면에서 동일하게 취급되는 것이 중요하다고 생각합니다.

나는 그 점에 대해 같은 입장이다.

2년 간의 토론, > 100개의 게시물 이후 확장에 대한 구문에 대한 토론을 왜 다시 시작하려는지 잘 모르겠습니다.

하고 싶은 문제가 아닙니다. 아니, 난 원하지 않아. 그러나 그 당시 우리는 나중에 처리하기 위해 일종의 믹스인을 섞었습니다. 이 구문이 우리가 원하는 대로 작동하는지 확신할 수 있는지 묻고 싶습니다. 문제가 작동하지 않거나 일부 용도에 부적절하다고 생각되면 질문을 다시 방문하는 데 아무런 문제가 없습니다. LESS는 연장 없이 오래 전부터 존재해 왔습니다. 빨리 끝내는 것보다 제대로 하는 것이 더 중요하다.

그래서, 우리는 이것으로 괜찮습니까?

.mybox {
  &:extend(.clearfix());
  &:extend(#namespace > .box-template all);
  &:extend(.text-shadow(2px 2px #ff0000));
  &:extend(.some .random .selector);
}

parens 내부의 parens - :extend( .some-mixin() ) - 특히 :extend( .some-selector ) 가 이미 설정되어 있기 때문에 그다지 신경쓰지 않습니다.

그렇습니다. 사실 우리는 이미 Less.js에서 이중 괄호에 대한 선례를 가지고 있으며 기존 확장 구문을 사용합니다. 그리고 이미 설정된 선례는 우리가 mixin으로 제안하는 것만큼 눈에 쉽지 않습니다. 현재 다음과 같이 할 수 있습니다.

.one:nth-child(5) {
  color: red;
}
// We can extend psuedos
.two:extend(.one:nth-child(5)) {
  background: blue;
}
// And attributes
.two:extend(.one, [hidden]) {
  width: 2px;
}

기존 CSS 구문 에서 중첩된 괄호를 찾을 수도

그래서 여기에 _nested parens_ 및 _nested pseudo-class_ 구문이 있습니다. 그리고 나는 그것에 대해 아무런 문제가 없습니다. IMO가 분명합니다.

그래서 저는 @DesignByOnyx 에 동의합니다. 그것이 제 원래 제안이었고 어떤 이유로 다른 사람들에게는 불쾌해 보였기 때문에 다른 구문을 찾으려고 노력했습니다. 그러나 저는 확장의 괄호 안에 있는 일반 이전 믹스인 구문을 사용하기 위해 최선을 다하고 있습니다.

사실, 원래 구문은 여러 쉼표로 구분된 클래스 또는 믹스인을 확장할 수 있습니다.

.banner {
    &:extend(.clearfix(), .border-radius(4px), .alert, .navbar-fixed-top, [hidden]); 
}

그것은 작업을 수행하고 빡빡합니다. 여기에 불만이 없습니다.

그래서, 우리는 이것으로 괜찮습니까?

네. 완전히. 그것은 이미 CSS에 있는 방식입니다. 그래서 잘해요.

네. 완전히. 그것은 이미 CSS에 있는 방식입니다. 그래서 잘해요.

그래서 그것을 통과해야합니다.

질문, 현재 :extend에서 다중 선택자를 지원하지 않는다고 생각합니다. 그래서 "all" 키워드가 해당 형식에 맞는 위치가 어디인지 궁금합니다. 그러나 그것은 아마도 별도의 문제의 일부일 것입니다.

당신은 당신의 경우를 만들었습니다, Mr. Schlinkert. 당신은 법에 갔어야 했다. ;)

현재 :extend에서 다중 선택자를 지원하지 않는다고 생각합니다.

하지만 우리는 ;-) 광범위하게 해왔습니다. 방금 전에 이렇게 했습니다.

.global-nav {
  // Extend and override bootstrap styles
  &:extend(.navbar, .navbar-fixed-top all, .navbar-inverse); // this works, and it's pretty handy
  &.hidden:extend(.navbar.hidden) {}
  &.visible:extend(.navbar.visible) {}
  &:hover {
    background: lighten(@brand-primary, 5%);
  }
  .navbar-brand {
    padding-left: 20px; 
  }
  .navbar-nav > .active > a {
    &, &:hover, &:focus {
      background-color: darken(@brand-primary, 5%);      
    }
  }
}

당신은 당신의 경우를 만들었습니다, Mr. Schlinkert. 당신은 법에 갔어야 했다. ;)

Pfft, lol 오 그만!

이 구문을 생각한다고 추가하고 싶습니다.

.foo {
  &:extend( .bar() );
}

중대하다. 저는 괄호가 전혀 어색하지 않습니다.

하지만 주로 제가 좋아하는 전처리기에서 SASS에서 작업하고 있는 멋진 작업을 모두 수행할 수 있도록 여러분이 서둘러 주셨으면 합니다.:D

의견을 보내주셔서 감사합니다. @mgerring !

+1 이 기능을 기다리고 있습니다. 좋은 일을 계속하십시오 :)

원본 게시물로:

.clearfixed {
   // stuff
}
.clearfix() {
    &:extend(.clearfixed);
}
.navbar {
  .clearfix();
}
.banner {
  .clearfix();
}

게시할 때 작동하지 않았을 수도 있습니다. 그러나 결과는 원하는 것과 매우 유사합니다.

.clearfixed,
.navbar,
.banner {
  // stuff
}

@aaronmw , 예, 귀하의 예제가 동일한 작업을 수행

예, @seven-phase-max의 요점에 따라 설명하는 방식으로 수행할 수 있지만 관용적이지는 않습니다.

맞습니다. 죄송합니다. 이제 이 스레드를 더 많이 읽었고 우리가 목표로 하는 것이 무엇인지 확인했습니다. 내가 사용한 "스켈레톤" 클래스는 컴파일된 출력에서 ​​쓰레기일 뿐입니다. .clearfixed 클래스는 믹스인 외부에서 명시적으로 참조되지 않기 때문입니다. &:extend(.clearfix()) 는 이제 나에게 의미가 있고 꽤 흥미진진합니다. 지금은 CSS를 어지럽히는 스켈레톤 클래스를 다룰 것입니다.

여기에서 훌륭한 토론!

:+1:

이 기능은 언제 예상할 수 있습니까? OOCSS와 같은 개념이 "추상 클래스"와 같은 구성을 만드는 데 매우 유용합니다.

• 중첩/범위 및 믹스인 대 일반 클래스에 대처하는 방법 결정

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {}  //
.b:extend(.a) {}  // and if so is the output wrapped by #thing?
.b:extend(.a()) {}  // do I need special format to say extend only that mixin?

• 우리는 인수를 처리합니까? 믹스인을 동일한 인수로 결합합니까?
• mixin 정의를 제거하지 않도록 css-visitor로 변경
• 확장 방문자가 mixin 정의를 방문하고 새 클래스로 새 규칙 세트를 생성하도록 합니다.

가장 어려운 부분은 실제로 작동 방식을 _정확하게_ 결정하는 것입니다.

중첩/범위 및 믹스인 대 일반 클래스에 대처하는 방법 결정

나는 mixin 확장을 이런 식으로 해석하려고 할 것입니다.
.b:extend(.a(1, 2, 3)) {} 는 내부에서 .a(1, 2, 3) 를 호출한 다음 일반적인 방식으로 확장하는 'b' 범위에서 익명의 매개변수가 아닌 믹스인(즉, 단순 선택기)을 만드는 것과 동일하게 작동해야 합니다. 즉, 다음과 같습니다.

.a(<strong i="11">@a</strong>, <strong i="12">@b</strong>, @c) {
    // ...
}

.b:extend(.a(1, 2, 3)) {}

다음과 같아야 합니다.

.a(<strong i="16">@a</strong>, <strong i="17">@b</strong>, @c) {
    // ...
}

#__anon_a_1_2_3 {.a(1, 2, 3);}

.b:extend(#__anon_a_1_2_3) {}

출력에 #__anon_a_1_2_3이 나타나지 않는다는 점을 제외하고. 나는 그러한 접근 방식이 특별한 규칙을 발명하지 않고도 덜 간단하게 만들어야 한다고 생각합니다.

따라서 위의 개념을 #thing .a 예제에 적용하면 다음을 얻습니다.

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {} // since we do ignore parens on mixin call and have ...
// no plans changing this (?), it should probably create .b {color: black} 

.b:extend(.a) {}  // there's only one .a in this scope so it's -> .b {color: green}

.b:extend(.a()) {}  // same as above -> .b {color: green}

반면에 "선택적 괄호"는 실용적인 관점에서 볼 때 아주 사소한 것이므로 더 엄격하게 만들고 extend 내부의 매개변수 믹스인에 대해 괄호를 요구하는 것도 괜찮을 수 있습니다. extend 는 어쨌든 완전히 호환되지 않으므로 일반 mixin 호출 구문을 상속합니다.

믹스인을 동일한 인수로 결합합니까?

이상적으로는 그렇습니다. 그렇지 않으면 모든 것이 쓸모없게 될 것입니다. 예:

.b:extend(.a()) {}
.c:extend(.a()) {}

다음을 생성해야 합니다.

.b, .c {color: green}

흠, 병합이 구현하기 가장 어려울 것 같습니다.

또 다른 문제는 스코프입니다. 최근 #1730에서 믹스인은 '상대' 스코프 경로를 사용하고 확장은 '절대'를 사용하므로 두 가지를 결합할 때 일종의 충돌이 발생합니다.

.div {color: green}

body {
   .div {color: red}

   p-a       {.div()}    // -> body p-a {color: red}
   p-b:extend(.div)   {} // -> body p-b {color: green}
   p-c:extend(.div()) {} // -> ???
}

파라메트릭 믹스인으로 이 예제를 다시 작성하면 훨씬 더 혼란스럽습니다.

저는 지금이 한발 물러서서 "확장 믹스인을 어떻게 사용해야 하는지"라고 말할 수 있는 좋은 시간이 될 수 있다고 말하기 위해 2센트를 제안하고 싶습니다. 그리고 @donaldpipowitch 가 약간의 OOCSS 능력을 가져온다고 말하는 것이 옳다고 생각합니다. . 따라서 하위 클래스("속성", 원하는 경우)가 클래스 자체 내에서 확장되는 방식에 너무 얽매여서는 안 된다고 생각합니다. 예를 들어 사용자는 "속성"(중첩 선택기)이 있는 특정 "클래스"(구성 요소)를 갖게 됩니다.

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
}

사용자가 다음을 수행하려는 상황에 초점을 맞춰야 한다고 생각하지 않습니다.

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
    .tail:extend( .leg() ) { 
        .toes { display:none; } 
    }
}

이것은 IMO의 프린지 케이스 시나리오일 뿐만 아니라 사용자는 어쨌든 다음과 같이 자신의 스타일을 작성해야 합니다.

.dog() {
    .leg, .tail { ... }
    .ears { ... }
    .fur { ... }
    .tail .toes { display:none; }
}

믹스인 확장의 99.8% 사용 사례는 개발자가 수년 동안 축적한 스타일로 가득 찬 방대한 LESS 라이브러리를 가질 수 있도록 하는 것입니다. 이 방대한 라이브러리는 다음과 같은 것으로 가득 차 있습니다.

.clearfix() { ... }
.modal() { ... }
.alert-box() { 
    &:extend( .modal() ); 
    &.message { ... } 
    &.warning { ... } 
    &.error { ... } 
}
.grid-wrap() { ... }
.form-input() { ... }
.form-select() { ... }
.button( <strong i="16">@bgColor</strong>, <strong i="17">@textColor</strong> ) { ... }
[... thousands more like this ...]

그리고 그들은 작문 스타일에 집중할 수 있습니다.

.page-wrap:extend( .grid-wrap(), .clearfix() ) { ... }
input[type="text"]:extend( .form-input ) { ... }
textarea:extend( .form-input() );

그들이 원하고 "모달" 스타일이 이 프로젝트에서 사용되지 않기 때문에 최종 출력에 존재하지 않는 경우 이 작업을 수행할 수도 있습니다.

.inline-error:extend( .alert-box.error )

예, @DesignByOnyx에 요점 이 있는 것 같습니다. 나중에 더 복잡한 것을 알아내는 데 아무런 문제가 없다고 생각합니다. 사실, 현재로서는 _비매개변수가 아닌_ 믹스인 확장을 먼저 구현하는 것이 가장 좋을 것이라고 생각합니다. 그것은 아마도 모든 사용 사례의 80 – 90%를 커버할 것입니다(스타일시트에 보다 객체 지향적인 구조를 허용하는 등). 다른 모든 것은 패치 또는 두 개를 기다릴 수 있습니다.

@DesignByOnyx 와 @calvinjuarez 우리는 이것을 나중에 알아낼 수 없습니다. 그것은 어떤 식으로든 코딩되어야 합니다. 솔루션에 뛰어들었다가 나중에 변경하기로 결정하면 브레이킹 체인지가 도입되는데 이는 좋지 않습니다.

프린지 시나리오를 지원하지 않는 접근 방식을 개발할 수 있다면 더할 나위 없이 기쁩니다. 이것이 우리가 주요 확장 지원으로 끝낸 일입니다(필요한 경우 더 많은 키워드로 확장할 수 있음). 그러나 지원 대상과 방법에 대한 계획이 필요합니다.

위의 맥락에서 @seven-phases-max, 지금은 파라메트릭 믹스인을 무시하는 것이 좋습니다.

흠, 병합이 구현하기 가장 어려울 것 같습니다.

• 근데 합쳐진다? 나는 기존 확장과 동일한 접근 방식을 사용할 것입니다. 예를 들어 일치 항목을 찾아 추가합니다. 따라서 두 확장을 모두 3번째 위치인 mixin에 넣는 것만큼 병합하지 않고 특수 파일로 출력됩니다. genCSS의 경우

나는 또한 범위에 대한 @seven-phases-max 의 두 번째 예제가 누군가에게 영향을 미칠 가능성이 높다고 생각합니다. 이름이 같은 믹스인과 빈 매개변수 믹스인만 있으면 됩니다.

@lukeapage :+1: 사실, 파헤칠 수 있습니다. 좋은 전화입니다.

사실, @seven-phase-max가 옳았다고 생각합니다. 그래서 :+1: 그것도 있습니다.

@lukeapage - 나는 "한 가지 또는 다른" 유형의 솔루션을 옹호하려는 것이 아니라 (당신이 말했듯이) 프린지 사례를 지원하지 않는 접근 방식을 옹호하려고 했습니다. 사실, 우리는 이미 "로컬" 범위에 대한 기능을 지나쳤고 :extend 가 다음과 같이 작동하기 때문에 "돌아가기에는 너무 늦음" 단계 IMO에 들어갔습니다.

.block { color: green; }

.component {
  .block { color: red; }    
  div:extend( .block ) {};
}

/*
.block,
.component div {
  color: green;
}
.component .block {
  color: red;
}
*/

다음 코드가 위와 다르게 작동해야 할 이유가 없습니다. 최종 출력에 .block 클래스가 없다는 이점이 있습니다.

.block() { color: green; }

.component {
  .block() { color: red; }  
  div:extend( .block() ) { };
}

/*
.component div {
  color: green;
}
*/

Btw., 명명 규칙에 약간의 드리프트가 있습니다. :) 예를 들어 "매개변수 믹스인"은 매개변수가 0인 항목을 포함하여 괄호로 정의된 모든 믹스인을 의미합니다(예: .mixin() {} 는 "매개변수"임). 그리고 "비매개변수" mixin은 단순한 선택기(예: .mixin {} )입니다. 지금까지는 이 드리프트가 오해를 일으키지 않았다고 생각하지만(예: 위의 대부분의 예에서 .mixin() {} 가 "비매개변수" 믹스인으로 언급된 경우 컨텍스트에서 명확했습니다)...
문서 에서 간단한 선택기의 이름도 "mixin"으로 지정되고(혼합되는 즉시) "비매개변수" mixin인 것도 놓치지 마세요. 따라서 .mixin() {} 를 "비모수적"으로만 언급하는 것은 상당히 모호할 수 있습니다(기술적으로 차이점은 인수의 수가 아니라 정의 괄호의 존재 여부에 있습니다).
좋아, 이것은 나의 평소의 boo-boo-boo였습니다. :)

@lukeapage

지금은 파라메트릭 믹스인을 무시하는 것이 좋습니다.

즉, 0이 아닌 매개변수가 있는 믹스인에 대해 확장을 지원하지 않습니까? 나는 괜찮습니다. 나는 그것이 어떻게 구현될 수 있는지 추정하려고 했을 뿐입니다.

근데 합쳐진다? 기존 확장과 동일한 접근 방식을 사용합니다. 예를 들어 일치 항목을 찾아 추가합니다.

맞아요, 거기에서 믹스인의 확장을 실제 인수와 병합할 때 발생할 수 있는 어려움에 대해 더 많이 생각하고 있었던 것 같습니다. 예:

.b:extend(.a(1, 2, 3)) {}
.c:extend(.a(1, 2, 3)) {}

반면에 매개변수가 0인 믹스인에도 숨겨진 놀라움이 있다고 생각합니다. 예를 들면 다음과 같습니다.

.a {color: red}
.a {width: 2px}

.b:extend(.a) {}   // creates two `.b` blocks (it is expected since there're two `.a` blocks anyway)

.c {.a}            // creates one `.c` block (OK, this is just how mixins work)

.d() {color: blue}
.d() {width: 10px}

.e {.d()}          // creates one `.e` block (OK, this is just how mixins work)

.f:extend(.d()) {} // tada! another room for complains if this creates two `.f` blocks :)

글쎄, 아마도 이것은 너무 깊숙이 들어갈 것입니다.

.f:extend(.d()) {} // tada! another room for complains if this creates two .f blocks :)

"이 예에서 .d() 는 매개변수이므로 두 개의 .f 블록을 생성해서는 안 된다"는 생각으로?

예, mixin이 다음과 같은 결과를 초래한다는 점을 감안할 때 귀하의 요점을 알 수 있습니다.

.f {
  color: #0000ff;
  width: 10px;
}

IMHO 단계적으로 수행하는 것이 합리적이라면 설명만 하면 되지만 불만 자체를 피하기 위해 구현하지는 _하지_ 않을 것입니다. 물론 이것은 내 2c입니다. 그리고 설명된 동작으로 구현된 경우 기능을 추가할 때 "확장된 선택기에서 CSS 블록 병합"에 대한 기능 요청을 생성하여 불만을 해소할 수도 있습니다...?

그러나 나는 불만 그 자체를 피하기 위해 무언가를 구현하지 않을 것입니다.

전적으로 동의합니다. 나는 단지 "변경하기에는 너무 늦었다"는 것 중 하나가 될 수 있는 모든 놀라움을 예측하려고 노력하고 있습니다.

:+1: 네, 당신이 생각하는 방식이 좋아요!

나는 이 토론이 여전히 진행되고 있다는 것을 좋아한다. 이 토론의 몇 가지 요점으로 돌아가겠습니다. 첫째, 일반적인 사용에 있어서는 동일합니다.

.mixin {} == .mixin() {}

.mixin { }가 출력을 클래스로 가져오는 것을 제외하고. 나는 파서에서 그것들이 아마도 다르게 취급된다는 것을 알고 있지만, 사용법에서는 속성/값 쌍을 덤프합니다.

의미:

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    .mixin1;
    foo:bar;
}
.use2 {
    .mixin2;
    foo:bar;
}

이 Less 구문 기록 때문에 다음과 같이 할 수 있습니다.

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use2 {
    &:extend(.mixin2);
    foo:bar;
}

저에게 이것은 논쟁의 여지가 없습니다. 우리가 종종 :extend는 원래 믹스인 사용의 많은 인스턴스의 드롭인 교체에 대해 이야기했습니다.

일반인의 경우 이는 직관적으로 동일할 것입니다. .mixin1이 괄호로 작성되었는지 여부에 관계없이 역사적으로 다음과 같은 방식으로 참조될 수 있기 때문입니다.

.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}

그래서, 나는 이것을 기대할 것입니다 :

.mixin1() {
    color: red;    
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}
.use2 {
    &:extend(.mixin1());
    bar:foo;
}

...출력하다...

.use1, .use2 {
    color: red;    
}
.use1 {
    foo:bar;
}
.use2 {
    bar:foo;
}

mixin이 두 번 정의되면 클래스 선택자인 자매와 마찬가지로 확장 시 두 번 대체됩니다.

.mixin1() {
  color: red;
}
.mixin1() {
  width: 30px;
}
.use1 {
  &:extend(.mixin1);
  foo: bar;
}
.use2 {
  &:extend(.mixin1);
}
//output

.use1, .use2 {
  color: red;
}
.use1, .use2 { 
  width: 30px;
}
.use1 {
  foo: bar;
}

이것이 기본적으로 믹스인 정의에서 괄호를 제거하는 경우 지금 확장이 작동하는 방식입니다. 단, 물론 믹스인 이름이 출력에 표시되므로 기존 확장 동작을 따르는 것이 합리적입니다.

매개변수(내 90% 사용 사례)의 경우 입력으로 구분된다는 점을 제외하고는 동일합니다.

.col(@width) {
  width: @width;
  display: table-cell;
}

.col1:extend(.col(10%)) { }
.col2:extend(.col(10%)) { }
.col3:extend(.col(80%)) { }

//output 

.col1, .col2 {
  width: 10%;
  display: table-cell;
}
.col3 {
  width: 80%;
  display: table-cell;
}

저에게 믹스인을 확장하는 이유는 매개변수를 그룹화하여 매우 간결한 출력을 생성할 수 있는 보다 강력한 믹스인 라이브러리로 이어지기 위함입니다. 매개변수가 없는 믹스인에 사용하는 것은 그다지 중요하지 않습니다. 왜냐하면 오늘은 기존 Less 기능을 사용하여 원하는 결과를 얻을 수 있기 때문입니다.

이를 계속 추진해 주셔서 감사합니다. 꽤 강력한 추가 기능이 될 수 있다고 생각합니다.

:+1 포괄적인 분석에 대해 @matthew-dean에게 감사드립니다. 귀하가 다룬 모든 내용에 동의합니다. 최근 토론 주제 중 하나인 이 시나리오에 대해 의견을 제시해 주시겠습니까?

.mixin() { color: red; }

.component {
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

LESS가 현재 작동하는 방식은 전역 범위의 믹스인만 확장됩니다. 즉, 빨간색 스타일이 확장됩니다. 저는 개인적으로 이 동작에 동의하며 누군가가 위의 코드를 작성하고 파란색 스타일이 우세할 것으로 예상하지만 extends의 "전역적" 동작은 문서에서 한 줄짜리라고 생각합니다.

// this is ".mixin()", which is being extended
.mixin() { color: red; }

.component {
    // this is ".component .mixin()", which is not. 
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

나는 extends의 "전역"동작이 문서에서 한 줄짜리라고 생각합니다.

완전히 동의합니다. 여기에 회색 영역을 도입하는 것은 끔찍한 생각이라고 생각합니다.

저에게 중요한 것은 일관성입니다. 현재 동작이 로컬 범위에서 선택기를 확장하지 않는 경우나 믹스인에서도 확장해서는 안 됩니다. 나중에 로컬에서 선택기를 확장하면 믹스인도 확장해야 합니다. 사람들은 라이브러리 전체에 걸친 :extend 패턴을 신뢰할 수 있어야 합니다.

(내가 더 간결하게 말할 수도 있었지만: " @jonschlinkert 의 의견에 +1". ;-)

이 시점에서 누구든지 이 기능을 혼란스럽게 만드는 사용 사례를 제공할 수 있습니까? @matthew-dean의 포괄적인 개요 와 이후의 응답으로 시작하여 다루지 않은 실제 상황을 시도해 보십시오.

즐거운 휴일 보내세요. 메리 크리스마스. 펠리스 피에스타스!

정말 좋은 개요. @matthew-dean 및 다음 모든 의견에 동의합니다. :+1:

나는 또한 @matthew-dean에 동의합니다. 그는 팽팽한 친구처럼 보이며 나는 그와 악수하고 싶습니다.

(-익명의)

@matthew-딘 단어. :+1:

이 기능을 사용하면 Bootstrap의 그리드 시스템 코드를 훨씬 더 깔끔하게 만들 수 있습니다!

:+1: @cvrebert에 동의했습니다! 좋은 것!

그냥 재방문. 나는 우리가 거의 합의에 이르렀고 구현이 필요하다고 생각합니다. 맞습니까?

나는 이것에 대해 더 많은 정보를 찾으려고 노력하고 있지만 모든 것을 읽는 미로와 같습니다. 이것이 구현된 적이 있습니까? 그렇다면 누군가 친절하게 문서의 적절한 영역을 알려줄 수 있습니다.

@josh18 아니요, 기능 요청이 아직 열려 있으면 일반적으로 구현되지 않았음을 의미합니다.

네, 감사합니다. 혹시 제가 놓친 부분이 있는지 다시 한 번 확인해 보겠습니다.

언젠가 Wiki에서 공개/구현될 기능을 요약할 계획이지만 아직 시간이 없습니다.

언젠가 Wiki에서 공개/구현될 기능을 요약할 계획이지만 아직 시간이 없습니다.

@matthew-dean +1

안녕 얘들아! 내가 이해하는 한 이 기능은 SASS 자리 표시자와 다소 유사합니다. 언제 구현되는지 알고 싶었습니다.

안녕하세요,
내 시간과 다른 기여자를 예측하는 것이 어렵다는 것을 알게 되었습니다.
그들이 관심이 있는 것을 구현하기 때문에 확실하지 않습니다. 내가 말할 수 있는 것은
우리는 그것을 높은 우선 순위로 생각하며, 내 목록에서 다음으로 중요한 것입니다.

답변 주셔서 감사합니다. 이것이 구현되고 작동하는 것을 보기를 기대합니다. :)

이 기능에 대해 +1입니다. CSS 크기를 줄이는 데 매우 유용합니다.

이 기능에 대해 +1입니다.

이 기능에 대해 +1입니다.

+1 관심있게 시청해주셔서 감사합니다!

:+1:

이 문제가 생성된 지 2년이 지났습니다. 2014년 11월 이후의 높은 우선 순위 태그입니다. 이정표는 1.6.0 또는 2.0.0입니다. 엄청난. 지금은 2.5 미만입니다.

@그롤

홍보할 준비가 되셨나요?

@seven-phases-max 생각했던 것과 거의 비슷합니다. 그러한 권리의 표시. ;)

@seven-phases-max lol 아니요 저는 그냥 프론트엔드/디자이너입니다.
@Celc 진짜 못생겼어 😂

이 문제가 생성된 지 2년이 지났습니다.

그래, 어쨌든 내가 너희들에게 돈을 지불하는 것은 무엇인가? ;-)

슬프게도 참여를 도울 수 없지만 이 요청에 적극 찬성합니다!

이것은 복잡하고 효과적인 프레임워크를 구축하기 위한 매우 중요한 기능입니다.

3년과 계산. 다행히 Sass v4( sass-* 접두어 기능 포함)가 출시되고 Less를 제거할 수 있습니다.

@stevenvachon 우리는 Sass에 대해 원한을 품지 않습니다. 물론 어떤 면에서는 경쟁자지만 프로젝트마다 철학이 다르고 그것을 불러 우리를 해치려는 것은 무의미합니다.

물론 누구든지 풀 리퀘스트를 환영합니다. 우리는 이 기능과 함께 기능적 pull 요청을 기꺼이 병합할 것입니다.

나는 누군가를 다치게 하려고 하는 것이 아닙니다. 사실 아마 그러한 것을 방지하려고 할 것입니다. 자신이 느끼는 감정과 그에 따른 새로운 방향을 표현하는 것이 더 좋은 것 같아요. 빨리 아는 것이 낫다고 생각합니다. 모두가 떠나기 전에. 예를 들어, Bootstrap v4는 Less.js를 사용하지 않으며 사용자 기반에 큰 타격을 줄 것이라고 확신합니다. 물론 그러한 정치는 원하는 대로 무시할 수 있습니다.

@stevenvachon 왜 그렇게 :extend 기능 을 사용했습니다. 이 문제가 왜 아직 열려 있는지조차 모르겠습니다.

젠장, 저는 레일즈 개발자이고 루비 프로젝트가 아닐 때 gulp+LESS를 사용합니다.

주제를 벗어? 이 기능은 3년 동안 구현되지 않았으며 매우 유용할 것입니다.

Sass가 JS로 작성되었으면 더 좋았겠지만, 그렇지도 않고 그게 가장 중요한 것도 아닙니다. 그 기능은 다음과 같습니다. Sass를 사용하면 자리 표시자를 확장할 수 있지만 Less를 사용하면 믹스인을 확장할 수 없습니다.

야, 그것은 전혀 주제에서 벗어나지 않지만 매우 기대되는 기능입니다! (여러 가지 이유로 어쨌든 덜 선호하지만)

만들어달라고 애원할 뿐입니다.

추신 제 경우에는 실제로 js에 대한 약간의 지식을 가진 디자이너입니다. 대부분은 dom과 관련이 있으며 less.js 코드베이스에 기여할 수 있는 개발자와는 거리가 멉니다. 어쨌든 슬픈 이야기입니다)

단지 매우 관심 있는 프로젝트 후원자)

공익광고

언제든지 풀 리퀘스트를 제출하거나 개발자와 협력하여 풀 리퀘스트를 받을 수 있으며 이 기능이 병합될 가능성이 매우 높습니다. Less.js 라이브러리는 이 스레드에 있는 사람들과 같은 개인의 정기적인 기여가 더 필요합니다. . 어느 한 사람의 책임이 아닙니다. 이 스레드를 보거나 이 기능을 필요로 하고 시간을 들여 이를 실현하는 것은 전적으로 한 개인에게 달려 있습니다.

귀하의 응답이 귀하가 개발자가 아니라는 것이라면, 새로운 기능에 필요한 문서를 제공하거나 웹사이트에서 디자인 지원을 제공하고, 테스트를 실행하고, 피드백을 제공하는 등 비개발 역할에서 이 프로젝트를 지원할 수 있는 다른 많은 방법이 있습니다. 문제, 프로젝트 관리, 스택 오버플로에 대한 질문에 답하기, 블로그 게시물 작성, Less에 대해 트윗하기, CSS 및 웹 커뮤니티에 기여하기, Less 라이브러리 작성하기.

이러한 작업의 대부분은 개발자인 개인이 수행하므로 개발에 기여할 수 있는 시간을 이러한 다른 작업에 할애합니다.

당신이 개발자이고 당신의 응답이 "시간이 없습니다."라면 이것이 바로 이 문제가 공개된 정확한 이유입니다. 기능이 완료되었는지 여부는 100% 귀하에게 달려 있으므로 "누군가"가 완료하지 않은 이유를 묻는 것은 유용하지 않습니다. _당신이 바로 그 사람입니다._ 당신이 이 프로젝트에 참여한다면 그리고 그 때 일어날 것입니다. 웹에서 가장 인기 있는 오픈 소스 도구 중 하나에 참여할 수 있습니다. 당신은 수천 명의 삶을 바꿀 수 있습니까? 수십만? 수백만? 그리고 부수적인 이점으로 좋아하는 기능이 더 빨리 실행되도록 할 수 있습니다.

이 기능이나 어떤 기능이 발생하기를 원한다면 그것을 실현하십시오 . 우리는 당신을 갖고 싶습니다. 우리는 당신과 함께 일하고 싶습니다! 이 커뮤니티가 성장할수록 더 좋아질 수 있습니다!

그리고, 가끔 사람들이 기여할 시간이 전혀 없는데도 여전히 특정 기능이 구현되기를 바라는 경우가 있다는 점에 감사드립니다. 괜찮아. 나는 당신이 그 시나리오에 있다면 당신을 돕기 위해 시간(때로는 돈)을 기부하는 사람들에 대한 공감과 감사를 목표로 하고 있으며 Less 커뮤니티의 다른 사람들이 최선을 다할 것이라고 확신합니다. 그들이 할 수 있는 한 계속하십시오.

감사합니다,
Matthew Dean, Less.js 핵심 팀 멤버

나는 이미 내 자신의 프로젝트를 지원하고 그들의 기능 요청을 듣습니다. 솔직히 Less.js 코어를 파헤칠 시간이 없습니다.

sass 자리 표시자(또는 "silent class") 지원을 위해 여기에 오는 사람들은 이 주석을 읽으십시오. (#1851과 "참조된" 파일에 그런 클래스가 없기 때문에) 거기까지 가는 것은 아니지만 없는 것보다는 낫습니다.