CSS को संगठित और स्केल करना

docs.scrimba.com

एक नई परियोजना पर पहली स्टाइलशीट लिखना एक आनंद है। कुछ सौ लाइनों में, कुछ बदल जाता है: आप एक बटन का रंग बदलते हैं और तीन अन्य बटन भी बदल जाते हैं, एक शीर्षक तब तक हिलता नहीं है जब तक आप इसके आगे !important पेस्ट नहीं करते, और हर नया नियम महसूस होता है कि वह एक पुराने को तोड़ सकता है। CSS स्वयं अभी भी सही है। जो समाप्त हो गया है वह इसे पकड़ने वाली संरचना है, और यह संरचना, सिंटैक्स नहीं, यह तय करती है कि क्या कोई स्टाइलशीट हजार लाइनों पर या सौ हजार पर काम करने योग्य रहती है।

CSS को स्केल करना क्यों मुश्किल हो जाता है

CSS डिफ़ॉल्ट रूप से वैश्विक है। आप जो हर नियम लिखते हैं वह पृष्ठ पर कहीं भी किसी भी मेल खाने वाले तत्व तक पहुंच सकता है। p { color: navy; } लिखें और पूरी परियोजना में हर अनुच्छेद नीले रंग का हो जाता है, भले ही आप उन सभी को नहीं चाहते हों। एक छोटे पृष्ठ पर यह सुविधाजनक है। जैसे-जैसे परियोजना बढ़ती है, यह अधिकांश परेशानी का मूल है।

समस्या नियमों के टकराने के रूप में दिखाई देती है। दो स्टाइलशीट दोनों p को लक्षित करते हैं, या एक सामान्य नियम और एक विशिष्ट नियम दोनों एक ही तत्व पर लागू होते हैं, और अब आपको यह पता लगाना होगा कि कौन जीतता है। आपने CSS कैसे काम करता है में इस तंत्र को देखा: ब्राउज़र विशिष्टता और क्रम द्वारा संघर्षों को हल करता है। CSS को अच्छी तरह से स्केल करना ज्यादातर पहली जगह में उन संघर्षों को नहीं बनाने के बारे में है।

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

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

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

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

/* एक वैश्विक नियम पृष्ठ पर हर अनुच्छेद तक पहुँचता है */
p {
  color: navy;
}

/* एक दूसरा नियम, कहीं और, समान तत्वों के लिए प्रतिस्पर्धा कर रहा है */
.notice p {
  color: crimson;   /* .notice के अंदर जीतता है: अधिक विशिष्ट */
}

JunoCSS को स्केल करना क्यों मुश्किल हो जाता है CSS नियम वैश्विक हैं: एक नियम पृष्ठ भर में तत्वों को स्टाइल कर सकता है, जो शुरुआत में सुविधाजनक है और बाद में गड़बड़ा हुआ है। जैसे-जैसे कोई परियोजना बढ़ती है, नियमों को टकराने लगते हैं, और ब्राउज़र को विशिष्टता और क्रम का उपयोग करके एक विजेता चुनना होता है। CSS को संगठित करने का अधिकांश हिस्सा पहली जगह में एक दूसरे के साथ लड़ने वाले नियमों को लिखने के बारे में है।

JunoCSS को स्केल करना क्यों मुश्किल हो जाता है CSS में कोई स्कोपिंग नहीं है, इसलिए हर नियम वैश्विक है और कोई भी मेल खाने वाले तत्व तक पहुंचने के लिए स्वतंत्र है। जैसे-जैसे कोडबेस बढ़ता है दो चीजें काटती हैं: नियमों के टकराते हैं, और विशिष्टता बढ़ती है क्योंकि झड़प के लिए तेज़ सुधार हमेशा एक अधिक विशिष्ट चयनकर्ता है। उस क्रीप को जांच में रखें और स्केलिंग के बाकी हिस्से को प्राप्त करना बहुत आसान हो जाता है।

JunoCSS को स्केल करना क्यों मुश्किल हो जाता है CSS एक समतल वैश्विक नामस्थान है जिसमें कोई मॉड्यूल सीमा नहीं है, इसलिए कैस्केड हर झड़प को मूल द्वारा, फिर विशिष्टता द्वारा, फिर क्रम द्वारा सुलझाता है। जाल विशिष्टता रैचेट है: प्रत्येक तेज़ ओवरराइड फर्श को बढ़ाता है, इसलिए अगले को उच्चतर चढ़ना होगा, और आप !important पर नीचे करते हैं। इस अध्याय की हर तकनीक विशिष्टता को कम रखने का एक तरीका है ताकि रैचेट कभी भी मुड़ना शुरू न हो।

विशिष्टता को कम और समतल रखें

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

समस्या दो चीजों से आती है: आईडी और चयनकर्ताओं की लंबी चेनें। #header जैसी आईडी एक वर्ग की तुलना में ओवरराइड करना बहुत कठिन है, और .sidebar ul li a जैसी चेन एक सटीक संरचना के लिए बंधी हुई है। सादा वर्ग पसंद करें जिसे आप कहीं भी रख सकते हैं:

CSS को बनाए रखने योग्य रखने के लिए मूल आदत विशिष्टता को कम और समतल रखना है: एकल कक्षाओं के साथ शैली दें, और उन दो चीजों से बचें जो विशिष्टता को स्पाइक करती हैं, आईडी और गहरी वंशजों की श्रृंखलाएं। एक एकल वर्ग甜 बिंदु है। यह पर्याप्त विशिष्ट है जो आप मतलब करते हैं उसे लक्षित करने के लिए और कमजोर है ताकि एक और एकल वर्ग बिना लड़ाई के बाद में इसे ओवरराइड कर सके।

आईडी कक्षाओं की तुलना में बहुत अधिक स्कोर करते हैं, इसलिए एक #id नियम ओवरराइड करना दर्दनाक है और आपको ऊपर की ओर बाध्य करता है। लंबी वंशज श्रृंखलाएं एक अलग समस्या का कारण बनती हैं: .sidebar nav ul li a विशिष्टता बढ़ाता है और नियम को एक सटीक HTML संरचना में वेल्ड करता है, इसलिए यह मार्कअप बदलने के तुरंत बाद टूट जाता है। तत्व को अपनी कक्षा दें और सीधे उसे लक्षित करें।

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

दो निर्माण समतलता को तोड़ते हैं और दोनों डिफ़ॉल्ट रूप से से बचना लायक हैं। आईडी एक वर्ग की तुलना में परिमाण का एक क्रम अधिक विशिष्टता में योगदान करते हैं, इसलिए एक एकल #id नियम वर्ग नियमों के किसी भी ढेर के ऊपर बैठता है और केवल एक अन्य आईडी या !important द्वारा हराया जा सकता है; कक्षाओं के साथ शैली दें और आईडी को अंशांकन लिंक और JavaScript हुक के लिए आरक्षित रखें। गहरी वंशज श्रृंखलाएं प्रति चयनकर्ता विशिष्टता बढ़ाती हैं और नियम को एक निश्चित पूर्वजता के लिए युग्मित करती हैं, इसलिए .sidebar nav ul li a ओवरराइड करना और नाजुक दोनों हैं: मार्कअप बदलें और यह चुपचाप मिलना बंद कर देता है। अगला अनुभाग में पद्धति आपको सीधे एक तत्व का नाम देने की अनुमति देने के लिए मौजूद है, इसलिए आप कभी भी एक चेन तक पहुंचने के लिए पहुंचते नहीं हैं।

/* पसंद करें: एक एकल वर्ग, कम और समतल */
.nav-link {
  color: navy;
}

/* बचें: एक आईडी, बाद में ओवरराइड करना कठिन */
#nav-link {
  color: navy;
}

/* बचें: एक गहरी चेन, नाजुक और उच्च विशिष्टता */
.sidebar nav ul li a {
  color: navy;
}

Junoविशिष्टता को कम और समतल रखें कक्षाओं के साथ शैली दें, और ज्यादातर एक बार में एक कक्षा, जैसे .card या .nav-link। एक एकल वर्ग पुन: उपयोग करने में तेज़ है और बाद में ओवरराइड करना दर्दनाक है, जो वास्तव में आप चाहते हैं। #header जैसी आईडी और .sidebar ul li a जैसी लंबी चेनों से दूर रहें, क्योंकि दोनों बदलने के लिए बहुत कठिन हैं।

Junoविशिष्टता को कम और समतल रखें एकल कक्षाएं甜 बिंदु हैं: आप जो मतलब करते हैं उसे लक्षित करने के लिए पर्याप्त विशिष्ट, बिना लड़ाई के किसी अन्य वर्ग द्वारा ओवरराइड किए जाने के लिए पर्याप्त कमजोर। आईडी विशिष्टता को स्पाइक करते हैं और आपको ऊपर की ओर खींचते हैं, और गहरी चेनें .sidebar nav ul li a जैसे मार्कअप के बदलते ही टूट जाती हैं। जब कोई नियम रखना कठिन हो, तो तत्व को अपनी कक्षा दें और उसे लक्षित करें।

Junoविशिष्टता को कम और समतल रखें कम और समतल का अर्थ है हर नियम समान छोटे वजन के पास अंकित होता है, इसलिए केवल स्रोत क्रम ही कोई भी झड़प को सुलझा सकता है। आईडी कक्षाओं के एक क्रम में बैठते हैं और केवल !important या दूसरी आईडी उन्हें हरा देते हैं, इसलिए उन्हें अंशांकन लिंक और JS हुक के लिए रखें। गहरी चेनें विशिष्टता बढ़ाती हैं और एक नियम को एक HTML आकृति के लिए वेल्ड करती हैं, जो एकल नाम देना अपने पूर्वजों के माध्यम से इसे खोजने से बेहतर है।

एक नामकरण परंपरा

एक बार जब आप कक्षाओं के साथ शैली दे रहे हैं, तो अगला सवाल यह है कि उन्हें क्या कहना है। .blue या .thing2 जैसे नाम तेज़ी से अलग हो जाते हैं, क्योंकि वे कुछ नहीं कहते कि कक्षा किस लिए है। एक नामकरण परंपरा कक्षाओं का नाम देने का एक सहमत तरीका है ताकि नाम आपको बताता है कि एक कक्षा क्या करता है और यह कहां है।

व्यापक रूप से उपयोग किया जाने वाला को BEM कहा जाता है, जो ब्लॉक, एलिमेंट, संशोधक के लिए खड़ा है। एक ब्लॉक एक कार्ड जैसा एक घटक है। एक तत्व इसके अंदर एक हिस्सा है, दो अंडरस्कोर के साथ लिखा गया है। एक संशोधक एक भिन्नता है, दो डैश के साथ लिखा गया है:

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

सबसे व्यापक रूप से अपनाई गई परंपरा BEM है (ब्लॉक, एलिमेंट, संशोधक)। ब्लॉक घटक है (.card), एक तत्व इसका एक हिस्सा है दो अंडरस्कोर के साथ जुड़ा हुआ है (.card__title), और एक संशोधक एक संस्करण है दो डैश के साथ जुड़ा हुआ है (.card--featured)। इसका भुगतान समतल विशिष्टता है: क्योंकि हर हिस्सा को अपनी एकल कक्षा मिलती है, आपको .card__title तक पहुंचने के लिए कभी भी वंशज चेन की आवश्यकता नहीं है, इसलिए BEM और कम-और-समतल आदत एक दूसरे को मजबूत करते हैं।

एक नामकरण परंपरा उस स्कोपिंग को प्रतिस्थापित करती है जो भाषा नहीं देती है। वर्ग नाम में एक घटक सीमा को एन्कोड करके, यह आपको टकराव-मुक्त, स्व-दस्तावेज़ नाम देता है जिसमें कोई भाषा विशेषता नहीं है: एक कक्षा पढ़ें और आप इसके घटक, इसके हिस्से, और इसकी विविधता जानते हैं। कोई भी सुसंगत परंपरा यह वितरित करता है; मूल्य संगति में है, सटीक विराम चिह्न में नहीं।

BEM (ब्लॉक, एलिमेंट, संशोधक) सबसे व्यापक रूप से उपयोग किया जाता है। ब्लॉक घटक का नाम देता है (.card), एक तत्व एक दोहरे अंडरस्कोर के साथ एक हिस्से का नाम देता है (.card__title), और एक संशोधक एक दोहरे डैश के साथ एक संस्करण का नाम देता है (.card--featured)। जो BEM को नामकरण से परे इसका वजन खींचता है वह यह है कि यह निर्माण द्वारा विशिष्टता को समतल रखता है: हर तत्व को अपनी एकल-वर्ग चयनकर्ता मिलता है, इसलिए आप .card__title को सीधे संबोधित करते हैं .card .title लिखने के बजाय, और घटक में हर नियम समान वजन में बैठता है। यह पिछले अनुभाग से समान कम-और-समतल संपत्ति है, अब नामकरण योजना से मुक्त गिरता है। लागत HTML में शब्दबहुल कक्षा सूचियां हैं, जिसे अधिकांश दलें यह अनुमानितता खरीदने के लिए स्वीकार करते हैं।

/* ब्लॉक: घटक स्वयं */
.card { }

/* एलिमेंट: ब्लॉक का एक हिस्सा, दो अंडरस्कोर */
.card__title { }
.card__body { }

/* संशोधक: ब्लॉक की एक भिन्नता, दो डैश */
.card--featured { }

<article class="card card--featured">
  <h2 class="card__title">सप्ताहांत कार्यशाला</h2>
  <p class="card__body">लेआउट की एक संक्षिप्त शुरुआत।</p>
</article>

Junoएक नामकरण परंपरा एक नामकरण परंपरा वर्गों का नाम देने का एक सहमत तरीका है ताकि नाम आपको बताता है कि यह किस लिए है। BEM आम है: एक ब्लॉक जैसे .card, इसके अंदर एक तत्व जैसे .card__title दो अंडरस्कोर के साथ, और एक संस्करण जैसे .card--featured दो डैश के साथ। आपको BEM का उपयोग करना नहीं है, लेकिन कुछ सुसंगत स्कीम चुनें और इसके अनुसार रहें।

Junoएक नामकरण परंपरा एक परंपरा वर्ग के नामों को अनुमानित और टकराव-मुक्त बनाता है, इसलिए एक नाम इसके घटक और इसके हिस्से को बताता है। BEM व्यापक रूप से उपयोग किया जाता है: ब्लॉक .card, तत्व .card__title, संशोधक .card--featured। यह विशिष्टता को भी समतल रखता है, क्योंकि हर हिस्सा अपनी एकल कक्षा को वंशज चेन के बजाय प्राप्त करता है।

Junoएक नामकरण परंपरा एक परंपरा उस स्कोपिंग की जगह लेती है जो CSS कभी नहीं दी गई: घटक सीमा वर्ग नाम में रहती है, इसलिए नाम टकराव-मुक्त और स्व-दस्तावेज़ रहते हैं। BEM ब्लॉक, तत्व, और संशोधक को .card, .card__title, .card--featured के रूप में एन्कोड करता है, और इसका वास्तविक भुगतान निर्माण द्वारा समतल विशिष्टता है, क्योंकि हर हिस्सा एक एकल वर्ग है। कीमत मार्कअप में शब्दबहुल कक्षा सूचियां हैं, जो आमतौर पर अनुमानितता के लिए सार्थक है।

फाइलों को संरचित करना

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

एक विस्तृत जब आप फाइलें विभाजित करते हैं: जो आदेश आप उन्हें लोड करते हैं। जब दो नियमों की विशिष्टता समान होती है, तो जो बाद में आता है वह जीतता है, इसलिए एक बाद में लोड की गई स्टाइलशीट एक पहले को ओवरराइड कर सकती है। अपनी फाइलों को सबसे सामान्य से सबसे विशिष्ट में लोड करें:

CSS को भूमिका के आधार पर फोल्डरों में विभाजित करना एक बढ़ते हुए कोडबेस को नेविगेट करने योग्य रखता है। एक आम संरचना तीन समूह हैं: आधार (रीसेट्स और तत्व डिफ़ॉल्ट जैसे body, शीर्षकें, और लिंक), घटक (स्व-निहित टुकड़े जैसे .card और .btn), और उपयोगिताएं (एकल-उद्देश्य सहायक जैसे .text-center या .mt-4)।

जिस क्रम में आप इन फाइलों को जोड़ते या आयात करते हैं वह सौंदर्य नहीं है, क्योंकि स्रोत क्रम एक कैस्केड टाई-ब्रेकर है: जब दो नियमों की विशिष्टता बराबर होती है, तो बाद वाला जीतता है। तो आप सबसे कम से सबसे विशिष्ट में लोड करते हैं, आधार पहले, फिर घटक, फिर अंत में उपयोगिताएं, ताकि एक उपयोगिता किसी को विशिष्टता बढ़ाए बिना एक घटक को ओवरराइड कर सके। आदेश को सही प्राप्त करना वह है जो आपको सब कुछ एकल-वर्ग विशिष्टता पर रखने देता है और फिर भी अपेक्षित जगह पर ओवरराइड को उतरने दे।

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

यही कारण है कि आदेश इरादे के अनुसार सबसे कम से सबसे विशिष्ट तक जाता है, आधार, फिर घटक, फिर उपयोगिताएं, ताकि बाद के समूह किसी को विशिष्टता बढ़ाए बिना पहले के लोगों को ओवरराइड कर सकें। एक .text-center उपयोगिता एक घटक के अपने पाठ संरेखण को हरा देना चाहिए, और यह यह कर सकता है, विशुद्ध रूप से क्योंकि यह अंतिम में समान वजन पर लोड होता है। यह काम करता है, लेकिन यह अनुशासन द्वारा रखी गई एक परंपरा है: कुछ भी भाषा में किसी को पहले उपयोगिताओं को आयात करने से रोकता नहीं है और शांति से संपूर्ण योजना को उल्टा कर देता है। बड़ी टीम में स्रोत क्रम पर निर्भर करना बिल्कुल इसी कारण से नाजुक है, जो बदले में स्पष्ट रूप से आदेश देने को पदीय के बजाय बनाने की प्रेरणा देता है, जो अंतिम अनुभाग का विषय है।

/* main.css: आदेश सबसे कम से सबसे विशिष्ट तक जाता है */
@import "base/reset.css";        /* तत्व डिफ़ॉल्ट */
@import "base/typography.css";

@import "components/card.css";    /* स्व-निहित टुकड़े */
@import "components/button.css";

@import "utilities/spacing.css";  /* अंतिम में लोड किया गया इसलिए वे ओवरराइड कर सकते हैं */
@import "utilities/text.css";

Junoफाइलों को संरचित करना CSS को नियमों के द्वारा विभाजित करें कि वह क्या करते हैं: तत्व डिफ़ॉल्ट के लिए आधार, कार्ड और बटन जैसे टुकड़ों के लिए घटक, और छोटी सहायकों के लिए उपयोगिताएं। फिर उस आदेश को देखें जिसमें आप उन्हें लोड करते हैं, क्योंकि विशिष्टता बंधन होने पर बाद का नियम जीतता है। सामान्य को पहले लोड करें और विशिष्ट को अंतिम में, इसलिए सहायक टुकड़ों को ओवरराइड कर सकते हैं।

Junoफाइलों को संरचित करना भूमिका के आधार पर फाइलों को समूहित करें: आधार, घटक, फिर उपयोगिताएं। उन्हें कम से सबसे विशिष्ट में लोड करें, क्योंकि स्रोत क्रम विशिष्टता बराबर होने पर टाई-ब्रेकर है, इसलिए अंतिम में लोड की गई एक उपयोगिता किसी को विशिष्टता बढ़ाए बिना एक घटक को ओवरराइड कर सकती है। आदेश को सही प्राप्त करना वह है जो आपको सब कुछ एकल-वर्ग वजन पर रखने देता है और फिर भी अपेक्षित जगह पर ओवरराइड को उतरने दे।

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

कैस्केड को स्पष्ट करना

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

अब तक की तकनीकें विशिष्टता और स्रोत क्रम के माध्यम से कैस्केड को अप्रत्यक्ष रूप से प्रबंधित करती हैं। नई CSS आपको इसे सीधे प्रबंधित करने देती है। एक कैस्केड परत, @layer नियम के साथ लिखा गया, एक नामित आदेश देने वाली बाल्टी है: आप परतों को उस क्रम में एक दूसरे को आगे घोषित करते हैं जो आप जीतना चाहते हैं, और हर नियम एक परत के अंदर हर नियम को एक पहले की परत में हरा देता है, विशिष्टता की परवाह किए बिना।

/* विजेता आदेश को एक बार घोषित करें, सबसे-हारने वाले को सबसे-जीतने वाले तक */
@layer base, components, utilities;

@layer components {
  .card { padding: 16px; }
}

@layer utilities {
  .p-0 { padding: 0; }   /* विशिष्टता के बराबर होने के बावजूद .card को हरा देता है */
}

क्योंकि एक बाद की परत हमेशा जीतती है, आपको फाइल क्रम को पूर्ण होने की आवश्यकता नहीं रह गई है, और आपको शायद ही कभी !important की आवश्यकता है एक ओवरराइड को बाध्य करने के लिए। यह व्यावहारिक लाभ है: परतें आदेश देने को नाज़ुक "कौन सी फाइल पहले लोड हुई" के क्षेत्र से बाहर और एक स्पष्ट घोषणा में ले जाती हैं सभी पढ़ सकते हैं।

स्रोत क्रम नाज़ुक है क्योंकि यह स्थितीय है: यह काम करता है जब तक कोई एक आयात को फिर से व्यवस्थित नहीं करता। कैस्केड परतें, @layer नियम, उसे विशिष्टता के ऊपर स्पष्ट आदेश से प्रतिस्थापित करता है। आप परत क्रम को एक बार घोषित करते हैं, और कैस्केड परत क्रम से परामर्श लेता है इससे पहले कि यह विशिष्टता को देखता भी है, इसलिए एक बाद की परत में एक नियम एक पहले की परत में एक नियम को हरा देता है यहां तक कि पहला नियम अधिक विशिष्ट होने पर भी। आदेश देना फाइल स्थिति का एक पक्ष प्रभाव के बजाय एक नामित, पठनीय निर्णय बन जाता है।

/* एक पंक्ति पूरे कोडबेस के लिए विजेता आदेश को ठीक करता है */
@layer reset, base, components, utilities;

@layer components {
  .card__title { font-size: 1.25rem; }
}

@layer utilities {
  .text-lg { font-size: 1.5rem; }   /* जीतता है: उपयोगिताएं बाद की परत हैं */
}

यह दो आदतों को फिर से आकार देता है। पहली बात, यह विशिष्टता युद्ध को निष्क्रिय करता है: क्योंकि परत क्रम विशिष्टता को आगे निकलता है, आप एक झड़प को जीतने के लिए अधिक विशिष्ट चयनकर्ताओं तक पहुंचना बंद कर देते हैं, और आप लगभग कभी !important की आवश्यकता नहीं होती है, जिसका पूरा काम एक विशिष्टता से बचना था जिसे आप अन्यथा हरा नहीं सकते। (परतें यहां तक कि !important को ही वश में करती हैं, इसकी प्राथमिकता को उल्टा करती हैं ताकि एक पहले परत में एक महत्वपूर्ण घोषणा जीते, लेकिन लक्ष्य यह है कि इसकी आवश्यकता न पड़े कि यह तुच्छ रहे।) दूसरी, यह संगठित करने की लंबे समय से चलने वाली पसंद को स्पष्ट करता है: एक उपयोगिता-पहले दृष्टिकोण, कई परमाणु एकल-संपत्ति कक्षाओं से पृष्ठों की रचना करना, और एक घटक दृष्टिकोण, शैलियों को एक अर्थवहन वर्ग के पीछे प्रत्येक टुकड़े में बंडल करना। अधिकांश उत्पादन कोडबेस दोनों चलाते हैं, और परतें उन्हें डिज़ाइन द्वारा सहअस्तित्व करने देती हैं: घटकों को एक components परत में और उपयोगिताओं को एक बाद की utilities परत में रखें, और एक उपयोगिता बिना किसी को विशिष्टता को बढ़ाए एक घटक को विश्वसनीय रूप से ओवरराइड करता है। निर्णय "कौन सा कैस्केड लड़ाई को जीतता है" बदल जाता है "यह UI के इस टुकड़े के लिए बेहतर क्या पढ़ता है", क्योंकि कैस्केड परत क्रम द्वारा तय किया जाता है, न कि कि किसने धकेल देने वाला चयनकर्ता लिखा। यह अनुमानितता वास्तविक पुरस्कार है क्योंकि एक टीम बढ़ता है: विजेता क्रम एक घोषणा है सभी पढ़ सकते हैं, आयात अनुक्रम के बारे में जनजातीय ज्ञान नहीं। जब आपको इन परतों के पार रंग और दूरी जैसे मान साझा करने की आवश्यकता है, कस्टम गुण आपको उन्हें एक बार परिभाषित करने देते हैं उन्हें डुप्लिकेट करने के बजाय।

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

Junoकैस्केड को स्पष्ट करना@layer के साथ एक कैस्केड परत एक नामित आदेश देने वाली बाल्टी है: परत क्रम को आगे घोषित करें और एक बाद की परत एक पहले को विशिष्टता की परवाह किए बिना हरा देती है। इसका अर्थ है फाइल क्रम को पूर्ण होने की आवश्यकता नहीं है और आप शायद ही कभी !important को एक जीत को बाध्य करने की आवश्यकता है। यह आदेश देने को नाज़ुक फाइल स्थिति से बाहर और एक पंक्ति में ले जाता है सभी पढ़ सकते हैं।

Junoकैस्केड को स्पष्ट करना कैस्केड परतें विशिष्टता के ऊपर बैठती हैं, इसलिए एक बाद की परत यहां तक कि एक अधिक विशिष्ट नियम के खिलाफ भी जीतता है, जो विशिष्टता रैचेट को जारी करता है और आपके अधिकांश !important उपयोगों को सेवानिवृत्त करता है। वे उपयोगिता-पहले और घटक शैलियों को सहअस्तित्व करने देते हैं: घटकों एक परत में, उपयोगिताएं एक बाद में, और एक उपयोगिता किसी को भी बढ़ाए बिना एक घटक को ओवरराइड करता है। एक टीम बढ़ने के साथ जीत यह है कि आदेश एक पठनीय घोषणा है, आयात अनुक्रम के बारे में जनजातीय ज्ञान नहीं।