Less.js: 변수에 선택기 저장

흥미롭게도 그러한 요청이 이미 존재한다고 절대적으로 확신했습니다. 분명히 그렇지 않습니다.
(분명히 이 아이디어는 #1174, https://github.com/less/less.js/issues/1075#issuecomment-16891103 등의 이전 티켓에 많이 등장했습니다.)
그래서 내가 추측하자.

Btw., 만일을 대비하여(그리고 가능한 impl./syntax 충돌을 생각하기 위해 일부 사용 사례를 수집하기 위해):
어떻게 사용하시겠습니까? 나는 많은 경우에 게으른 평가 때문에 예상대로 작동하지 않을 것이라고 생각합니다. 예:

a {
    <strong i="11">@r</strong>: &;
    b {
        something: @r;
    }
}

결과:

a b {
    something: a b; // not a!
}

때문에 @r 값이 정말 내부 평가 a b (즉, 그것이 사용되는 곳 -하지 포인트 당신이 그것을 정의에서).
(따라서 특정 유스 케이스는 실제로 변수가 아닌 다른 언어 구성이 필요할 수 있다고 생각합니다. 그리고 다른 많은 관련 유스 케이스는 #1075의 주제로 이전에 고려되었습니다.)

많은 경우 게으른 평가 때문에 예상대로 작동하지 않습니다.
특정 사용 사례에는 실제로 변수가 아닌 다른 언어 구성이 필요할 수 있다고 생각합니다.

할당된 변수의 평가에 의해 호출되는 지점이 아니라 정의된 지점에서 선택기 컨텍스트를 캡처하려면 특수 언어 구성이 필요합니다. 평가는 정의 사이트에서 캡처된 컨텍스트를 내보내야 합니다.

클로저로 변수를 찾는 것과 크게 다르지는 않지만 그렇습니다. 함수가 아닌 특별한 언어 구조가 필요합니다.

@rjgotten

예, 우리는 이전에 selector 의사 함수에 대해 논의한 것 같습니다(일반 함수 구문 분석은 선택기 특정 결합자를 모두 처리할 수 없기 때문에 의사). 그런 다음 의사(예: Url 와 같은 전용 유형)
따라서 <strong i="10">@foo</strong>: selector(&); 같은 것이 트릭을 할 수 있을 것 같습니다. 그러나 다음 사소한 문제가 발생합니다.

a {
    <strong i="13">@var</strong>: selector(x, #y & .z);

    b {
        @{var} { // ? is it regular & or "saved-context-&" ?
            // ...
        }
    }
}

따라서 & 연산자/키워드 이외의 다른 항목이 필요할 수 있습니다. (또는 current-selector() 와 같은 전용 의사 함수일 수도 있습니다. ... 흠, 이제 모든 작은 제품의 API를 오염시키지 않도록 일반 PseudoFunction 유형을 코딩하는 아이디어가 떠올랐습니다. 으악! :).

언어에 새로운 것을 추가하는 데 일반적으로 주저가 있다는 것을 알고 있지만 선택자 지정자가 편리할 수 있습니다. CSS @namespace 선택기 구문의 일부이지만 | 좋아 합니다 . 그러나 | 가 선택기를 _start_할 수 있는 것 같지 않으므로 충돌하지 않아야 합니다. 모호하게 적절해 보이는 Math의 "절대값"을 생각나게 하고 간단하기 때문에 사용하고 있습니다. 대화에 영감을 주는 생각일 뿐입니다.

a {
  <strong i="10">@var</strong>: |x, #y & .z|; // starting w/ `|` means selector, in current context, ended w/ another `|`
  b {
    @{var} {
      //...
    }
  }
}

(사실, _any_ var가 즉시 처리되어 저장되어야 함을 지정하는 데 사용할 수 있습니다. 그러나 그것은 _way_ 범위를 초과하는 것처럼 느껴집니다.)

일반 & 또는 saved-context-& 입니까?

selector() 의사 함수가 호출되는 사이트에서 선택기 컨텍스트를 캡처해야 하고 & 가 _that_ 컨텍스트 내에서 평가되어야 하며 최종 결과가 이 새 유형에 할당되어야 한다고 말하고 싶습니다. Selector 트리 노드.

Selector 유형의 트리 노드를 보유하는 _any_ 변수가 예에서 @{var} 를 사용하는 경우와 같이 선택기로 보간되면 결과 선택기가 동일한 방식으로 빌드되어야 합니다. & 보간기가 선택기에 있을 때와 같이, 즉 ; 한 단계 위의 선택자와 결합하고 접두사를 사용하지 마십시오.

그 이유는 둘 다 캡처된 선택기이기 때문입니다. selector() 는 사용자가 캡처한 것이고 & 는 항상 존재하고 캡처된 '상위' 선택기입니다.

그런 다음 사용자가 _current_ 선택기 컨텍스트와 함께 캡처된 Selector 노드의 보간을 필요로 하는 경우 이에 대해 명시적일 수 있습니다. 예: & @{var} { ... }

닫는 중

a {
    <strong i="24">@var</strong>: selector(x, #y & .z);

    b {
        @{var} { ... }
    }
}

생성해야 한다

x, #y a .z { ... }

반면

a {
    <strong i="31">@var</strong>: selector(x, #y & .z);

    b {
        & @{var} { ... }
    }
}

생성해야 한다

a b x,
a b #y a .z { ... }

흠, @{var} 대 & @{var} 는 상당히 인위적으로 보입니다. 이것은 Less에서 작동하는 방식이 아닙니다. ... { & div ... 및 ... { div ... 는 항상 동일한 명령문이었습니다. 또한 이것을 세지 않고 x, #y * .z 다른 곳에서 정의된 a b x, #y a b .z 가 필요한 경우 어떻게 해야 합니까?

나는 선택자를 위한 함수와 같은 구조의 팬이 아닙니다. 나는 상속된 선택자를 참조, 수정 또는 전송(변수에 할당 및 재사용)할 수 있는 것을 지지합니다.

그러나 이것이 #1075(상위 선택자를 대상으로 함)의 변형이거나 https://github.com/less/less-meta/issues/16#issuecomment -292679320(할당 변수에 대한 단일 선택자)? 아니면 이것이 단일 평가된 선택기(또는 믹스인)가 아닌 선택기 목록이고 출력이 평가된 규칙 세트가 아니라 선택기 목록 이기 때문에 앨리어싱 믹스인과 다른가요? 이 기능이 다르다고 가정합니다. 이 모든 것이 같은 방향으로 움직이고 있는지 확인하고 싶습니다.

@matthew-dean
실제로 평가된 규칙 집합을 캡처하고 나중에 사용할 수 있도록 해당 목록을 출력하는 것이 아니라 실제 선택기 목록을 캡처하는 것입니다.

extract(list,index) 와 같은 기능이 선택기 목록에서 선택기 구성 요소를 추출할 수 있도록 업데이트되고 사용자가 흥미로운 방식으로 쉽게 조작할 수 있도록 선택기로 쉽게 작업할 수 있도록 유사한 개선 사항을 상상할 수 있습니다. 예를 들어, BEM과 같은 특정 명명 체계를 따르는 구성 요소의 경우.

예를 들어 주어진 믹스인

.my-bem-component(<strong i="10">@a</strong>, @b) {
  // Component will only ever be constructed on the first selector in
  // a list, for simplicity.
  <strong i="11">@selectors</strong> : selector(&);
  <strong i="12">@selector</strong>  : extract(<strong i="13">@selectors</strong>, 1);

  // Generate a clean block name, cleared of modifiers.
  // Grabs e.g. "bar" from ".foo > .bar--baz"
  @block-name : replace(<strong i="14">@selector</strong>, "\.([^\.\s]+)--\S+$", "$1" );

  // Generate the modifier name and generate different CSS for
  // BEM classes that have one.
  // Grabs e.g. "baz" in ".foo > .bar--baz"
  @mod-name : replace(<strong i="15">@selector</strong>, "\.+--(\S+)$", "$1" );

  .generate-block();
  // When @mod-name matches <strong i="16">@selector</strong>, no replacement has
  // occured and we are infact in the situation where we have no
  // BEM modifier and generate the 'base' component.
  .generate-block() when (@mod-name = "@{selector}") {
    @{selector} {
      prop-a : @a;
    }
    @{selector}__element {
      prop-b : @b;
    }
  }

  .generate-block() when (default()) {
    @{selector} {
      prop-a : @a;
    }
    @{selector} > .@{block}__element {
      prop-b : @b;
    }
  }
}

다음 덜

.block {
  .my-bem-component(foo, bar);
}
.block--caps {
  .my-bem-component(FOO, BAR);
}

CSS 생성

.block {
  prop-a : foo;
}
.block__element {
 prop-b : bar;
}
.block--caps {
  prop-a : FOO;
}
.block--caps > .block__element {
  prop-b : BAR;
}

Sass는 오랫동안 이것을 사용해 왔으며 이 기술이 매우 영리하게 사용되는 많은 예가 있습니다. 내 예와 같은 코드 팩토리에서 또는 다른 목적으로.

에 관해서:

less/less-meta#16(주석)과의 충돌 가능성(변수에 단일 선택기 할당)

개인적으로 나는 다음과 같은 행동을 가정합니다.
"사소한" 선택기 값(예: .mixin , .ns.mixin , #foo .bar , baz 등, 운 좋게도 이것은 mixin/function으로 사용/정의될 수 있는 모든 것을 다룹니다. ) 변수에 직접 할당(또는 함수에 매개변수로 전달)

<strong i="15">@var</strong>: .ns.mixin; // OK, its just Anonymous value (representing an arbitrary identifier) 
function(.mixin); // error: TODO 

^ 이것은 (본질적으로) 선택자와 전혀 관련이 없습니다 - 이 값은 @var(...) 또는 @var[...] 명세서
(일반적으로 논리적 규칙은 mixin 식별자가 (내부적으로는) 선택자로 표시된다는 사실을 잊어버리지만 항상 점 또는 # 접두사가 있는 식별자로 생각하고 .ns > .mixin 와 같은 것을 결국 중복되고 쓸모없는 것으로 사라집니다. :)

복잡한 또는 "실제" 선택기 에는 구문/파서의 모호성 때문에 selector 의사 함수가 필요합니다. 즉:

• <strong i="29">@var</strong>:foo>bar <- 선택기 및 (잠재적으로) 논리 표현식
• <strong i="32">@var</strong>:.1+.2; <- 산술 표현식 및 유효한 Less 선택기
  (등. 모든 특정 선택기 기호를 잘 기억하십시오. 거의 모든 값 구문 분석 컨텍스트에서 무언가와 충돌하며 위의 값이 매개변수로 함수/믹스인에 잠재적으로 전달될 때 훨씬 더 극적입니다. 예를 들어 다음은 불가능합니다. selector() :
  less: some-function(abc, selector(#foo .is :not(> bar)[baz="qux"], abc), selector(bla), 42); // ^ remove `selector()` and try to parse

나는 선택자를 위한 함수와 같은 구조의 팬이 아닙니다.

요약하면 selector 의사 함수는 현재 및 잠재적인 구문 및 의미 체계 충돌을 한 번에 영원히 제거하는 데 필요합니다. 그래서 여기에 옵션이 너무 많은지 의심스럽습니다(값 및 선택기 구문 분석 컨텍스트는 어떻게든 분리해야 함).

(모든 위의 값에 의해 반환 된하지 의미합니까 selector() 호출 가능한 개체로 사용할 수 없습니다 예를 들어 @var() , 아마 수도 -하지만 그것으로 거의 가치가 그래서, 그냥 필요 / 쓸모없는 것 신경 쓰다).

@rjgotten

extract(list,index) 와 같은 함수가 선택자를 추출할 수도 있도록 업데이트되는 것을 상상할 수 있습니다.

물론 그러한 문자열이 일부 선택기를 포함할 수 있다고 가정하고 문자열과 함께 작동하도록 함수를 조정할 수 있지만 이는 extract 뿐만 아니라 모든 그러한 함수가 업데이트/조정/수정되어야 함을 의미합니다. 반대의 접근 방식은 더 효율적이고 부담이 덜할 것입니다. 즉, 전용 selector-string->values 변환 함수이거나 selector 의해 직접 노드의 적절한 구조를 반환하는 것입니다(어느 경우든 가장 까다로운 부분은 사용할 때마다 선택기 결합기를 포장/풀기하는 방법입니다) -케이스는 다른 표현을 선호할 수 있습니다).

(선택기 보간 기능 자체는 여전히 @{var} 를 결국 적절한 형식으로 변환해야 하므로 해당 var의 값이 어떤 형식으로 입력되는지는 중요하지 않습니다. 문자열이든 익명이든 무엇이든 상관없습니다. 노드 구조 - 대부분의 변환 속임수는 그대로 유지됨).

@block-name : replace(<strong i="17">@selector</strong>, "\.([^\.\s]+)--\S+$", "$1" );

솔직히 말해서, 이것은 "인라인 JavaScript 및 LessHat과 같은 해커"의 환생처럼 보이며 금지할 수는 없지만 공격적으로 광고할 것입니다.
(예가 꽤 불행 하다는 것을 계산하지 않고 <- 줄을 세십시오) 차라리 less-plugin-bem-selectors 제안하고 싶습니다(여기서 단순히 get-block-name 기능을 가질 수 있습니다. & 기능)과 같은 추악한 정규식 대신("CSS 전처리기를 임의의 텍스트 프로세서로 사용" 접근 방식은 결국 PostCSS와 유사한 것으로 심하게 느슨해질 것입니다).

& 대 context-saving-& 돌아가서 지금까지는 함수에 대한 전용 플래그(예: selector(..., lazy or not) 또는 두 개)보다 더 나은 아이디어가 없습니다. 별도의 기능. 또는 other-than-&-keyword (예: ₸ )를 사용합니다. 평가 시점 모호성을 자동으로 해결하는 안전한 방법이 보이지 않습니다.

less-plugin-bem-selectors 제안하고 싶습니다.

전적으로. 정규식 기반 추출은 사용자 지정 함수를 포함하지 않는 예제를 제공하기 위한 것입니다. ;)

나는 선택자를 위한 함수와 같은 구조의 팬이 아닙니다.

또한 모양 만 의미한다면 ... 물론 ⁞#foo:not(.bar)⁞ 와 같이 다른 구성일 수도 있지만 이미 무료 기호가 부족하다는 것을 알고 있습니다. 따라서 의사 함수 구문은 이미 url 와 같은 개념을 가지고 있기 때문에 제안된 것입니다(따라서 새로운 개념이 깨질 수 있거나 깨질 것에 대해 생각할 필요가 없음).

이제 재미있는 부분입니다.

나는 current-selector 함수의 빠르고 더러운 플러그인 구현 을 만들었습니다(단지 그것이 얼마나 부풀려질 수 있는지 보기 위해, 물론 var lazy-evaluation 때문에 매우 유용할 수는 없을 것으로 예상합니다). 그리고 무엇을 알고 있습니까? 이 기본 예:

div {
    <strong i="9">@x</strong>: current-selector();
    span {
        r: @x; // -> div
    }
}

결과는 r: div :)
컴파일러 코드의 어떤 부분이 이 특정 동작을 처리하는지 정확히 모르지만 다음은 마법을 설명하기 위한 고급 예제입니다.

div {
    <strong i="15">@x</strong>: current-selector();     // [1]
    <strong i="16">@y</strong>: current-selector() @v;  // [2]
    <strong i="17">@z</strong>: current-selector(@v);   // [3]
    <strong i="18">@v</strong>: whatever;
    span {
        1: @x; // div
        2: @y; // div span
        3: @z; // div span
        4: current-selector();  // [4] div span
    }
}

[2] 및 [3] 문만 두 번 호출되는 반면(즉, 실제로 지연 평가됨) [1] 는 그렇지 않습니다(값에 변수가 포함되어 있지 않기 때문에 분명히 다시 말하지만 이것이 의도적인 것인지 아니면 일부 캐싱의 부작용인지, 아니면 내 코드의 운이 좋은 버그일 수 있는지 모르겠습니다. 예를 들어 이 줄 이 이 캐싱에 대해 이러한 부작용을 유발할 수 있지만 명확하지 않습니다. 추가 변수의 영향을 받는 이유 - 더 많은 연구가 필요함).

즉, context-saving-& 의 플러그인 기반 버전이 가능한 것 같습니다(물론 <strong i="29">@var</strong>: & 대신 <strong i="31">@var</strong>: current-selector() 같은 것을 사용한다는 점은 제외). 매개변수가 없으면 지연 평가됩니다(변수가 전달된 경우). 처음에 4개로 계획했기 때문에 이것은 슬픈 일입니다.
상당히 악의적이지만 해결 방법/폴리필로 사용할 수 있습니다. 보다 실제적인 예도 원하는 대로 작동합니다.

div#zoo {
    <strong i="35">@x</strong>: current-selector();
    span {
        <strong i="36">@y</strong>: replace(<strong i="37">@x</strong>, div, body);
        r: @y; // OK, body#zoo
        @{y} { 
        // ^ not very useful this way (except maybe bem stuff) since you can't remove div
            color: red;
        }
    }
}

즉, 후속 변수 할당/함수 호출은 초기 변수의 평가 지점에 영향을 미치지 않습니다.

@seven-phases-max
사랑해.

매개변수 인수가 있을 때 지연 평가가 현재 작업에서 스패너를 발생시킨다 하더라도 _that_은 아마도 '실제' 구현을 위해 해결할 수 있는 것입니다.

또한, 그것이 어떻게 보이는지 의미한다면... 물론 ⁞# foo:not (.bar)⁞과 같은 다른 구성일 수 있지만 이미 무료 기호가 부족하다는 것을 알고 있습니다.

그럴 수 있지. 나는 사용법과 관련하여 이것에 대해 내 머리를 감싸지 않았으며 더 나은 아이디어가 없습니다. 여기에 뭔가 특별한 것이 있었던 것 같지만 그렇지 않을 수도 있습니다. $() 에 대한 논의가 있었던 것으로 알고 있지만 결국 $ . BTW, 그것은되지 않을 것 selectors() 하지 selector() ? & 와 같이 선택기를 여러 개 포함할 수 없습니까?

그리고 selector(&) 가 current-selector() 보다 더 의미가 있는 것 같습니다. 즉, " & 이든 문자열이든 X 개체에서 선택기 목록을 만듭니다." 최종 구문이 무엇이든 & 를 인수로 사용하는 것처럼 보입니다.

그리고 selector(&) 가 current-selector() 보다 더 의미가 있는 것 같습니다.

이것들은 다른 것들입니다. current-selector 는 & 의 함수 변형일 뿐입니다(후자는 파서에서 지원하지 않기 때문에). selector(...) 는 파서가 임의의 선택기를 지원하기 위한 패치입니다( & ).

selectors - 글쎄요. 그러나 단일 선택기 사용 사례의 99%이므로 복수형은 대부분의 사용자에게 덜 분명하게 들릴 것입니다(대부분의 경우 일반적으로 h1, h2, h3 {} 을 선택기로 제목을 지정하고 Less 상위 선택기(심지어 선택기 s 인 경우 :) 그래서 왜 귀찮게합니까?

그래.

@matthew-dean
복수형과 단수형은 CSS 사양 작성자를 제외한 누구에게나 거의 호환됩니다. 사실, 다음과 같이 하십시오. 사양 작성자를 포함한 모든 사람

꽤 웃기게; 복수형 용어 '선택자'는 쉼표로 구분된 집합을 지정하는 공식적인 방법도 아닙니다. 복수형에 대한 엄격하게 올바른 용어는 _selector list_라고 생각합니다.

따라서 이 모호한 참조가 실제로 얼마나 깊이 뿌리를 두고 있는지 알 수 있습니다.

복수형에 대한 엄격하게 올바른 용어는 선택자 목록이라고 생각합니다.

예, 어제 w3c도 검색했습니다. "선택자 그룹", "선택자 목록" 등입니다. "선택자는 결합자로 분리된 하나 이상의 단순 선택자 시퀀스의 체인입니다." 있습니다 :) 그냥 "선택자" 형식은 "선택자 유형"을 설명하는 데 주로 사용됩니다.

"선택자는 결합자로 분리된 하나 이상의 단순 선택자 시퀀스의 체인입니다."

그리고 그것이 쉼표로 구분된 목록을 참조할 수 있다고 생각하는 사람을 위해: 그렇지 않습니다. 해당 인용문의 전체 형식은 다음과 같아야 합니다. "_복잡한_ 선택자는 결합자로 분리된 하나 이상의 단순 선택자 시퀀스의 체인입니다."

CSS 사양에는 "선택자"의 일반화된 형식이 사양에서 공식적으로 _복잡한 선택자_라고 부르는 것을 참조하는 데 주로 사용되는 또 다른 문제가 있습니다. 복잡한 선택자는 단순 선택자입니다. 예: tag ; #id ; .class ; [attr] ; 등 , 결합자를 통해 연결됨, 예: > ; + ; ~ 등

ul > li 와 같은 것을 복합 선택기라고 합니다.

경고 다음은 약간의 난리입니다.

CSS 사양은 슬프게도 일관성이 없고 이름이 잘못된 용어의 수렁입니다. 뒤로 갈수록 점점 더 나빠집니다. CSS3 모듈의 로드가 계속 CSS 2.1 모듈을 다시 참조하거나 새 CSS3 모듈이 이전 CSS 2.1 문서를 그대로 복사하여 지정되었다는 것은 도움이 되지 않습니다. 선택기의 사양과 시각적 형식 지정 모델은 최악의 경우입니다. 너무 모호하거나 비슷하게 들리거나 이름이 좋지 않은 용어.

예를 들어 [*|attr^="value" i] 와 같이 ul > li 보다 훨씬 덜 사소한 것을 예로 들어 보겠습니다. 후자는 기술적으로 단순 선택기로 분류됩니다. (네 진짜로 요.)

나는 몇 년 전 어느 시점에 디자인 지향적인 동료 중 한 명에게 후자의 시각적 서식 지정 모델 사양의 일부를 설명하려고 시도하고 설명해야 했습니다. 나는 우리가 라인 박스의 개념을 다루는 구절을 살펴보는 동안 우리의 두뇌 _둘 다_에서 실제로 몇 개의 퓨즈가 끊어졌다고 생각합니다. (제정신에 대한 가치가 거의 없다면 테이블 형식화 모델인 마법의 la-la-land를 사용해보십시오.)

오픈 소스 프로젝트 문서의 다양한 즐거움...

예를 들어 [*|attr^="value" i] 와 같이 ul > li 보다 훨씬 덜 사소한 것을 예로 들어 보겠습니다. 후자는 기술적으로 단순 선택기로 분류됩니다.

그것은 결합자를 사용하지 않기 때문에 실제로 나에게 의미가 있습니다. 정의를 정확히 따릅니다. 많은 기호를 사용한다고 해서 더 "복잡한" 것은 아닙니다. ul > li 는 두 개의 쿼리 세트, 즉 li 와 일치하는 모든 요소를 ​​쿼리한 다음 ul 포함된 요소를 결정하기 위해 각각의 트리를 탐색하기 때문에 복잡합니다. 후자는 개별 요소를 한 번만 테스트합니다. 하나의 쿼리이므로 간단한 선택기입니다.

복수형 용어 '선택자'는 쉼표로 구분된 집합을 지정하는 공식적인 방법도 아닙니다. 복수형에 대한 엄격하게 올바른 용어는 선택자 목록이라고 생각합니다.

맞습니다. 당신이 맞습니다. "선택기"는 실제로 요소를 선택할 수 있도록 정의된 비트이지만 ul > li > .title 는 "선택기" 단수입니다. 그래서 저는 selector() 가 사실 의미상 더 가깝다고 생각합니다.

@seven-phases-max

quick-n-dirty 플러그인 기능과 관련된 또 다른 사소한 문제가 발생했습니다. 네임스페이스 믹스인의 액세스를 올바르게 처리하지 않습니다. 네임스페이스는 일반 Ruleset 유형 프레임이므로 해당 이름이 선택기에 추가됩니다.

실제 구현은 아마도 그 경우도 다루어야 할 것입니다.

[편집하다]
작동하게 하는 비결은 함수 컨텍스트의 스택에 있는 프레임 중 하나가 MixinDefinition 인지 확인하고 _is_이면 해당 스택의 다음 x 프레임을 건너뛰는 것입니다. 여기서 x 는 MixinDefinition 스택의 프레임 수와 같습니다.

(기본적으로 MixinCall 가 MixinDefinition 실행할 때 스택에 추가되는 '클로저' 프레임을 건너뜁니다.)

"부실" 라벨을 제거했습니다. 이것은 여전히 ​​탐구해야 할 좋은 문제입니다.

아마도 current-selector() 가 그렇게 나쁘지 않을 것입니다. 분명히 말하지만 실제로는 current-selectors() 입니다. 그러나 그것은 여전히 ​​장황합니다. 더 간결한 "capturing &"에 대한 함수 이름을 생각할 수 있다면 더 찬성할 것 같습니다.

더 간결한 "캡처 &"의 함수 이름입니다.

이름을 &() 됩니다. 개념적으로 & 에 있는 것에 대한 getter에 지나지 않습니다.
예

.rule {
  <strong i="11">@selectors</strong> : &();
}

🤔
네, 괜찮습니다. 이의가 있으신가요?

제안된 기능을 이해하고 있는지 확인하기 위해 요약하려고 합니다.

새 함수 &() 는 현재 컨텍스트에서 & 가 출력할 내용을 반환하여 이를 허용합니다.

.component { // I only write "component" once!  Much concise, such DRY!
  <strong i="9">@this</strong>: &();

  /* base styles */

  &_child {
    /* styles for the child */
  }

  &-variant { // component-variant styles all together, and inside the `.component` block
    /* nothing too schmancy so far */
    @{this}_child {
      /* IT'S MAGIC! */
    }
  }
}

그리고 모든 것이 이것을 출력할 것입니다.

.component {
  /* base styles */
}
.component_child {
  /* styles for the child */
}
.component-variant {
  /* nothing too schmancy so far */
}
.component-variant .component_child {
  /* IT'S MAGIC! */
}

놀랍고 사랑하기 때문입니다.

이것에 대해 더 생각해보면, (첫 번째 통과 후, 너무 미쳐버리면 그만) 표준화된 구성 요소 "블록"(규칙 집합) 스타일을 가질 가능성이 가장 매력적이라고 ​​생각합니다. 기본적으로 간단한 선택기 문자열 값을 저장하는 대신 함수가 _" & 매핑되기를 거의 희망하지만 범위에서 변수가 "_에 정의되어 이 작성 스타일을 허용합니다. 구성 요소의 경우(이를 동작 A 라고 합니다):

.component{ <strong i="8">@this</strong>:&();
  /* default styles */
  @{this}_child {
  // ↑ The crucial difference: `@{this}` here behaves _like `&`_, **NOT** like `.component`
    /* child default styles */
  }
}

그런 다음 " & 대신 @this 사용"이라고 말할 수 있습니다.

내 유일한 관심사는 플립 케이스(나는 행동 B 라고 부를 것이다)이지만, 나는 그 행동을 원할 설득력 있는 케이스를 생각할 수 없다. 그것은 누군가가 왜 이것을하고 싶어하는지 알 수 없다는 것입니다.

.foo { <strong i="16">@and</strong>: &();
  @{and} {
    /*stuff meant to live under selector `.foo.foo` */
  }
}

이를 달성하는 현재 방법이 훨씬 더 간결하기 때문입니다(그리고 & 가 어휘에 명확하면 읽기도 가능합니다).

.foo {
  && {
    /*stuff meant to live under selector `.foo.foo` */
  }
}

행동 A보다 행동 B에 대한 설득력 있는 사례(구현 어려움 제외)가 있습니까?

이것은 작업을 시작하기 전에 대답해야 한다고 생각하는 질문 중 하나일 뿐입니다.

TL;DR: 내 투표는 &() 가 동적이기를 위한 것입니다. 즉, 본질적으로 _" & 이지만 정적 값을 반환하는 것이 아니라 더 깊은"_ 대신 여기에 중첩된 것처럼 & 입니다."_

@calvinjuarez 예상 출력을 작성하지 않았기 때문에 예제가 다소 혼란스럽기 때문에 이론적인 영역에서 다소 보이지만 기본적으로는 다음과 같습니다.

.component{
  <strong i="7">@this</strong>: &();  // <strong i="8">@this</strong> is now assigned the value of `.component`
  @{this}_child { a: b; } // this variable, when evaluated, forms the selector .component_child
}
// therefore this output is:
.component .component_child {
  a: b;
}

본질적으로 "&, 그러나 더 깊은 대신 여기에 중첩된 것처럼"을 의미하며, 정적 "현재 & 값"을 반환하지 않습니다.

이게 무슨 뜻인지 정말 이해가 안됩니다.

이것에 대해 생각하는 또 다른 방법. 이것:

.component {
  <strong i="6">@this</strong>: &()
}

작성하는 것과 동일합니다.

.component {
  <strong i="10">@this</strong>: .component;
}

@matthew-dean

예. 그러나 &() 믹스인 호출자의 선택기 컨텍스트를 잡는 믹스인의 렌즈를 통해 생각해 보십시오.

작성자 스스로가 자연스럽게 클래스 이름의 루트를 결정할 수 있는 믹스인 기반 구성 요소를 작성할 수 있습니다. 예를 들어

.my-button {
  #buttons.base();
  #buttons.size( ... );
  #buttons.inset-icon-support( left right );
}

.my-button--wide {
  #buttons.size( ... )
}

.my-button--condensed {
  #buttons.size( ... )
}

거기에 사용된 믹스인은 &() 를 통해 클래스를 읽고 적절하게 출력에 사용할 수 있습니다. 예를 들어 두 번째 및 세 번째 규칙에 대해 캡처된 선택기는 BEM 구문을 분해하여 기본 블록 클래스를 얻을 수 있으며, 이는 중첩 요소 선택기에 대한 재정의를 생성하는 데 사용할 수 있습니다.

그건; 매개변수로 선택기 이름을 전달할 필요 없이 .my-button--wide > .my-button__text 와 같은 선택기를 생성하는 데 사용할 수 있습니다. 수신자 선택기 컨텍스트에서만.

이와 같은 믹스인 기반 _컴포넌트 팩토리_는 스타일링 프레임워크를 사용할 때 발생하는 모든 문제를 피할 수 있습니다. 프레임워크를 등록할 수 있지만 실제로 통합하려는 구성 요소와 이름을 세부적으로 선택할 수 있습니다.

@rjgotten

거기에 사용된 믹스인은 &()를 통해 클래스를 읽고 적절하게 출력으로 작업할 수 있습니다. 예를 들어 두 번째 및 세 번째 규칙에 대해 캡처된 선택기는 BEM 구문을 분해하여 기본 블록 클래스를 얻을 수 있으며, 이는 중첩 요소 선택기에 대한 재정의를 생성하는 데 사용할 수 있습니다.

네, 알겠습니다. 아마도 믹스인에서 가장 유용할 것입니다. 직접 선택기 이름을 사용하는 것보다 &() 의 유틸리티를 확실히 얻었습니다. 내 요점은 주어진 예제에서 &() 의 값을 명확히 하려는 것이었습니다.

더 나아가서, 나는 그것이 좋은 구문적 솔루션이라고 생각하고, 누군가가 그것을 받아들이고 싶어한다면 &() 구현으로 앞으로 나아가는 데 개인적으로 👍 를 주고 싶습니다.

@matthew-dean

예상 출력을 작성하지 않았기 때문에 예제가 다소 혼란스럽습니다.

죄송합니다. 제대로 다시 설명하겠습니다. Less here가 아래 CSS로 컴파일되면 &() 가 더 강력한 기능이 될 것 같습니다.

.component { <strong i="10">@this</strong>:&();
  /* default styles */
  @{this}_child {
  // ↑ The crucial difference: `@{this}` here behaves _like `&`_, **NOT** like `.component`
  // (since it's in the same rule block and scope level).
    /* child default styles */
  }
}

.component {
  /* default styles */
}
.component_child {
  /* child default styles */
}

경우 <strong i="15">@this</strong>:&(); 단지 같은 동작합니다 <strong i="17">@this</strong>:.component; 이 경우, 우리는 유지 mixin 내부 유틸리티 _only_이 기능을 이관하고 있지만 내가 생각하는 것이 더 제공합니다.

본질적으로 "&, 그러나 더 깊은 대신 여기에 중첩된 것처럼"을 의미하며, 정적 "현재 & 값"을 반환하지 않습니다.

이게 무슨 뜻인지 정말 이해가 안됩니다.

.thing{ & {} } 와 .thing{ <strong i="11">@amp</strong>:&(); @{amp} {} } 가 같은 출력을 내야 한다고 생각합니다.

즉, 보다 실질적으로 쉬운 BEM을 수행하기 위해 mixin을 작성할 필요가 없지만 인라인으로 정의할 수 있습니다. 이전 예 중 하나로 돌아가서:

_component.less_

.component { // I only write "component" once!  Much concise, such DRY!
  <strong i="16">@this</strong>: &();

  /* base styles */

  @{this}_child {
    /* styles for the child */
  }

  @{this}-variant { // component-variant styles all together, and inside the `.component` block
    /* nothing too schmancy so far */
    @{this}_child {
      /* IT'S MAGIC! */
    }
  }
}

↓↓↓

_component.css_

.component {
  /* base styles */
}
.component_child {
  /* styles for the child */
}
.component-variant {
  /* nothing too schmancy so far */
}
.component-variant .component_child {
  /* IT'S MAGIC! */
}

이점: & 또는 @{this} 를 의미하는지 팀에 물어볼 필요가 없습니다. "어디서나 @{this} 하세요."라고 말하면 됩니다.

실제로 컴포넌트 팩토리 믹스인 정의를 내부적으로도 일관성 있게 만들 것입니다.

_hypothetical-button-mixin.less_

#button () {
  .size(large) { <strong i="7">@button</strong>: &();
    @{button} { // same scope, so it behaves _exactly_ like `&`.
      font-size: 1.8rem;
    }
    @{button}-primary { // same scope, so it behaves _exactly_ like `&`.
      border-width: 5px;
      @{button}_icon { // nested scope, behaves like the parent selector at the mixin call (.btn).
        height: 1.8rem;
        width:  1.8rem;
      }
    }
  }
}
// ...

_가상 스타일.less_

.btn {
  #button.size(large);
}

_hypothetical-styles.css_

.btn {
  font-size: 1.8rem;
}
.btn-primary {
  border-width: 5px;
}
.btn-primary .btn_icon {
  height: 1.8rem;
  width:  1.8rem;
}

.thing{ & {} } 및 .thing{ @amp :&(); @{amp} {} }는 동일한 출력을 생성해야 합니다.

예, 우리가 같은 것을 말하고 있다고 생각하지만 이 예를 통해 확인하겠습니다. 이것이 내가 이 기능과 제자리 & 입니다.

.mixin() {
  <strong i="10">@this</strong>: &();
  .a {
    .b @{this} { c: d; }
  }
}
.component {
  .mixin();
}

// outputs:
.component .a .b .component {
  c: d;
}

반면:

.mixin() {
  .a {
    .b & { c: d; }
  }
}

생산할 것:

.b .component .a {
  c: d;
}

@calvinjuarez 나는 아무도 당신의 예와 다른 것을 제안하지 않았다고 생각하기 때문에 혼란 스러웠습니다. &() 는 기본적으로 해당 위치에서 this.selectors.toCSS() 되는 것과 같습니다( 실제로는 아니지만 설명을 위해 .... 실제로 가장 빠른 방법일 수 있음). 그런 다음 선택기로 다시 평가할 다른 위치에 해당 문자열을 삽입합니다.

@matthew-dean
모든 목록 구성원을 기반으로 선택기를 확장하기 위한 특별한 동작을 포함하여 선택기 목록을 실제 선택기 목록으로 노출하면 실제로 _더_더_ 굉장할 것입니다.

예를 들어

.a, .b {
  <strong i="8">@this</strong> : &();

  @{this} {
    c : d;  
  }
}

산출

.a .a,
.a .b,
.b. .a,
.a .b {
  c : d
}

네이티브 & 처럼.

네, 정확히 그렇게 될 것입니다. 3.5에서 선택기에서 평가된 모든 변수로 인해 전체 선택기 목록이 새 선택기 목록으로 다시 구문 분석됩니다. 예, 예상대로 작동합니다. 최근에 내가 한 몇 가지 PR 때문에 실제로 매우 쉽습니다.

2018년 7월 7일 오전 10시 34분에 rjgotten [email protected]에서 다음과 같이 썼습니다.

@matthew-dean
모든 목록 구성원을 기반으로 선택기를 확장하는 특수 동작을 포함하여 선택기 목록을 실제 선택기 목록으로 노출하면 실제로 훨씬 더 멋질 것입니다.

예를 들어

.a, .b {
@이 : &();

@{이것} {
CD;
}
}
산출

.a .a,
.a.b,
.비. .ㅏ,
.a .b {
CD
}
네이티브 & will처럼.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

.component{
 <strong i="6">@this</strong>: &();  // <strong i="7">@this</strong> is now assigned the value of `.component`
 @{this}_child { a: b; } // this variable, when evaluated, forms the selector .component_child
}
// therefore this output is:
.component .component_child {
 a: b;
}

추가 .component 는 내가 반대하는 것입니다. 다음과 같이 작동해야 한다고 제안합니다.

less .component{ <strong i="12">@this</strong>: &(); // <strong i="13">@this</strong> is now assigned the value of `.component < &` @{this}_child { a: b; } // this variable evaluates like `&_child` } // therefore this output is: .component_child { // < Note: `.component_child` !== `.component .component_child` a: b; }

하지만 기능이 다른 방향으로 가고 있는 것 같습니다. 그냥 내 입장을 밝히고 싶었다.

다음과 같이 작동해야 한다고 제안합니다.

즉, 일반 _string_ 대신 _selector list_인 선택기에 대체 토큰이 있는 경우 대체 토큰은 & 가 지정되고 중첩으로 인해 발생하는 일반 선택기 연결을 _비활성화_하는 것과 동일하게 작동합니다.

&() 가 실제 선택자 목록으로 식별할 수 있도록 하는 노드 유형을 출력하는 경우 해당 동작은 비교적 쉽게 달성할 수 있다고 생각합니다.

사실, 전용 노드 유형을 출력하는 경우 나중에 캡처된 선택기 목록을 _조작_하기 위한 플러그인 기능 생성을 지원할 수도 있습니다.

나에게 그것은 &()가 한 번에 너무 많은 일을 하게 만드는 것처럼 들립니다. 선택자를 변수에 저장하기를 원하면 한 가지이지만 _content_ 때문에 해당 변수가 선택기 연결을 비활성화하도록 하는 것은 구문에서 명확하지 않습니다. 그 변수는 어디에서나 올 수 있으며(예: mixin에서 전달) 선택기 목록은 간단한 변수 할당으로 생성할 수 있습니다. 즉, 변수 사용에서 변수의 내용에 따라 다른 연결 동작이 발생하는지 명확하지 않습니다.

체이닝을 비활성화하려면 암시적 &를 다음과 같은 다른 값으로 바꾸도록 지정해야 한다고 생각합니다.

.요소 {
@var : &();
&(@var)_child {} // 또는 "&의 대체" 구문과 같은 일부
}

그래서 결과가 바람직한 이유를 알지만 IMO에서는 선택기 목록의 출처를 기반으로 하는 변수 병합 동작을 "매직 스위치"할 수 없습니다. 이를 위해서는 두 가지 다른 기능이 필요합니다.

오... 난 사실 &(...) 좋아해...

하, 정말? &() (&에서 선택기 캡처) 및 &(@arg) ( &를 선택기로 대체)의 의미상 혼동이 있을 것이라고 생각하지 않습니까?

누군가가 & 를 기본적으로 버리기 위해 빈 선택기로 대체하려고 할 수 있으므로 혼합하지 않는 것이 좋습니다. (루트에 자식을 배치하기 위해.) 아마도 &(“”) .child가 될 수 있다고 생각하지만?

잘 모르겠습니다. 약간의 생각/고려가 필요합니다.

또한 "상위 선택자는 대상이 있어야 함" 스레드에서 언급했듯이 상속된 선택자의 특정 부분(또는 전체)을 대체하는 사용 사례가 있으므로 이를 생각하면 두 가지 개별 문제로 추적해야 한다고 생각합니다. 이 문제는 캡처 및

이 원을 닫기 위해 여기에서 함수와 유사한 구조로 & 를 제자리에서 변경하는 것을 언급했습니다. - https://github.com/less/less.js/issues/1075#issuecomment -397697714

따라서 " & 상속을 변경하는 방법/여부"에 대한 토론이 상위 선택자 스레드에 남아 있고 이 스레드는 <strong i="9">@var</strong>: &() 가 - & 선택기를 변수에 배치합니다. 내 생각에는 다른 스레드에도 불구하고 여전히 괜찮은 것 같습니다. 둘 다 할 수 있는 기회가 있는지 없는지 잘 모르겠습니다.

나는 이것을 하려고 노력하고 있다

.html, .css, .js, .php, .mysql, .jquery, .txt, .java {
    <strong i="6">@html</strong>: '\f2d0';
    <strong i="7">@css</strong>: '\f034';
    <strong i="8">@js</strong>: '\f121';
    <strong i="9">@php</strong>: '\f120';
    <strong i="10">@mysql</strong>: '\f1c0';
    <strong i="11">@jquery</strong>: '\f78c';
    <strong i="12">@java</strong>: '\f11b';
    <strong i="13">@txt</strong>: '\f15c';
    &:before {
        content+_: @&;
    }
}

하지만 이것이 구현될 때까지는 작동하지 않을 것입니다.