Less.js: बिल्टिन फ़ंक्शंस के अंदर कस्टम गुण जैसे `rgba ()` थ्रो एरर

बस भाग जाओ ।

मैंने "फीचर रिक्वेस्ट" लेबल लगाया क्योंकि यह निश्चित रूप से एक समस्या बन जाती है जब कस्टम गुण टीआर में होते हैं। CSS फ़ंक्शंस args के लिए किसी भी त्रुटि का पता लगाने को अक्षम करके इसे ठीक करना आसान है (हालाँकि यह काफी दुखद है क्योंकि यह भाषा के एक महत्वपूर्ण हिस्से को मारता है - यानी ब्राउज़र में डीबग होने तक हमें अब कोई त्रुटि नहीं मिलेगी)।

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

कम, AFAIK, कस्टम संपत्ति मूल्यों की अत्यंत अनुमेय प्रकृति के लिए भी परीक्षण नहीं करता है। जब तक वे शीर्ष-स्तरीय टोकन नहीं हैं (ब्रैकेट या घुंघराले-ब्रेस जोड़े में शामिल नहीं हैं) तब तक उनमें बहुत कुछ हो सकता है, यहां तक ​​​​कि अर्ध-कॉलन भी हो सकते हैं। देखें: https://www.w3.org/TR/css-variables/#syntax

चूँकि इस परिवर्तन के लिए किसी भी तरह से n-of-args जाँच की आवश्यकता होती है (फ़ंक्शन के भीतर कम से कम कुछ त्रुटि सत्यापन रखने के लिए), यह भी माना जाता है कि नया rgba कार्यान्वयन भी क्रमिक रंग मानों के लिए दो तर्क प्रपत्र का समर्थन करता है, उदाहरण के लिए :

rgba(var(--some), .42); // -> rgba(var(--some), .42)
rgba(#010101, .42); // -> rgba(1, 1, 1, .42)

हमें सामान्य रूप से args में कस्टम गुणों को कैसे संभालना चाहिए? तकनीकी रूप से, आप लगभग कहीं भी var(--some-property) उपयोग कर सकते हैं, और यदि कम अंतर्निहित CSS फ़ंक्शंस जैसे rgba() लिए args की व्याख्या करने का प्रयास कर रहा है, तो यह एक समस्या है। हालांकि मुझे यकीन नहीं है कि अंतर्निहित सीएसएस फ़ंक्शन के लिए कम सख्त मान त्रुटियां क्यों फेंक रहा है? सिर्फ भावों का समर्थन करने के लिए?

मुझे https://github.com/less/less.js/blob/master/lib/less/functions/color.js#L34 पर बिल्ट-इन CSS फ़ंक्शंस का एक पूरा गुच्छा दिखाई देता है, और IMO में से अधिकांश को ऐसा नहीं करना चाहिए वहाँ होना। कम एक लिंटर नहीं है, और वे कम कार्य नहीं हैं। यदि पार्सर सीएसएस कार्यों में सुपर-चालाक प्राप्त करने का प्रयास करता है, तो यह असफल हो जाएगा। तो मुझे लगता है कि समस्या का स्रोत है, कि कम वर्तमान में बंदर-पैचिंग नियमित सीएसएस रंग कार्यों को पास-थ्रू देने के बजाय है।

मुझे यकीन नहीं है कि क्या यह उन ब्राउज़र के लिए जोड़ा गया था जो अभी तक rgb() rgba() समर्थन नहीं करते थे? ऐसा लगता है कि इसे 4 साल पहले जोड़ा गया था। हो सकता है कि तर्क नए रंग कार्यों में संतुलन जोड़ना था जो अभी तक ब्राउज़र में समर्थित नहीं हैं? 🤔 @lukeapage आप अभी भी जवाब देने के लिए चारों ओर कर रहे हैं?

# ३२१४ पर मेरी टिप्पणी को ध्यान में रखते हुए, इस मुद्दे के लिए त्वरित सुधार होगा: "अगर (nargs <3/4) सीएसएस स्ट्रिंग में वापस आ जाता है (कुछ भी नहीं लौटाकर)" संबंधित कार्यों के कार्यान्वयन में।

(और इस तरह के प्रत्येक func में प्रत्येक आर्ग के लिए चेक डालने में एक और सख्त फिक्स यह तय करने के लिए है कि यह मूल्यांकन योग्य है और या तो रंगीन ऑब्जेक्ट या सीएसएस-स्ट्रिंग फ़ॉलबैक लौटा रहा है)।

# ३२१४ पर मेरी टिप्पणी को ध्यान में रखते हुए, इस मुद्दे के लिए त्वरित सुधार होगा: "अगर (nargs <3/4) सीएसएस स्ट्रिंग में वापस आ जाता है (कुछ भी नहीं लौटाकर)" संबंधित कार्यों के कार्यान्वयन में।

और इसी तरह की जांच var() ?

darken(rgba(var(--red-value), 2, 3, .4), 5%)

वह है: क्या हमें निम्नलिखित करना चाहिए:

1. कार्यों के पास-थ्रू की अनुमति दें यदि वे n-args से मेल नहीं खाते हैं? मुझे लगता है कि हमें विशेष रूप से कार्यों को ध्वजांकित करने की आवश्यकता होगी क्योंकि फ़ंक्शन रजिस्ट्री के बारे में कुछ खास नहीं है (जब तक कि हम toString() फ़ंक्शन की तरह कुछ पागल नहीं करते हैं और शाब्दिक रूप से रेगेक्स के साथ तर्कों की गणना करते हैं - AFAIK जेएस में प्रतिबिंब का एकमात्र प्रकार है; आप टाइपस्क्रिप्ट के साथ ऐसा करने में सक्षम हो सकता है लेकिन यह हमारी मदद नहीं करता है)
2. यदि गैर-मिलान फ़ंक्शन का उपयोग किसी अन्य कम फ़ंक्शन मूल्यांकन में किया जाता है, तो त्रुटि फेंकें।

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

यह एक दिलचस्प समस्या है क्योंकि कस्टम गुणों की शुरूआत ने संकलन समय पर सीएसएस कार्यों को हल करने योग्य नहीं बनाया है।

वास्तव में कुछ भी नया नहीं है। कम के साथ इसे संभालने के लिए सभी आवश्यक सुविधा इसके v1.x के बाद से है - नीचे देखें। एकमात्र चुनौती इसे नॉन-ब्लोटिंग तरीके से कोड करना है।

मुझे लगता है कि हमें विशेष रूप से कार्यों को ध्वजांकित करने की आवश्यकता होगी क्योंकि फ़ंक्शन रजिस्ट्री के बारे में कुछ खास नहीं है

नहीं, फ़ंक्शंस को केवल undefined (या null ) वापस करना चाहिए यदि वे पाते हैं कि वे अपने तर्कों का मूल्यांकन नहीं कर सकते हैं: इस तरह (जब तक वे यह भी पता नहीं लगाते कि तर्क 100% अनिश्चित हैं और यह बेहतर है एक त्रुटि ट्रिगर)। .
और अपरिभाषित वापसी मान फ़ंक्शन मूल्यांकनकर्ता को प्रारंभिक स्ट्रिंग प्रतिनिधित्व पर वापस आने के लिए बनाता है: डेमो ।

और var() लिए एक समान चेक

इसके अलावा, var या कुछ भी विशिष्ट (मूल रूप से सीएसएस भविष्य से अज्ञात चीजें) की जांच करने की कोई आवश्यकता नहीं है। यही तो बात है। कोड को इस बात की जांच करनी चाहिए कि क्या मूल्यांकन करना संभव है (ज्ञात चीजें) के बजाय क्या मूल्यांकन करना संभव नहीं है (अज्ञात)।
(हालांकि विवरण विशिष्ट कार्य के आधार पर बहुत हो सकता है - यह इतना महत्वपूर्ण नहीं है)।

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

@ सात-चरण-अधिकतम ओह ठीक है, तो आपको लगता है कि इन सीएसएस/कम कार्यों के लिए एक त्रुटि फेंकने के बजाय अपरिभाषित लौटने के लिए सरल फिक्स है (जैसा है प्रस्तुत करने के लिए)? यह उचित लगता है, तो यदि कार्य नं। 2 (जैसे darken() ) एक तर्क की व्याख्या नहीं कर सकता (जो इस बिंदु पर rgba() अनाम मान के लिए eval'd किया जाएगा?), इसे अभी भी फेंकना चाहिए?

खुद से बहस करना:

इसके अलावा, var() या कुछ भी विशिष्ट (मूल रूप से सीएसएस भविष्य से अज्ञात चीजें) की जांच करने की कोई आवश्यकता नहीं है।

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

@ मैथ्यू-डीन

यह उचित लगता है, तो यदि कार्य नं। 2 (जैसे अंधेरा ()) एक तर्क की व्याख्या नहीं कर सकता है (जो इस बिंदु पर एक आरजीबीए() अज्ञात मान के लिए eval'd किया जाएगा?), इसे अभी भी फेंकना चाहिए?

हां, बिल्कुल - हमें इसके लिए किसी नए कोड की भी आवश्यकता नहीं है (हालांकि आदर्श रूप से वे ( darken जैसे कार्य) में इस मामले में अधिक अनुकूल त्रुटि संदेश होने चाहिए क्योंकि वर्तमान "a.toHSL is not a function" -जैसे संदेश हैं काफी भ्रमित करने वाला)।

ठीक है, दूसरी बात का उल्लेख नहीं किया गया है कि rgba(calc(1),1,1) जैसी किसी चीज़ को ब्राउज़र द्वारा मान्य माना जाता है (कैल्क और 3 बनाम 4 तर्क दोनों पर ध्यान दें), इसलिए हमें शायद इसके बारे में बहुत चालाक नहीं होना चाहिए। यदि संभव हो तो मुझे सामान्य नियम के रूप में केवल आउटपुट करने का विचार पसंद है।

हां, मेरा यही मतलब है

कोड को इस बात की जांच करनी चाहिए कि क्या मूल्यांकन करना संभव है (ज्ञात चीजें) के बजाय क्या मूल्यांकन करना संभव नहीं है (अज्ञात)।

कम rgba लिए एकमात्र मान्य तर्क या तो एक संख्या या एक रंग वस्तु है (यदि हम rgba(#123, .42) जैसे "नियो"-"CSS4" जैसे रूपों पर भी विचार करते हैं)।
कुछ और या तो एक त्रुटि है या एक (अज्ञात लेकिन संभावित रूप से मान्य) CSS मान है।

सीएसएस कस्टम गुणों की सामग्री का सिंटेक्स बहुत अनुमेय है लेकिन यह rgba() जैसे बिल्टिन कार्यों के अंदर ऐसी संपत्तियों का उपयोग करते समय समस्याएं पैदा करता है

उदाहरण:
मेरी परियोजना उपयोगकर्ता को उच्चारण रंग को परिभाषित करने की अनुमति देती है जिस पर संपूर्ण ऐप UI और विभिन्न कस्टम घटक आधारित होते हैं। और मैं आरजीबी प्रारूप का उपयोग कर रहा हूं क्योंकि कुछ जगहों पर फीका होने की आवश्यकता है और सीएसएस कम में fade(<strong i="9">@color</strong>, 50%) जैसा कुछ भी प्रदान नहीं करता है। इस तरह मैं rgba( var(--color), 0.5 ) कर सकता हूं। यह क्रोम में काम करता है और स्टैंडआर्ट द्वारा समर्थित है। हालांकि कम निम्न त्रुटि फेंकता है error evaluation function 'rgba': color functions take numbers as parameters ।

उदाहरण कोड:

:root {
  --color-accent: 169,57,255;
}
button:hover {
  background-color: rgba(var(--color-accent), 0.2);
  color: rgb(var(--color-accent));
}

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

बीटीडब्लू: क्या कोई अस्थायी कामकाज है जो इस तरह के सख्त संचालन को छोड़ देगा और इसे वैसे भी बना देगा? ऐसा नहीं है कि मुझे नेस्टेड नियमों में एक ब्रैकेट याद आ रहा है।

इस तरह लिखें~

:root {
    --color-accent: 169,57,255;
}
button:hover {
    background-color: ~"rgba(var(--color-accent), 0.2)";
    color: ~"rgb(var(--color-accent))";
}

@weivea कम 3.x के नवीनतम संस्करण पर, यह आवश्यक नहीं है, बस rgba(var(--color-accent)) . लिखें