बुनियादी सीएसएस के सिद्धांतों को सीखते समय, रखरखाव सुनिश्चित करने के लिए मॉड्यूलर, पुन: प्रयोज्य और वर्णनात्मक शैलियों को लिखना सिखाया जाता है। लेकिन जब डेवलपर्स वास्तविक दुनिया के अनुप्रयोगों में शामिल हो जाते हैं, तो अनपेक्षित क्षेत्रों में शैलियों के लीक हुए बिना यूआई सुविधाओं को जोड़ना अक्सर असंभव लगता है। यह मुद्दा अक्सर एक स्व-पूर्ति पाश में बदल जाता है; वे शैलियाँ जो सैद्धांतिक रूप से एक तत्व या वर्ग तक सीमित हैं, वहाँ दिखाई देने लगती हैं जहाँ वे नहीं हैं। यह डेवलपर को लीक हुई शैलियों को ओवरराइड करने के लिए और भी अधिक विशिष्ट चयनकर्ता बनाने के लिए मजबूर करता है, जो फिर गलती से वैश्विक शैलियों को ओवरराइड कर देता है, इत्यादि। कठोर वर्ग नाम परंपराएँ, जैसे कि बीईएम, इस मुद्दे का एक सैद्धांतिक समाधान हैं। बीईएम (ब्लॉक, एलीमेंट, मॉडिफ़ायर) पद्धति सीएसएस फ़ाइलों के भीतर पुन: प्रयोज्य और संरचना सुनिश्चित करने के लिए सीएसएस कक्षाओं के नामकरण का एक व्यवस्थित तरीका है। इस तरह के नामकरण परंपराएं तत्वों और उनकी स्थिति का वर्णन करने के लिए डोमेन भाषा का लाभ उठाकर संज्ञानात्मक भार को कम कर सकती हैं, और यदि सही ढंग से लागू किया जाता है, तो बड़े अनुप्रयोगों के लिए शैलियों को बनाए रखना आसान हो सकता है। हालाँकि, वास्तविक दुनिया में, यह हमेशा उस तरह काम नहीं करता है। प्राथमिकताएँ बदल सकती हैं और परिवर्तन के साथ कार्यान्वयन असंगत हो जाता है। HTML संरचना में छोटे बदलावों के लिए कई CSS वर्ग नाम संशोधनों की आवश्यकता हो सकती है। अत्यधिक इंटरैक्टिव फ्रंट-एंड अनुप्रयोगों के साथ, बीईएम पैटर्न का पालन करने वाले वर्ग के नाम लंबे और बोझिल हो सकते हैं (उदाहरण के लिए, ऐप-उपयोगकर्ता-अवलोकन__स्थिति--प्रमाणीकरण), और नामकरण नियमों का पूरी तरह से पालन नहीं करने से सिस्टम की संरचना टूट जाती है, जिससे इसके लाभ समाप्त हो जाते हैं। इन चुनौतियों को देखते हुए, इसमें कोई आश्चर्य की बात नहीं है कि डेवलपर्स ने फ्रेमवर्क की ओर रुख किया है, टेलविंड सबसे लोकप्रिय सीएसएस फ्रेमवर्क है। शैलियों के बीच अजेय विशिष्टता युद्ध से लड़ने की कोशिश करने के बजाय, सीएसएस कैस्केड को छोड़ना और पूर्ण अलगाव की गारंटी देने वाले टूल का उपयोग करना आसान है। डेवलपर्स उपयोगिताओं पर अधिक निर्भर हैं हमें कैसे पता चलेगा कि कुछ डेवलपर कैस्केड शैलियों से बचने के इच्छुक हैं? यह "आधुनिक" फ्रंट-एंड टूलींग का उदय है - जैसे सीएसएस-इन-जेएस फ्रेमवर्क - विशेष रूप से उस उद्देश्य के लिए डिज़ाइन किया गया है। अलग-अलग शैलियों के साथ काम करना जो विशिष्ट घटकों तक सीमित हैं, ताजी हवा के झोंके की तरह लग सकते हैं। यह चीजों को नाम देने की आवश्यकता को हटा देता है - अभी भी सबसे अधिक नफरत और समय लेने वाले फ्रंट-एंड कार्यों में से एक - और डेवलपर्स को सीएसएस विरासत के लाभों को पूरी तरह से समझने या लाभ उठाने के बिना उत्पादक होने की अनुमति देता है। लेकिन सीएसएस कैस्केड को छोड़ना अपनी समस्याओं के साथ आता है। उदाहरण के लिए, जावास्क्रिप्ट में शैलियों की रचना के लिए भारी बिल्ड कॉन्फ़िगरेशन की आवश्यकता होती है और अक्सर शैलियों को घटक मार्कअप या HTML के साथ अजीब तरह से मिश्रित किया जाता है। नामकरण परंपराओं पर सावधानीपूर्वक विचार करने के बजाय, हम हमारे लिए चयनकर्ताओं और पहचानकर्ताओं को स्वचालित रूप से उत्पन्न करने के लिए टूल बनाने की अनुमति देते हैं (उदाहरण के लिए, .jsx-3130221066), जिससे डेवलपर्स को अपने आप में एक और छद्म भाषा के साथ बने रहने की आवश्यकता होती है। (मानो आपके सभी घटकों के उपयोग प्रभाव क्या करते हैं यह समझने का संज्ञानात्मक भार पहले से ही पर्याप्त नहीं था!) टूलिंग के लिए कक्षाओं के नामकरण के काम को और अधिक सारगर्भित करने का मतलब है कि मूल डिबगिंग अक्सर विकास के लिए संकलित विशिष्ट एप्लिकेशन संस्करणों तक ही सीमित होती है, बजाय इसके कि डेवलपर टूल्स जैसे लाइव डिबगिंग का समर्थन करने वाले देशी ब्राउज़र सुविधाओं का लाभ उठाया जाए। यह लगभग वैसा ही है जैसे हमें उन टूल को डीबग करने के लिए टूल विकसित करने की आवश्यकता है जिनका उपयोग हम उन टूल को अमूर्त करने के लिए कर रहे हैं जो वेब पहले से ही प्रदान करता है - यह सब मानक सीएसएस लिखने के "दर्द" से दूर भागने के लिए है। सौभाग्य से, आधुनिक सीएसएस सुविधाएँ न केवल लेखन मानक सीएसएस को अधिक लचीला बनाती हैं, बल्कि हमारे जैसे डेवलपर्स को कैस्केड को प्रबंधित करने और इसे हमारे लिए काम करने के लिए बहुत अधिक शक्ति भी देती हैं। सीएसएस कैस्केड परतें एक महान उदाहरण हैं, लेकिन एक और विशेषता है जिस पर आश्चर्यजनक रूप से ध्यान नहीं दिया जाता है - हालांकि यह अब बदल रहा है क्योंकि यह हाल ही में बेसलाइन संगत बन गया है। सीएसएस @स्कोप एट-नियम मैं सीएसएस @स्कोप एट-रूल को उस तरह की स्टाइल-लीक-प्रेरित चिंता के लिए एक संभावित इलाज मानता हूं, जिसे हमने कवर किया है, जो हमें एब्स्ट्रैक्शन और अतिरिक्त बिल्ड टूलिंग के लिए मूल वेब लाभों से समझौता करने के लिए मजबूर नहीं करता है। "नियम पर @scope CSS आपको विशिष्ट DOM उप-वृक्षों में तत्वों का चयन करने में सक्षम बनाता है, अति-विशिष्ट चयनकर्ताओं को लिखे बिना सटीक रूप से तत्वों को लक्षित करता है जिन्हें ओवरराइड करना कठिन होता है, और आपके चयनकर्ताओं को DOM संरचना में बहुत कसकर जोड़े बिना।" - एमडीएन
दूसरे शब्दों में, हम विशिष्ट उदाहरणों में विरासत, कैस्केडिंग, या यहां तक कि चिंताओं के बुनियादी पृथक्करण का त्याग किए बिना अलग-अलग शैलियों के साथ काम कर सकते हैंयह फ्रंट-एंड विकास का लंबे समय से चलने वाला मार्गदर्शक सिद्धांत रहा है। साथ ही, इसमें उत्कृष्ट ब्राउज़र कवरेज है। वास्तव में, फ़ायरफ़ॉक्स 146 ने दिसंबर में @scope के लिए समर्थन जोड़ा, जिससे यह पहली बार बेसलाइन संगत बन गया। यहां BEM पैटर्न बनाम @scope नियम का उपयोग करने वाले बटन के बीच एक सरल तुलना दी गई है: <बटन वर्ग='बटन बटन--प्राथमिक'>
<शैली> .बटन .बटन__पाठ {/* बटन पाठ शैलियाँ */ } .बटन .बटन__आइकन {/* बटन आइकन शैलियाँ */ } .बटन--प्राथमिक {प्राथमिक बटन शैलियाँ */ }
<बटन वर्ग='प्राथमिक-बटन'> मुझे क्लिक करें →
<शैली> @स्कोप (.प्राथमिक-बटन) { स्पैन: पहला-बच्चा {/* बटन टेक्स्ट शैलियाँ */ } स्पैन: लास्ट-चाइल्ड {/* बटन आइकन शैलियाँ */ } }
@स्कोप नियम कम जटिलता के साथ परिशुद्धता की अनुमति देता है। डेवलपर को अब वर्ग नामों का उपयोग करके सीमाएँ बनाने की आवश्यकता नहीं है, जो बदले में, उन्हें मूल HTML तत्वों के आधार पर चयनकर्ता लिखने की अनुमति देता है, जिससे निर्देशात्मक सीएसएस वर्ग नाम पैटर्न की आवश्यकता समाप्त हो जाती है। केवल वर्ग नाम प्रबंधन की आवश्यकता को हटाकर, @स्कोप बड़ी परियोजनाओं में सीएसएस से जुड़े डर को कम कर सकता है। बुनियादी उपयोग आरंभ करने के लिए, अपने सीएसएस में @scope नियम जोड़ें और एक रूट चयनकर्ता डालें जिसमें शैलियों को स्कोप किया जाएगा: @स्कोप (<चयनकर्ता>) { /* शैलियाँ <चयनकर्ता> के दायरे में आती हैं */ }
इसलिए, उदाहरण के लिए, यदि हम शैलियों को
@स्कोप (एनएवी) { ए {/* नेविगेशन दायरे के भीतर लिंक शैलियाँ */ }
ए: सक्रिय {/* सक्रिय लिंक शैलियाँ */ }
a:active::before {/* अतिरिक्त स्टाइलिंग के लिए छद्म-तत्व के साथ सक्रिय लिंक */ }
@मीडिया (अधिकतम-चौड़ाई: 768px) { ए {/* प्रतिक्रियाशील समायोजन */ } } }
यह, अपने आप में, कोई अभूतपूर्व सुविधा नहीं है। हालाँकि, निचली सीमा बनाने के लिए दायरे में एक दूसरा तर्क जोड़ा जा सकता है, जो दायरे के आरंभ और अंत बिंदुओं को प्रभावी ढंग से परिभाषित करता है।
/* ul के अंदर किसी भी तत्व में शैलियाँ लागू नहीं होंगी */ @स्कोप (एनएवी) से (उल) { ए { फ़ॉन्ट-आकार: 14px; } }
इस अभ्यास को डोनट स्कोपिंग कहा जाता है, और ऐसे कई दृष्टिकोण हैं जिनका उपयोग कोई भी कर सकता है, जिसमें DOM संरचना के साथ मजबूती से जुड़े समान, अत्यधिक विशिष्ट चयनकर्ताओं की एक श्रृंखला शामिल है, एक :छद्म-चयनकर्ता नहीं, या भिन्न सीएसएस को संभालने के लिए
निष्कर्ष यूटिलिटी-फर्स्ट सीएसएस फ्रेमवर्क, जैसे टेलविंड, प्रोटोटाइपिंग और छोटी परियोजनाओं के लिए अच्छा काम करते हैं। हालाँकि, जब कुछ से अधिक डेवलपर्स को शामिल करने वाली बड़ी परियोजनाओं में उपयोग किया जाता है, तो उनके लाभ जल्दी ही कम हो जाते हैं। पिछले कुछ वर्षों में फ्रंट-एंड विकास तेजी से जटिल हो गया है, और सीएसएस कोई अपवाद नहीं है। हालांकि @स्कोप नियम सब कुछ ठीक करने वाला नहीं है, लेकिन यह जटिल टूलींग की आवश्यकता को कम कर सकता है। जब रणनीतिक वर्ग नामकरण के स्थान पर या उसके साथ उपयोग किया जाता है, तो @scope रखरखाव योग्य सीएसएस लिखना आसान और अधिक मजेदार बना सकता है। आगे पढ़ना
सीएसएस @स्कोप (एमडीएन) "सीएसएस @स्कोप", जुआन डिएगो रोड्रिग्ज (सीएसएस-ट्रिक्स) फ़ायरफ़ॉक्स 146 रिलीज़ नोट्स (फ़ायरफ़ॉक्स) ब्राउज़र समर्थन (CanIUse) लोकप्रिय सीएसएस फ्रेमवर्क (सीएसएस 2024 की स्थिति) "सीएसएस में "सी": कैस्केड", थॉमस यिप (सीएसएस-ट्रिक्स) बीईएम परिचय (बीईएम प्राप्त करें)
