मूलभूत CSS ची तत्त्वे शिकताना, देखभालक्षमता सुनिश्चित करण्यासाठी मॉड्यूलर, पुन्हा वापरता येण्याजोग्या आणि वर्णनात्मक शैली लिहिण्यास शिकवले जाते. परंतु जेव्हा विकसक वास्तविक-जागतिक अनुप्रयोगांमध्ये सामील होतात, तेव्हा अनपेक्षित भागात लीक झाल्याशिवाय UI वैशिष्ट्ये जोडणे अनेकदा अशक्य वाटते. ही समस्या बऱ्याचदा स्नोबॉलमध्ये स्वयं-पूर्ण लूप बनते; सैद्धांतिकदृष्ट्या एका घटकासाठी किंवा वर्गासाठी व्यापलेल्या शैली त्या संबंधित नसलेल्या ठिकाणी दिसायला लागतात. हे विकसकाला लीक केलेल्या शैलींना ओव्हरराइड करण्यासाठी आणखी विशिष्ट निवडक तयार करण्यास भाग पाडते, जे नंतर चुकून जागतिक शैली ओव्हरराइड करतात आणि असेच. बीईएम सारख्या कठोर वर्ग नेम अधिवेशने या समस्येचे एक सैद्धांतिक उपाय आहेत. BEM (ब्लॉक, एलिमेंट, मॉडिफायर) पद्धत CSS फायलींमध्ये पुन्हा वापरता येण्याजोगी आणि रचना सुनिश्चित करण्यासाठी CSS वर्गांना नाव देण्याचा एक पद्धतशीर मार्ग आहे. यासारख्या नामकरण पद्धती घटक आणि त्यांच्या स्थितीचे वर्णन करण्यासाठी डोमेन भाषेचा फायदा घेऊन संज्ञानात्मक भार कमी करू शकतात आणि योग्यरित्या अंमलात आणल्यास, मोठ्या अनुप्रयोगांसाठी शैली राखणे सोपे करू शकते. वास्तविक जगात, तथापि, हे नेहमीच असे कार्य करत नाही. प्राधान्यक्रम बदलू शकतात आणि बदलामुळे अंमलबजावणी विसंगत होते. HTML संरचनेतील लहान बदलांसाठी CSS वर्ग नावाच्या अनेक पुनरावृत्तींची आवश्यकता असू शकते. अत्यंत परस्परसंवादी फ्रंट-एंड ऍप्लिकेशन्ससह, BEM पॅटर्नचे अनुसरण करणारी वर्गाची नावे लांब आणि अवास्तव होऊ शकतात (उदा. app-user-overview__status--is-authenticating), आणि नामकरण नियमांचे पूर्णपणे पालन न केल्याने सिस्टमची रचना खंडित होते, ज्यामुळे त्याचे फायदे नाकारले जातात. ही आव्हाने पाहता, डेव्हलपर फ्रेमवर्ककडे वळले यात आश्चर्य नाही, टेलविंड सर्वात लोकप्रिय CSS फ्रेमवर्क आहे. शैलींमधील अजिंक्य विशिष्टतेच्या युद्धासारखे लढण्याचा प्रयत्न करण्याऐवजी, CSS कॅस्केड सोडणे आणि संपूर्ण अलगावची हमी देणारी साधने वापरणे सोपे आहे. डेव्हलपर युटिलिटीजवर अधिक झुकतात आम्हाला कसे कळेल की काही विकासक कॅस्केड शैली टाळण्यास उत्सुक आहेत? हे "आधुनिक" फ्रंट-एंड टूलिंगचा उदय आहे — जसे की CSS-इन-JS फ्रेमवर्क — विशेषत: त्या उद्देशाने डिझाइन केलेले. विशिष्ट घटकांसाठी घट्ट व्यापलेल्या वेगळ्या शैलींसह कार्य करणे ताजी हवेच्या श्वासासारखे वाटू शकते. हे गोष्टींना नाव देण्याची गरज काढून टाकते — तरीही सर्वात घृणास्पद आणि वेळ घेणारे फ्रंट-एंड टास्क — आणि CSS वारशाचे फायदे पूर्णपणे समजून घेतल्याशिवाय किंवा त्याचा फायदा न घेता विकासकांना उत्पादक बनण्याची अनुमती देते. परंतु CSS कॅस्केड खोदणे त्याच्या स्वतःच्या समस्यांसह येते. उदाहरणार्थ, JavaScript मधील शैली कंपोझ करण्यासाठी हेवी बिल्ड कॉन्फिगरेशनची आवश्यकता असते आणि अनेकदा शैली घटक मार्कअप किंवा HTML सह विचित्रपणे मिसळते. नामकरण पद्धतींचा काळजीपूर्वक विचार करण्याऐवजी, आम्ही आमच्यासाठी निवडक आणि अभिज्ञापक (उदा., .jsx-3130221066) स्वयं व्युत्पन्न करण्यासाठी बिल्ड टूल्सना अनुमती देतो, ज्यासाठी डेव्हलपरना स्वतःमध्ये आणखी एक छद्म-भाषेचे पालन करणे आवश्यक आहे. (आपल्या सर्व घटकांचे परिणाम काय करतात हे समजून घेण्याचा संज्ञानात्मक भार आधीच पुरेसा नव्हता!) टूलींगला क्लासेसचे नाव देण्याचे काम आणखी ॲबस्ट्रॅक्ट करणे म्हणजे डेव्हलपर टूल्स सारख्या थेट डीबगिंगला सपोर्ट करणाऱ्या मूळ ब्राउझर वैशिष्ट्यांचा लाभ घेण्याऐवजी, मूलभूत डीबगिंग अनेकदा विकासासाठी संकलित केलेल्या विशिष्ट अनुप्रयोग आवृत्त्यांपर्यंत मर्यादित असते. हे जवळजवळ असेच आहे की आम्हाला वेब आधीच प्रदान करते ते अमूर्त करण्यासाठी आम्ही वापरत असलेली साधने डीबग करण्यासाठी साधने विकसित करणे आवश्यक आहे - सर्व काही मानक CSS लिहिण्याच्या "वेदना" पासून दूर जाण्यासाठी. सुदैवाने, आधुनिक CSS वैशिष्ट्ये केवळ मानक CSS लेखन अधिक लवचिक बनवत नाहीत तर आमच्यासारख्या विकासकांना कॅस्केड व्यवस्थापित करण्यासाठी आणि ते आमच्यासाठी कार्य करण्यासाठी मोठ्या प्रमाणात शक्ती देतात. CSS कॅस्केड लेयर्स हे एक उत्तम उदाहरण आहे, परंतु आणखी एक वैशिष्ट्य आहे ज्याकडे लक्ष न देता आश्चर्यचकित केले जाते - जरी ते आता बदलत आहे कारण ते अलीकडे बेसलाइन सुसंगत झाले आहे. CSS @scope At-Rule मी CSS @scope at-rule ला आम्ही कव्हर केलेल्या स्टाइल-लीक-प्रेरित चिंतेसाठी एक संभाव्य उपाय मानतो, जी आम्हाला ॲब्स्ट्रॅक्शन्स आणि अतिरिक्त बिल्ड टूलिंगसाठी मूळ वेब फायद्यांशी तडजोड करण्यास भाग पाडत नाही. “@scope CSS at-rule तुम्हाला विशिष्ट DOM सबट्रीजमधील घटक निवडण्यास सक्षम करते, अति-विशिष्ट निवडक न लिहिता ज्यांना ओव्हरराइड करणे कठीण आहे, आणि तुमच्या निवडकांना DOM संरचनेत घट्ट जोडल्याशिवाय घटक अचूकपणे लक्ष्यित करतात.”— MDN
दुस-या शब्दात सांगायचे तर, वारसा, कॅस्केडिंग किंवा अगदी मूलभूत पृथक्करणाचा त्याग न करता आम्ही विशिष्ट उदाहरणांमध्ये वेगळ्या शैलींसह कार्य करू शकतो.हे फ्रंट-एंड विकासाचे दीर्घकाळ चालणारे मार्गदर्शक तत्त्व आहे. शिवाय, यात उत्कृष्ट ब्राउझर कव्हरेज आहे. खरेतर, Firefox 146 ने डिसेंबरमध्ये @scope साठी समर्थन जोडले, ज्यामुळे ते प्रथमच बेसलाइन सुसंगत झाले. येथे @scope नियम विरुद्ध BEM पॅटर्न वापरून बटणाची साधी तुलना आहे:
@scope नियम कमी जटिलतेसह अचूकतेसाठी परवानगी देतो. डेव्हलपरला यापुढे वर्ग नावांचा वापर करून सीमा तयार करण्याची आवश्यकता नाही, ज्यामुळे, त्यांना मूळ HTML घटकांवर आधारित निवडक लिहिण्याची परवानगी मिळते, ज्यामुळे प्रिस्क्रिप्टिव्ह CSS वर्ग नावाच्या नमुन्यांची आवश्यकता नाहीशी होते. क्लास नेम मॅनेजमेंटची गरज दूर करून, @scope मोठ्या प्रकल्पांमध्ये CSS शी संबंधित भीती दूर करू शकते.
मूलभूत वापर
सुरू करण्यासाठी, तुमच्या CSS मध्ये @scope नियम जोडा आणि रूट सिलेक्टर समाविष्ट करा ज्यामध्ये स्टाइल स्कोप होतील:
@scope (
तर, उदाहरणार्थ, जर आपण
@scope (nav) { a { /* एनएव्ही कार्यक्षेत्रातील लिंक शैली */ }
a:सक्रिय { /* सक्रिय लिंक शैली */ }
a:active::before { /* अतिरिक्त स्टाइलिंगसाठी स्यूडो-एलिमेंटसह सक्रिय लिंक */ }
@media (कमाल-रुंदी: 768px) { एक { /* प्रतिसाद समायोजन */ } } }
हे, स्वतःच, एक महत्त्वपूर्ण वैशिष्ट्य नाही. तथापि, स्कोपचे प्रारंभ आणि शेवटचे बिंदू प्रभावीपणे परिभाषित करून, निम्न सीमा तयार करण्यासाठी स्कोपमध्ये दुसरा युक्तिवाद जोडला जाऊ शकतो.
/* ul मधील कोणत्याही घटकावर शैली लागू होणार नाही */ @scope (nav) ते (ul) { एक { फॉन्ट-आकार: 14px; } }
या सरावाला डोनट स्कोपिंग म्हणतात, आणि भिन्न CSS हाताळण्यासाठी समान, अत्यंत विशिष्ट निवडकांची मालिका, एक :नॉट स्यूडो-सिलेक्टर, किंवा घटकांना विशिष्ट वर्गाची नावे नियुक्त करणे यासह अनेक पद्धती वापरल्या जाऊ शकतात. त्या इतर पद्धतींकडे दुर्लक्ष करून, @scope पद्धत अधिक संक्षिप्त आहे. अधिक महत्त्वाचे म्हणजे, वर्गनावे बदलल्यास किंवा त्याचा गैरवापर झाल्यास किंवा HTML रचनेत बदल करायचा असल्यास मोडलेल्या शैलीचा धोका टाळतो. आता @scope हे बेसलाइन सुसंगत आहे, आम्हाला यापुढे उपायांची गरज नाही! एक "शैली आकृती आठ" तयार करण्यासाठी आम्ही ही कल्पना अनेक शेवटच्या सीमांसह पुढे नेऊ शकतो:
/*
निष्कर्ष उपयुक्तता-प्रथम CSS फ्रेमवर्क, जसे की Tailwind, प्रोटोटाइपिंग आणि लहान प्रकल्पांसाठी चांगले काम करतात. तथापि, दोनपेक्षा जास्त विकासकांचा समावेश असलेल्या मोठ्या प्रकल्पांमध्ये वापरल्यास त्यांचे फायदे त्वरीत कमी होतात. गेल्या काही वर्षांमध्ये फ्रंट-एंड डेव्हलपमेंट अधिकाधिक गुंतागुंतीचा बनला आहे आणि CSSही त्याला अपवाद नाही. जरी @scope नियम हा सर्व उपचार नसला तरी तो जटिल टूलिंगची गरज कमी करू शकतो. स्ट्रॅटेजिक क्लास नेमिंगच्या जागी किंवा सोबत वापरल्यास, @scope राखण्यायोग्य CSS लिहिणे सोपे आणि अधिक मनोरंजक बनवू शकते. पुढील वाचन
CSS @scope (MDN) “CSS @scope”, जुआन दिएगो रॉड्रिग्ज (CSS-युक्त्या) फायरफॉक्स 146 रिलीझ नोट्स (फायरफॉक्स) ब्राउझर सपोर्ट (CanIUse) लोकप्रिय CSS फ्रेमवर्क (CSS 2024 चे राज्य) CSS मधील "C": कॅस्केड", थॉमस यिप (CSS-ट्रिक) BEM परिचय (BEM मिळवा)
