Less.js: चयनकर्ता को एक चर में सहेजा जा रहा है

उत्सुकता से मुझे पूरा यकीन था कि ऐसा अनुरोध पहले से मौजूद है। जाहिर तौर पर ऐसा नहीं है।
(हालांकि स्पष्ट रूप से यह विचार पहले कई टिकटों में दिखाई दिया था: #1174, https://github.com/less/less.js/issues/1075#issuecomment-16891103 आदि)
तो ऐसा होने दो मुझे लगता है।

बीटीडब्ल्यू।, बस मामले में (और संभावित 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() ... हम्म, अब जो मुझे एक सामान्य PseudoFunction प्रकार को कोड करने के विचार में लाता है ताकि प्रत्येक छोटे गुडी के एपीआई को प्रदूषित न किया जा सके, ओह! :)।

मुझे पता है कि भाषा में नई चीजें जोड़ने में एक सामान्य झिझक है, लेकिन एक चयनकर्ता विनिर्देशक आसान हो सकता है। मुझे | , हालांकि यह CSS @namespace चयनकर्ता सिंटैक्स का हिस्सा है । हालांकि, ऐसा नहीं लगता है कि | को एक चयनकर्ता को _start_ करने की अनुमति है, इसलिए इसमें विरोध नहीं होना चाहिए। मैं इसका उपयोग कर रहा हूं क्योंकि यह मुझे गणित के "पूर्ण मूल्य" की याद दिलाता है जो अस्पष्ट रूप से उपयुक्त लगता है, और 'क्योंकि यह आसान है। बातचीत को प्रेरित करने के लिए बस एक विचार।

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 ट्री नोड का।

जब _any_ चर वाले Selector प्रकार के ट्री नोड को एक चयनकर्ता में प्रक्षेपित किया जाता है, जैसे कि उदाहरण में @{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} काफी कृत्रिम लगता है, ऐसा नहीं है कि ये चीजें कम में कैसे काम करती हैं। ... { & div ... और ... { div ... हमेशा समान कथन थे। इसके अलावा, यहां तक कि इस गिनती नहीं, क्या मैं अगर मैं जरूरत करूँ a b x, #y a b .z के साथ x, #y * .z कहीं परिभाषित?

मैं चयनकर्ताओं के लिए फ़ंक्शन-जैसी संरचना का प्रशंसक नहीं हूं। हालांकि मैं विरासत में मिले चयनकर्ताओं को संदर्भित करने, संशोधित करने या परिवहन (चर और पुन: उपयोग के लिए असाइन) करने में सक्षम होने का समर्थन करता हूं।

बस यह सुनिश्चित करने के लिए, हालांकि, यह कितना #1075 (अभिभावक चयनकर्ताओं को लक्षित करना) पर भिन्नता है या https://github.com/less/less-meta/issues/16#issuecomment -292679320 (असाइनिंग) के साथ संभावित विरोध में है एक चर के लिए एक चयनकर्ता)? या यह एलियासिंग मिक्सिन से अलग है क्योंकि यह एक चयनकर्ता सूची है और एक भी मूल्यांकन चयनकर्ता (या मिक्सिन) नहीं है, और आउटपुट चयनकर्ता सूची है और मूल्यांकन नियम नहीं है? मुझे लगता है कि यह सुविधा अलग है; मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि ये सभी एक ही दिशा में आगे बढ़ रहे हैं।

@ मैथ्यू-डीन
यह वास्तव में वास्तविक चयनकर्ता सूची को कैप्चर करने के बारे में है, न कि मूल्यांकन किए गए नियमों को कैप्चर करने के बारे में, और आगे उपयोग के लिए उक्त सूची को आउटपुट करने के बारे में है।

कोई भी extract(list,index) जैसे फ़ंक्शन की कल्पना कर सकता है जिसे चयनकर्ता सूची से चयनकर्ता घटकों को निकालने में सक्षम होने के लिए अद्यतन किया जा सकता है और चयनकर्ताओं के साथ काम करने में आसानी के लिए इसी तरह के संवर्द्धन, जैसे कि उपयोगकर्ता आसानी से दिलचस्प तरीकों से उनमें हेरफेर कर सकते हैं। उदाहरण के लिए, बीईएम जैसी कुछ नामकरण योजनाओं का पालन करने वाले घटकों के लिए।

उदाहरण के लिए एक मिश्रण दिया गया

.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);
}

सीएसएस उत्पन्न करता है

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

Sass के पास, afaik, यह लंबे समय से था और इस तकनीक के कई उदाहरण बहुत ही चतुर उपयोग में लाए जा रहे हैं। कोड कारखानों में जैसे मेरे उदाहरण में, या अन्य उद्देश्यों के लिए।

से संबंधित:

कम/कम-मेटा#16 (टिप्पणी) के साथ संभावित संघर्ष (एक चर के लिए एक चयनकर्ता असाइन करना)

व्यक्तिगत रूप से मैं निम्नलिखित व्यवहार मानता हूं:
"ट्रिविअल" चयनकर्ता मान (जैसे .mixin , .ns.mixin , #foo .bar , baz आदि, सौभाग्य से इसमें कुछ भी शामिल है जिसे मिक्सिन/फ़ंक्शन के रूप में उपयोग/परिभाषित किया जा सकता है ) सीधे एक चर (या कार्य करने के लिए पैरामीटर के रूप में पारित) को सौंपा गया है। यानी हमारे पास वास्तव में यह पहले से ही है:

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

^इसका (अनिवार्य रूप से) चयनकर्ताओं से कोई लेना- देना @var(...) साथ कॉल/eval करने का प्रयास करते हैं या @var[...] बयान
(आम तौर पर तार्किक परंपरा यह भूल जाती है कि मिक्सिन आइडेंटिफ़ायर (आंतरिक रूप से प्रतिनिधित्व) चयनकर्ता हैं, लेकिन हमेशा उन्हें केवल डॉट या # उपसर्ग के साथ पहचानकर्ता के रूप में सोचने के लिए, और .ns > .mixin जैसी चीजें अंततः बेमानी और बेकार के रूप में फीका :)

जबकि एक जटिल या "वास्तविक" चयनकर्ताओं को सिंटैक्स/पार्सर अस्पष्टता के कारण selector छद्म फ़ंक्शन की आवश्यकता होती है। यानी चीजें जैसे:

• <strong i="29">@var</strong>:foo>bar <- चयनकर्ता और (संभावित रूप से) एक तार्किक अभिव्यक्ति
• <strong i="32">@var</strong>:.1+.2; <- अंकगणित अभिव्यक्ति और मान्य कम चयनकर्ता
  (आदि। अच्छी तरह से सभी विशिष्ट चयनकर्ता प्रतीकों को याद करें - मूल्य पार्सिंग संदर्भ में कुछ के साथ लगभग हर संघर्ष, और यह तब और भी नाटकीय हो जाता है जब उपरोक्त मान संभावित रूप से किसी फ़ंक्शन/मिक्सिन को पैरामीटर के रूप में पास किए जाते हैं, उदाहरण के लिए निम्नलिखित असंभव है w/o 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" );

ईमानदार होने के लिए, यह "इनलाइन जावास्क्रिप्ट और लेसहैट-जैसी हैकरी" का पुनर्जन्म जैसा दिखता है, इसे प्रतिबंधित नहीं किया जा सकता है, लेकिन इसके खिलाफ आक्रामक रूप से विज्ञापन किया जाएगा।
(यह गिनती नहीं है कि उदाहरण बहुत दुर्भाग्यपूर्ण है <- लाइनों की गणना करें) मैं कुछ less-plugin-bem-selectors चीज़ का सुझाव दूंगा (जहां आप केवल get-block-name फ़ंक्शन प्राप्त कर सकते हैं, बीटीडब्ल्यू। यहां तक ​​​​कि w/o & फीचर) इस तरह के बदसूरत रेगेक्स के बजाय ("एक सीएसएस प्रीप्रोसेसर का एक मनमाना टेक्स्ट प्रोसेसर के रूप में उपयोग करना" दृष्टिकोण अंततः पोस्टसीएसएस जैसी सामग्री के अंत में बुरी तरह से ढीला हो जाएगा)।

और & बनाम context-saving-& वापस आना, अब तक मुझे डर है कि मेरे पास फ़ंक्शन के लिए समर्पित ध्वज से बेहतर कोई विचार नहीं है, उदाहरण के लिए selector(..., lazy or not) , या यहां तक ​​​​कि दो अलग कार्य। या other-than-&-keyword (जैसे ₸ ) का उपयोग कर रहे हैं। बस बिंदु-मूल्यांकन अस्पष्टता को स्वचालित रूप से हल करने के लिए कोई सुरक्षित तरीका नहीं देख सकता।

मैं इसके बजाय कुछ less-plugin-bem-selectors चीज़ का सुझाव देना चाहूँगा

बिल्कुल। रेगेक्स-आधारित निष्कर्षण केवल एक उदाहरण प्रदान करने के लिए था जिसमें कस्टम फ़ंक्शन शामिल नहीं थे। ;)

मैं चयनकर्ताओं के लिए फ़ंक्शन-जैसी संरचना का प्रशंसक नहीं हूं।

इसके अलावा, यदि आपका मतलब केवल यह है कि यह कैसा दिखता है ... यह निश्चित रूप से कुछ अन्य निर्माण हो सकता है, उदाहरण के लिए ⁞#foo:not(.bar)⁞ , लेकिन आप जानते हैं कि हमारे पास पहले से ही मुफ्त प्रतीकों से बाहर हो गए हैं। तो छद्म फ़ंक्शन सिंटैक्स केवल इसलिए सुझाया गया है क्योंकि हमारे पास पहले से ही url साथ ऐसी अवधारणा है (इस प्रकार चीजों के बारे में सोचने की कोई आवश्यकता नहीं है एक नई अवधारणा टूट सकती है या टूट जाएगी)।

अब, मजेदार हिस्सा।

मैंने current-selector फ़ंक्शन का एक त्वरित और गंदा प्लगइन कार्यान्वयन बनाया (बस यह देखने के लिए कि यह कितना ब्लोटिंग हो सकता है, उम्मीद है कि यह निश्चित रूप से var आलसी-मूल्यांकन के कारण बहुत उपयोगी नहीं हो सकता है), और क्या पता? यह मूल उदाहरण:

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() जैसे कुछ का उपयोग करेंगे) हालांकि फ़ंक्शन को नहीं करना चाहिए कोई पैरामीटर है अन्यथा यह आलसी-मूल्यांकन हो जाता है (यदि एक चर पारित किया जाता है) - यह दुखद है क्योंकि मैंने शुरुआत में इसे चार रखने की योजना बनाई थी :)।
काफी अपमानजनक लेकिन वर्कअराउंड/पॉलीफिल के रूप में काम कर सकता है। एक और वास्तविक उदाहरण वांछित के रूप में भी काम करता है:

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;
        }
    }
}

यानी बाद के वेरिएबल असाइनमेंट/फ़ंक्शन कॉल प्रारंभिक चर के मूल्यांकन-बिंदु को प्रभावित नहीं करते हैं।

@ सात-चरण-अधिकतम
इसे प्यार करना।

भले ही आलसी-मूल्यांकन वर्तमान में एक पैरामीटर तर्क मौजूद होने पर कार्यों में एक स्पैनर फेंकता है, _that_ संभवतः कुछ ऐसा है जिसे 'वास्तविक' कार्यान्वयन के लिए चारों ओर काम किया जा सकता है।

इसके अलावा, यदि आपका मतलब केवल यह है कि यह कैसा दिखता है... यह निश्चित रूप से कुछ अन्य निर्माण हो सकता है, उदाहरण के लिए # foo:not (.bar)⁞, लेकिन आप जानते हैं कि हमारे पास पहले से ही मुफ्त प्रतीकों से बाहर हो गए हैं।

काफी उचित। मैंने वास्तव में इस बारे में अपने दिमाग को उपयोग के रूप में लपेटा नहीं है और न ही मेरे पास कोई बेहतर विचार है। मुझे लगता है कि इसमें कुछ खास लग रहा था, लेकिन शायद नहीं। मुझे पता है कि किसी समय $() बारे में चर्चा हुई थी, लेकिन हमने $ करना समाप्त कर दिया। बीटीडब्ल्यू, क्या यह selectors() नहीं होगा और selector() ? क्या यह (जैसे & ) में चयनकर्ताओं की संख्या नहीं हो सकती है?

और ऐसा लगता है कि selector(&) current-selector() से अधिक समझ में आता है। वह है: "एक्स ऑब्जेक्ट से चयनकर्ता सूची बनाएं, चाहे वह & या एक स्ट्रिंग हो"। जो कुछ भी अंतिम वाक्य रचना है ऐसा लगता है कि यह एक तर्क के रूप में & लेगा।

और ऐसा लगता है जैसे selector(&) current-selector() से अधिक समझ में आता है

ये अलग चीजें हैं। current-selector बस के एक समारोह संस्करण है & (उत्तरार्द्ध के बाद से पार्सर द्वारा समर्थित नहीं है)। जबकि selector(...) एक मनमाना चयनकर्ता (सहित & ) का समर्थन करने के लिए पार्सर के लिए वह पैच है।

selectors - ठीक है, यह है। लेकिन चूंकि यह एकल चयनकर्ता उपयोग-मामलों का 99% है, मुझे लगता है कि अधिकांश उपयोगकर्ताओं के लिए एक बहुवचन रूप कम स्पष्ट होगा (अधिकांश में, वे आमतौर पर h1, h2, h3 {} एक चयनकर्ता के रूप में शीर्षक देते हैं और कम माता-पिता चयनकर्ता की बात करते रहते हैं (यहां तक ​​​​कि अगर यह के चयनकर्ता रों) :) तो क्यों परेशान?

आह अच्छा।

@ मैथ्यू-डीन
बहुवचन और एकवचन रूप किसी के लिए भी बहुत अधिक विनिमेय है, लेकिन CSS कल्पना लेखक। वास्तव में, इसे बनाएं: विशिष्ट लेखकों सहित किसी के लिए, यहां तक ​​​​कि सीएसएस चश्मा भी कभी-कभी एकवचन और बहुवचन रूप के परस्पर उपयोग के शिकार हो जाते हैं।

बहुत मज़ाकिया ढंग से; बहुवचन शब्द 'चयनकर्ता' अल्पविराम से अलग किए गए सेट को नामित करने का आधिकारिक तरीका भी नहीं है। बहुवचन रूप के लिए कड़ाई से सही शब्दावली है, मेरा मानना ​​​​है कि, एक _selector list_।

तो आप देख सकते हैं कि यह अस्पष्ट संदर्भ वास्तव में कितना गहरा है।

बहुवचन रूप के लिए कड़ाई से सही शब्दावली, मेरा मानना ​​है, एक चयनकर्ता सूची है।

हाँ, मैंने कल w3c भी खोजा था, यह "चयनकर्ताओं का समूह", "चयनकर्ताओं की एक सूची" आदि है, वास्तव में अजीब की तरह कुछ भी फैंसी नहीं है "एक चयनकर्ता संयोजकों द्वारा अलग किए गए सरल चयनकर्ताओं के एक या अधिक अनुक्रमों की एक श्रृंखला है" वे भी वहाँ है :) "चयनकर्ता प्रकार" चीज़ का वर्णन करने के लिए बस "चयनकर्ता" फॉर्म का उपयोग ज्यादातर वहां किया जाता है।

"एक चयनकर्ता संयोजकों द्वारा अलग किए गए साधारण चयनकर्ताओं के एक या अधिक अनुक्रमों की एक श्रृंखला है"

और यह सोचने वाले किसी भी व्यक्ति के लिए जो अल्पविराम से अलग की गई सूचियों का संदर्भ दे सकता है: ऐसा नहीं है। उस उद्धरण का पूर्ण रूप होना चाहिए: "एक _complex_ चयनकर्ता संयोजकों द्वारा अलग किए गए सरल चयनकर्ताओं के एक या अधिक अनुक्रमों की एक श्रृंखला है।"

सीएसएस स्पेक्स में एक और समस्या है जहां "चयनकर्ता" के सामान्यीकृत रूप का उपयोग ज्यादातर यह संदर्भित करने के लिए किया जाता है कि चश्मा आधिकारिक तौर पर _complex चयनकर्ताओं_ को क्या कहते हैं। जटिल चयनकर्ता सरल चयनकर्ता होते हैं, जैसे tag ; #id ; .class ; [attr] ; आदि , संयोजकों के माध्यम से जंजीर, जैसे > ; + ; ~ , आदि।

ul > li जैसी किसी चीज़ को जटिल चयनकर्ता कहा जाता है।

चेतावनी निम्नलिखित एक शेख़ी का एक सा होगा:

सीएसएस चश्मा दुख की बात है कि असंगत और गलत नाम वाली शब्दावली का एक दलदल है। आप जितना पीछे जाते हैं, यह उत्तरोत्तर बदतर होता जाता है। यह मदद नहीं करता है कि CSS3 मॉड्यूल का भार CSS 2.1 मॉड्यूल का संदर्भ देता रहता है या यह कि नए CSS3 मॉड्यूल को उनके पुराने CSS 2.1 दस्तावेज़ों को शब्दशः कॉपी करके निर्दिष्ट किया गया था। हालांकि चयनकर्ताओं के लिए चश्मा और दृश्य स्वरूपण मॉडल सबसे खराब अपराधी हैं; इतना अस्पष्ट, समान-ध्वनि वाला या सादा खराब नाम वाली शब्दावली।

उदाहरण के लिए ul > li से बहुत कम तुच्छ कुछ लें, जैसे कि [*|attr^="value" i] । उत्तरार्द्ध को तकनीकी रूप से एक साधारण चयनकर्ता के रूप में वर्गीकृत किया गया है। (हाँ सच।)

मुझे कुछ साल पहले एक बिंदु पर अपने एक और डिज़ाइन-उन्मुख सहयोगी को बाद के दृश्य स्वरूपण मॉडल स्पेक के कुछ हिस्सों को आजमाने और समझाने की ज़रूरत थी। मुझे लगता है कि कुछ फ़्यूज़ वास्तव में हमारे दिमाग में _दोनों_ उड़ा दिए गए थे जब हम उन अंशों पर गए जो लाइन बॉक्स की अवधारणा का इलाज करते हैं और यह इसका सबसे खराब हिस्सा भी नहीं था। (जादुई ला-ला-लैंड में चलने की कोशिश करें, जो कि टेबल फॉर्मेटिंग मॉडल है, अगर आपके पास अपनी पवित्रता के लिए बहुत कम मूल्य है।)

ओपन सोर्स प्रोजेक्ट्स प्रलेखन की कई गुना खुशियाँ ...

उदाहरण के लिए ul > li से बहुत कम तुच्छ कुछ लें, जैसे कि [*|attr^="value" i] । उत्तरार्द्ध को तकनीकी रूप से एक साधारण चयनकर्ता के रूप में वर्गीकृत किया गया है

यह वास्तव में मुझे समझ में आता है, लॉल, सिर्फ इसलिए कि यह एक संयोजक का उपयोग नहीं करता है। यह ठीक परिभाषा का पालन करता है। सिर्फ इसलिए कि यह बहुत सारे प्रतीकों का उपयोग करता है, इसे और अधिक "जटिल" नहीं बनाता है। ul > li जटिल है क्योंकि इसमें प्रश्नों के दो सेट शामिल हैं यानी li मेल खाने वाले सभी तत्वों के लिए पूछताछ करना और फिर प्रत्येक से पेड़ को यह निर्धारित करने के लिए कि कौन सा ul साथ निहित है। उत्तरार्द्ध केवल एक बार व्यक्तिगत तत्वों का परीक्षण करता है। यह एक प्रश्न है इसलिए यह एक साधारण चयनकर्ता है।

बहुवचन शब्द 'चयनकर्ता' अल्पविराम से अलग किए गए सेट को नामित करने का आधिकारिक तरीका भी नहीं है। बहुवचन रूप के लिए कड़ाई से सही शब्दावली, मेरा मानना ​​है, एक चयनकर्ता सूची है।

सही, तुम सही हो। "चयनकर्ता" वास्तव में केवल परिभाषित बिट्स हैं जो आपको तत्वों का चयन करने की अनुमति देते हैं, लेकिन ul > li > .title एक "चयनकर्ता" एकवचन है। तो मुझे लगता है कि selector() वास्तव में, शायद शब्दार्थ के करीब है।

@ सात-चरण-अधिकतम

क्विक-एन-डर्टी प्लगइन फ़ंक्शन के साथ बस एक और मामूली समस्या में भाग गया: यह किसी नेमस्पेस्ड मिक्सिन से एक्सेस को सही तरीके से हैंडल नहीं करता है। नेमस्पेस एक नियमित Ruleset प्रकार का फ्रेम है और इस प्रकार उनका नाम चयनकर्ताओं में जोड़ा जाता है।

एक वास्तविक कार्यान्वयन शायद उस मामले को भी कवर करना चाहिए।

[संपादित करें]
इसे काम करने की चाल यह जांचना है कि फ़ंक्शन संदर्भ के स्टैक पर फ़्रेमों में से एक MixinDefinition और यदि यह _is_ है, तो उस स्टैक पर अगले x फ़्रेम को छोड़ दें, जहां x MixinDefinition के स्टैक पर फ़्रेम की मात्रा के बराबर है।

(मूल रूप से, यह 'क्लोजर' फ्रेम को छोड़ देता है जो स्टैक में जोड़े जाते हैं जब MixinCall MixinDefinition निष्पादित करता है।)

"बासी" लेबल हटा दिया। यह अभी भी पता लगाने के लिए एक अच्छा मुद्दा है।

शायद current-selector() इतना बुरा नहीं है। हालांकि, स्पष्ट होने के लिए, यह वास्तव में current-selectors() । लेकिन यह अभी भी थोड़ा वर्बोज़ है। मुझे लगता है कि अगर हम "कैप्चरिंग &" के लिए एक फ़ंक्शन नाम के बारे में सोच सकते हैं तो मैं अधिक पक्ष में होगा जो कि अधिक संक्षिप्त है।

"कैप्चरिंग और" के लिए फ़ंक्शन नाम जो अधिक संक्षिप्त है।

बस इसे &() नाम दें। यह अवधारणात्मक रूप से & में जो कुछ भी है उसके लिए गेटटर से ज्यादा कुछ नहीं है।
उदाहरण के लिए

.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! */
}

क्योंकि यह अद्भुत है, और मुझे यह पसंद है।

इसके बारे में और अधिक सोचते हुए, मुझे लगता है कि मेरे लिए सबसे अधिक सम्मोहक (पहले-पास के बाद; अगर मैं बहुत अधिक पागल हो रहा हूं तो मुझे रोकें) एक मानकीकृत घटक "ब्लॉक" (नियमसेट) शैली होने की संभावना होगी। मूल रूप से, मुझे उम्मीद है कि एक साधारण चयनकर्ता स्ट्रिंग मान सहेजे जाने के बजाय, फ़ंक्शन _" & मैप करेगा, लेकिन दायरे में चर को "_" में परिभाषित किया गया था, जो इस संलेखन शैली की अनुमति देगा एक घटक के लिए (मैं इसे व्यवहार ए कहूंगा):

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

तब मैं कह सकता था " @this बजाय हर जगह & "।

मेरी एकमात्र चिंता फ्लिप केस होगी (जिसे मैं व्यवहार बी कहूंगा), लेकिन मैं एक आकर्षक मामले के बारे में नहीं सोच सकता जहां मुझे वह व्यवहार चाहिए। यही कारण है कि मैं नहीं देख सकता कि कोई ऐसा क्यों करना चाहेगा।

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

क्योंकि इसे पूरा करने का वर्तमान तरीका _much_ अधिक संक्षिप्त है (और पढ़ने योग्य भी, एक बार & आपकी शब्दावली में स्पष्ट हो जाता है)।

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

क्या व्यवहार ए पर व्यवहार बी के लिए एक सम्मोहक मामला (कार्यान्वयन में कठिनाई के अलावा) है?

यह उन प्रश्नों में से एक है जो मुझे लगता है कि काम शुरू होने से पहले उत्तर दिया जाना चाहिए।

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;
}

@ मैथ्यू-डीन

हां। लेकिन इसके बारे में मिक्सिन्स के लेंस के माध्यम से सोचें, जहां &() मिक्सिन कॉलर के चयनकर्ता संदर्भ को पकड़ लेगा।

यह मिक्सिन-आधारित घटकों को लिखने में सक्षम बनाता है जहां लेखक स्वयं स्वाभाविक रूप से वर्गनाम की जड़ पर स्वतंत्र रूप से निर्णय ले सकते हैं। जैसे दिया गया

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

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

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

वहां इस्तेमाल किए गए मिश्रण कक्षा को &() माध्यम से पढ़ सकते हैं और इसे अपने आउटपुट में उचित रूप से काम कर सकते हैं। उदाहरण के लिए दूसरे और तीसरे नियमों के लिए कब्जा कर लिया चयनकर्ता बेस ब्लॉक क्लास प्राप्त करने के लिए बीईएम सिंटैक्स को विघटित कर सकता है, जिसका उपयोग नेस्टेड तत्व चयनकर्ताओं के लिए ओवरराइड उत्पन्न करने के लिए किया जा सकता है।

अर्थात्; इसका उपयोग किसी भी चयनकर्ता नाम को पैरामीटर के रूप में पारित किए बिना .my-button--wide > .my-button__text जैसे चयनकर्ता को उत्पन्न करने के लिए किया जा सकता है। केवल कैली चयनकर्ता संदर्भ से ही।

मिक्सिन-आधारित _घटक कारखाने_ इस तरह स्टाइलिंग ढांचे का उपयोग करने के साथ आपको मिलने वाली सभी-या-कुछ भी हमारी-या-राजमार्ग की कई समस्याओं से बचते हैं। वे आपको ढांचे को पंजीकृत करने की अनुमति देते हैं, लेकिन बारीक रूप से चुनें कि आप किन घटकों को वास्तव में शामिल करना चाहते हैं और किस नाम के तहत।

@rjgotten

वहां इस्तेमाल किए गए मिश्रण कक्षा को &() के माध्यम से पढ़ सकते हैं और इसे अपने आउटपुट में उचित रूप से काम कर सकते हैं। उदाहरण के लिए दूसरे और तीसरे नियमों के लिए कब्जा कर लिया चयनकर्ता बेस ब्लॉक क्लास प्राप्त करने के लिए बीईएम सिंटैक्स को विघटित कर सकता है, जिसका उपयोग नेस्टेड तत्व चयनकर्ताओं के लिए ओवरराइड उत्पन्न करने के लिए किया जा सकता है।

हाँ, मैं समझ गया। यह मिश्रण में शायद सबसे उपयोगी है। प्रत्यक्ष चयनकर्ता नाम का उपयोग करने पर मुझे निश्चित रूप से &() की उपयोगिता मिलती है। मेरा कहना केवल दिए गए उदाहरण में &() के मूल्य को स्पष्ट करने का प्रयास करना था।

आगे जाने के लिए, मुझे लगता है कि यह एक अच्छा वाक्यात्मक समाधान है, और मैं व्यक्तिगत रूप से &() कार्यान्वयन के साथ आगे बढ़ने के लिए दूंगा, अगर कोई इसे लेना चाहता है।

@ मैथ्यू-डीन

आपके उदाहरण कुछ भ्रमित करने वाले हैं क्योंकि आप अपना अपेक्षित आउटपुट नहीं लिख रहे हैं

ओह, क्षमा करें। मैं इसे ठीक से दोहराऊंगा। मुझे लगता है कि &() एक मजबूत विशेषता होगी यदि कम यहां नीचे सीएसएस में संकलित किया गया है।

.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; तरह व्यवहार करता है, तो हम इस सुविधा को मिक्सिन के अंदर उपयोगिता _only_ पर लागू कर रहे हैं, लेकिन मुझे लगता है कि इसमें और भी बहुत कुछ है।

अर्थ अनिवार्य रूप से "&, लेकिन जैसे कि गहराई के बजाय यहां घोंसला बनाया गया है", एक स्थिर "अभी और का मूल्य" वापस करने के बजाय।

मैं वास्तव में इसका अर्थ नहीं समझता।

इसका मतलब है कि मुझे लगता है कि .thing{ & {} } और .thing{ <strong i="11">@amp</strong>:&(); @{amp} {} } एक ही आउटपुट का उत्पादन करना चाहिए।

इसका मतलब है, अधिक व्यावहारिक रूप से, आपको आसान बीईएम करने के लिए एक मिश्रण लिखने की ज़रूरत नहीं है, लेकिन इसे इनलाइन परिभाषित कर सकते हैं। मेरे पुराने उदाहरणों में से एक को वापस जाना:

_घटक.कम_

.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 {
  /* base styles */
}
.component_child {
  /* styles for the child */
}
.component-variant {
  /* nothing too schmancy so far */
}
.component-variant .component_child {
  /* IT'S MAGIC! */
}

लाभ: आपको अपनी टीम से यह पूछने की ज़रूरत नहीं है कि उनका मतलब & या @{this} । आप बस कहते हैं "बस हर जगह @{this} उपयोग करें।"

यह वास्तव में एक घटक फैक्ट्री मिक्सिन परिभाषा को और अधिक आंतरिक रूप से सुसंगत बना देगा।

_काल्पनिक-बटन-मिश्रण। रहित_

#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;
      }
    }
  }
}
// ...

_काल्पनिक-शैली। रहित_

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

_काल्पनिक-शैली.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() eval'd जैसा होगा ( वास्तव में नहीं, लेकिन केवल उदाहरण के लिए .... वास्तव में यह करने का सबसे तेज़ तरीका हो सकता है)। और फिर उस स्ट्रिंग को अन्य स्थानों में सम्मिलित करना चयनकर्ताओं के रूप में पुनः मूल्यांकन किया जाना है।

@ मैथ्यू-डीन
यह वास्तव में _more_ भी भयानक होगा यदि यह चयनकर्ता सूची को चयनकर्ताओं की वास्तविक सूची के रूप में उजागर करेगा, जिसमें सभी सूची सदस्यों के आधार पर चयनकर्ताओं का विस्तार करने के लिए विशेष व्यवहार शामिल है।

उदाहरण के लिए

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

  @{this} {
    c : d;  
  }
}

उत्पादन

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

जैसे देशी & होगा।

हाँ, यह ठीक यही करेगा। 3.5 में, चयनकर्ताओं में मूल्यांकन किए गए किसी भी चर के कारण संपूर्ण चयनकर्ता सूची को एक नई चयनकर्ता सूची के रूप में फिर से पार्स किया जाता है। तो हाँ, यह अपेक्षा के अनुरूप काम करेगा। मेरे द्वारा किए गए कुछ हालिया पीआर के कारण यह वास्तव में काफी आसान है।

जुला 7, 2018, पर 10:34 AM पर, rjgotten [email protected] लिखा है:

@ मैथ्यू-डीन
यह वास्तव में और भी भयानक होगा यदि यह चयनकर्ता सूची को चयनकर्ताओं की वास्तविक सूची के रूप में उजागर करेगा, जिसमें सभी सूची सदस्यों के आधार पर चयनकर्ताओं का विस्तार करने के लिए विशेष व्यवहार शामिल है।

उदाहरण के लिए

.ए, .बी {
@ यह : और ();

@{यह} {
सी: डी;
}
}
उत्पादन

.ए.ए,
.ए.बी,
।बी। ।ए,
.ए.बी {
सी: डी
}
मूल निवासी की तरह और होगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे 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_ है, तो प्रतिस्थापन टोकन उसी तरह कार्य करता है जैसे कि & निर्दिष्ट किए गए थे और यह _disables_ सामान्य चयनकर्ता चेनिंग जो घोंसले से उत्पन्न होता है।

यदि &() एक नोड प्रकार को आउटपुट करना था जो इसे वास्तविक चयनकर्ता सूची के रूप में पहचानने योग्य बनाता है, तो मुझे लगता है कि व्यवहार को हासिल करना तुलनात्मक रूप से आसान होगा।

वास्तव में, यदि यह एक समर्पित नोड प्रकार को आउटपुट करने के लिए था, जो बाद में कैप्चर की गई चयनकर्ता सूची को _manipulate_ करने के लिए प्लगइन फ़ंक्शंस के निर्माण में सहायता कर सकता है।

मेरे लिए, ऐसा लगता है कि एक बार में बहुत अधिक काम करना &() करना। यदि आप चाहते हैं कि यह चयनकर्ताओं को एक चर में सहेजे, तो यह एक बात है, लेकिन उस चर को अक्षम करने के लिए चयनकर्ता श्रृंखला को _content_ के कारण सिंटैक्स में अस्पष्ट होगा। वह चर कहीं से भी आ सकता है (उदाहरण के लिए एक मिश्रण से पारित) और चयनकर्ता सूची सरल चर असाइनमेंट द्वारा उत्पन्न की जा सकती है। यही है, यह परिवर्तनीय उपयोग से स्पष्ट नहीं है कि चर की सामग्री के आधार पर एक अलग श्रृंखलाबद्ध व्यवहार होगा।

मुझे लगता है कि यदि आप चेनिंग को अक्षम करना चाहते हैं, तो आपको यह निर्दिष्ट करना होगा कि आप निहित और को किसी अन्य मान से बदलना चाहते हैं, जैसे (स्वरूपण को क्षमा करें, मैं अपने फोन पर हूं) -

।अवयव {
@वर : और ();
&(@var)_child {} // या कुछ ऐसे "& का प्रतिस्थापन" सिंटैक्स
}

तो मुझे लगता है कि परिणाम वांछनीय क्यों है, लेकिन आईएमओ हम चयनकर्ता सूची कहां से आते हैं, इसके आधार पर हम केवल "जादू-स्विच" परिवर्तनीय विलय व्यवहार नहीं कर सकते हैं। इसके लिए दो अलग-अलग विशेषताओं की आवश्यकता होती है।

ओह... मुझे वास्तव में &(...) चीज़ पसंद है...

हा, सच में? आपको नहीं लगता कि &() (& से चयनकर्ताओं को कैप्चर करें) और &(@arg) ( & को चयनकर्ताओं के साथ बदलें) का अर्थ संबंधी भ्रम होगा?

आप उन्हें मिश्रित न करने पर विचार कर सकते हैं, क्योंकि कोई व्यक्ति & को एक खाली चयनकर्ता के साथ अनिवार्य रूप से त्यागने के लिए प्रतिस्थापित करना चाह सकता है। (बच्चे को जड़ में रखने के लिए।) हालांकि मुझे लगता है कि शायद यह &(“”) सकता है।

मुझे पता नहीं, यह कुछ विचार/विचार के योग्य है।

साथ ही, जैसा कि "पैरेंट चयनकर्ताओं के पास लक्ष्य होना चाहिए" थ्रेड में उल्लेख किया गया है, विरासत चयनकर्ता (या पूरी तरह से) के विशिष्ट हिस्सों को बदलने के लिए उपयोग के मामले हैं, इसलिए इसके बारे में सोचकर, मुझे लगता है कि उन्हें दो अलग-अलग मुद्दों के रूप में ट्रैक किया जाना चाहिए। यह मुद्दा सिर्फ कैप्चरिंग के बारे में होना चाहिए और

बस इस सर्कल को बंद करने के लिए, यहां पर मैंने & को एक फ़ंक्शन-जैसी संरचना के साथ बदलने का उल्लेख किया है। - 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+_: @&;
    }
}

लेकिन यह तब तक काम नहीं करेगा जब तक इसे लागू नहीं किया जाता