Less.js: सशर्त सीएसएस कोड

http://www.lesscss.org/ पर जाएं और गार्ड खोजें।

मिक्सिन का उपयोग करने से बचने के लिए, किसी भी सीएसएस पर गार्ड को अनुमति देने के लिए फीचर अनुरोध को देखता है।

हाँ, मुझे पता है कि लेकिन अगर हम बहुत कम लिख रहे हैं तो हमें सैकड़ों .mixins write लिखना और प्रबंधित करना होगा
मुझे नहीं लगता कि मिक्सिन इस मुद्दे को हल करता है। इस फीचर से मिक्सिंस को भी काफी ताकत मिलेगी।
कम सीएसएस में लगभग सभी विशेषताएं होती हैं जो कुछ प्रोग्रामिंग भाषा में होती हैं तो यह क्यों नहीं?

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

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

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

मैं इस सुविधा के लिए एक बड़ा +1 जोड़ूंगा जो मुझे वास्तव में याद आ रहा है। एक बड़े कोडबेस के साथ गार्ड बनाए रखना वास्तव में एक बुरा सपना है। यह वास्तव में चीजों को बहुत आसान बना देगा ...

हम स्विच स्टेटमेंट भी जोड़ सकते हैं..

@lukeapage क्या आप कृपया इस मुद्दे को फिर से खोल सकते हैं। मुझे लगता है कि हमें इस मुद्दे/सुविधा पर चर्चा करनी चाहिए

LESS कोई स्क्रिप्टिंग भाषा नहीं है। वाक्य रचना / शैली CSS से मिलती जुलती है।

LESS का मतलब घोषणात्मक होना है, जिसका अर्थ है कि यह शाखाओं में बंटने वाले तर्क, लूप आदि के साथ सक्षम जटिल स्थिति नहीं होनी चाहिए।

@pierresforge क्या आपके पास कोई उदाहरण है जहां गार्ड अपर्याप्त हैं?

और जहां किसी भी चयनकर्ता पर गार्ड रखने में सक्षम होने से इसे हल नहीं किया जाएगा?

चर्चा खुली है .. यदि आप मुझे (या कोर टीम के किसी अन्य सदस्य को) समझा सकते हैं तो वे आवश्यक हैं तो मैं इस मुद्दे को फिर से खोलूंगा .. लेकिन बातचीत पहले हो चुकी है और इस पर बहुत समय बिताया गया है .

http://lesscss.org/ से वाक्य
"कम गतिशील व्यवहार जैसे चर, मिश्रण, संचालन और कार्यों के साथ सीएसएस का विस्तार करता है।"

हां LESS स्क्रिप्टिंग भाषा नहीं है, लेकिन फिर भी इसमें चर, कार्य और संचालन जैसी विशेषताएं हैं।
सशर्त तर्क क्या गायब है।

मुझे लगता है कि सीएसएस मीडिया क्वेरी सशर्त तर्क के अलावा और कुछ नहीं है।

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

यदि CSS में गार्ड की तरह सशर्त तर्क हो सकते हैं। तो अंतर क्या है। गार्ड सिर्फ इसे मिक्सिन तक बढ़ा रहे हैं।
गार्ड केवल सीएसएस कोड ब्लॉक के बाहर की स्थितियों की अनुमति देता है, न कि कोड ब्लॉक के अंदर।
उदाहरण के लिए कृपया https://github.com/cloudhead/less.js/issues/1293#issuecomment -16929701 देखें, इस तरह की आवश्यकता के लिए गार्ड मदद नहीं कर सकते।

यहां तक ​​​​कि एचटीएमएल में सशर्त तर्क है, हां और यह एक मार्कअप भाषा है जो स्क्रिप्टिंग भाषा नहीं है।

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

@lukeapage धन्यवाद ..

गार्ड मीडिया के प्रश्नों के समान होते हैं। ध्यान दें कि सामान्य CSS में आप चयनकर्ताओं के अंदर मीडिया प्रश्नों को नेस्ट नहीं कर सकते हैं; आप उन्हें केवल दस्तावेज़ के मूल में रख सकते हैं।

नहीं, मेरे पास ऐसा कोई उदाहरण नहीं है जहां गार्ड पर्याप्त न हों। हालाँकि, वहाँ बहुत कुछ है जहाँ गार्ड वास्तव में रखरखाव के लिए सर्वश्रेष्ठ नहीं हैं।

एक उदाहरण:

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

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

मेरे अर्थ में अधिक संक्षिप्त और आत्म-व्याख्यात्मक है (ज्यादातर ऐसे मामलों में जहां कोड को फिर से प्रयोग करने योग्य बनाने का कोई मतलब नहीं है, क्योंकि एल्गोरिथ्म बहुत सारे कारकों पर निर्भर करता है) की तुलना में:

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

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

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

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

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

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

इस तरह की स्थिति इसलिए मैंने कंट्रास्ट फ़ंक्शन लिखा है - यह एक प्रकार के सशर्त ऑपरेशन के रूप में कार्य करता है जो अन्यथा उपलब्ध नहीं है, और जैसा कि आप कहते हैं, गार्ड का उपयोग करने से यह बहुत साफ है। मुझे लगता है कि हम किसी प्रकार के सामान्य कार्य को लागू कर सकते हैं जो एक प्रकार के चयनकर्ता के रूप में कार्य करता है, बजाय इसके कि शर्तों के लिए सिंटैक्स जोड़ने तक।

@ सोवियत शैतान के वकील - कम में, आप वास्तव में अपनी मीडिया क्वेरी को चयनकर्ता के अंदर रख सकते हैं, जो अक्सर काफी उपयोगी होता है।

मैं ifs के खिलाफ रहा हूं, क्योंकि यह आपके कोड की जटिलता को तेजी से बढ़ाना शुरू कर देता है, और LESS को सरल और सीधा होने के लिए डिज़ाइन किया गया है। इस समय, नई सुविधाओं को जोड़ने पर भाषा को स्थिर करने के लिए कुछ प्रयास किए जा रहे हैं।

हालांकि .... डेविल्स एडवोकेट फिर से, इस तर्क के आधार पर कि मीडिया के प्रश्न अब चयनकर्ताओं के भीतर दिखाई देते हैं, गार्ड सैद्धांतिक रूप से उसी सिद्धांत का पालन कर सकते हैं।

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

  background-color: @coreBackgroundColor;

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

or

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

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

ifs की तुलना में अधिक घोषणात्मक, मौजूदा LESS के करीब सिंटैक्स, और प्रत्येक कथन का स्वतंत्र रूप से मूल्यांकन करता है (जैसे LESS / CSS परिभाषित किया गया है)।

वैकल्पिक रूप से (या इसके अलावा), इसी तरह, मूल्यांकन के बिंदु पर मिश्रण के मूल्यांकन को जोड़ना:

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

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

यकीनन, स्टेटमेंट-लेवल गार्ड्स मिक्सिन-लेवल गार्ड्स IMO की तुलना में अधिक/कम जटिल या अलग तर्क नहीं हैं। शायद उदाहरण 2 और 3 भाषा के लिए कम विस्तृत हैं। बस सोचा कि मैं इसे विचार/चर्चा के लिए वहां फेंक दूंगा।

मुझे लगता है कि मेरे डिक्लेरेशन गार्ड्स प्रस्ताव पर किसी के पास कहने के लिए ज्यादा कुछ नहीं था। ;-)

वास्तव में, नहीं, कहने के लिए बहुत कुछ नहीं है। यह बहुत अच्छी बात होगी, आईएमओ :)

हाँ, अगर वे पहले से ही मिश्रित हैं, और मीडिया प्रश्न तत्वों के अंदर हो सकते हैं, ऐसा लगता है कि उन्हें विस्तारित करने का तर्क उचित है। जिज्ञासु क्या @lukeapage और @jonschlinkert और अन्य सोचते हैं।

@matthewdl : +1:

लगता है कि मैंने पहले ही उस मुद्दे पर उनका समर्थन किया है जिस पर वे चर्चा कर रहे हैं.... :)

@lukeapage क्या आप #748 अंक के बारे में बात कर रहे हैं? यदि ऐसा है, तो मैंने वाक्य रचना में थोड़ा सा जोड़ा है। ;-)

मैं किसी प्रकार के if या @when के लिए अपनी इच्छा व्यक्त करने में झंकार करना चाहूंगा।

मैं इस भावना से सहमत नहीं हूं कि गार्ड सार्वभौमिक रूप से बेहतर हैं और कम कोड को सशर्त उपयोग करने से कम जटिल बनाते हैं। मुझे ऐसी व्यावहारिक परिस्थितियाँ मिल रही हैं जहाँ गार्ड वास्तव में मेरी LESS फ़ाइलों को पढ़ने में कठिन और कठिन बनाते हैं लेकिन if / @when वास्तव में असाधारण रूप से पठनीय होगा। गार्ड और if / @when सशर्त स्वाभाविक रूप से केवल उपकरण हैं, इन दोनों का उपयोग चीजों को सुंदर या बदसूरत बनाने के लिए किया जा सकता है और विभिन्न स्थितियों के लिए बेहतर अनुकूल हैं। नरक, मैं एक ~300b .less फ़ाइल बना सकता हूं जो केवल 1GB से अधिक RAM खाने और CPU को मिनटों के लिए मंथन करने के लिए सबसे बुनियादी चयनकर्ता विस्तार सुविधा का उपयोग करती है।

हाल ही में एक प्रोजेक्ट में मैं डेस्कटॉप और मोबाइल दोनों के लिए भारी समर्थन के इरादे से काम कर रहा था, मैंने अंततः फैसला किया कि इनलाइन मीडिया प्रश्नों के साथ ऐसा करना काफी अच्छा नहीं था। किसी भी मोड में अतिरिक्त सीएसएस की सेवा करना, जिसका वह उपयोग भी नहीं करेगा, अच्छा नहीं लगता, साथ ही पृष्ठभूमि-छवियों को डबल लोडिंग करने की कोशिश करने में पूरी परेशानी और उसके आसपास काम करने के लिए समय बर्बाद किए बिना डेटा यूआरआई को एम्बेड करने में असमर्थ होने के बावजूद एक पूरी छवि की सेवा करना जो एक मोड उपयोग नहीं करेगा। और दो स्टाइलशीट को कैस्केड करने की कोशिश करके इससे निपटने से मेरी कम बड़ी गड़बड़ हो जाएगी क्योंकि अब एक वर्ग के लिए शैलियों की घोषणा करने वाले दो स्थान होंगे।

मेरा निर्णय यह था कि एक से दो स्टाइलशीट परोस कर, मीडियाविकि आरटीएल को कैसे संभालता है, इसका एक पेज लेना था। मीडियाविकि एलटीआर में स्टाइलशीट लिखकर और फिर दूसरी आरटीएल स्टाइलशीट बनाने के लिए स्टाइलशीट को फ्लिप करके ऐसा करता है। आरटीएल को संभालने के लिए एलटीआर के लिए निर्दिष्ट सभी चीजों को आजमाने और ओवरराइड करने की कोई आवश्यकता नहीं है। इसी तरह मैंने फैसला किया कि मैं अपनी प्राथमिक शैलियों को main.less (और संभावित रूप से शैलियों को अलग करने के लिए संदर्भित फ़ाइलों) में लिखूंगा, उस फ़ाइल को सीधे संकलित नहीं किया जाएगा। इसके बजाय मेरे पास दो स्टाइलशीट होंगी एक Desktop.less और एक mobile.less, ये दोनों <strong i="14">@mobile</strong>: true/false; , <strong i="16">@desktop</strong>: true/false; जैसे सामान सेट करेंगे, और चीजों के आकार जैसे कुछ कम चर को भी ओवरराइड करेंगे। इस तरह मेरा main.less समाप्त हो गया दोनों एक Desktop.css और mobile.css में बदल गया, और मैं मीडिया क्वेरी/परीक्षण को यह निर्धारित कर सकता हूं कि कौन सा कहीं और लोड करना है (यदि मैं वास्तव में चाहता था कि मैं वास्तव में यह निर्धारित कर सकूं कि कौन सा लोड करना है ऐसे उपकरण पर जो मीडिया प्रश्नों का समर्थन भी नहीं करता है)।

हालांकि एक मुद्दा सशर्त ब्लॉक है। मेरे द्वारा तय किए गए कोड के कुछ हिस्से हैं "मोबाइल को इन शैलियों की आवश्यकता नहीं है" या "डेस्कटॉप को इन शैलियों की आवश्यकता नहीं है"। वर्तमान में मैं इसे कम में करने का एकमात्र तरीका है:
((ठीक है, तकनीकी रूप से ये शैलियाँ काल्पनिक हैं क्योंकि मैं एक अकॉर्डियन नेविगेशन का उपयोग नहीं कर रहा हूँ, लेकिन वे मेरे द्वारा किए जा रहे कार्यों के लिए सही हैं))

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

इस स्थिति में @when जैसी किसी चीज़ का उपयोग करना कहीं अधिक समझ में आता है।

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

मैंने वास्तव में @when सिंटैक्स को हैक में बदलने के लिए अपनी कम फ़ाइलों को पूर्व-संसाधित करने पर विचार किया, जहां एक गतिशील रूप से उत्पन्न मिक्सिन + गार्ड बनाया जाता है और फिर उसके बाद सीधे शामिल किया जाता है।
कहने की जरूरत नहीं है, अगर प्री-प्रोसेसर को प्री-प्रोसेस करने का विचार एक अच्छे विचार की तरह लगता है जिससे चीजों को समझना आसान हो जाएगा ... वर्तमान प्री-प्रोसेसर में कुछ गड़बड़ है।

और सच्चाई यह है कि यह केवल मेरे डेस्कटॉप/मोबाइल तकनीक पर लागू नहीं होता है। यह समान रूप से थीम योजनाओं पर लागू हो सकता है। अपनी थीम के साथ एक मुख्य कम फ़ाइल लिखें। फिर कम फाइलों का एक गुच्छा है जिसमें आप बस उस कम फ़ाइल को शामिल करते हैं और फिर रंग योजना जैसी चीजों को नियंत्रित करने के लिए कुछ कम चर सेट करते हैं। रंग परिवर्तन ठीक काम करेंगे, लेकिन एक बार जब आप पाएंगे कि आप वास्तव में @use_horizontal_nav जैसी किसी चीज़ का उपयोग कर सकते हैं, तो आप तुरंत एक चट्टान से भाग जाएंगे।

@dantman 1.5.0 के रूप में और सीएसएस शैलियों पर गार्ड जो जुड़ा हुआ है, आप यह कर सकते हैं

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

जो आपके उदाहरण के लिए चीनी है।

केवल नकारात्मक पक्ष यह है कि इस समय यह सोचता है कि यह एक नया चयनकर्ता है इसलिए यह इसे पिछले चयनकर्ता के साथ विलय नहीं करता है। हालाँकि मुझे लगता है कि इससे आपको समस्या होने की संभावना नहीं है और कुछ ऐसा होगा जिसे मैं/हम भविष्य के संस्करणों में ठीक कर देंगे।

ठीक है धन्यवाद, क्या हम इसे एक फीचर के रूप में दस्तावेज कर सकते हैं?

सच कहूं तो मुझे यह भी यकीन नहीं है कि यह @when की तुलना में बहुत समझ में आता है, मुझे यकीन नहीं है कि अगर मैंने पहले & when(...) को एक .less फ़ाइल में देखा होता तो मुझे समझ में आता कि यह क्या है एक नजर में किया। @when चीनी के रूप में & when() के लिए अच्छा हो सकता है।

मैं @ मैथ्यू-डीन से सहमत हूं कि इस तरह की सशर्त संरचनाओं को जोड़ने से संभवतः कम कोर फाइलों को बनाए रखने और परीक्षण करने में कठिनाई होगी। और .less फ़ाइलों को डीबग करना कठिन होता है और इसी तरह।

अभी हमें जो मिला है वह कला का एक टुकड़ा है, लोग कम से कम 10 मिनट से भी कम समय में LESS की मूल बातें समझ और सीख सकते हैं (मैं घोंसले के शिकार और मिश्रण के बारे में बात कर रहा हूं), सशर्त बयान जोड़ने से अन्य प्रकार के लोगों के लिए चीजों को पचाना कठिन हो जाता है जैसे डिजाइनर और उत्साही। IF कथनों की नकल या अनुकरण करने के लिए गार्डों का उपयोग करने की कोशिश करना सिर्फ एक ऐसी समस्या को बढ़ाने की कोशिश कर रहा है जो मौजूद नहीं है और जिसे समाधान की आवश्यकता नहीं है।

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

उदाहरण के लिए ऐसा न हो कि मेरे पास "myfile.less.php" नाम की एक फ़ाइल है जिसमें सशर्त, स्विच, सरणियों और सभी फैंसी सामान के साथ पागल कोड है जो आप PHP पर देख सकते हैं और फिर उस ".less.php" फ़ाइल से दूसरी फ़ाइल थूक सकते हैं "myfile.less" कहा जाता है जिसमें अंतिम कम कोड होता है, इस तरह मैं PHP के साथ सभी सर्वर वर्र्स से पूछ सकता हूं, यह तय कर सकता हूं कि मेरी नई .less फ़ाइल में @imports क्या शामिल होगा या बहिष्कृत होगा, अब बड़ी मात्रा में मूर्खतापूर्ण वर्र्स को पास करने की आवश्यकता नहीं है कम कंपाइलर और आईएफ या स्विच संरचनाओं की नकल करने के लिए मूर्खतापूर्ण गार्ड को पढ़ने के लिए बदसूरत, कठिन लिखने की कोई आवश्यकता नहीं है।

एक बुनियादी कार्यप्रवाह इस तरह हो सकता है

1- जांचें कि क्या कैश समाप्त हो गया है
1- सभी फाइलों ".less.php" फाइलों को खोजने और पूर्व-संसाधित करने के लिए स्क्रिप्ट को कॉल करें
2- सभी ".less" फ़ाइलों को संकलित करने के लिए स्क्रिप्ट को कॉल करें
3- कैश अपडेट करें

@enav मैं दृढ़ता से असहमत हूं। साथ ही साथ कम विकास मैं इसे नोड के शीर्ष पर आधारित एंटरप्राइज़ समाधान में उपयोग करता हूं, जहां हम किसी समस्या को हल करने के लिए 2 भाषाओं का उपयोग नहीं करना चाहते हैं।

@dantman बहुत सी चीजें प्रलेखित नहीं हैं और हां, हमें इसे दस्तावेज करने की आवश्यकता है। प्रलेखन का विस्तार करने और वेबसाइट को बेहतर बनाने के लिए कम-दस्तावेज़ों पर प्रयास चल रहा है। मैं वहां एक मुद्दा जोड़ूंगा।

@lukeapage , हाँ मैंने हाल ही में देखा है। मैंने चैंज के माध्यम से स्किम किया और svg-gradient और संपत्ति के साथ विलय जैसी चीजें देखीं।

कड़ाई से बोलना & when ... पहले से ही प्रलेखित है क्योंकि यह दो प्रलेखित सुविधाओं & और CSS Guards का एक साधारण कॉम्बो है। लेकिन एक समर्पित उदाहरण निश्चित रूप से नुकसान नहीं पहुंचाएगा।

@ सात-चरण-अधिकतम, मुझे उस दस्तावेज़ीकरण की जानकारी नहीं थी। इसके स्वरूप से, यह पुरानी साइट को बदलने के लिए दस्तावेज़ों का एक अधूरा नया सेट है, जिसे "इसे जल्द ही lesscss.org रेपो में स्थानांतरित कर दिया जाएगा! हम अनुशंसा करते हैं कि जब तक सब कुछ लाइव न हो जाए तब तक आप इस साइट से लिंक करने से बचें।" टिप्पणी। यह जानकर अच्छा लगा कि ऐसा कुछ काम कर रहा है।

मैं lesscss.org पर वर्तमान दस्तावेज़ीकरण की बात कर रहा था, जो केवल वही दस्तावेज़ थे जिनके बारे में मुझे जानकारी थी, और वर्तमान में केवल दस्तावेज़ गार्ड एक मिक्सिन फ़ीचर के रूप में हैं, यह सुझाव नहीं दे रहे हैं कि यह कहीं और उपलब्ध है।

गार्ड इतने अच्छे नहीं हैं। :(

यह एक आवश्यक विशेषता है और स्कैस में भी मौजूद है।

इसके लिए +1

चूंकि यह टिप्पणी आज इस मुद्दे को खोले जाने के कुछ साल बाद उठाई गई थी, इसलिए मैं एक बात बताऊंगा जो इस समय दिमाग में आती है।

मूल चर्चा में @when का कुछ प्रतिरोध अतिरिक्त नियम है। हालाँकि, अभी इसके बारे में सोचते हुए, इसकी आवश्यकता नहीं होनी चाहिए।

यह देखते हुए कि ये दो ब्लॉक समान हैं:

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

फिर इन दोनों कथनों को भी पार्सर द्वारा समान मान कर स्वीकार किया जाना चाहिए।

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

यदि किसी अन्य कारण से & when के अलावा वाक्य रचनात्मक रूप से वास्तव में अजीब है। & को छोड़ना अभी भी एक चयनकर्ता को मूल चयनकर्ता के साथ शामिल होने का संकेत देने के लिए सभी के साथ अस्तित्व में है, इसलिए & को छोड़कर माता-पिता चयनकर्ता पर एक गार्ड को छोड़ना एक छलांग की तरह प्रतीत नहीं होता है। साथ ही, ब्लॉक-रूट फ़ंक्शंस अब पार्सर द्वारा प्लगइन्स के साथ उपयोग के लिए स्वीकार किए जाते हैं, इसलिए यह अब उतना अजीब नहीं दिखता जितना 2013 में हो सकता है।

मुझे इसे फिर से खोलने का कोई कारण नहीं दिखता। आखिर हमारे पास पहले से ही #2072 . है

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

सिर्फ दो वर्णों की अर्थव्यवस्था के लिए एक बड़ा भ्रम बॉक्स खोलना?

गार्ड इतने अच्छे नहीं हैं।

मैंने सोचा कि एक यादृच्छिक अनुचित टिप्पणी पर टिप्पणी करना भी उचित नहीं होगा। किसी भी स्थिति के पीछे कुछ होना चाहिए (अन्यथा मैं कहूंगा कि कोई भी सशर्त कोड लंगड़ा है और if s मूर्खतापूर्ण हैं क्योंकि मुझे पता है कि लगभग हर भाषा में एक भी शर्त के बिना _anything_ कैसे लिखना है)।

मुझे इसे फिर से खोलने का कोई कारण नहीं दिख रहा है। आखिरकार हमारे पास पहले से ही when (1=1) { color: blue; } है

अरे... नहीं हम नहीं?

लेकिन यह उचित है कि हमें करना चाहिए। हम बस इसे अनुमति दे सकते हैं और इसके साथ किया जा सकता है।

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

इसलिए इसे #2072 में मर्ज किया जा रहा है।

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

उस मुद्दे को "संरक्षित स्वयं चलने वाले ब्लॉक के अंदर परिवर्तनीय पुनर्वितरण की अनुमति दें" कहा जाता है और उस मुद्दे के नीचे की स्पर्शरेखा चर्चा में एक चयन/मामले और एक vbscript iif ([ifcond], [तब], [else]) के अनुरूप उपयोग के मामले शामिल थे। केवल नग्न से अधिक कार्य करते हैं, हालांकि यह चर्चा के लिए शायद अधिक तार्किक पिकअप है। Buuut... शायद इसे केवल when () बनाम & when () प्रश्न के साथ एक नए मुद्दे के रूप में उठाया जाना चाहिए।

बस कब () बनाम और कब () प्रश्न के साथ।

आप इस पर गंभीर नहीं हो सकते, है ना? आख़िर किस वजह से? यदि आप & हटाते हैं तो when if नहीं बनेगा (सभी कारणों से #2072 देखें)। इसलिए इसे वैसे ही छोड़ दें और इसके साथ हो जाएं।

अरे, क्या आप इसे एक पायदान नीचे कर सकते हैं? यदि आप इसके बारे में परेशान हैं, तो कुछ समय दें और बाद में मेरे द्वारा नए अंक में पोस्ट किए गए तर्क को देखने के लिए वापस आएं। इन मूल चर्चाओं के बाद से कुछ चीजें विकसित हुई हैं।

मेरा मतलब ठेस पहुँचाना या कुछ और नहीं था।
मेरे:

इसलिए इसे वैसे ही छोड़ दें और इसके साथ हो जाएं।

बस एक जवाब था:

हम बस इसे अनुमति दे सकते हैं और इसके साथ किया जा सकता है।

@ सात-चरण-अधिकतम ठीक है, पाठ में स्वर खो जाता है। किसी भी मामले में, मैं इस विचार से बहुत अधिक जुड़ा नहीं था, और कुल मिलाकर, मौजूदा @when प्रस्ताव वैसे भी बेहतर / अधिक बहुमुखी है।

मुझे लगता है कि 'एसएएस' कम से बेहतर है। यह पहले से ही अगर-और है। यह वास्तव में कठिन है और कोडिंग की कई लाइनें कम हैं। जब काम करता है लेकिन यह जरूरत को पूरा नहीं करता है। इसके अतिरिक्त हम कम में लूप बना सकते हैं लेकिन भाषा की अपनी विशेषता होनी चाहिए।

@aukgit नौकरी के लिए सही उपकरण का प्रयोग करें। यदि SCSS आपको बेहतर तरीके से सूट करता है, तो इसका उपयोग करना बेहतर है। सास और कम बहुत अलग परियोजनाएं हैं।

@ मैथ्यू-डीन महीनों तक कम सीखने और टन कम लिखने के बाद अगर 'कम' समुदाय बेहतर नहीं होना चाहता है तो यह हम दोनों के लिए नुकसान है। मुझे लगता है कि यही कारण है कि बूटस्ट्रैप कम से 'एसएएस' (https://github.com/twbs/bootstrap/tree/v4-dev) में चला गया (प्रारंभिक कारण तेज संकलन था)। जबकि प्रारंभिक स्रोत 'कम' में था। अब वे अपना मूल स्रोत 'एसएएस' में लिखते हैं और फिर इसे कम में परिवर्तित करते हैं (जबकि यह दूसरी तरफ था)।

एक और बात :

"सही काम के लिए सही उपकरण"

यहां आवेदन नहीं करना चाहिए

कम | एससीएसएस | स्टाइलस समान परियोजनाओं। उस समय से शुरू हुआ जो उस समय लोकप्रिय था, अब ऐसा लगता है कि 'कम' समुदाय खुद को सुधारना नहीं चाहता है।

'कम' के पीछे का विचार कम लिखना और अधिक करना है। कहीं यह कमी करता है लेकिन कहीं अधिक लेखन की आवश्यकता है।

आपकी टिप्पणीयों के लिए धन्यवाद।

फैनबॉयिश पुराना प्रचार। इन सभी पक्षपाती या केवल झूठे बयानों पर बहस करना समय की बर्बादी होगी।

जैसे:

वास्तव में संकलित सशर्त कोड बनाने का कोई तरीका नहीं है।

हाँ, "मुझे अपना स्पेगेटी कोड लिखने के लिए एक उपकरण की आवश्यकता है" - ठीक इसी तरह . यदि आप इस तरह एक कोड लिखते हैं, तो वास्तव में कम निश्चित रूप से आपका टूल नहीं है।

मुझे लगता है कि "कम" एसएएस और स्टाइलस से कुछ अलग 'एक्स' करता है। अन्य सभी समान कार्य करते हैं जबकि 'कम' का दावा है कि यह एक समान प्रकार का नहीं है। :)

@aukgit

मुझे लगता है कि "कम" एसएएस और स्टाइलस से बहुत अलग 'एक्स' करता है।

_क्यों_ इसे ऐसा ही करना चाहिए? उदाहरण के लिए देखें [1] और [2] डिजाइनों के बीच महत्वपूर्ण अंतर खोजने के लिए। तो आप अवधारणा को पसंद नहीं कर सकते हैं लेकिन कोई भी आपको उस उपकरण का उपयोग करने के लिए मजबूर नहीं करता है जो आपको पसंद नहीं है।

अब समझ आया। शुक्रिया। वास्तव में, यह वास्तव में अब तक की सबसे गलत समझी जाने वाली भाषा है। यहां तक ​​​​कि जावास्क्रिप्ट को भी गलत नहीं समझा गया है क्योंकि डगलस क्रॉकफोर्ड कहते हैं।

जेएस में लोग गलती करते हैं लेकिन जागरूकता बहुत है। 'कम' के लिए यह पहले पृष्ठ (less.org) में होना चाहिए जिसमें वर्णन किया गया हो कि क्या कम है और क्या नहीं।

शुक्रिया।

एक मिश्रण लिखा:

कम:

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

    .x(@value);
}

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

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

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

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

सीएसएस आउटपुट:

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

अगर 'कम' समुदाय बेहतर नहीं होना चाहता तो यह हम दोनों के लिए नुकसान है

मुझे लगता है कि यह मान लेना एक गलती है कि "X सुविधा जो मुझे चाहिए वह समर्थित नहीं है" == "कम समुदाय बेहतर नहीं बनना चाहता"। यह हमें कहीं नहीं मिलता।

नियंत्रण प्रवाह में सुधार पर काम करने के लिए जीथब पर कई चर्चाएं हैं। वास्तव में, इस थ्रेड को अस्वीकार नहीं किया गया था, इसे #2072 में मिला दिया गया है। आपने 3 साल पुराने बंद धागे पर टिप्पणी की। मेरे पास कुछ अन्य विचार थे जो मुझे लगा कि शायद इसे #2072 से थोड़ा अलग बना सकते हैं, लेकिन अनिवार्य रूप से अन्यथा आश्वस्त थे।

अब ऐसा लगता है कि पसंद में बेहतर विशेषताएं नहीं हैं

कम में _more_ विशेषताएं नहीं होती हैं, यह सच है। यह डिजाइन द्वारा है। ऐसा इसलिए है कि आप एक दिन में कम सीख सकते हैं, और कम की विशेषताएं 99% सामान्य उपयोग के मामलों को कवर करती हैं। Sass में सीखने की अवस्था तेज है। Sass में इतना अधिक फीचर ब्लोट था कि उन्हें इसे संकलित करना जारी रखने में सक्षम होने के लिए निम्न-स्तरीय C-आधारित कंपाइलर बनाना पड़ा। जो एक बड़ी उपलब्धि है। लेकिन कुछ के लिए एक महान वसीयतनामा नहीं है, जो दिन के अंत में सिर्फ एक स्टाइल शीट बना रहा है।

अब वे अपना मूल स्रोत 'एसएएस' में लिखते हैं और फिर इसे कम में परिवर्तित करते हैं (जबकि यह दूसरी तरफ था)।

सच है, लेकिन यह कई कारकों पर आधारित है, और आप उनसे पूछ सकते हैं कि वे क्या होंगे। मुझे व्यक्तिगत रूप से लगता है कि कम उपयोगकर्ताओं को छोड़ना एक गलती है, क्योंकि आज बहुत सारे लोग कम में बूटस्ट्रैप का उपयोग कर रहे हैं।

दिन के अंत में, सशर्त लिखने के लिए आवश्यक हुप्स के बारे में आपकी शिकायतें _गलत नहीं_ हैं। यहां दिए गए उदाहरण भाषा के लिए बिल्कुल उपयुक्त हैं। मेरा सुझाव है कि आप इस सूत्र को #2072 में पढ़ लें।

(यह वास्तव में थोड़ा हटकर है, लेकिन मैं बस सोच रहा हूं)

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

और .if-value-present-multi को कॉल करने के अलावा इन चरों का क्या उपयोग होगा?
(और _if_ ये चर _are_ किसी और चीज़ के लिए उपयोग किए जाते हैं) क्या इसका कोई मतलब नहीं होगा, इसके बजाय एक उचित संपत्ति/मूल्य जोड़े का उपयोग करना, जैसे:

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

इसके अलावा, यदि आपको केवल .x {content: 'new val'} की आवश्यकता है तो .x {.if-value-present(content, 'new val')} लिखने का क्या उद्देश्य हो सकता है? और .x {.if-value-present(content)} लिखना अगर यह कुछ नहीं करता है?

(हालांकि ईमानदारी से मैंने [1] को देखा - ठीक है, केवल एक चीज़ को छोड़कर किसी भी चीज़ पर टिप्पणी नहीं करना: (_अपना समय बचाने के लिए_) elements और lesshat जैसे प्राचीन कामों को फेंकने पर विचार करें - और इसके बजाय autoprefixer का उपयोग करें। हमें अभी कुछ समय के लिए CSS प्रीप्रोसेसर के लिए विक्रेता-उपसर्ग पुस्तकालयों की आवश्यकता नहीं है)।

आमतौर पर अधिकांश "सुविधा अनुरोध" इस प्रकार आते हैं: "XY समस्या" । (संबंधित क्षेत्र में समान विफलताओं के अन्य अच्छे उदाहरण: #1400 और #1894, ऐसा नहीं है कि सुविधाएं पूरी तरह से बेकार होंगी (इसलिए दोनों को खुला रखा जाता है), लेकिन जब कोई उनके वास्तविक उपयोग के मामलों के बारे में पूछना शुरू करता है, तो यह आमतौर पर प्रकट होता है एक्स को हल करने के प्रयास में यह सिर्फ गलत वाई था)।

वैसे यहाँ उपयोग का मामला है:
मैंने 3 पैरामीटर के साथ मिक्सन बनाने की कोशिश की, यदि अंतिम नहीं दिया गया है, तो इसे मिक्स के अंदर इसकी विशेषता बनानी चाहिए, इसलिए स्थितियां उपयोगी थीं।

यहां https://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/responsive/responsive-placements.less में मैंने एक ही मिक्स को बार-बार लागू करने की कोशिश की थी जहां मैं इसे हासिल कर सकता था शर्तों के साथ बहुत आसानी से।

मुझे अब मिल गया .. आप सभी का धन्यवाद।

@aukgit आप उन मिश्रणों को आसानी से ध्वस्त करने में सक्षम होना चाहिए।

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

अपना समय निकालने और मेरी मदद करने के लिए @ मैथ्यू-डीन धन्यवाद। :) मैं तुम्हारे लिए बहुत अच्छा हूँ।

:)

मुझे लगता है कि 'एसएएस' कम से बेहतर है। यह पहले से ही अगर-और है।

दोनों भाषाओं के अपने-अपने मुद्दे हैं।

गतिशील आयात की उनकी कमी - और इसे लागू करने की उनकी अनिच्छा - मुख्य कारण है कि मैं Sass से कम में स्विच करना चाहता हूं। कम में यह सुविधा वर्षों से है!

हालांकि, पारंपरिक नियंत्रण संरचनाओं (जैसे फॉर-लूप या आईएफ-ईएलएसई-स्टेटमेंट) की कमी और क्रिंग-योग्य सिंटैक्स मुझे यह कदम उठाने से रोकता है।

मैं एक चट्टान और एक कठिन जगह के बीच फंसा हुआ महसूस करता हूँ ...

@jslegers वही टिप्पणी #249 में। कम के विभिन्न रूप हैं (नए संस्करण में अधिक से अधिक) सशर्त सख्ती के v1.x के बाद से।

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

मैं कम में लूप के विकल्प के रूप में आईएफ-स्टेटमेंट और रिकर्सिव मिश्रण के विकल्प के रूप में संरक्षित मिश्रणों से अवगत हूं। लेकिन यह सब मैं कम में नियंत्रण संरचनाओं के बारे में दस्तावेज़ों में ढूंढने में सक्षम हूं। और कई भाषाओं में प्रोग्रामिंग अनुभव वाले किसी व्यक्ति के रूप में, मुझे उनका वाक्यविन्यास भ्रमित करने वाला लगता है और - ईमानदार होने के लिए - काफी क्रिंग-योग्य।

यदि उनके अलावा अन्य नियंत्रण संरचनाएं हैं जो उल्लेखनीय हैं, तो मैं उन्हें दस्तावेज़ों में नहीं ढूंढ पा रहा हूं।

वैसे भी कुछ...

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

... या ऐसा ही कुछ...

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

... या यह...

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

... कम में संरक्षित मिश्रण या रिकर्सिव मिश्रण के साथ कुछ लिखने की तुलना में सास में मेरी राय में कहीं अधिक पठनीय और कहीं अधिक सुरुचिपूर्ण है।

इस तरह के बयानों की कमी और कम का समग्र कम पठनीय वाक्यविन्यास (एसएएस की तुलना में) दो मुख्य कारण हैं जिन्हें मैं सास के साथ रहना पसंद करता हूं और मैं अपनी परियोजनाओं में से एक के लिए कम पर विचार करने के लिए अनिच्छुक हूं।

और यह देखते हुए कि सैस कम से कहीं अधिक लोकप्रिय हो गया है, मैं स्पष्ट रूप से अकेला नहीं हूं जो ऐसा महसूस करता है।

@jslegers आपके उदाहरणों के लिए - यह जानने का प्रयास करें कि उन्हें पोस्ट करने से पहले क्या उपलब्ध है।
बाकी के लिए (लोकप्रियता और इसी तरह) - इस तरह के oversimplified तरीके से कुछ चर्चा करने का कोई मतलब नहीं है (स्टाइलस के पास यह सब है और तो क्या?), इसके अलावा कम को कभी भी अन्य सीएसएस-प्रीप्रोसेसरों को बदलने और न ही उनके क्लोन बनने की घोषणा नहीं की गई थी। और अंत में, सबसे आम गलती यह सोचना है कि किसी चीज़ की लोकप्रियता ही कुछ लेखकों का प्राथमिक और एकमात्र लक्ष्य है।

उन्हें पोस्ट करने से पहले यह जानने की कोशिश करें कि क्या उपलब्ध है।

बेहतर दस्तावेज़ करने का प्रयास करें या लोगों को सीधे उस चीज़ की ओर इंगित करें जिसे वे ढूंढ रहे हैं, यदि उन्हें वह नहीं मिल रहा है।

बाकी के लिए (लोकप्रियता और इसी तरह) - इस तरह के बड़े पैमाने पर कुछ चर्चा करने का कोई मतलब नहीं है [...] और अंत में, सबसे आम गलती यह सोचना है कि किसी चीज़ की लोकप्रियता प्राथमिक और एकमात्र लक्ष्य है जो कुछ लेखकों का है।

FYI करें, मैंने कभी नहीं कहा कि लोकप्रियता गुणवत्ता या उपयोगिता के लिए एक मजबूत संकेतक है। वास्तव में, अक्सर यह दूसरी तरफ होता है।

फिर भी, यदि आप देखें कि लोग लेस से सैस की ओर क्यों बढ़ते हैं, तो यह बहुत सीधा है ...

व्यक्तिगत रूप से मैं कुछ भी नहीं देख सकता, लेकिन सामान्य रूप से "मुझे अपनी PHP स्पेगेटी चाहिए" (ऊपर गलत टूल के बारे में पोस्ट देखें), इसकी 2012 की गिनती भी नहीं (मैंने पहले ही संकेत दिया था कि इनमें से अधिकांश उदाहरण आधुनिक कम में बहुत कॉम्पैक्ट हैं, लेकिन यह ऐसा लगता है कि आप जागना नहीं चाहते)।
लेकिन कोई बात नहीं, आमतौर पर मैं केवल एक स्पष्ट गलत सूचना का तर्क देता हूं, कुछ होता है या नहीं होता है, इस बारे में व्यक्तिगत राय की चर्चा पूरी तरह से मेरे हित से बाहर है।

व्यक्तिगत रूप से वहां मैं सामान्य रूप से कुछ भी नहीं देख सकता "मुझे मेरी PHP स्पेगेटी चाहिए"

मुझे ऐसा लगता है कि Sass के बजाय कम का उपयोग करने से आपका कोड अनिवार्य रूप से "PHP स्पेगेटी" जैसा दिखता है (यदि आपको लगता है कि PHP स्पेगेटी कोड का प्रतीक है, तो आपने स्पष्ट रूप से कभी कोई ABAP प्रोग्रामिंग नहीं की) जैसे ही आप कुछ और जटिल करना चाहते हैं बुनियादी चर और मिश्रणों की तुलना में, लेकिन मैं यह मानने को तैयार हूं कि मैं यहां गलत हूं।

मैंने पहले ही संकेत कर दिया था कि इनमें से अधिकांश उदाहरण आधुनिक लेस में काफी कॉम्पैक्ट हो जाते हैं, लेकिन ऐसा लगता है कि आप जागना नहीं चाहते हैं

तो क्यों न मुझे जगाने का प्रयास किया जाए और मुझे एक या दो स्रोत दिए जाएं जो मुझे मेरी अज्ञानता से मुक्त कर सकें?

मुझे गलत साबित करने वाले से ज्यादा रोमांचक कुछ नहीं है। मेरे अनुभव में, यह बढ़ने का सबसे अच्छा तरीका है...