Less.js: मैथ्स को कैसे हैंडल करें

मुझे नहीं लगता कि हम चीजों को बड़े पैमाने पर बदलना चाहते हैं या ड्राइंग बोर्ड पर वापस जाना चाहते हैं

हां, मैंने इसे केवल इसलिए शुरू करने का सुझाव दिया क्योंकि _if_ हम 3.0 में कुछ "डिफ़ॉल्ट" सख्त गणित चाहते हैं, हमें वर्तमान की तुलना में कुछ कम भारी का आविष्कार करना होगा (और किसी भी नए --alt-strict-math को पेश किए बिना सभी समस्याओं को ठीक करने की संभावना font जैसे हार्डकोडिंग समाधान के पीछे छिपे मुद्दों के कारण काफी असत्य प्रतीत होता है ...)

मुझे नहीं पता था कि यह बढ़ रहा है

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

:(

मुझे लगता है कि फिलहाल मैं स्ट्रिक्टमैथ्स को शुरू में विस्तारित करने के पक्ष में हूं

• बंद
• विभाजन
• पर

और फिर 2.0.0 के लिए डिफॉल्ट को डिवीजन के रूप में सेट करना

इसलिए..

मीडिया प्रश्न - यदि बंद है, तो उप-नोड्स के लिए विभाजन पर स्विच करें
फ़ॉन्ट - यदि बंद है, तो उप नोड के लिए विभाजन पर स्विच करें
कैल्क (- यदि बंद या विभाजन है, तो उप-नोड्स के लिए स्विच ऑन करें

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

हां, मुझे लगता है कि वे _any_ "शोरहैंड संपत्ति" में "आशुलिपि मान" (यानी x/y ) की अनुमति देने की ओर हैं ...

संबंधित: https://github.com/less/less.js/issues/1480

एक अन्य विकल्प .. कैल्क कॉल की प्रक्रिया करें लेकिन केवल वहीं जहां इकाइयां इसे संभव बनाती हैं उदा
कैल्क (1% + 2%) => 3%
कैल्क(100% - 10 पीएक्स) => अपरिवर्तित

यह calc को ठीक कर देगा लेकिन #1627 और संबंधित सामग्री को ठीक नहीं करेगा।
मेरा मतलब है हाँ, calc(100% - 10 px) => unchanged calc लिए एक समाधान हो सकता है लेकिन यह less-heavy-than-parens-everywhere समाधान की आवश्यकता को रद्द नहीं करता है।

यदि सख्त गणित पर दोबारा गौर किया जा रहा है, तो मैं यह सुझाव देना चाहूंगा कि percentage() जैसे कम कार्यों को उनके अंदर अतिरिक्त कोष्ठक की आवश्यकता नहीं है। सख्त गणित के साथ, आपको तर्क को दोहराना होगा। यह भ्रम और कठिन-से-खोजने वाले बग की संभावना को बहुत कम कर देगा, क्योंकि percentage(16 / 17) और percentage((16 / 17)) दोनों ही मान्य होंगे।

@calvinjuarez V2 एक प्लगइन सबसिस्टम प्रदान करता है जहां एक प्लगइन पर्यावरण के लिए मनमाने ढंग से कार्यों को जोड़ सकता है और इस अर्थ में कोर यह तय करने में सक्षम नहीं होगा कि इस तरह के अंतर्निर्मित फ़ंक्शन एकल मान या अभिव्यक्ति की अपेक्षा करते हैं, यानी यह है स्वीकार करने की अनुमति है 16/17 , और फिर मूल्यांकन करना 16/17 _before_ यह किसी फ़ंक्शन को दिया गया है गलत होगा (ठीक है, मोटे तौर पर बोलना - यह आंतरिक रूप से थोड़ा अधिक जटिल है)।

उस संदर्भ में ./ परिवर्तन मेरा पसंदीदा प्रतीत होता है, हालांकि मैं समझता हूं कि यह बहुत नाटकीय परिवर्तन होगा (यदि इसकी तुलना (/) , तो इसे गिनने के लिए . से पहले एक व्हाइटस्पेस की भी आवश्यकता होती है। , उदाहरण के लिए 16 ./17 और न कि 16./17 , हम्म)।

एक और चीज जहां कम वर्तमान में वैध सीएसएस तोड़ती है वह पृष्ठभूमि आशुलिपि है:

background: url(image.png) 50%/300px no-repeat;

मुझे लगता है कि फिलहाल मैं स्ट्रिक्टमैथ्स को शुरू में विस्तारित करने के पक्ष में हूं

बंद
विभाजन
पर
और फिर 2.0.0 के लिए डिफॉल्ट को डिवीजन के रूप में सेट करना

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

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

इसे 16/17 स्वीकार करने की अनुमति है, और फिर किसी फ़ंक्शन को पास करने से पहले 16/17 का मूल्यांकन करना गलत होगा

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

हमारे --math विकल्प अधिक पसंद किए जा सकते हैं:

• हमेशा
• डिवीजन (डिफ़ॉल्ट)
• कठोर

इसलिए, हम --strict-math=true को पदावनत कर सकते हैं और इसे --math=strict . के लिए एक उपनाम बना सकते हैं

हालांकि, मुझे लगता है कि इस तरह के तर्कों को संसाधित करने के लिए कार्यों को चुनने की अनुमति देना स्मार्ट होगा, अगर यह समझ में आता है।

उन्हें पहले से ही अनुमति है (बस परीक्षण करें कि percentage(16 / 17) और percentage((16 / 17)) --strict-math=on साथ कैसे काम करते हैं)।
हालांकि कोई भी फ़ंक्शन उपयोग नहीं करता है:

और फिर प्रतिशत फ़ंक्शन कुछ सहायक फ़ंक्शन को यह देखने के लिए कॉल कर सकता है कि टेक्स्ट गणित है या नहीं।

केवल इसलिए कि इस तरह प्रत्येक फ़ंक्शन में उस अतिरिक्त-सहायक-रूपांतरण-आर्ग-चेकिंग-स्मार्ट-आर्ग-हैंडलिंग-सामान की ~ 20 अतिरिक्त लाइनें होनी चाहिए, जबकि अधिकांश मामलों में स्वयं का फ़ंक्शन कोड सिर्फ एक (!) लाइन है।

प्रत्येक फ़ंक्शन में 20 अतिरिक्त लाइनें होनी चाहिए? आप कैसे समझते है?

यदि प्रतिशत पहले से ही एकल कोष्ठक के साथ सख्त गणित पर काम करता है, तो मुझे @calvinjuarez की समस्या समझ में नहीं आती है। आप अपनी प्रतिक्रिया में यह संकेत दे रहे थे कि एकल कोष्ठक प्राप्त करने योग्य नहीं थे।

प्रत्येक फ़ंक्शन में 20 अतिरिक्त लाइनें होनी चाहिए? आप कैसे समझते है?

यह केवल एक सामान्य अतिशयोक्ति है: शायद 5, शायद 10, शायद 20... यदि वास्तविक-कोड/ऑक्स-कोड अनुपात -> 0 तो सटीक संख्याओं की परवाह कौन करेगा। (व्यावहारिक दृष्टिकोण अपनाते हुए मैं percentage(16 / 17) पर रुक जाऊंगा, केवल NaN% (अभी की तरह) के उत्पादन के बजाय एक त्रुटि फेंक रहा हूं, और कोई रूपांतरण करने की कोशिश नहीं कर रहा हूं ... हालांकि इस तरह से भी यह अभी भी है कोड की 4 अतिरिक्त पंक्तियां - ठीक है, कम या अधिक स्वीकार्य मुझे लगता है :)

मेरा प्रारंभिक उत्तर यह कह रहा था कि वह इस 16/17 -> (16/17) रूपांतरण को संकलक द्वारा स्वयं (और फ़ंक्शन द्वारा नहीं) परोक्ष रूप से निष्पादित करने के लिए मानता है।

विकल्पों की बात कर रहे हैं। एक आदर्श दुनिया में मैं सपना देखूंगा कि इसके लिए कोई विकल्प नहीं है (यानी यह एक और एकमात्र होना चाहिए और बाकी को बहिष्कृत और अंततः हटा दिया जाना चाहिए) ... ये सभी अतिरिक्त विकल्प कोडबेस को गैर बनाते हैं -रखरखाव योग्य .. यहां तक ​​​​कि एक छोटे से एक-लाइनर फिक्स/एज-केस की संख्या को बदलने के लिए आपको भविष्यवाणी करनी है और परीक्षण करने के लिए आपको तेजी से बढ़ने की आवश्यकता है ... (लगभग बिना किसी कारण के)।

मैं बस सोच रहा था कि यह कुछ ऐसा होगा:

percentage: function(...) {
  Helper.convertMath(arguments);  // a function that doesn't need it doesn't call it
  // ... the rest
} 

विकल्पों की बात कर रहे हैं। एक आदर्श दुनिया में मैं सपना देखूंगा कि इसके लिए कोई विकल्प न हो

मैं सहमत हूँ। लेकिन हमें अल्पावधि में विकल्पों की आवश्यकता होगी। खासकर अगर हम सख्त गणित और विरासत व्यवहार से विचलित हो रहे हैं। यदि हम "स्मार्ट गणित" विकल्प को पूर्ण करते हैं, तो उन दोनों को बहिष्कृत के रूप में चिह्नित किया जा सकता है।

Helper.convertMath(arguments);

arguments बहुत आशावादी है।
सबसे अच्छा (न केवल percentage गिनती - जो वैसे भी बेकार है , लेकिन कोई अन्य फ़ंक्शन एक संख्यात्मक तर्क की अपेक्षा करता है) न्यूनतम आवश्यकता होगी:

some: function(a, b, c) { 
    a = convert2number(a, "Error message when fails"); 
    // b is not a number for example
    c = convert2number(c, "Error message when fails"); 
} 

लेकिन यह वास्तव में मेरा मुद्दा नहीं था, मेरा मतलब शायद कुछ ऐसा है: जबकि यह हमेशा संभव है/संभव है, कोई भी इस तरह के कोड को लिखने के लिए परेशान नहीं है ... (कुछ सीमित अपवादों के साथ ) ...

हाँ, मैं तुम्हें मिलता हूँ।

percentage(16 / 17) बस एक त्रुटि फेंक रहा है

एक सुधार होगा, निश्चित रूप से। (मैं किसी भी समय यह नहीं सोच सकता कि NaN% एक उपयोगी आउटपुट होगा।)

जहां तक ​​​​कि कौन से कार्य अपने तर्कों के बारे में चतुर होने का प्रयास करेंगे, वहां सब कुछ अनुमान लगाने का प्रयास करने का कोई कारण नहीं है। @ मैथ्यू-डीन के सुझाव के रूप में एक सहायक कार्य को काफी सरलता से लागू किया जा सकता है क्योंकि फीचर अनुरोध किए जाते हैं और विशिष्ट कार्यों को बेहतर बनाने के लिए चर्चा की जाती है।

वास्तव में, शुरू से ही, मैं कहूंगा कि गणित के कार्यों को उनके तर्कों के बारे में स्मार्ट होना चाहिए।

संपादित करें: वास्तव में, जब भी कोई गणित कार्य केवल एक तर्क पारित किया जाता है।

इस पर क्या स्थिति है? हमें शिकायतें मिल रही हैं कि LESS अमान्य CSS गुणों को गणित के रूप में पार्स करने का प्रयास करता है। उदाहरण के लिए lost-column: 1/3; ब्रेक।

ऐसा लगता है कि http://www.w3.org/TR/css-grid-1/#grid -template-rowcol LESS के साथ काम नहीं करेगा।

क्या कोई इसे पैच कर सकता है, यदि कोई स्पष्ट रूप से किसी संपत्ति पर विभाजन करने के लिए LESS का उपयोग करना चाहता है, जिसे उन्हें इसे माता-पिता या कुछ और में लपेटने की आवश्यकता है?

@corysimmons क्या आपने इसे #2769 पर ही नहीं पूछा और जवाब नहीं मिला? ओ_ओ

एक बात जिस पर हमने पहली बार चर्चा नहीं की थी। ऐसा लगता है कि एकमात्र वास्तविक गणित संघर्ष विभाजन है। और विभाजन अनिवार्य रूप से एक मुद्दा है क्योंकि हम अनिवार्य रूप से एक सीएसएस "पृथक्करण" चरित्र को "पुनर्प्रयोजन" कर रहे हैं।

किसी भी तरह से विभाजन को "रैप" करने की कोशिश करने के बजाय, या सभी गणित को लपेटो (इस समस्या के हमारे पहले समाधान के रूप में) मुझे आश्चर्य है कि हमने स्पष्ट के बारे में कभी बात क्यों नहीं की: _मौजूदा ऑपरेटर को पहले स्थान पर दोबारा नहीं लगाना_, खासकर जब यह इतना स्पष्ट रूप से ए) कम कोड अस्पष्ट बनाता है, बी) संघर्ष का कारण बनता है।

हमारे पास इसे पचाने का समय होने के बाद, गणित को कोष्ठकों में लपेटना, भले ही यह केवल विभाजन हो, _still_ उन मामलों के लिए अस्पष्टता का कारण बनता है जहां गणित पहले से ही कोष्ठक में है। (जिसका अर्थ यह भी हो सकता है कि कोष्ठक "गणित आवरण" का गलत विकल्प था।)

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

निष्पक्ष होने के लिए, अन्य गणित प्रतीकों को सीएसएस के अन्य हिस्सों में पुनर्निर्मित किया गया है, यह सिर्फ इतना है कि गणित में उनके उपयोग से कोई अस्पष्टता नहीं होती है।

मैं कुछ विचारों का प्रस्ताव करने जा रहा था, लेकिन, देखो और देखो, विभाजन के लिए पहले से ही मानक वैकल्पिक पात्र हैं। ÷ , जो कीबोर्ड पर नहीं है, मुझे यह मिला:

विभाजन चिन्ह भी गणितीय रूप से अनुपात प्रतीक के बराबर है, जिसे आमतौर पर एक कोलन (:) द्वारा दर्शाया जाता है और "इस टू" पढ़ा जाता है। इस प्रकार, किसी भी वास्तविक संख्या x और किसी भी अशून्य वास्तविक संख्या y के लिए, यह समीकरण मानता है:

एक्स ÷ वाई = एक्स: वाई

दूसरे शब्दों में:

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 

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

विचार?

_वैकल्पिक रूप से, हम अभी भी कोष्ठकों और/या कोष्ठकों में विभाजन चिह्न का समर्थन कर सकते हैं, जैसे:

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 
lost-column: (1/3);
lost-column: [1/3];

हां, यही कारण है कि शुरुआत में मैंने ./ शुरुआत की (मैटलैब वेक्टर-डिव ऑपरेटर से प्रेरित, यह दो सिम्स है लेकिन दृष्टि से हल्के वजन वाले बिंदु के कारण यह शायद कम से कम भारी है, हालांकि कम खराब होने के संदर्भ में डॉट नहीं है एक शानदार विचार)।
: - यह डेज़ी को एक बार फिर से धक्का देगा, इस प्रतीक का उपयोग बहुत सारे सीएसएस संदर्भों में किया जाता है। वास्तव में पहले से ही परस्पर विरोधी वाक्य रचना है:

.foo(<strong i="9">@a</strong>: 1, <strong i="10">@b</strong>: 2) {
  result: <strong i="11">@a</strong> @b;  
}

bar {
    <strong i="12">@b</strong>: 4;
    .foo(<strong i="13">@b</strong>:3); // would mean both @second-parameter:3 and 4/3
}

@ सात-चरण-अधिकतम आह, हाँ, धिक्कार है। यदि केवल कीबोर्ड बड़े होते। हां, विभाजन के लिए 2-वर्ण अनुक्रम अपरिहार्य लगता है। मुझे पूरा सूत्र पढ़े हुए काफी समय हो गया था, इसलिए मैं इसके बारे में भूल गया। ./ यह वास्तव में बुरा नहीं है। यदि आप और @lukeapage दोनों बोर्ड पर हैं, तो यह एक बुरा समझौता नहीं होगा। हो सकता है कि हम इसे प्रस्ताव चरण में ले जाएं, और देखें कि क्या कोई आपत्ति है?

इस बिंदु पर वापस पढ़ना:

इसे गिनने के लिए . से पहले एक व्हाइटस्पेस की भी आवश्यकता होती है, उदाहरण के लिए 16 ./17 और 16./17

मुझे यकीन नहीं है कि मैं सहमत हूं। हां, तकनीकी रूप से 16. एक वैध संख्या है, लेकिन किसी के लिए इसे इस तरह लिखना विचित्र होगा। मुझे लगता है कि आप इसे कैसे भी लिखेंगे, सफेद स्थान या नहीं, इसे 16 को 17 से विभाजित करना चाहिए।

एक सही विकल्प नहीं होगा, लेकिन मुझे लगता है कि यह ए से बेहतर है) डिफ़ॉल्ट रूप से विभाजन के लिए / का उपयोग करना, बी) हमेशा कोष्ठक की आवश्यकता होती है। (अतीत में मेरी स्थिति के बावजूद, मैं भी हां के आसपास आया हूं, यह एक प्रकार का कष्टप्रद है, विशेष रूप से अन्य कोष्ठकों में। और विशेष रूप से क्योंकि यह केवल मेरी जानकारी के लिए विभाजन के कारण आवश्यक है। हां?)

मुझे लगता है कि आप इसे कैसे भी लिखेंगे, सफेद स्थान या नहीं, इसे 16 को 17 से विभाजित करना चाहिए।

हाँ, वास्तव में।
हालांकि इसके बारे में अधिक सोचने पर मुझे उम्मीद है कि पार्सर को कुछ अतिरिक्त चालबाजी डालने के लिए ./ (संख्या पार्सिंग को ./ से पहले रोकने के लिए अतिरिक्त रूप से देखने की आवश्यकता होगी, जबकि वर्तमान में यह हमेशा . समाप्त होता है। )

और विशेष रूप से क्योंकि यह केवल मेरी जानकारी के लिए विभाजन के कारण आवश्यक है। हां?)

हाँ बिल्कुल। calc के अंदर कोड की गिनती नहीं करना - लेकिन इसके लिए मुझे लगता है कि @lukepage द्वारा सुझाए गए समाधान को चाल चलनी चाहिए।

(तकनीकी रूप से, भविष्य में यह +, -, * लिए कुछ अतिरिक्त अस्पष्टता हो सकती है यदि वे अपने CSS रंग हेरफेर फ़ंक्शन सिंटैक्स पर बने रहें - लेकिन यह बहुत नाटकीय नहीं होना चाहिए क्योंकि वहां के मान * 20% रूप में हैं (इस प्रकार उन्हें स्पष्ट रूप से कुछ गैर-कम-मूल्यांकन किए गए expr के रूप में पहचाना जा सकता है। उन सभी मज़ा के बाद भी कुछ पार्सिंग परिवर्तनों की आवश्यकता होगी क्योंकि वर्तमान में (* 20%) जैसे मान पार्सिंग त्रुटि का कारण बनते हैं)।

शायद... हम यह सब गलत कर रहे हैं। (निश्चित रूप से मुझे इसमें शामिल है, क्योंकि मैं "सख्त गणित" सुविधा का प्रारंभिक उत्साही समर्थक था।)

हम गणित को सार्वभौमिक रूप से काम करने की कोशिश कर रहे हैं, लेकिन .... इसकी वास्तव में आवश्यकता नहीं है। यही है, हम उन मामलों में गणित करने की कोशिश कर रहे हैं जहां यह स्पष्ट होना चाहिए कि कोई गणित नहीं किया जाना चाहिए।

calc(100% - 10px) उदाहरण सबसे स्पष्ट है। कोई कम गणना नहीं है जिसे तब तक किया जा सकता है/किया जाना चाहिए जब तक कि हम इकाइयों को कास्ट नहीं करते हैं, जो मैं सहमत हूं कम को डिफ़ॉल्ट रूप से करना बंद कर देना चाहिए। ¹

आइए एक उदाहरण के रूप में प्रयुक्त फ़ॉन्ट शॉर्टहैंड संपत्ति को देखें।

font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
font: italic bold 12px/30px Georgia, serif;

इसके लिए वर्तमान समाधान strict-math: on को फ़ॉन्ट गुण के लिए चालू करना है। लेकिन... किसी भी गणना को सबसे पहले कम क्यों करना चाहिए? निश्चित रूप से, 13px/150% गणित में एक मान्य कथन है, लेकिन क्या इसे कम में मान्य मानना ​​उचित है? 12px/30px आप _could_ को एक मान्य गणित कथन के रूप में मान सकते हैं, लेकिन क्या आपको ऐसा करना चाहिए? ²

वह है: कम में, इकाइयों पर गणित संचालन _integers_ और _floats_ द्वारा किया जाना चाहिए, न कि इकाइयों द्वारा। हम इन्हें मान्य गणित कथनों के रूप में मान रहे हैं, जैसे कि लोग वास्तव में अपना गणित इस तरह लिख रहे हैं। लेकिन मैं नहीं देखता कि यह कैसे सच हो सकता है।

यानी, किसी को 13px/150% को 13px/1.5 रूप में लिखने की आवश्यकता उचित है। और यहां तक ​​कि इस तथ्य की अनदेखी करते हुए कि 12px/30px गणित के संचालन के रूप में कोई मतलब नहीं होगा, हमें यह जानने की जरूरत नहीं है कि यह नहीं है, और हमें font को श्वेत-सूचीबद्ध करने की आवश्यकता नहीं है . यदि कोई कम लेखक गणित का ऑपरेशन कर रहा होता, तो वे यथोचित रूप से इसे 12px/30 लिख रहे होते। इतना ही नहीं यह उचित होगा, इसकी बहुत अधिक संभावना है कि _वे इसे पहले स्थान पर कैसे लिख रहे हैं_।

मेरे लिए एक मिश्रण लिखना या यहां तक ​​​​कि एक ही ब्लॉक में कुछ इस तरह का उपयोग करना आम बात है:

width: <strong i="5">@size</strong> / 2;
height: <strong i="6">@size</strong> / 2;

मैं इसे इस तरह क्यों लिखूंगा? क्या _कोई_ इसे इस तरह लिख रहा है?

width: <strong i="10">@size</strong> / 2px;
height: <strong i="11">@size</strong> / 2px;

ऑपरेशन _sort of_ समझ में आता है यदि @size एक px इकाई है, लेकिन, इसकी परवाह किए बिना, यह कम/सीएसएस के दायरे में बाद के मामले में गणित करने की कोशिश करने के लिए कम समझ में आता है जब भाजक एक इकाई के साथ एक मूल्य है। दूसरा गणित जैसा नहीं लगता। यह एक सीएसएस मूल्य की तरह दिखता है।

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

<strong i="18">@pad</strong>: 2px;
width: 10px + @pad; 

लेकिन जब एक मान w/इकाई को दूसरी w/एक भिन्न इकाई में जोड़ना/घटाना हो, तो कम को इसे अकेला छोड़ देना चाहिए।

<strong i="22">@val1</strong>: 100%;
<strong i="23">@val2</strong>: 10px;
width: calc(<strong i="24">@val1</strong> - @val2);

// output
width: calc(100% - 10px);

जोड़/घटाव (या पूर्णांक/फ्लोट) के लिए मिलान इकाइयों की आवश्यकता होती है, और इकाइयों के खिलाफ गणित संचालन में पूर्णांक/फ्लोट की आवश्यकता होती है (इकाइयों द्वारा गुणा/विभाजित कोई इकाई नहीं) 99% अस्पष्टताओं को हल करेगी, और अभी भी बिना किसी नए के वैध गणित संचालन की अनुमति देगी प्रतीकों .

उदाहरण के लिए, उन नियमों के आधार पर, पृष्ठभूमि आशुलिपि ठीक होगी:

background: no-repeat 10px 10px/80% url("../img/image.png");

% एक CSS इकाई है। px एक अलग CSS इकाई है। इसलिए, कोई गणित नहीं। विशेष अपवाद शून्य होगा।

background: no-repeat 0 0/80% url("../img/image.png");

यदि कोई शून्य को किसी अन्य संख्या से विभाजित करता हुआ प्रतीत होता है, या किसी संख्या को शून्य से विभाजित करता है, तो मुझे लगता है कि हम सुरक्षित रूप से केवल आउटपुट कर सकते हैं।

सीमा-त्रिज्या, वही बात:

border-radius: 30% / 20%;

कम इसे पास देंगे। यदि कोई गणित करना चाहता है, तो उसे लिखने का उपयुक्त तरीका यह होगा:

border-radius: 30% / 0.2;

अच्छी बात यह है कि इन भेदों को बनाकर, यह स्पष्ट होना चाहिए कि एक गणित ऑपरेशन _cannot_ एक CSS मान हो, क्योंकि border-radius उदाहरण की तरह, एक मान्य CSS मान के लिए दोनों पक्षों की इकाइयों की आवश्यकता होगी। कोई ओवरलैप/अस्पष्टता नहीं होगी।

एक मामले को छोड़कर मैं सोच सकता हूं, और अन्य भी हो सकते हैं:

font: 10px/1.5;

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

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

मैं गैलरी की प्रतिक्रियाओं/टिप्पणियों का स्वागत करता हूं।

¹ _मुझे एहसास हुआ कि मुझे यह स्पष्ट कर देना चाहिए कि टिप्पणियां , और @ सेवन -फेज-मैक्स का लिंक ही मुझे इस दिशा में सोचने पर
² _जैसा कि मैंने उदाहरणों को देखते हुए पाया, फ़ॉन्ट के लिए सख्त-गणित चालू करना एक अपरिहार्य समाधान हो सकता है, लेकिन मुझे लगता है कि बाकी तर्क लागू होते हैं।_

केवल कुछ ऐतिहासिक संदर्भों के लिए, यह ध्यान रखना महत्वपूर्ण है कि जब कम.जेएस को पहली बार रिलीज़ किया गया था तो कास्टिंग इकाइयां उतनी समस्या नहीं थीं। calc() लागू नहीं किया गया था, और background और border-radius में मान्य मानों के रूप में स्लैश नहीं थे। मुझे लगता है कि font एकमात्र ऐसी जगह थी जिसने चीजों को ट्रिप किया (जो, विडंबना यह है कि अभी भी मामला हो सकता है)।

मेरी एकमात्र चिंता कार्यान्वयन पक्ष है, उदाहरण के लिए: calc(4px + 2rem + 20%) (वास्तविक इकाइयों से कोई फर्क नहीं पड़ता) के लिए, पहला जोड़ परिणाम अब और संख्यात्मक परिणाम नहीं देता है, इस प्रकार दूसरा अतिरिक्त हैंडलर इसके इनपुट को अलग नहीं कर सकता है जो कुछ भी not-a-number + 20% कथन जहां उसे एक त्रुटि फेंकनी चाहिए। शायद कोई बड़ी समस्या नहीं है (अतिरिक्त प्रकार/प्रकार-झंडे लगाकर हल करने योग्य), लेकिन अभी भी कुछ जांच की जरूरत है।

और दूसरी चिंता एहम है, निश्चित नहीं है, "रेडैबिलिटी"? यानी स्पष्ट संख्याओं के लिए परिणाम क्रिस्टल स्पष्ट दिख रहा है, चर के लिए यह काफी अस्पष्ट दिखने लगता है, उदाहरण: border-radius: 10px <strong i="8">@a</strong> / <strong i="9">@b</strong> 30px; - आप कभी नहीं जानते कि इसका क्या अर्थ है जब तक आप @a और @b परिभाषाएं।

और हाँ, font अभी भी एक समस्या बनी हुई है (संभवतः अन्य शॉर्टहैंड-गुण दोनों पक्षों पर इकाइयों का उपयोग करते प्रतीत होते हैं लेकिन फिर हम कभी नहीं जानते कि वे आगे क्या करते हैं (#2769 जैसी चीजों की गिनती भी करते हैं)... ए कुछ और उपहार जैसे font और यह फिर से टूटा हुआ दिखने लगेगा)।

पुनश्च एक और मुद्दा (शायद एक मामूली प्रतिगमन)। इस तरह के मूल्य हैं:

border-radius: 10px / auto;
border-radius: 1px inherit / 2px;
background: ... center / 80% ...;
// etc.

यानी पूरी चीज काम करने के लिए हमें किसी भी मौजूदा असंगत-div-operand-त्रुटियों को अक्षम करना होगा ताकि कोई भी foo/bar , 1x/bar और foo/1x w/oa पास कर सकें त्रुटि।

मेरी एकमात्र चिंता कार्यान्वयन पक्ष है, उदाहरण के लिए: कैल्क (4px + 2rem + 20%) के लिए (वास्तविक इकाइयां कोई फर्क नहीं पड़ता)

मैं यही कह रहा हूं। वास्तविक इकाइयों को मायने रखना चाहिए। कम उसे अकेला छोड़ देना चाहिए, परवाह किए बिना। ब्राउज़र में 4px + 2rem का अर्थ है, लेकिन कम में अर्थहीन है। जब इसका कोई मतलब नहीं है, तो इसे जोड़ने का प्रयास करने का कोई कारण नहीं है, और इन ऐड-ऑन मुद्दों का कारण बनता है।

उदाहरण: border-radius: 10px <strong i="10">@a</strong> / <strong i="11">@b</strong> 30px ; - जब तक आप @a और @b परिभाषाएं नहीं देखते, तब तक आप इसका अर्थ नहीं जान पाएंगे।

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

इन गणित नियमों के साथ मैं प्रस्तावित कर रहा हूं, इस पर विचार करें:
calc(4px + 2rem - 2px)

कम इसकी गणना कर सकता है/कर सकता है calc(2px + 2rem) , जो वास्तव में पूरी तरह से ठीक है, और वास्तव में एक सही मूल्य आउटपुट है। अभी, कम इसकी गणना calc(4px) में करता है, जो एक सही या उपयोगी उत्तर नहीं है। (हाँ, यह है कि अगर हम इकाइयों छोड़ वर्तमान में सही है, लेकिन इकाइयों अंतर-संचालित नहीं व्यर्थ नहीं कर रहे हैं, और कुछ मामलों को छोड़कर,।) कम की गणना करता है 2px + 100% के रूप में 102px , वहाँ में कुछ मूल्य है, जैसे कि वह परिणाम, जब कोई संभवतः परिणाम के रूप में ऐसा नहीं चाहेगा।

काम करने के लिए पूरी चीज के लिए हमें किसी भी मौजूदा असंगत-डिव-ऑपरेंड-त्रुटियों को अक्षम करना होगा ताकि कोई भी फू/बार, 1x/बार और फू/1x w/oa त्रुटि पास कर सके।

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

कैल्क (2px + 2rem) के रूप में कम गणना कर सकता/सकती है

मुझे डर है कि यह कभी नहीं होगा क्योंकि इसके लिए एक नए अनुकूलन अभिव्यक्ति हैंडलर की आवश्यकता होगी जो एक ओवरकिल होगा (मूल रूप से 4px + 2rem - 2px पेड़ में (4px + 2rem) - 2px रूप में संग्रहीत किया जाता है ताकि 2px + 2rem यह सभी वैध फेरबदल का प्रयास करने के लिए एक पुन: आदेश देने वाला इंजन होना चाहिए (इस विशेष मामले में तुच्छ लेकिन अधिक ऑपरेंड/ऑपरेटरों के लिए काफी जटिल हो रहा है)। लेकिन कोई बात नहीं, 4px + 2rem - 2px को जैसा है वैसा ही छोड़ना ठीक है (बाद में) सभी यदि आप 4px - 2px + 2rem तो यह अनुकूलित है)।

लेकिन उस टिप्पणी से मेरा वास्तव में जो मतलब था, वह कुछ इसी तरह की है:

ताकि कोई भी foo/bar, 1x/bar और foo/1x w/oa त्रुटि पास कर सके।

यानी (4px + 2rem) - 2px expr.evaluator के लिए समान होगा foo + 2px , इस प्रकार काम करने के लिए इसे उस तरह की चीजों के लिए भी त्रुटियां उत्पन्न नहीं करनी चाहिए।
असल में, मैंने foo/bar, 1x/bar, foo/1x परीक्षण किया और वे पहले से ही w/o त्रुटियां पास कर चुके हैं (अजीब मैंने सोचा कि वे फेंक देते हैं), लेकिन अन्य ऑपरेटरों के परिणामस्वरूप सभी प्रकार की अजीब चीजें होती हैं (हालांकि वास्तव में कुछ भी महत्वपूर्ण नहीं है, बस प्रत्येक मामले को ठीक करने का मामला है एक के बाद एक)।

मुझे डर है कि यह कभी नहीं होगा क्योंकि इसके लिए एक नए अनुकूलन अभिव्यक्ति हैंडलर की आवश्यकता होगी जो एक ओवरकिल होगा (मूल रूप से 4px + 2rem - 2px पेड़ में संग्रहीत किया जाता है (4px + 2rem) - 2px तो 2px + 2rem प्राप्त करने के लिए इसमें है सभी वैध शफलिंग (इस विशेष मामले में तुच्छ लेकिन अधिक ऑपरेंड/ऑपरेटरों के लिए काफी जटिल बनने) का प्रयास करने के लिए एक पुन: आदेश देने वाला इंजन बनना।

क्यों फेरबदल? आप समान वरीयता स्तर पर ऑपरेटरों को समतल करते हैं (इसलिए पेड़ Sum(4px, 2rem, -2px) ), संगत इकाइयों के साथ शब्द एकत्र करें (शायद पहले से इकाइयों को सामान्य करके), और प्रत्येक भाग को सरल बनाएं। यह प्रतीकात्मक बीजगणित है, जहां इकाइयों को स्वतंत्र चर के रूप में माना जाता है।

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

मुद्दा यह है कि, जबकि इसे हल करना आसान समस्या नहीं है, अधिक सामान्य समस्या पहले से ही बहुत अच्छी तरह से हल हो चुकी है, और ऐसा सबसिस्टम अन्य तरीकों से कम.जेएस के लिए उपयोगी हो सकता है।

आप समान वरीयता स्तर पर ऑपरेटरों को फ़्लैट करते हैं (इसलिए पेड़ Sum(4px, 2rem, -2px) है),

और क्या वास्तव में कोड को यह सोचने के लिए बनाता है कि कुछ अभिव्यक्ति वृक्ष वास्तव में सपाट है? (तो मेरा "पीड़ा" कुछ विशिष्ट कटौती एल्गोरिदम के बारे में नहीं है, लेकिन आपके "समतल" सहित "उन सभी को आजमाएं" के लिए एक शॉर्टकट है)।

लेकिन वहाँ बहुत सारे पुस्तकालय हैं जो शायद बेहतर परीक्षण किए गए हैं और पूर्ण होने की अधिक संभावना है।

मुझे यकीन नहीं है कि आप गंभीर हैं। तो आपको लगता है कि कम पेड़ को बाहरी lib पेड़ में बदलने के लिए वह सब कोड और पीछे (उन जेएस libs में से कोई भी गिनती नहीं है जो सीएसएस इकाइयों को संभाल सकता है) वास्तव में उस विशिष्ट 4px + 2rem - 2p मामले को अनुकूलित करने के लायक है? हम्म...

तो, कोई समस्या नहीं है (मैंने यह नहीं कहा कि यह असंभव है कि यह कभी भी इसके लायक नहीं होगा) - कोशिश करें और पीआर का स्वागत है।
(इसके अलावा शायद यह ध्यान रखना महत्वपूर्ण है कि सबएक्सप्रेशन ऑप्टिमाइज़ेशन चीज़ इस टिकट का लक्ष्य भी नहीं है, यहां तक ​​​​कि इसके शीर्ष तीन में भी नहीं)।

और क्या वास्तव में कोड को यह सोचने के लिए बनाता है कि कुछ अभिव्यक्ति वृक्ष वास्तव में सपाट है? (तो मेरा "पीड़ा" कुछ विशिष्ट कटौती एल्गोरिदम के बारे में नहीं है, लेकिन आपके "समतल" सहित "उन सभी को आजमाएं" के लिए एक शॉर्टकट है)।

पार्सर निर्धारित करता है कि संदर्भ "लंबाई" है, और क्या उपट्री को "लंबाई" के रूप में व्याख्या किया जा सकता है।

मुझे यकीन नहीं है कि आप गंभीर हैं। तो आपको लगता है कि कम पेड़ को बाहरी lib पेड़ में बदलने के लिए वह सब कोड और पीछे

इसे सिंटैक्स ट्री में पार्स करने की आवश्यकता है। वहां से, बीजीय व्यंजक का प्रतिनिधित्व करने वाली एक स्ट्रिंग को आउटपुट करना अपेक्षाकृत सरल होगा। वापस जाना कठिन हो सकता है: इसे एक स्ट्रिंग से फिर से पार्स करने की आवश्यकता हो सकती है, या हाँ, इसे बाहरी lib के पेड़ को लेने की आवश्यकता हो सकती है। कठिनाई इस बात पर निर्भर करती है कि कौन सा पुस्तकालय चुना गया है।

(उन JS libs में से कोई भी गिनती नहीं करना CSS इकाइयों को संभाल सकता है)

आप बस इकाइयों को बीजीय चर में बदल देंगे। प्रतिस्थापन (जैसे mm -> px ) तब भी किया जा सकता है जब अभिव्यक्ति प्रतीकात्मक रूप में हो।

वास्तव में उस विशिष्ट 4px + 2rem - 2p मामले को अनुकूलित करने के लायक है?

मैं अभिव्यक्ति अनुकूलन के लिए एक वैकल्पिक सुझाव दे रहा हूं जो कम कठिन है (एक एल्गोरिदम समस्या के रूप में जिसे कम का अपना कोड हल करना होगा) और जो आपने कहा था उससे अधिक आम तौर पर उपयोगी था।

बीजगणितीय सरलीकरण कोष्ठकों में उप-अभिव्यक्तियों के साथ चीजों को हल कर सकता है, और कम को और अधिक मैथी सुविधाओं को जोड़ने की अनुमति देता है।

कोशिश करो और पीआर का स्वागत है।

मै कोशिश करूँगा। मैंने केवल आज ही कम देखना शुरू किया है, और मुझे परियोजनाओं को पूरा करने में समस्या है, इसलिए मैं मानता हूं कि मुझे शायद पीआर आउट नहीं मिलेगा।

इसके अलावा, शायद यह ध्यान रखना महत्वपूर्ण है कि सबएक्सप्रेशन ऑप्टिमाइज़ेशन चीज़ इस टिकट का लक्ष्य भी नहीं है, यहां तक ​​​​कि इसके शीर्ष तीन में भी नहीं

मैं जानता हूँ। मैं यहां एक कारण से था। ऐसा दंश क्यों?

ऐसा दंश क्यों?

ठीक है, हो सकता है... यदि ऐसा है - मेरे लिए खेद है (ऐसा लगता है कि मैं प्रयासों और समय से बहुत हैरान हूं और कोई मौजूदा calc(4px + 2rem - 2px) समस्या को हल करने के लिए समर्पित करने के लिए तैयार है। शायद हमारे पास बहुत अलग धारणा है हल्केपन का)।

और कम को अधिक मैथिली सुविधाओं को जोड़ने की अनुमति दें।

क्या आप कुछ का नाम बता सकते हैं?

बहुत अधिक मौजूदा calc(4px + 2rem - 2px) समस्या को हल करने के लिए

हुह? कम इसे बिल्कुल भी नहीं संभाल सकता। [बाकी हटा दी गई क्योंकि मैंने गलत समझा कि क्या संबोधित किया जा रहा था]

प्रस्ताव को सरल/पुनर्स्थापित करने के लिए - गणित में परिवर्तन इस प्रकार होंगे

1. जोड़ और घटाव की गणना समान इकाइयों पर ही की जाएगी। उदाहरण के लिए 1px + 2px = 3px , 1px + 1vh = 1px + 1vh
2. भाग और गुणन की गणना केवल इकाई-रहित भाजक/गुणकों के साथ की जाएगी। जैसे 10px/2 = 5px , 10px/5px = 10px/5px
3. इकाइयों के बिना मूल्य अनुपात # 2 के समान माना जाएगा। उदाहरण के लिए 1/3 = 1/3
4. सरलीकरण के लिए, आंशिक रूप से अमान्य उप-अभिव्यक्तियों वाले व्यंजकों को अमान्य गणित व्यंजक और आउटपुट के रूप में माना जा सकता है। जैसे 1px + 2vh / 2 = 1px + 2vh / 2

यह प्रस्ताव निम्नलिखित को हल करता है ( इस धागे से ):

• font: 10px/5px और समान (अनुपात) सिंटैक्स (कोई गणना नहीं)
• calc(100vh - 30px) (कोई गणना नहीं)
• lost-column: 1/3 और समान कस्टम अनुपात सिंटैक्स (कोई गणना नहीं)

साथ ही, ये परिवर्तन 99% विशिष्ट कम गणित उपयोग को संरक्षित रखेंगे। साथ ही, मौजूदा unit() और convert() फ़ंक्शन उपयोगकर्ताओं को गणित के लिए संगत इकाइयों में मान डालने की अनुमति देते हैं।

कम इसे बिल्कुल भी नहीं संभाल सकता।

आपने अभी वह नहीं पढ़ा जो मैं और @leewz ऊपर बात कर रहे थे। इसका calc(100vh - 30px) से कोई लेना-देना नहीं था। और मेरा "बहुत अधिक मौजूदा समस्या को हल करने के लिए" पूरी तरह से " calc में अंकगणितीय अभिव्यक्तियों को अनुकूलित करने" के लिए जाता है।

@ सात-चरण-अधिकतम ओह्ह ठीक है। माफ़ करना। नहीं, हमें अनुकूलित करने की आवश्यकता नहीं है। बस यह पता करें कि गणित कब करना है।

इस समस्या को स्वचालित रूप से पुराने के रूप में चिह्नित कर दिया गया है क्योंकि इसमें हाल की गतिविधि नहीं है। आगे कोई गतिविधि नहीं होने पर इसे बंद कर दिया जाएगा। आपके योगदानों के लिए धन्यवाद।

स्लेट लेबल को हटाना क्योंकि समस्या अभी भी महत्वपूर्ण है और सीएसएस के विकसित होने के साथ ही और भी बदतर होती जा रही है।

@ मैथ्यू-डीन
यहां एक पल के लिए शैतान के वकील का किरदार निभाने जा रहा हूं...

12px/30px आप _could_ को एक मान्य गणित कथन के रूप में मान सकते हैं, लेकिन क्या आपको ऐसा करना चाहिए?

हां; तुम्हे करना चाहिए। यह एक अदिश मान की गणना करता है जो दोनों आकारों के बीच के अनुपात का प्रतिनिधित्व करता है और जो एम यूनिट में कनवर्ट करते समय काफी उपयोगी हो सकता है।

मान लें कि मेरे पास 16px का एक ज्ञात आधार फ़ॉन्ट आकार और 24px का एक ज्ञात शीर्षक आकार है, दोनों चर में टक गए हैं, और फिर मैं सही फ़ॉन्ट आकार के साथ शीर्षक का एक विशेष स्वाद असाइन करना चाहता हूं, लेकिन एक em इकाई में।

@fontsize-body    : 16px;
@fontsize-heading : 24px;

// ( ... and then somewhere else ... )

.heading {
  font-size : unit(@fontsize-body/@fontsize-heading, em);

  // Or if dividing compatible unit values is produces a unit-less scalar
  // value ( as it really _should_ -- mind you... ),  you could prefer:
  font-size : @fontsize-body/@fontsize-heading * 1em;
}

और यदि आपको गणित व्यंजक के रूप में संगत इकाइयों के विभाजन का समर्थन करने की आवश्यकता है, तो आपको प्रत्येक आधे मामलों को कवर करने के लिए कम गणित के भावों से शाब्दिक सीएसएस को अलग करने के तरीके का समर्थन करने की आवश्यकता होगी।

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

इसलिए...

अपने तर्क को इधर-उधर क्यों नहीं करते? यदि कोई चीज़ गणित के व्यंजक की तरह दिखती है और उसकी संगत इकाइयाँ हैं तो उसे डिफ़ॉल्ट रूप से गणित व्यंजक के रूप में माना जाएगा । और अगर आप नहीं चाहते कि ऐसा हो... ठीक है; फिर ~"..." एस्केप हैच का उपयोग करें। यह वही है जो इसके लिए है, आखिर...

प्रस्ताव की मेरी वर्तमान दृष्टि:

• / को किसी भी अनटिस की परवाह किए बिना और किसी भी विकल्प की परवाह किए बिना कहीं भी विभाजन के रूप में इलाज करना बंद करें (जब तक कि - वैकल्पिक रूप से - यह अनावश्यक माता-पिता द्वारा संलग्न है जैसे -sm=on)
  इस प्रकार केवल 1anything./3whatever और (वैकल्पिक रूप से) (1anything/3whatever) का मूल्यांकन कम द्वारा किया जाता है।
• + , - और * अपरिवर्तित रहेंगे
• calc किसी भी अंकगणित का मूल्यांकन न करके उप-समस्या का समाधान किया जाता है। calc(...) अंदर अभिव्यक्तियां (हालांकि, फिर भी, अनावश्यक माता-पिता का भी उनका प्रभाव हो सकता है)।

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

इसके साथ समस्या यह है कि / डिवीजन ऑपरेटर के रूप में अविश्वसनीय रूप से अंतर्निहित है। इसके लिए किसी अन्य प्रतीक का उपयोग करना उपयोगकर्ताओं के लिए कठिन बिक्री होगी। आप सामान्य उपयोग के मामले को ले रहे हैं और इसे असाधारण उपयोग के मामले (सीएसएस शॉर्टहैंड में / ) के लिए बाहर फेंक रहे हैं जिसका शायद ही कोई कभी उपयोग करता है।

@rjgotten

उस के साथ समस्या है / अविश्वसनीय रूप से डिवीजन ऑपरेटर के रूप में अंतर्निहित है।

सीएसएस में नहीं।

असाधारण उपयोग के मामले (/ सीएसएस शॉर्टहैंड में) के लिए जो शायद ही कभी कोई उपयोग करता है।

अब तक / का पहले से ही बहुत उपयोग किया जा चुका है, और इसकी तुलना में यह कम div op इन दिनों CSS / तुलना में पूरी तरह से अधिक असाधारण है (इसके विपरीत यह कुछ साल पहले था जहां CSS / ज्यादातर केवल font भीतर ही मिल सकता है)।

@ सात-चरण-अधिकतम इसे शीर्ष पर रखने के लिए धन्यवाद। मैंने मुद्दों को प्रबंधित करने में हमारी मदद करने के लिए बासी बॉट को जोड़ा और बासी को चिह्नित करने के लिए काफी उदार समय दिया। मैंने दो लेबल, "बग" और "अप-फॉर-ग्रैब्स" से भी छूट दी है। उस पर किसी भी सुझाव का स्वागत है, जैसे श्वेतसूची में अन्य लेबल। फ़ाइल यहाँ है: https://github.com/less/less.js/blob/3.x/.github/stale.yml

मुद्दे के सूत्र पर वापस आना...

@rjgotten
आपका उपयोग मामला एक मनमाना समस्या पैदा करता है। तर्क यह है कि यह उपयोगी है। लेकिन इस तरह से अपने वर्रों को संरचित करना एक समस्या पैदा करता है जो वाक्यविन्यास से बचने योग्य है, जैसा कि @ सात-चरण-अधिकतम इंगित किया गया है, अस्पष्ट है।

यहां तक ​​​​कि अंकित मूल्य पर लिया गया, सीएसएस के साथ कम सिद्धांतों के लिए गाइड के रूप में, आप कैल्क में, 12px को 30px से विभाजित नहीं कर सकते। कम में ऐसा करने से न केवल अस्पष्टता की समस्या पैदा होती है, बल्कि यह बिना किसी अच्छे कारण (ऐतिहासिक के अलावा) के मॉडल से टूट जाता है। संभवत: उन चीजों में से एक जो कम से गायब है, वह इकाई-मूल्य के संख्यात्मक मान को निकालने का एक तरीका है ताकि कम को विभाजन के लिए यह गणित जादू न करना पड़े।

तो, सरल उत्तर यह है कि आपका उदाहरण कुछ इस तरह दिखेगा:

font-size : @fontsize-body/number(@fontsize-heading) * 1em

लेकिन मैं @ सेवन-फेज-मैक्स के प्रस्ताव के साथ भी ठीक हूं। हम अभी भी _vars_ का मूल्यांकन calc() , लेकिन गणित का नहीं। और माता-पिता के बाहर विभाजन का मूल्यांकन न करें। मुझे लगता है कि यह एक अच्छा समझौता है। और, संभवतः, यदि आप एक इकाई को एक इकाई से विभाजित करने के जादू विभाजन गणित को संरक्षित करना चाहते हैं लेकिन इकाई को रखते हुए (जो अभी भी अजीब है, लेकिन यह ठीक है), यह माता-पिता के भीतर हो सकता है।

मुझे पता है कि कम में गणित के विषय पर कुछ अलग प्राथमिकताएं हैं, लेकिन मुझे लगता है कि यह वास्तव में बहुत अच्छा होगा यदि हम किसी ऐसी चीज पर आम सहमति तक पहुंच सकें जिससे कम से कम दुष्प्रभाव हो और बड़े रखरखाव के बिना तर्क करना सबसे आसान हो। या विकास का बोझ

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

संभवत: उन चीजों में से एक जो कम से गायब है, वह इकाई-मूल्य के संख्यात्मक मान को निकालने का एक तरीका है

unit फ़ंक्शन वास्तव में ऐसा करता है यदि आप दूसरा पैरामीटर निर्दिष्ट नहीं करते हैं। लेकिन यह इस तथ्य का एक और साइड-इफेक्ट है कि स्केलर्स को वर्तमान में Dimension नोड प्रकार के साथ कार्यान्वित किया जाता है जिसमें एक इकाई परिभाषित नहीं होती है।

दिया गया; यह बहुत लंबा रास्ता तय करता है, लेकिन अगर आप _वास्तव में संगत इकाइयों वाले आयामों को विभाजित करने से बचना चाहते हैं, तो यूनिट को बंद करना काम करेगा।

मैं यह भी जोड़ूंगा कि मैं इस विशेष संदर्भ में किसी भी "संगत इकाइयों" अनुमानों के खिलाफ हूं (जैसे a/b को एक डिवीजन और b/c लिए रहने दें)।
सिर्फ इसलिए कि:

• असाधारण हैंडलिंग सभी बुराइयों की जड़ है (उदाहरण #3047 - नीचे देखें, http://stackoverflow.com/questions/19705791- मुझे याद है कि मुझे SO समस्या का कारण तब तक नहीं मिला जब तक कि मैं वास्तव में प्रत्येक ज़िलियन लाइन के माध्यम से कदम नहीं उठाता डिबगर में शामिल कम कोड)।
• और सबसे महत्वपूर्ण, यह सिर्फ भविष्य-सबूत नहीं है, यानी यदि कोई बड़ा ब्रेकिंग-चेंज अपरिहार्य है तो हम इसे एक बार (और आदर्श रूप से हमेशा के लिए) सुनिश्चित करना बेहतर समझते हैं ... और ऐसा नहीं है कि वे a/b शामिल कुछ नई सीएसएस सुविधा जोड़ते हैं

तो मेरे लिए "संगत इकाइयां" सामान पूरी तरह से असंबंधित और ऑर्थोगोनल चीज़ की तरह है (परिणामी इकाइयों पर -su साथ या बिना कुछ चर्चा हो सकती है, लेकिन यह एक और कहानी है)।

(विषय से परे:)
और बीटीडब्ल्यू।, उपरोक्त उदाहरणों की बात करते हुए:
@rjgotten अगर आपके पास है:

@fontsize-body/@fontsize-heading * 1em; 

आपके कोड में कहीं और दो चरों में से कोई भी px आप वास्तव में एक बग का उपयोग कर रहे हैं :)
उचित कोड है:

1em * @fontsize-body/@fontsize-heading;

यह हमेशा http://lesscss.org/features/#features -overview-feature-operations के अनुसार एक अच्छी तरह से परिभाषित इकाई में परिणत होता है (# 3047 को ठीक करने के लिए, बग फिर से एक बग का एक उदाहरण है जो वास्तव में बहुत अधिक उत्पन्न होता है कोड बेस में "संगत इकाइयों" के आसपास अनुमान लगाने वाला कोड)। --su , number , unit bla-bla के लिए कोई वास्तविक आवश्यकता नहीं है ... वर्तमान -su व्यवहार जैसे "यदि आप असंगत इकाइयां देखते हैं तो बस एक त्रुटि फेंक दें" , यानी एक साधारण सत्यापन, ठीक से अधिक है (मेरे लिए)। मुझे 1px/2px->.5 और 1px*2px->2px^2 मैम्बो-जैम्बो ओवरइंजीनियरिंग की कोई आवश्यकता नहीं दिख रही है। लेकिन फिर भी यह एक और असंबंधित कहानी है)।

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

वास्तव में एक बग का उपयोग करना

उह .. हाँ; तुम सही हो, बिल्कुल। सौभाग्य से मेरे पास वास्तव में वह कोड कहीं भी उत्पादन में नहीं है। यह बिंदु को स्पष्ट करने के लिए एक साथ उछाला गया एक त्वरित उदाहरण था।

मैं यह भी जोड़ूंगा कि मैं इस विशेष संदर्भ में किसी भी "संगत इकाइयों" अनुमानों के खिलाफ हूं (जैसे कि ए/बी को एक डिवीजन और बी/सी होने के लिए रहने दें)।

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

साथ ही, मुझे बाद में एहसास हुआ कि font: 10px/3 वैध शॉर्टहैंड है। तो वास्तव में कोई एल्गोरिथम समाधान नहीं है जो वहां मदद कर सके।

अपने प्रश्न पर वापस जाने के लिए, @rjgotten...

अपने तर्क को इधर-उधर क्यों नहीं करते? यदि कोई चीज़ गणित के व्यंजक की तरह दिखती है और उसकी संगत इकाइयाँ हैं तो उसे डिफ़ॉल्ट रूप से गणित व्यंजक के रूप में माना जाएगा। और अगर आप नहीं चाहते कि ऐसा हो... ठीक है; फिर ~"..." एस्केप हैच का उपयोग करें। यह वही है जो इसके लिए है, आखिर...

लेस टू सीएसएस का विचार/संबंध टाइपस्क्रिप्ट टू जावास्क्रिप्ट के समान है। यानी अपने वैध .css का नाम बदलकर .less और आप कम सुविधाएं जोड़ना शुरू कर सकते हैं। इसी तरह आप .js का नाम बदलकर .ts और टाइपस्क्रिप्ट सुविधाओं को जोड़ना शुरू कर सकते हैं। यदि आप कुछ भी नहीं जोड़ते हैं, तो आपको आउटपुट वही वैध कम/जावास्क्रिप्ट प्राप्त करना चाहिए, क्योंकि भाषाएं मूल भाषा के सुपरसेट हैं।

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

यही तर्क calc() पर लागू होता है। हां, आप अपने भावों को तार-तार कर सकते हैं, लेकिन आपको ऐसा नहीं करना चाहिए। .css नाम बदलकर .less गया है, उसी प्रभावी CSS का उत्पादन करना चाहिए। मूल स्टाइलशीट में हस्तक्षेप/ओवरराइट/ओवर-व्याख्या न करने के लिए यह परियोजना का मूल लक्ष्य होना चाहिए। पहली बार में पार्सर/भाषा का उपयोग करने के अलावा किसी अन्य पाप के लिए समस्या को डेवलपर पर धकेलने की कोशिश कर रहा है।

हां, आप अपने भावों को तार-तार कर सकते हैं, लेकिन आपको ऐसा नहीं करना चाहिए। .css का नाम बदलकर .less कर दिया गया है, वही प्रभावी CSS तैयार करना चाहिए। मूल स्टाइलशीट में हस्तक्षेप/ओवरराइट/ओवर-व्याख्या न करने के लिए यह परियोजना का मूल लक्ष्य होना चाहिए। पहली बार में पार्सर/भाषा का उपयोग करने के अलावा किसी अन्य पाप के लिए समस्या को डेवलपर पर धकेलने की कोशिश कर रहा है।

वह।

कम जानता है कि / की अनुमति कहां है और यह सीएसएस में कहां नहीं है। जहां यह नहीं है लेकिन वैसे भी दिखाई देता है, उसे गणित किया जाना चाहिए। इसके अलावा जहां गणित राउंड ब्रैकेट से घिरा हुआ है जहां सीएसएस में राउंड ब्रैकेट की अनुमति नहीं है, कम से कम व्याख्या की जानी चाहिए।

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

@ थानी

संकलक क्या जानता है इसकी बहुत सी धारणाएं (और उनमें से कुछ बस गलत हैं)।
किसी भी तरह से "गोल कोष्ठक" मोड लगभग वही है जो --sm=on करता है, इसलिए इसका उपयोग करें और इस धागे के बारे में भूल जाएं (सबसे अधिक संभावना है कि आप calc अलावा अपनी परियोजनाओं में किसी भी गणित का उपयोग नहीं कर रहे हैं (कुछ पेश किए गए हैं) कम डिज़ाइन किए जाने के वर्षों बाद) ताकि आप यह नहीं देख सकें कि अतिरिक्त माता-पिता कैसे परेशान कर रहे हैं। लेकिन अन्य करते हैं।)

बाकी के लिए https://github.com/less/less.js/issues/1880#issuecomment -345194431 देखें।

@ सात-चरण-अधिकतम यह न भूलें कि / का अर्थ background और border-radius शॉर्टहैंड में भी है, और संभवतः अन्य जिनके बारे में मैं अभी नहीं सोच रहा हूं। LESS खुशी से उनको एक विभाजन के रूप में मानेगा। सख्त गणित मोड के साथ या उसके बिना, LESS को अपने स्वयं के छोटे गणित करने के लिए "पता होना चाहिए कि कब रुकना है"।

@ थानी
LESS को अपने स्वयं के छोटे गणित करने के लिए "पता होना चाहिए कि कब रुकना है"।

नहीं, ऐसा नहीं होना चाहिए। यह जानने का कोई तरीका नहीं है कि डिवीजन स्लैश के साथ भविष्य के सीएसएस शॉर्टहैंड कहां दिखाई देने वाले हैं। इसके बारे में कम संकलक 'पता' होना एक मौलिक रूप से त्रुटिपूर्ण दृष्टिकोण है और यह चर्चा जिस बात का समाधान खोजने का प्रयास कर रही है।

एक डिवीजन ऑपरेटर के रूप में / लिए अब तक दो, समझदार और अनुमानित विकल्प हैं:

• हमेशा इसे इस तरह से व्यवहार करें और अन्य उपयोगों के लिए स्पष्ट रूप से भागने की आवश्यकता है।
  यह उस व्यवहार को तोड़ देगा जहां कम सिंटैक्स सीएसएस सिंटैक्स का सख्त सुपरसेट है।
• इसे कभी भी एक डिवीजन ऑपरेटर के रूप में न मानें, __ जब तक __ यह ज्ञात गणित संदर्भ में न हो।
  जहां ज्ञात गणित संदर्भ वर्तमान --strict-math=on व्यवहार के अनुसार तय किया जा सकता है।

_{(साथ ही, कृपया ध्यान दें कि कम नाम अब सभी बड़े अक्षरों में नहीं लिखा गया है।)}

यह मत भूलो कि / का पृष्ठभूमि और सीमा-त्रिज्या शॉर्टहैंड में भी अर्थ है,

मूल रूप से यह सूत्र इसी से शुरू होता है।
और प्रस्तावित परिवर्तनों का सारांश https://github.com/less/less.js/issues/1880#issuecomment -345194431 पर

नहीं, ऐसा नहीं होना चाहिए। यह जानने का कोई तरीका नहीं है कि डिवीजन स्लैश के साथ भविष्य के सीएसएस शॉर्टहैंड कहां दिखाई देने वाले हैं। इसके बारे में कम संकलक 'पता' होना एक मौलिक रूप से त्रुटिपूर्ण दृष्टिकोण है और यह चर्चा जिस बात का समाधान खोजने का प्रयास कर रही है।

मैं पूरी तरह से इस बात से सहमत हूं। @thany जब आप मेरे द्वारा लिखी गई बातों के बारे में मेरे साथ सहमत थे, तो आप मेरे द्वारा किए गए निष्कर्ष से अलग निष्कर्ष पर पहुंच रहे हैं। कम को नहीं पता होना चाहिए और न ही पता होना चाहिए कि "गणित करना कब बंद करें"। मैं जो कहूंगा वह यह है कि ब्रेकिंग चेंज यह होना चाहिए कि पहले स्थान पर गणित (अमेरिकी/कनाडाईवाद का उपयोग करने के लिए) शुरू करने के बारे में कम रूढ़िवादी है।

@rjgotten

इसे कभी भी एक डिवीजन ऑपरेटर के रूप में न मानें, जब तक कि यह ज्ञात गणित के संदर्भ में न हो।
जहां ज्ञात गणित के संदर्भ को वर्तमान - सख्त-गणित = व्यवहार पर तय किया जा सकता है।

बस स्पष्ट करने के लिए, यह हिस्सा (जिससे मैं सहमत हूं):

इसे कभी भी एक डिवीजन ऑपरेटर के रूप में न मानें, जब तक कि यह ज्ञात गणित के संदर्भ में न हो।

असल में 4 संभावित समाधान हैं, जो मुझे पता है कि आप जानते हैं, लेकिन धागे के लिए बस फिर से सारांशित करना:

1. सभी गणित केवल कोष्ठकों में करें । यह स्पष्ट रूप से कॉमन्स द्वारा खारिज कर दिया गया है, जो ठीक है, हालांकि यह अभी भी एक वैकल्पिक टॉगल ( strictMath ) के रूप में उपलब्ध है।
2. सभी गणित हर जगह करें, लेकिन विभाजन केवल कोष्ठक में करें।
3. सभी गणित हर जगह करें, लेकिन विभाजन केवल कोष्ठक में करें। जब तक कि डिवीजन ऑपरेटर ./ रूप में मुद्रित न हो
4. सभी गणित हर जगह करें, लेकिन गणित को ठीक करें ताकि 12px/4px परिणाम विभाजन न हो। (गुणा और भाग केवल इकाई-रहित मानों के साथ।) दूसरे शब्दों में, हर जगह विभाजन, लेकिन अधिक रूढ़िवादी नियमों के साथ। उन मामलों में जहां यह चीजों को हल नहीं करता है, भागने का सहारा लें। तो, एक पूर्ण समाधान नहीं है, लेकिन फिर भी मौजूदा स्थिति में एक (बहस योग्य) सुधार है।

उपयोगिता के नजरिए से, मुझे गणित को #4 तरह "स्मार्ट" बनाना पसंद है। एक इंजीनियरिंग और रखरखाव के दृष्टिकोण से, और भविष्य के सीएसएस परिवर्तनों से बचाने के लिए, मुझे सबसे मजबूत समाधान के रूप में #3 ।

हालांकि, मुझे लगता है कि वास्तव में, हमें #3 और #4 दोनों को करने की आवश्यकता होगी ताकि calc() को ठीक किया जा सके। अभी, गणित करते समय सभी इकाइयों को कम अनदेखा करना एक वास्तविक गड़बड़ है। 100vh - 12px को कभी भी कम (कोष्ठक या नहीं) से स्पर्श नहीं करना चाहिए। लेकिन आईएमओ को न तो 12px/4px (कोष्ठक या नहीं) होना चाहिए, लेकिन मैं उस पर अल्पमत में हो सकता हूं।

इसलिए, मैं इसे "सीएसएस सिंटैक्स के साथ विरोधाभासी गणित" समस्या के रूप में इतना अधिक नहीं देखता जितना कम समय से पहले गणित समीकरणों को हल करने के साथ अत्यधिक आक्रामक तरीके से आक्रामक होना।

केवल इकाई-रहित मानों के साथ गुणा और भाग।

यह चाल नहीं चलने वाला है क्योंकि ऐसी चीजें हैं:

font: small-caps bold 24px/3 ...;
lost-column: 1/3;
// etc.

और वे divs नहीं हैं।

हालांकि, मुझे लगता है कि वास्तव में, हमें #3 और #4 दोनों को करने की आवश्यकता होगी ताकि calc() को ठीक किया जा सके।

calc() एक दर्द है। विडंबना यह है कि इसे वास्तविक कम फ़ंक्शन के रूप में कार्यान्वित करके _probably_ सबसे अच्छा हल किया जाता है, जो आदर्श रूप से इसके पार्स किए गए अभिव्यक्ति पेड़ को ले जाएगा और अभिव्यक्ति को सरल बनाने का प्रयास करेगा। वह है: इसे 4px + 12px (या 4px + @a जब @a एक पिक्सेल मान के लिए जाना जाता है) जैसे संगत घटकों को पूर्व-गणना और संयोजित करना चाहिए, लेकिन असंगत घटकों को छोड़ दें, उदाहरण के लिए वे असंगत इकाइयों के साथ, अकेले।

उदाहरण के लिए

<strong i="17">@a</strong> : 4px;
<strong i="18">@b</strong> : 2;
width : calc(100%/<strong i="19">@b</strong> - 10px + @a);

अंततः प्रस्तुत करना चाहिए

width : calc(50% - 6px);

( https://github.com/less/less.js/issues/1880#issuecomment-345345735 से खुद को दोहराते हुए)
और मुझे calc अंदर अभिव्यक्तियों को अनुकूलित करने के लिए अनुपालनकर्ता को अत्यधिक इंजीनियरिंग करने का कोई लाभ नहीं दिख रहा है। यदि आप calc लिख रहे हैं तो आप ब्राउज़र के साथ काम करने के लिए ठीक हैं जो भी लंबी अभिव्यक्ति आपके पास है। तो जैसा कि पहले ही ऊपर उल्लेख किया गया है, मैं " calc अंदर कुछ भी स्पर्श न करें" के लिए हूं (= वास्तव में जरूरी होने से ज्यादा स्मार्ट बनने की कोशिश न करें) और इसे ब्राउज़र के लिए छोड़ दें ( या एक सीएसएस-मिनिफायर के बाद से , अगर मुझे सही से याद है, तो उनमें से कुछ पहले से ही कैल्क उप-अभिव्यक्तियों को अनुकूलित करने पर बहुत अच्छा काम कर रहे हैं)।

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

PS जैसे ही calc एक गैर-अंकगणित-मूल्यांकन अभिव्यक्ति प्राप्त करने वाला फ़ंक्शन बन जाता है (इसे वैसे भी करना होगा) कोई भी प्लगइन लिखने में सक्षम होगा और वांछित अनुकूलन के साथ इसे ओवरराइड कर सकेगा।

@rjgotten
इसके बारे में कम संकलक 'जानना' एक मौलिक रूप से त्रुटिपूर्ण दृष्टिकोण है

मुझे लगता है कि यह एक मौलिक रूप से सही दृष्टिकोण है। LESS CSS के लिए एक कंपाइलर है, इसलिए यह दुनिया में सभी समझ में आता है कि LESS को इसके बारे में पता है कि यह क्या संकलित कर रहा है।

@ मैथ्यू-डीन
कम को नहीं पता होना चाहिए और न ही पता होना चाहिए कि "गणित करना कब बंद करें"। मैं जो कहूंगा वह यह है कि ब्रेकिंग चेंज यह होना चाहिए कि पहले स्थान पर गणित (अमेरिकी/कनाडाईवाद का उपयोग करने के लिए) शुरू करने के बारे में कम रूढ़िवादी है।

दिलचस्प है कि आप इसे दूसरी तरफ से सोचते हैं, इसलिए बोलने के लिए। यहाँ मैं क्या प्रस्तावित कर रहा हूँ:

background: url(...) no-repeat 50% 50% / 40px + 10px 40px;

यहाँ LESS को क्या करना चाहिए, यह मेरे लिए स्पष्ट है:

background: url(...) no-repeat 50% 50% / (40px + 10px) 40px;

जिसके परिणामस्वरूप:

background: url(...) no-repeat 50% 50% / 50px 40px;

इसमें 50% / 50px भाग की गणना नहीं करनी चाहिए, क्योंकि (1) यह असंगत इकाइयों के कारण सक्षम नहीं होना चाहिए और (2) क्योंकि यह पहले से ही background मूल्य के लिए पर्याप्त है . तो यह वह जगह है जहाँ यह "गणित करना बंद कर देगा"।

मेरा मतलब LESS से था "यह जानना कि कब रुकना है"।

क्या यह इस तरह की एक अलग संपत्ति थी:

padding-left: 50% / 10px + 5px;

इसे एक त्रुटि (असंगत इकाइयों) के साथ तोड़ना चाहिए। एक संभावित आउटपुट 50% / 15px जो इस संपत्ति के लिए अमान्य है। एक अन्य परिणाम 5% हो सकता है जो वह वर्तमान में करेगा, जो हर दिशा में गलत है।
और:

padding-left: 50px / 10px + 5px;

इसका परिणाम होना चाहिए:

padding-left: 10px;

आशा के अनुसार। तो इस मामले में, / के लिए अमान्य है padding-left और कम में ले लिया है है और इसके गणित thingy है।

@ मैथ्यू-डीन
असल में 4 संभावित समाधान हैं, जो मुझे पता है कि आप जानते हैं, लेकिन धागे के लिए बस फिर से सारांशित करना:

एक और:
5) LESS में डिवीजनों के लिए \ ऑपरेटर का उपयोग करें, और / का उपयोग करके बहिष्कृत करें। MATLAB में कुछ ऐसा है, और बेसिक के कुछ स्वादों ने इसे पूर्णांक विभाजन को मजबूर करने के लिए उपयोग किया है। तो बैकस्लैश का उपयोग करना पूरी तरह से अनसुना नहीं है।

/ संपादित करें
हम keybaords पर ÷ कुंजी को शामिल करने के लिए लॉबी भी कर सकते हैं और इसे डिवीजन ऑपरेटर के रूप में उपयोग कर सकते हैं। यही मैंने प्राथमिक विद्यालय में सीखा :)

आप जो सुझाव देते हैं उस पर पहले भी कई बार चर्चा हो चुकी है (यहां संदर्भित सूत्र को देखने में संकोच न करें)। तो यहाँ सिर्फ छोटी-छोटी आलसी टिप्पणियाँ हैं:

कम में विभाजन के लिए \ ऑपरेटर का उपयोग करें, और / का उपयोग करके बहिष्कृत करें।

https://github.com/less/less.js/issues/1872#issuecomment -35245890

background लिए पर्याप्त ... padding-left लिए अमान्य है

मिलिए "दोस्तों, मेरे ब्राउज़र/पॉलीफिल/जो कुछ भी fnord संपत्ति के लिए अभी जोड़ा/अपडेट/विस्तारित समर्थन है, क्या आप कृपया मेरे लिए एक नया कम संस्करण जारी करेंगे?" मुद्दा।
font मुद्दे को पूरा करें ।
आदि आदि।
खैर, @rjgotten ने पहले ही ऊपर टिप्पणी कर दी थी कि इस तरह का "ज्ञान" कहीं नहीं जाने का रास्ता क्यों है।

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

मिलिए "दोस्तों, मेरे ब्राउज़र/पॉलीफिल/जो कुछ भी एक fnord संपत्ति के लिए अभी जोड़ा/अपडेट/विस्तारित समर्थन है, क्या आप कृपया मेरे लिए एक नया कम संस्करण जारी करेंगे?" मुद्दा।

सीएसएस एक अच्छी तरह से परिभाषित मानक है। आपको मानक के बाहर किसी भी चीज़ का समर्थन नहीं करना चाहिए। यह तुम्हारी समस्या है, मुझे लगता है। आपको fnord संपत्ति का समर्थन नहीं करना चाहिए, क्योंकि यह किसी मानक का हिस्सा नहीं है। जब यह नई अनिर्दिष्ट संपत्ति होती है, तो LESS अपने डिफ़ॉल्ट व्यवहार पर वापस आ सकता है, जो वर्तमान हो सकता है, या कोष्ठक की आवश्यकता हो सकती है, या जब तक यह अस्पष्ट नहीं है, तब तक कुछ भी हो सकता है।

फ़ॉन्ट समस्या से मिलें।

फ़ॉन्ट समस्या यह साबित करती है कि / समस्या LESS की पूर्ण शुरुआत के बाद से मौजूद है। इतना ही नहीं जब background को पृष्ठभूमि-आकार के लिए एक मूल्य शामिल करने की क्षमता मिली या जब border-radius आया। टीबीएच, फ़ॉन्ट समस्या बताकर, आपने अभी अपने खिलाफ सबसे अच्छा तर्क दिया है :)

टीबीएच, फ़ॉन्ट समस्या बताकर, आपने अभी अपने खिलाफ सबसे अच्छा तर्क दिया है :)

मुझे लगता है कि आप कुछ गलत समझ रहे हैं। यह मैं था जिसने शुरुआत में / को एक div ऑपरेटर के रूप में पूरी तरह से हटाने का प्रस्ताव दिया था। तो बाकी चीजों के लिए मुझे लगता है कि यह वही मुद्दा है जो आपने जवाब दिया है पर ध्यान नहीं दे रहा है।

सीएसएस एक अच्छी तरह से परिभाषित मानक है।

यदि आप उन विशिष्ट भागों से चिपके रहेंगे जो टीआर स्तर पर पूरी तरह से परिपक्वता तक पहुँच चुके हैं, हो सकता है।
अन्यथा? नहीं यह नहीं। नए सीएसएस 'मॉड्यूल' के उपग्रह विनिर्देश हैं और मौजूदा मॉड्यूल के संशोधन उनमें नए परिवर्धन के साथ मासिक रूप से पॉप अप हो रहे हैं, यदि साप्ताहिक नहीं।

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

यह चाल नहीं चल रहा है क्योंकि इसमें चीजें हैं: फ़ॉन्ट: स्मॉल-कैप बोल्ड 24px/3 ...

नहीं, मैं समझ गया। मेरा कहना बिल्कुल यही था: इकाई-कम केवल div/गुणा समस्या को कम करता है लेकिन समस्या का समाधान नहीं करता है।

और मुझे लगता है कि सामान्य तौर पर सभी डिवीजनों के लिए ./ का आपका सुझाव अभी भी काफी तार्किक लगता है।

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

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

मैं इससे पूरी तरह सहमत हूं। अगर हम सिर्फ calc() श्वेतसूची में डाल देते हैं तो हम गणित से संबंधित 99% नए मुद्दों को खत्म कर देंगे। जबकि मैंने कुछ तरीकों का सुझाव दिया है कि calc() मुद्दों (जो शायद यह होना चाहिए) से बचने के लिए कम अधिक चालाकी से गणित कर सकता है, मैं क्षमा चाहता हूं अगर इसे इस विचार के खिलाफ तर्क के रूप में व्याख्या किया गया था। मैं भी इसका समर्थन करता हूं।

एकमात्र चेतावनी (जैसा कि यहां/अन्यत्र चर्चा की गई है) यह है कि एक डेवलपर अनिवार्य रूप से calc() में चर का उपयोग करना चाहता है, इसलिए हमें यह सुनिश्चित करने के लिए सावधान रहना होगा कि हम वर्र्स को स्वैप करना जारी रखते हैं, लेकिन ऐसा न करें गणित। मुझे यकीन नहीं है कि यह कितना चुनौतीपूर्ण है। अगर हम ऐसा करने में कामयाब रहे, तो मैं आज calc() प्रबंधन में बदलाव का समर्थन करूंगा।

@ थानी

फ़ॉन्ट समस्या यह साबित करती है कि / समस्या LESS की पूर्ण शुरुआत के बाद से मौजूद है।

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

संयोग से, इस उदाहरण द्वारा सचित्र Sass समस्या का समाधान करता है:

p {
  font: 10px/8px;             // Plain CSS, no division
  $width: 1000px;
  width: $width/2;            // Uses a variable, does division
  width: round(1.5)/2;        // Uses a function, does division
  height: (500px/2);          // Uses parentheses, does division
  margin-left: 5px + 8px/2px; // Uses +, does division
  font: (italic bold 10px/8px); // In a list, parentheses don't count
}

यह एक-से-एक नहीं है, क्योंकि आप कम कार्यों के तर्कों के भीतर गणित (वर्तमान में) कर सकते हैं, और कम फ़ंक्शन पिक्सेल मान वापस कर सकते हैं (इसलिए कम font: print10px()/8px , सैद्धांतिक रूप से? नहीं?), तो मैं मैं इसे सिर्फ उदाहरण के तौर पर चिपका रहा हूं, किसी तरह के सुझाव के तौर पर नहीं। यह दिलचस्प है कि उन्होंने समस्या से कैसे संपर्क किया।

व्यक्तिगत रूप से, मुझे लगता है कि डेवलपर्स यह याद रखने की कोशिश करते हैं कि जादू के भावों के अस्तित्व के आधार पर गणित किन मामलों में घटित होगा (जैसे + द्वारा पूर्व-लंबित किया जा रहा है?), लेकिन प्रत्येक के लिए अपना स्वयं का .

व्यक्तिगत रूप से, मुझे लगता है कि डेवलपर्स यह याद रखने की कोशिश करते हैं कि जादू के भावों के अस्तित्व के आधार पर गणित किन मामलों में होगा, यह एक तरह का पागलपन है

+1

_{यह गिनती भी नहीं है कि "समाधान" यहां चर्चा की गई समस्याओं में से कोई भी हल lessc --sm पहले से ही करता है। और 1/2 और $var/2 लिए अलग-अलग परिणाम सिर्फ एक असाधारण शानदार है ... ~मूर्खता~ "हैप्पी डिबगिंग, हारे हुए!"}

@ मैथ्यू-डीन
संयोग से, इस उदाहरण द्वारा सचित्र Sass समस्या का समाधान करता है:

एक अलग ऑपरेटर का सहारा लिए बिना यह एक शानदार समाधान है।
यदि अभिव्यक्ति संभवतः मान्य CSS है, तो इसे छोड़ दें।

व्यक्तिगत रूप से, मुझे लगता है कि डेवलपर्स यह याद रखने की कोशिश करते हैं कि जादू के भावों के अस्तित्व के आधार पर गणित किन मामलों में होगा, यह एक तरह का पागलपन है

असहमत। यह नियमों का एक सरल सेट है, जो आपको याद रखने के लिए आवश्यक (पागल या नहीं) नियमों के किसी भी अन्य सेट से अलग नहीं है।

ऐसे कुछ किनारे-मामले हैं जहां गणित बिना अर्थ के होता है, लेकिन फिर आप केवल कोष्ठक लागू करेंगे और आपका काम हो गया।

यह भी नहीं गिनना कि "समाधान" यहां चर्चा की गई समस्याओं में से कोई भी हल नहीं करता है, जो कि lessc --sm पहले से ही करता है। मैं (1/2) के बजाय 0 + 1/2 क्यों लिखूंगा जब मैं जो चाहता हूं वह सिर्फ एक विभाजन है? और 1/2 और $var/2 के लिए अलग-अलग परिणाम सिर्फ एक असाधारण शानदार है ... मूर्खता "हैप्पी डिबगिंग, हारे हुए!" संदेश।

हा, हाँ, यह।

@ थानी

एक अलग ऑपरेटर का सहारा लिए बिना यह एक शानदार समाधान है।
यदि अभिव्यक्ति संभवतः मान्य CSS है, तो इसे छोड़ दें।

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

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

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

आप अभी भी अपनी कल्पनाओं के साथ बहस करते हैं, न कि जो वे आपको बताते हैं उससे। सरल प्रश्न का उत्तर दें: " 0 + 1/2 संभवतः (1/2) से बेहतर कैसे हो सकता है?"। यदि 100%-सीएसएस संगतता केवल एक चीज है जिसकी आप परवाह करते हैं तो सुंदर -sm सेट करें और इस धागे के बारे में भूल जाएं।

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

इस भाग से मैं अनिवार्य रूप से सहमत हूं, और मुझे लगता है कि आपको इस सूत्र में उस बिंदु पर काफी सहमति मिलेगी। अधिकांश असहमति समाधान के इर्द-गिर्द रही है, प्रत्येक समाधान के विभिन्न दुष्प्रभाव हैं।

मैं इन ब्रेकिंग परिवर्तनों को प्राथमिकता के रूप में करने के साथ ऑन-बोर्ड रहूंगा:

1. कोष्ठक के बाहर गणित को नग्न / बजाय ./ आवश्यकता होती है (और, जाहिर है, फ़ंक्शन तर्कों को कोष्ठक के एक अतिरिक्त सेट की आवश्यकता होती है जैसे my-function(12px/10px, arg2, arg3) 12/10 को विभाजित नहीं करता है लेकिन my-function((12px/10px), arg2, arg3) करता है और my-function(12px./10px, arg2, arg3) करता है) जब तक हम कुछ अन्य नहीं करना चाहते हैं / का विशेष संकेतक जैसे \/ या सिर्फ \ जैसे 12px\10px ।

@ सात-चरण-अधिकतम - मैं बैकस्लैश पर फिर से जाना चाहता हूं। इससे संबंधित, मुझे पता है कि आपने https://github.com/less/less.js/issues/1872#issuecomment -35245890 का उल्लेख किया है, लेकिन मुझे कोई स्पष्ट विरोध नहीं दिखता, क्योंकि वे पहचानकर्ता नहीं हैं और मुझे लगता है कि नहीं हो सकता गणित के भावों का हिस्सा। या मैं गलत हूँ? मुझे लगता है कि नाम के हिस्से के रूप में एक बच निकले चरित्र के साथ एक फ़ंक्शन नाम जैसे सैद्धांतिक मामले के साथ आना संभव है, लेकिन यह वास्तविक दुनिया के मामले की तुलना में बौद्धिक अभ्यास की तरह लगता है। बच गए चयनकर्ता, हां, वे आमतौर पर विभिन्न कारणों से उपयोग किए जाते हैं, लेकिन संपत्ति मूल्यों में, यह असंभव लगता है, या, किनारे के मामले में, ऐतिहासिक (बस इस पाठ से बचें) कामकाज के साथ तोड़ने/काम करने के लिए ठीक है।

क्या हम थोड़ा और पता लगा सकते हैं कि विभाजन के लिए एक बैकस्लैश का उपयोग करने से वास्तविक दुनिया में संघर्ष होगा? मेरी प्रवृत्ति यह है कि \ वर्तमान स्थिति की तुलना में कम समस्याग्रस्त है / , और यह ./ तुलना में अधिक देव-अनुकूल है। यदि हमने शोध किया और पाया कि यह व्यवहार्य था, तो हम कोष्ठक में / अनुमति देने के बजाय संदर्भ-स्विचिंग के बजाय इसे हर जगह उपयोग करने के लिए ब्रेकिंग परिवर्तन कर सकते थे। और फिर हम लीगेसी स्विच के साथ / समर्थन कर सकते हैं।

1. (दूसरी प्राथमिकता) calc() विशेष-आवरण होने के कारण यह परिवर्तनीय प्रतिस्थापन कर सकता है लेकिन किसी भी गणित अभिव्यक्ति का मूल्यांकन नहीं करेगा

क्या हम थोड़ा और पता लगा सकते हैं कि विभाजन के लिए एक बैकस्लैश का उपयोग करने से वास्तविक दुनिया में संघर्ष होगा?

खैर, समस्या यह है कि \anycharacter वैध CSS है और इसका अपना अर्थ है। निश्चित रूप से, आपको वास्तविक परियोजनाओं में मुश्किल से ऐसा कोड मिलता है (शायद \9 -जैसे हैक्स को छोड़कर), लेकिन... क्या हम उस शेर को खिलाना चाहते हैं? एक "उह-ओह, मेरा 100% -वैध सीएसएस संकलित नहीं करता है" को ठीक करना, उसी के एक और "उह-ओह" को पेश करके थोड़ा अजीब लगता है :)

जहां तक calc सवाल है, मुझे लगता है कि शुरू से ही हमारे बीच आम सहमति थी - इसलिए यह मूल रूप से केवल एक स्वयंसेवक को इसे लागू करने की प्रतीक्षा करता है (मेरा अनुमान है कि नए कोड की केवल 5-6 पंक्तियों में त्वरित सुधार किया जाना है - इसलिए यह वास्तव में ऐसा करने के लिए केवल एक बहादुर व्यक्ति के बारे में है - मामूली कार्यान्वयन विवरण भिन्न हो सकते हैं लेकिन मुझे लगता है कि वे प्रक्रिया में तय किए जाने के लिए ठीक हैं)।

खैर, समस्या यह है कि \anycharacter मान्य CSS है और इसका अपना अर्थ है। निश्चित रूप से, आपको वास्तविक परियोजनाओं में मुश्किल से ऐसा कोड मिलता है (शायद \9-जैसे हैक्स को छोड़कर), लेकिन... क्या हम उस शेर को खिलाना चाहते हैं? एक "उह-ओह, मेरा 100% -वैध सीएसएस संकलित नहीं करता है" को ठीक करना, उसी के एक और "उह-ओह" को पेश करके थोड़ा अजीब लगता है :)

मैं आपको सुनता हूं, यह एक संभावित व्यापार-बंद है। और हाँ मुझे पता है कि \anycharacter वैध सीएसएस है। मुझे लगता है कि मैं सोच रहा हूं कि क्या यह ट्रेड-ऑफ का बेहतर सेट है। यह सिर्फ इतना है कि जब मैंने 12px./10px लिखा तो यह अजीब, वाक्य रचनात्मक रूप से लगा। मुझे लगता है कि कम वाक्य रचनात्मक रूप से संघर्षों को पैदा किए बिना जितना संभव हो सके सीएसएस का पुन: उद्देश्य करने की कोशिश की है।

जैसे, ./ सिंटैक्स स्पष्टता प्रदान करता है और पूरी तरह से संघर्ष से बचा जाता है, लेकिन गणित के लिए हर जगह कोष्ठक लागू किया है, यही कारण है कि मैंने इसका समर्थन किया, लेकिन बैकलैश था, और मैं यहां इसके बारे में चिंतित हूं। तो क्या कोई वैध मामला है जहां हम 10px\10 को डेवलपर के इरादे के रूप में \10 से बचने की गलती करेंगे? मुझे पता है कि यह एक कठिन सैद्धांतिक है, और आपकी बात शायद यह होगी कि हम वास्तव में नहीं जानते हैं …. जंगली और न ही भविष्य सीएसएस।

कैल्क के लिए मुझे लगता है कि हमारे पास शुरुआत से ही एक आम सहमति थी - इसलिए यह मूल रूप से केवल एक स्वयंसेवक को इसे लागू करने की प्रतीक्षा करता है (मेरा अनुमान है कि नए कोड की केवल 5-6 पंक्तियों में त्वरित सुधार किया जाएगा - इसलिए यह वास्तव में केवल एक के बारे में है ऐसा करने के लिए बहादुर आदमी - मामूली कार्यान्वयन विवरण भिन्न हो सकते हैं लेकिन मुझे लगता है कि प्रक्रिया में निर्णय लेने के लिए उन्हें ठीक है)।

अच्छा! क्या हमें दृश्यता को टक्कर देने के लिए इसे अलग से ट्रैक करना चाहिए?

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

निश्चित रूप से, आपको वास्तविक परियोजनाओं में मुश्किल से ऐसा कोड मिलता है (शायद \9 -जैसे हैक्स को छोड़कर)

सही । ओह, वह उग्र "पश्चिमी" ... :)

@ सात-चरण-अधिकतम
सरल प्रश्न का उत्तर दें: "0 + 1/2 संभवतः (1/2) से बेहतर कैसे हो सकता है?"

मैं नहीं देखता कि आप इसके साथ कहाँ जा रहे हैं। (1/2) LESS द्वारा निष्पादित किया जाना चाहिए क्योंकि यह संभवतः वैध CSS नहीं हो सकता है, इसलिए इसका अर्थ LESS होना चाहिए। 0 + 1/2 बन जाना चाहिए 1/2 जहां LESS 0 + 1 भाग को निष्पादित करता है क्योंकि यह वह हिस्सा है जो मान्य CSS नहीं हो सकता है। 1/2 भाग मान्य हो सकता है, इसलिए बेहतर है कि इसे स्पर्श न करें।

@ थानी
ठीक है, अब महसूस करें कि (1/2) काम करता है जैसा कि आप कम और सैस दोनों में उम्मीद करते हैं ..
और 0 + 1/2 (साथ ही 1 * 1/2 आदि) उस समाधान का हिस्सा है जिसे आप ऊपर शानदार कहते हैं और "शानदार दक्षिण" परिणाम 0.5 ।
अभी भी पता नहीं यहाँ क्या हो रहा है?
ऊपर दी गई हर चीज़ (आपकी पहली पोस्ट से शुरू) को एक बार फिर से पढ़ें और अपने आप को जवाब देने का प्रयास करें " वास्तव में मैं किस बारे में शिकायत कर रहा हूँ?"।

@ सात-चरण-अधिकतम
और 0 + 1/2 (साथ ही 1 * 1/2 आदि) उस समाधान का हिस्सा है जिसे आप ब्रिलियंट कहते हैं और "द ब्रिलियंट साउथियन" का परिणाम 0.5 है।

नहीं, समाधान 1/2 नहीं 0.5 , क्योंकि 1/2 वैध सीएसएस हो सकता है। ऐसा लगता है कि आप यह नहीं जानना चाहते कि स्लैश कब मान्य है, इसलिए मान लें कि यह हमेशा हो सकता है। इसलिए केवल 1/2 ही तार्किक परिणाम है। उसी तरह, 2 * 1/2 का परिणाम 2/2 , क्योंकि * अन्यथा इसे अमान्य CSS बना देगा।

अभी भी पता नहीं यहाँ क्या हो रहा है?

मैं पूरी तरह से स्पष्ट हूं कि यहां क्या हो रहा है। LESS गणित के विभाजनों को उत्सुकता से क्रियान्वित कर रहा है और आँख बंद करके इकाइयों की उपेक्षा करता है।

ऊपर दी गई हर चीज़ (आपकी पहली पोस्ट से शुरू) को एक बार फिर से पढ़ें और अपने आप को जवाब देने का प्रयास करें "वास्तव में मैं किस बारे में शिकायत कर रहा हूँ?"।

व्यक्तिगत हमलों की कोई जरूरत नहीं है।

LESS गणित के विभाजनों को उत्सुकता से क्रियान्वित कर रहा है और आँख बंद करके इकाइयों की उपेक्षा करता है।

तो यह है कि तुम क्या, के बारे में शिकायत कर रहे हैं सही है?

व्यक्तिगत हमलों की कोई जरूरत नहीं है।

तो इसके बजाय मुझे क्या करना चाहिए? मूल दो पदों को बार-बार (और फिर से) दोहरा रहे हैं? जब तक यह आपके लिए स्पष्ट न हो जाए:
@समुदाय :

-sm विकल्प का उपयोग करें

@थानी :

तो यह डिफ़ॉल्ट रूप से चालू होना चाहिए।

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

ऐसा नहीं हो सकता क्योंकि यह तुरंत वहाँ से बाहर अरबों परियोजनाओं को तोड़ देगा। इसलिए यदि आप डिफ़ॉल्ट व्यवहार को एक समस्या के रूप में देखते हैं तो बस प्रलेखित विकल्प सेट करें और किया जाए।

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

तो यह धागा किस बारे में है? यह "यह महसूस करने के बारे में है कि " -sm -समान व्यवहार डिफ़ॉल्ट बनाने का एक अंतिम ब्रेकिंग परिवर्तन अपरिहार्य है, हमें भयानक के अलावा अधिक आरामदायक अंकगणित के लिए सुविधाएं प्रदान करनी होगी: margin: (1/2) (3/4) (5/6) (7/8); उन लोगों के लिए जो अंकगणित का बहुत उपयोग करें"।
आप यहां पोस्ट करते हैं या तो कुछ ऐसा सुझाव देते हैं जो पहले से मौजूद -sm व्यवहार से बेहतर (या बिल्कुल वैसा ही कर रहा है) या किसी ऐसी चीज के साथ बहस करता है जो शुरू से वहां )। दूसरे शब्दों में, बस एक यादृच्छिक शोर ।

@ सात-चरण-अधिकतम @ थानी आइए तापमान को एक पायदान नीचे ले जाएं। चारों ओर मजबूत राय है।

मुझे लगता है कि अधिकांश लोग इन दोनों के आस-पास एक ही पृष्ठ पर हैं, आदर्श रूप से कम द्वारा गणित की अभिव्यक्ति के रूप में व्याख्या नहीं की जा रही है:

font: 12px/10px;
width: calc(100% - 20px);

इसलिए, उन बिंदुओं पर अधिकतर सहमति है, और अधिकांश तर्क संभावित समाधानों के आसपास हैं। calc() समस्या ऐसा लगता है कि इसमें आगे बढ़ने के लिए पर्याप्त सहमति है। मूल रूप से: कैल्क को स्पर्श न करें, और स्ट्रिंग इंटरपोलेशन की तरह calc() में vars का इलाज करें। यह काफी हद तक Sass कैसे करता है, हालांकि इसे calc() में इंटरपोलेशन सिंटैक्स की आवश्यकता होती है, जो मुझे नहीं लगता कि हमें इसकी आवश्यकता है।

font भाग के समाधान बहुत अधिक बालों वाले हो जाते हैं और प्रमुख समाधान निम्न हैं:

1. डिफ़ॉल्ट रूप से हर चीज के लिए माता-पिता की आवश्यकता होती है (पहला प्रयास - लगभग कार्यान्वित, लेकिन समुदाय अस्वीकृत)
2. strictMath स्विच को पलटें (जो इसे डिफ़ॉल्ट बनाने के बजाय जोड़ा गया था, और @ सात-चरण-अधिकतम का सुझाव) और फिर स्पष्ट रूप से अपना सारा गणित करें। यह, तकनीकी रूप से, वर्तमान में अधिकांश लोगों के लिए एक संभावित समाधान है, लेकिन....प्रश्न इतनी बार आता है और हम मनोवैज्ञानिक रूप से जानते हैं कि किसी भी प्रणाली में कोई नया व्यक्ति किसी भी चूक को बनाए रखता है, इसलिए यह समस्याग्रस्त है। और हर डेवलपर अपनी बिल्ड सेटिंग नहीं बदल सकता, खासकर टीमों में।
3. कम में डिवीजन ऑपरेटर को अनिवार्य रूप से बदलें। धागे में अग्रणी दावेदार ./ , जो काम करता है लेकिन देखने में थोड़ा अजीब है। \ इस बिंदु पर शोध के बिना अज्ञात है। काम कर सकता है, भागने के साथ अज्ञात संघर्ष कर सकता है। यह क्लीनर सिंटैक्स है, (संभावित, लेकिन अज्ञात) उच्च जोखिम पर। यदि कोई यह प्रदर्शित करने के लिए समय लेगा कि इससे संघर्ष नहीं होगा यानी बचने के उदाहरण प्रदान करना और गणित को इस तरह से जोड़ना कि पार्सर स्पष्ट रूप से दोनों को अलग कर सके, तो यह अभी भी एक संभावना है। तो यह सिर्फ काम लेता है। @thany , अगर आप या कोई और इसका प्रशंसक है, तो यह आवश्यक कार्य है। आखिरी चीज जो हम चाहते हैं वह है ब्रेक को कहीं और ले जाना।

मुझे लगता है, इस सूत्र को सरल बनाने के लिए, हमें यहाँ से केवल #3 पर ध्यान केंद्रित करना चाहिए। मैंने ज्यादातर जिज्ञासा के रूप में सैस उदाहरण पोस्ट किया, लेकिन मुझे विश्वास नहीं है कि वे समाधान अच्छे हैं या पूरी तरह से समस्या का समाधान करते हैं, और वे कम के साथ अवधारणात्मक रूप से असंगत हैं। 0 + 1/2 की आवश्यकता की वैधता के बारे में बहस करने से हमें कुछ हासिल नहीं होने वाला है।

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

यदि लेस डिवीजन ऑपरेटर को बदला जाना चाहिए, तो इसे किसमें बदला जाना चाहिए?

• ./ - क्या यह उतना ही अजीब है जितना मुझे लगता है, या लोगों को लगता है कि यह ठीक है?
• \ - बिना शोध और सबूत के, और एक पार्सर के लिए छद्म कोड का पालन करने के लिए, यह आगे नहीं बढ़ेगा। मैं व्यक्तिगत रूप से इसे पसंद करूंगा, अगर इसे सुरक्षित साबित किया जा सकता है।
• अन्य प्रतिस्थापन?

ईमानदारी से, अगर हम calc() बदलते हैं और / बदलते हैं, तो मुझे लगता है कि हम गणित के आसपास के 99% शोर को कम में शांत कर देंगे।

हे सब, मैंने calc() - https://github.com/less/less.js/pull/3162

जब मैं एक ऐसे समाधान के साथ आया जो बिना किसी ऐड-ऑन कोड के काम करता था, तो मैं थोड़ा चकित था। मूल रूप से, हमारे पास पहले से ही strictMath स्विच के लिए कोड था, और अगर यह माता-पिता के बाहर था तो गणित का मूल्यांकन नहीं करने के लिए अभिव्यक्तियों में जांच करता है, इसलिए मैंने calc() मूल्यांकन करते समय गणित को बंद करने के लिए कॉल पर एक अतिरिक्त स्विच जोड़ा।

https://github.com/less/less.js/pull/3162/files#diff -a94aaffd78b1d3c5eda7a42d5be1ca0d और https://github.com/less/less.js/pull/3162/files#diff -4e696271823c96903a91fff84983bab6 देखें

क्या परीक्षण पर्याप्त हैं?

@ मैथ्यू-डीन: कॉफी:

क्या परीक्षण पर्याप्त हैं?

पीआर में टिप्पणियों के अनुसार कृपया एक परीक्षण जोड़ें:

foo: 1 + 2 calc(3 + 4) 5 + 6; // expected result: 3 calc(3 + 4) 11;

और एक छोटी सी टिप्पणी: यह फिक्स स्पष्ट रूप से उसी मुद्दे को पेश करता है जैसे #1627, अर्थात

<strong i="13">@a</strong>: floor(1.1);
<strong i="14">@b</strong>: floor(1 + .1);

div {
    foo: calc(<strong i="15">@a</strong> + 20%); // ok
    bar: calc(<strong i="16">@b</strong> + 20%); // error: invalid floor arguments
    baz: @b;             // ok
}

लेकिन calc यह ठीक है मुझे लगता है (आखिरकार आलसी-eval अवधारणा के प्रमुख पुनर्विकास को ठीक करने के लिए इसे ठीक करने के लिए कोई अन्य आसान तरीका calc भीतर vars का उपयोग करते समय आलसी-eval को ध्यान में रखने के लिए दस्तावेज़ों में नोटिस डालने का मामला है।

और एक छोटी सी टिप्पणी: यह फिक्स स्पष्ट रूप से उसी मुद्दे को पेश करता है जैसे #1627

अच्छी कैच!

संदर्भ mathOn संपत्ति प्रति कॉल को स्विच करना इसे हल करता है, पीआर में आपकी टिप्पणी के समान। मैंने float(1 + .1) लिए एक परीक्षण जोड़ा है जो पास हो गया है!

संदर्भ को स्विच करना गणित प्रति कॉल संपत्ति इसे हल करती है, पीआर में आपकी टिप्पणी के समान। मैंने फ्लोट(1 + .1) के लिए एक परीक्षण जोड़ा है जो पास हो जाता है!

:) नहीं, "फर्श" त्रुटि तब होनी चाहिए जब -sm: off । पीआर में मेरी नई टिप्पणी देखें।
पुनर्स्थापना केवल 1 + 2 calc(3 + 4) 5 + 6 जैसी चीजों का ख्याल रखती है।

:) नहीं, "फर्श" त्रुटि तब होनी चाहिए जब -sm: off।

क्यों? calc() अंदर कोई भी कार्य कम कार्य होना चाहिए। यहां तक ​​​​कि अगर वे नहीं हैं, तो कैल्क () के अंदर कोई सीएसएस-मूल कार्य नहीं हैं, जिनके बारे में मुझे पता है कि कच्चे गणित के भाव ले सकते हैं। अपेक्षित परिणाम वर्र्स और कम कार्यों का मूल्यांकन करना होगा, लेकिन कच्चे कार्यों को अकेले calc() अंदर छोड़ दें।

साइड नोट: मैंने कम में एक डिवीजन ऑपरेटर के रूप में / से \ पर स्विच करने का एक शाखा प्रयोग किया। बचने के लिए पहले से ही बहुत सारे परीक्षण हैं (और मैंने और जोड़ा, पता करने के लिए: # 3160), और वे सभी अभी भी ठीक काम करते हैं, और ऑपरेटरों के स्विच के साथ गणित ठीक काम करता है। मैंने कोई अंतर्निहित संघर्ष नहीं देखा। शाखा यहाँ मेरे कांटे पर है: https://github.com/matthew-dean/less.js/commit/509d34fff7e234846afa150b099cd259755a39d0

पुन: नेस्टेड कार्य

इसके लिए:

div {
    bar: calc(floor(1 + .1) + 20%);
}

एक डेवलपर के रूप में, अपेक्षित परिणाम होना चाहिए:

div {
    bar: calc(1 + 20%);
}

अब ठीक ऐसा ही होता है (इन परिवर्तनों के साथ)। इसे एक त्रुटि नहीं फेंकनी चाहिए।

@ मैथ्यू-डीन
नहीं, जिस तरह से आपने इसे लिखा है, यह:

foo: unit(1/2, px);

-sm:on संकलित होगा:

foo: .5px;

^ - गलत।
नेस्टेड कार्यों के लिए वही। इसके अलावा, तथ्य यह है कि अधिकांश फ़ंक्शन आमतौर पर अंकगणितीय अभिव्यक्तियों को नहीं ले सकते क्योंकि तर्क -sm: on का उल्लंघन करने का कारण नहीं है;
इस प्रकार -sm: on दोनों पंक्तियों के तहत:

foo: floor(1 + .1);
bar: calc(floor(1 + .1) + 20%);`

एक त्रुटि फेंकनी चाहिए (और यह वही है जो कमिट में टूट जाता है)।

तुम्हारी किस बारे में बोलने की इच्छा थी?

unit(1/2, px) साथ -sm:on :

ERROR: error evaluating function `unit`: the first argument to unit must be a number. Have you forgotten parenthesis?

calc(floor(1 + .1) + 20%) साथ -sm:on

ERROR: error evaluating function `floor`: argument must be a number

शाखा का निरीक्षण करें। कोशिश करके देखो।

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

मेरी क्षमा याचनाएं। मुझे लगता है कि मैं इस भाग के अप्रत्यक्ष नियंत्रण से चूक गया।

शाखा का निरीक्षण करें। कोशिश करके देखो

मैं नहीं कर सकता, क्षमा करें।

मेरी क्षमा याचनाएं। मुझे लगता है कि मैं इस भाग के अप्रत्यक्ष नियंत्रण से चूक गया।

चिंता न करें। उस पते के साथ, क्या ऐसा लगता है कि यह काम कर रहा है जैसा आप उम्मीद करेंगे?

उस पते के साथ, क्या ऐसा लगता है कि यह काम कर रहा है जैसा आप उम्मीद करेंगे?

हां, अभी तक मैं वहां किसी और संदिग्ध चीज की कल्पना नहीं कर सकता।

@ मैथ्यू-डीन
कम में डिवीजन ऑपरेटर को अनिवार्य रूप से बदलें। धागे में अग्रणी दावेदार रहा है ./, जो काम करता है लेकिन देखने में थोड़ा अजीब है। \ इस बिंदु पर अनुसंधान के बिना एक अज्ञात है [...] @thany , यदि आप या कोई और इसका प्रशंसक है, तो यह आवश्यक कार्य है। आखिरी चीज जो हम चाहते हैं वह है ब्रेक को कहीं और ले जाना।

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

मुझे अभी भी लगता है कि वास्तविक समाधान संदर्भ के बारे में कम जानने के लिए है। यह होना चाहिए (हां, यहां मैं अपने "चाहिए" के साथ फिर से जाता हूं, मुझे किस अन्य शब्द का उपयोग करना चाहिए ...) पता है कि calc() एक सीएसएस फ़ंक्शन है और इसे केवल गणित का मूल्यांकन करना चाहिए जो सीएसएस नहीं कर सकता है . लेकिन floor() सीएसएस में मौजूद नहीं है, इसलिए इसे अमान्य सीएसएस को बाहर नहीं निकालने के लिए (पूरी तरह से) मूल्यांकन करना होगा। मुझे लगता है कि इसका उल्लेख पहले किया गया है, हालांकि अलग-अलग शब्दों में।

मुझे अभी भी लगता है कि वास्तविक समाधान संदर्भ के बारे में कम जानने के लिए है। यह होना चाहिए (हां, यहां मैं अपने "चाहिए" के साथ फिर से जाता हूं, मुझे किस अन्य शब्द का उपयोग करना चाहिए? ...) पता है कि कैल्क() एक सीएसएस फ़ंक्शन है और इसे केवल उन गणित का मूल्यांकन करना चाहिए जो सीएसएस नहीं कर सकता है। लेकिन फर्श () सीएसएस में मौजूद नहीं है, इसलिए इसे अमान्य सीएसएस को बाहर नहीं निकालने के लिए (पूरी तरह से) मूल्यांकन करना होगा। मुझे लगता है कि इसका उल्लेख पहले किया गया है, हालांकि अलग-अलग शब्दों में।

पर्याप्त पुन: \ , लेकिन जहां तक ​​संदर्भ की बात है, आपकी अन्य पोस्टों के आधार पर, मैं गारंटी दे सकता हूं कि यह आपकी सोच से कहीं अधिक जटिल समस्या है। आपको वास्तव में इसे उबालना होगा:

12px/10px  // Is this division, or not?
10px/1.5 // is this division, or not? 

यदि आप निश्चित रूप से / को एक डिवीजन ऑपरेटर के रूप में छोड़ना चाहते हैं, calc() नकल करने के लिए, और यह अस्पष्ट नहीं है, तो आपको पूरी तरह से यह सुनिश्चित करने की आवश्यकता है कि / अंदर है कोष्ठक ( calc() अपवाद के अलावा)। यह अनुमानित संदर्भ प्रदान करेगा।

इस सूत्र की शुरुआत में यह सुझाव अभी भी एक संभावना है, और इसे कुछ मजबूत समर्थन प्राप्त था। अनिवार्य रूप से, कि डिफ़ॉल्ट सेटिंग यह है कि सभी गणित कोष्ठक के बाहर समर्थित है (और फिर, calc() को छोड़कर, अब 3.0+ से मामला है)। शायद यही रास्ता है। यह अनुमति देगा:

font: 10px/1.5;   // not division
font: (10px/10);  // division, result is 1px
font: 10px+15px/1.5;   // addition but not division, result is 25px/1.5
font: (10px+15px/1.5);  // result is 20px

बात यह है कि, 10px+15px/1.5 का परिणाम अभी भी देवों के लिए कठिन हो सकता है, एक अभिव्यक्ति के साथ जो "आधा-मूल्यांकन" प्राप्त करने के लिए लगता है जब तक कि यह कोष्ठक में न हो। अगर हम आगे बढ़ते और डिफ़ॉल्ट रूप से सख्त गणित चालू करते, तो शायद यह ठीक होता। यह और भी कम अस्पष्ट है। [श्रग] किसी भी तरह से, गणित को किसी प्रकार के संदर्भ में लपेटना अस्पष्टता को खत्म करने का तरीका है, और डिवीजन ऑपरेटर को बदलने के अलावा विभाजन का एकमात्र तरीका है।

समुदाय को अनिवार्य रूप से दिशा तय करनी होती है। इस धागे में व्यवहार्य विकल्प हैं। प्रत्येक में डाउनसाइड्स हैं। प्रत्येक में दर्द बिंदु होते हैं। किसी की पूरी सहमति नहीं होगी। लेकिन आईएमओ उनमें से कोई भी मौजूदा परिदृश्य से बेहतर है। बस उस गोली को निगल जाना है।

निर्णय के लिए अंतिम कॉल

तो असंभव को काम करने के प्रयास में, मैं प्रस्ताव करना चाहता हूं कि हम ऐसा करें (3 साल पहले की टिप्पणियों का जिक्र करते हुए।)

--strict-math 3 सेटिंग दें

1. बंद
2. विभाजन
3. सख्त (उर्फ on बैक-कंपैट के लिए)

बहस को निपटाने के लिए, --strict-math=division स्विच को निम्न कार्य करने दें:

1. कोष्ठक के बाहर केवल / वर्ण के साथ विभाजन न करें। जैसे border-radius: 55px / 25px; -> नो-मैथ (हाँ, यह मान्य CSS है)
2. दो अलग-अलग तरीकों से विभाजन की अनुमति दें:
   ए। . उपसर्ग - border-radius: 55px ./ 25px;
   बी। कोष्ठक - border-radius: (55px / 25px);
3. दोनों रूप कोष्ठक में मान्य हैं - जैसे border-radius: (55px ./ 25px); मान्य होगा

इसलिए, एक डेवलपर के रूप में, यदि आपको लगता है कि एक संस्करण आपकी प्राथमिकता नहीं है, तो आप दूसरे का उपयोग कर सकते हैं। कुछ लोग कोष्ठक का उपयोग नहीं करना पसंद कर सकते हैं; कुछ संशोधित डिवीजन ऑपरेटर का उपयोग नहीं करना पसंद कर सकते हैं। सब के लिए कुछ न कुछ। और उन नए लोगों के लिए कोई अप्रिय आश्चर्य नहीं है जो अब CSS में एक व्यापक सिंटैक्स का उपयोग कर रहे हैं, / में font , background , border-radius , @media प्रश्न, CSS ग्रिड गुण, और शायद भविष्य में और भी बहुत कुछ।

अगले कदम

मैं अनुशंसा करता हूं कि यह एक विकल्प के रूप में पीआर में जाता है, और फिर, जैसा कि चर्चा की गई है, भविष्य के प्रमुख संस्करण के लिए डिफ़ॉल्ट के रूप में स्विच हो जाता है

@ मैथ्यू-डीन

यानी पीरियड एस्केप सीक्वेंस के विलोम की तरह काम करता है?
बुरा विचार नहीं, सच में...

और सभी बातों पर विचार किया गया, _probably_ सबसे स्वच्छ संभव समाधानों में से एक।

@rjgotten यहां एक शुरुआत हुई: https://github.com/matthew-dean/less.js/tree/strict-math-division

मुझे अभी भी परीक्षणों में से एक अजीब त्रुटि मिल रही है, जहां ऐसा लगता है कि यह आयाम नोड्स में से एक को ऑपरेशन नोड में बदल देता है (और फिर एक त्रुटि फेंकता है क्योंकि यह ऑपरेशन नोड पर एक ऑपरेशन नहीं कर सकता है। यह ' t एक पार्सिंग समस्या प्रतीत होती है क्योंकि strictMath: division तहत नहीं चलने वाला एक अन्य परीक्षण ठीक काम करता है। इसे देखना चाहते हैं और देखना चाहते हैं कि क्या आप मदद कर सकते हैं?

मैं जो करना चाहता हूं वह इस मुद्दे को बंद करना है और शेष गणित के प्रश्नों को संभालने वाले नए मुद्दे बनाना है। विशेष रूप से:

1. हैंडलिंग डिवीजन, और strictMath: 'division' सुविधा।
2. मिश्रित इकाइयों का गणित संभालना। देखें: https://github.com/less/less.js/issues/3047