हमने Yandex.Mail में स्टाइलस प्रीप्रोसेसर का उपयोग क्यों शुरू किया, साथ ही साथ उस पुस्तकालय के बारे में जो आईई के साथ रहने में मदद करता है

आज मैं बात करना चाहता हूं कि क्यों और कैसे हम यैंडेक्स.मैल के विकास में स्टाइलस प्रीप्रोसेसर का उपयोग करने के लिए आए थे, और आईई के लिए शैलियों के साथ काम करने के लिए हमारे द्वारा उपयोग की जाने वाली विधि का भी वर्णन करें। यह बहुत आसानी से प्रीप्रोसेसरों का उपयोग करके कार्यान्वित किया जाता है और IE समर्थन को सरल और सुविधाजनक बनाता है। हमने इसके लिए एक विशेष पुस्तकालय विकसित किया है, जिसे हम साझा करेंगे - if-ie.styl ।

यह Yandex.Mail में स्टाइलस प्रीप्रोसेसर का उपयोग करने के बारे में लेखों की एक श्रृंखला में केवल पहला लेख है, जिसे हम प्रकाशन के लिए तैयार कर रहे हैं।

हम प्रीप्रोसेसरों का उपयोग करने के लिए कैसे आए

हालाँकि बाहरी रूप से Yandex.Mail एक-पेज के अनुप्रयोग की तरह दिखता है, इसके अंदर भारी संख्या में सभी प्रकार के ब्लॉक, उनके संशोधन और संदर्भ होते हैं जिनमें ये ब्लॉक और संशोधन दिखाई दे सकते हैं।

इसके अलावा, उसके पास पहले से ही तीस से अधिक थीम हैं। एक हल्के पृष्ठभूमि और एक अंधेरे वाले विषय हैं, ऐसे विषय हैं जो केवल रंग में भिन्न हैं, और ऐसे भी हैं जिनमें लगभग पूरे इंटरफ़ेस को प्लास्टिसिन से मैन्युअल रूप से ढाला गया है ( http://habrahabr.ru/company/yandex/blog-110556/ )। कुछ विषयों में केवल एक पृष्ठभूमि छवि होती है, जबकि अन्य में पृष्ठभूमि बदल सकती है - बेतरतीब ढंग से या दिन और मौसम के समय के आधार पर।

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

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

प्रीप्रोसेसर चयन

तीन विकल्पों में से चुनें: सैस, कम और स्टाइलस। यह प्रक्रिया काफी सरल थी: हमने कुछ उपलब्ध ब्लॉकों को लिया, और फिर उनमें से प्रत्येक प्रीप्रोसेसर का उपयोग करके उन्हें वापस लाने का प्रयास किया।

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

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

• &__bar , .foo चयनकर्ता के लिए उपयोग किया जाना चाहिए, .foo__bar देना चाहिए - ऐसे निर्माण BEM नामों के उपयोग को सरल बनाने के लिए आवश्यक होते हैं और बहुत सुविधाजनक होते हैं जब आपको एक लूप में कई संशोधक उत्पन्न करने की आवश्यकता होती है।
• .baz& , .foo .bar चयनकर्ता के लिए लागू किया जाना चाहिए, एक .baz.foo .bar देना चाहिए, लेकिन यह Sass में नहीं किया जा सकता है: यह केवल एक। लिखने के लिए संभव होगा। यदि आप नाम &.baz , लेकिन इसके विपरीत नहीं।
• button& .foo लिए लागू किया गया button& से पहले चयनकर्ता को स्पष्ट करना चाहिए।

और यह बहुत बुरा नहीं होगा अगर सास इंटरपोल में माता-पिता के चयनकर्ता को एक सूचक का उपयोग कर सकते हैं। लेकिन नहीं - सैस पहले प्रक्षेप का विस्तार करता है और उसके बाद ही चयनकर्ता को एक त्रुटि देने की कोशिश करता है।

सबसे आक्रामक बात यह है कि यह व्यवहार बग नहीं है, बल्कि एक विशेषता है । और यह नहीं बदलेगा। वह सास सिंटैक्स की विचारधारा है।

स्टाइलस प्रीप्रोसेसरों में सबसे नया था, और अंत में हमारी पसंद उस पर गिर गई। हां, यह नम है, इसमें अप्रिय कीड़े हैं, इसका समुदाय इतना बड़ा नहीं है, और विकास उतनी तेजी से नहीं हो रहा है जितना हम चाहते हैं। लेकिन हमारे कार्यों के लिए, वह सबसे अच्छा आया, और यहाँ क्यों है:

• स्टाइलस एक बहुत ही लचीला प्रीप्रोसेसर है, और अक्सर यह एक ही सैस की तुलना में अधिक लचीला होता है। उदाहरण के लिए, माता-पिता का संदर्भ स्टाइलस पूरी तरह से प्रकट करता है।
• स्टाइलस में पारदर्शी मिश्रण जैसी एक चीज है - एक फ़ंक्शन को नियमित सीएसएस संपत्ति के रूप में कॉल करने की क्षमता। यही है, पहले foo(bar) को परिभाषित करें, और फिर इसे foo: 10px रूप में कॉल करें। ऐसा रिकॉर्ड कॉलिंग foo(10px) बराबर होगा। सामान्य कार्यों के लिए, यह हमेशा सुविधाजनक नहीं होता है, लेकिन यह आपको किसी भी उपलब्ध संपत्ति को ओवरराइड करने की अनुमति देता है। कहते हैं कि आप padding में margin को ओवरराइड कर सकते हैं। गंभीरता से, इस कार्यक्षमता का उपयोग करते समय, आप आसानी से भ्रमित हो सकते हैं और समझ सकते हैं कि कोड क्या करता है: आखिरकार, यह हमेशा स्पष्ट नहीं होगा कि किन कार्यों को कोड द्वारा परिभाषित किया गया था और अगली संपत्ति को कॉल करने के परिणामस्वरूप क्या होगा।
  
  हालांकि, पारदर्शी मिश्रण बहुत समर्थन को सरल करते हैं, उदाहरण के लिए, ब्राउज़र उपसर्ग। यह याद रखना आवश्यक नहीं है कि किसी विशेष संपत्ति में कौन सा उपसर्ग है और इस बारे में चिंता करना कि क्या अगली संपत्ति के लिए एक विशेष निर्माण लिखना आवश्यक है। यह उपसर्गों के बिना हमेशा लिखने के लिए पर्याप्त सरल है, और जुड़ा पुस्तकालय उनके जोड़ का ख्याल रखेगा (हम इसके लिए हमारे कांटा नीब का उपयोग करते हैं)।
  
• स्टाइलस को JS में लिखा गया है। इसका मतलब है कि इसमें बग्स को बनाए रखना और ठीक करना आसान है (Yandex.Mail इंटरफ़ेस के सभी डेवलपर्स जेएस को रूबी से बहुत बेहतर जानते हैं)। इसके अलावा, यह नोड के अन्य उपकरणों (जैसे CSSO ) के साथ एक श्रृंखला में स्टाइलस का उपयोग करना आसान बनाता है।

स्टाइलस में अभी भी बहुत अलग-अलग उपयोगी चीजें हैं, लेकिन यह ऊपर वाले थे जिन्होंने हमें उनके पक्ष में चुना।

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

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

अगर-यानी। पुस्तकालय

यैंडेक्स.मैल को स्टाइलस में स्थानांतरित करने के दौरान, यह स्पष्ट हो गया कि प्रीप्रोसेसर उन विशेषताओं को प्रदान कर सकता है जो हमारे पास नियमित सीएसएस का उपयोग करते समय नहीं थे। हमने मेलों में नियमित ब्राउज़र के लिए और IE के पुराने संस्करणों के लिए लंबे समय तक स्टाइल पृथक्करण का उपयोग किया है। सभी शैलियों को BEM फ़ाइल संरचना के अनुसार निर्धारित किया गया था , और प्रत्येक ब्लॉक के लिए दो फाइलें पास में बनाई गई थीं: b-block.css और b-block.ie.css ।

पहली फ़ाइल सभी ब्राउज़रों के लिए शैली गई, और दूसरी, क्रमशः, केवल वही जो इंटरनेट एक्सप्लोरर के लिए आवश्यक थीं। यह ध्यान दिया जाना चाहिए कि कई कारणों से हमने IE8 को IE7 के साथ संगतता मोड में रखा है, और IE6 का समर्थन करने के लिए भी, हम इसे मेल के "हल्के" संस्करण में भेजते हैं। इस प्रकार, हमारे पास शैलियों के दो अलग-अलग संस्करण हैं: सभी ब्राउज़रों के लिए एक, IE के सभी पुराने संस्करणों के लिए दूसरा। सब कुछ स्वचालित रूप से एकत्र किया गया था - पहले "सभी के लिए" स्टाइलशीट को इकट्ठा किया गया था, जिसके बाद .ie.css फ़ाइलों से सभी शैलियों को इसमें जोड़ा गया था और IE के लिए स्टाइलशीट प्राप्त की गई थी।

प्रत्येक ब्राउज़र को केवल अपनी स्वयं की स्टाइलशीट प्राप्त होती है - इसके लिए हम सशर्त टिप्पणियों का उपयोग करते हैं, कुछ इस तरह से:

 <!--[if gt IE 7]><!--> <link rel="stylesheet" href="style.css" /> <!--<![endif]--><!--[if lt IE 8]> <link rel="stylesheet" href="style_ie.css" /> <![endif]--> 

सबसे पहले, शैलियों की इस जुदाई ने अच्छा काम किया, लेकिन प्रीप्रोसेसर के आगमन के बाद सवाल उठने लगा: क्या बेहतर करना संभव है?

यह पता चला कि यह संभव है।

तो स्टाइलस के लिए एक पुस्तकालय था - " इफ-यानी.स्टाइल "। यह वास्तव में एक पुस्तकालय नहीं है, बल्कि IE के लिए शैलियों के साथ काम करने के लिए एक पद्धति है। इस पद्धति में कुछ भी गुप्त नहीं है, इसलिए हमने इसे एमआईटी लाइसेंस के तहत जीथब पर लगाने का फैसला किया। आप इसे अपने प्रोजेक्ट के लिए सुरक्षित रूप से उपयोग कर सकते हैं, बग्स की रिपोर्ट कर सकते हैं या यहां तक ​​कि खुद को ठीक कर सकते हैं - ओपन सोर्स, सभी चीजें। या हो सकता है कि कोई दूसरा पूर्वप्रोसेसर के लिए इसे फिर से लिख सकेगा? परियोजना को कांटा करें या एक नया निर्माण करें, कार्यप्रणाली को आधार के रूप में लें - यह बहुत अच्छा होगा।

कार्यप्रणाली का आधार

कार्यप्रणाली एक बहुत ही सरल विचार पर आधारित है: हम वैरिएबल का निर्माण करते हैं, जो सभी साधारण ब्राउज़रों के लिए false होगा, और जब हम IE के लिए शैलियों को प्राप्त करना चाहते हैं तो यह true । उसके बाद, आप केवल एक मुख्य शैली शीट का उपयोग कर सकते हैं, जिसमें सामान्य परिस्थितियों में विभिन्न ब्राउज़रों के लिए शैलियों को भेद करना है। एक सरल उदाहरण: style.styl फ़ाइल लें:

 ie ?= false .foo overflow: hidden zoom: 1 if ie 

इस तरह के डिफ़ॉल्ट स्टाइलस कोड - नियमित ब्राउज़र के लिए - इस तरह सीएसएस बन जाएगा:

 .foo { overflow: hidden; } 

चूँकि ie वैरिएबल false था, if ie कंडीशन काम नहीं करती थी, और इस स्टाइलशीट में zoom प्रॉपर्टी शामिल नहीं थी।

अब अगली style_ie.styl :

 ie = true @import style.styl 

यदि हम ऐसा स्टाइलस कोड देते हैं, तो हमें यह मिलता है:

 .foo { overflow: hidden; zoom: 1; } 

यह वही है जो हमें चाहिए था - एक अलग तालिका जिसमें केवल IE में आवश्यक शैलियों हैं।

उसी समय, यदि हम केवल नियमित ब्राउज़र के लिए कुछ शैलियों को लिखना चाहते हैं, तो हम if का उपयोग कर सकते हैं if !ie स्थिति और शैलियों को फ़िल्टर करना बहुत सरल हो जाता है।

If-ie.styl की अतिरिक्त विशेषताएं

बेशक, यह हमारे लिए पर्याप्त नहीं था और हमने सभी प्रकार के उपयोगी कार्यों को जोड़ने का फैसला किया जो हमारे कोड में बहुत कुछ अनुकूलित करेंगे। और इसलिए यह एक "पुस्तकालय" निकला।

इसका उपयोग करने के लिए, कनेक्टिंग स्टाइल थोड़ा अलग दिखेंगे।

style.styl फ़ाइल बन जाएगी:

 @import if-ie.styl .foo overflow: hidden zoom: 1 

इस तरह एक style_ie.styl :

 ie = true @import if-ie.styl @import style.styl 

अतिरिक्त कार्यों के बिना विकल्प के साथ तुलना में दो अंतर हैं:

1. दोनों फ़ाइलों में, आपको लाइब्रेरी को अन्य सभी शैलियों से कनेक्ट करने की आवश्यकता है, और दोनों बार सुनिश्चित करें। (ऐसा लग सकता है कि केवल पहले पर्याप्त होगा - आखिरकार, IE के लिए स्टाइलशीट में पहले से ही मुख्य स्टाइलशीट शामिल है - लेकिन फिर निम्न में से कुछ विशेषताएं काम नहीं करेंगी)। इस फ़ाइल में, ie ?= false पहले ie ?= false ही परिभाषित है, और इसलिए आपको मुख्य शैली शीट में इसे स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता नहीं है।
2. if ie IE के लिए स्टाइलशीट में आईवी की स्थिति गायब हो गई है - यह पुस्तकालय की पहली विशेषता के संचालन को दर्शाता है: zoom संपत्ति स्वचालित रूप से केवल IE के लिए स्टाइलशीट में दिखाई देगी। बेशक, सामान्य ब्राउज़रों में आप इस संपत्ति का उपयोग कर सकते हैं, लेकिन व्यवहार में ऐसी आवश्यकता अत्यंत दुर्लभ है, इसलिए आप मुख्य स्टाइलशीट को कम से कम थोड़ा हल्का कर सकते हैं।

स्टाइलस कोड में, ऐसे कार्यों को परिभाषित करना बहुत आसान है। इस मामले में, नया पारदर्शी मिश्रण इस तरह दिखेगा:

 zoom() zoom: arguments if ie 

इस कोड के साथ, हम एक zoom फंक्शन बनाते हैं जो संबंधित संपत्ति को किसी भी दलील के साथ पंजीकृत करेगा यदि हम वर्तमान में IE के लिए शैलियों का संग्रह कर रहे हैं।

inline-block

यह व्यापक रूप से ज्ञात है कि IE के पुराने संस्करणों में "बॉक्स से बाहर" display संपत्ति inline-block मूल्य का समर्थन नहीं करती है। IE में एक समान तंत्र है, लेकिन यह केवल इनलाइन तत्वों के लिए काम करता है और केवल तभी जब हैलआउट तंत्र चालू होता है। यह काफी संभावना है कि display: inline-block IE में display: inline-block बस इसे चालू करता है, लेकिन display: inline करने के लिए एक तत्व को स्विच करने के लिए "भूल जाता है" display: inline , इसलिए ऐसा रिकॉर्ड शुरू में <div> जैसे तत्वों को ब्लॉक करने के लिए काम नहीं करेगा। तो सबसे आसान तरीका IE में किसी भी तत्व के लिए इनलाइन-ब्लॉक व्यवहार को लागू करने की गारंटी है - केवल इसके लिए पंजीकरण करें zoom: 1; display: inline; zoom: 1; display: inline; ।

If-ie.styl में, display प्रॉपर्टी यह स्वचालित रूप से और केवल IE के लिए करेगी। नियमित ब्राउज़र display: inline-block देखेंगे display: inline-block , जबकि IE केवल zoom: 1; display: inline; करेगा zoom: 1; display: inline; zoom: 1; display: inline; । फिर कोई यह देख सकता है कि दूसरा रिकॉर्ड पहले की तुलना में लंबा है, और शुरू में इनलाइन ब्लॉक के लिए इसे बचाना संभव होगा ... लेकिन अगर आप सावधानीपूर्वक गणना करते हैं, तो बचत केवल एक बाइट होगी। यह इस बात पर ध्यान देने के लायक नहीं है कि ब्लॉक शुरू में इनलाइन है या नहीं। इसके अलावा, आदर्श रूप से, लेआउट पर निर्भर नहीं होना चाहिए कि यह किस तत्व पर लागू होता है।

CSS3 के गुणों को ओवरराइड करना

यदि हम डिफ़ॉल्ट रूप से zoom: 1 नहीं करते हैं zoom: 1 सामान्य ब्राउज़रों को, सभी शैलियों को दो फ़ाइलों में विभाजित करना (जैसा कि सामान्य तौर पर, प्रीप्रोसेसर की शुरूआत से पहले) था, तो प्रीप्रोसेसरों के साथ आप यह भी सोच सकते हैं कि IE के लिए स्टाइलशीट को कैसे सरल बनाया जाए।

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

इससे पहले लेख में, मैंने पहले ही उल्लेख किया था कि हम नायब लाइब्रेरी का उपयोग करते हैं - यह लाइब्रेरी अधिकांश नए सीएसएस गुणों के लिए पारदर्शी मिश्रण को परिभाषित करती है, उदाहरण के लिए, ट्रेंच के लिए। नतीजतन, स्टाइलस के लिए शैलियों में हम बस transition: opacity .3s लिखते हैं transition: opacity .3s और परिणामस्वरूप हमें यह संपत्ति सभी आवश्यक उपसर्गों के साथ मिलती है। लेकिन IE में हमें न केवल उपसर्गों की आवश्यकता है, बल्कि संपत्ति भी! इसलिए, हम अपने पुस्तकालय में इस और कई अन्य गुणों को फिर से परिभाषित कर सकते हैं ताकि वे कुछ भी वापस न करें।

यह इस प्रकार किया जाता है:

 if ie transition() z if 0 transition-property() z if 0 // … 

यहां सब कुछ लगभग स्पष्ट है: एक स्थिति में, हम केवल IE के लिए सभी आवश्यक गुणों को फिर से परिभाषित करते हैं। हालांकि, स्टाइलस की ख़ासियत के कारण, एक फ़ंक्शन की परिभाषा में कम से कम एक नियम लिखना आवश्यक है - z if 0 निकला, z if 0 यह काफी कम है।

नतीजतन, IE, निब में परिभाषित ट्रांस्फ़ॉर्म मिक्सिन के बजाय, जिसे हम if-ie.styl में परिभाषित करते हैं, और परिणामी स्टाइलशीट पहले की तुलना में बहुत आसान है - लगभग सब कुछ जिसकी ज़रूरत नहीं है, वह इससे बाहर कट जाएगा।

rgba-ie

हम लेख को नहीं बढ़ाएंगे और अगर-यानी.स्टील में है, तो सब कुछ का वर्णन करेंगे - यह पहले से ही परियोजना प्रलेखन में विस्तार से वर्णित है ।

हालाँकि, हमें आपको एक अन्य फ़ंक्शन के बारे में बताने की ज़रूरत है जो कि Yandex.Mail की थीम के भाग के रूप में हमारे लिए बहुत उपयोगी है। यह rgba-ie फंक्शन है। दरअसल, इस फ़ंक्शन को बस rgba कहा जा सकता है, लेकिन स्टाइलस में एक बग है: जेएस में परिभाषित कार्यों को उसी तरह से फिर से परिभाषित नहीं किया जा सकता है जैसे कि स्टाइलस में परिभाषित किए गए थे, इसलिए मुझे एक नया बनाना था।

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

If-ie.styl से rgba- rgba-ie फ़ंक्शन इस कार्य को बहुत सरल करता है: सामान्य rgba फ़ंक्शन की क्षमताओं की नकल करते हुए, हमें एक और वैकल्पिक पैरामीटर मिलता है जो फ़ंक्शन को दिया जा सकता है - बैकबैक के लिए पृष्ठभूमि रंग। डिफ़ॉल्ट रूप से, यह पैरामीटर #FFF सेट है।

एक सरल उदाहरण:

 .foo color: rgba-ie(0,0,0,0.5) 

सामान्य ब्राउज़रों में, यह रंग सामान्य rgba(0,0,0,0.5) , लेकिन IE में यह #808080 rgba(0,0,0,0.5) में बदल जाएगा - अर्थात्, सफेद रंग के शीर्ष पर संबंधित रंग।

अंतिम तर्क के रूप में लक्ष्य पृष्ठभूमि के साथ एक अधिक जटिल उदाहरण (और स्टाइलस सुविधाओं में से एक का उपयोग करते हुए - तीन अंकों r , g और b बजाय हेक्स में रंग निर्दिष्ट करने की क्षमता):

 .foo background: rgba-ie(#FFDE00, .42, #19C261) 

इस उदाहरण में, सामान्य ब्राउज़रों के लिए, रंग rgba(255,222,0,0.42) , लेकिन IE को सही #7ace38 ।

उसी समय, $default_rgba_fallback चर का उपयोग करके डिफ़ॉल्ट फ़ॉलबैक को सेट करना संभव है।

नतीजतन, आप अपने जीवन को बहुत सरल कर सकते हैं यदि आप सामान्य rgba बजाय rgba-ie फ़ंक्शन का उपयोग करते हैं - तो आप शायद ही इस मामले में IE के बारे में याद कर सकते हैं।