सीएसएस आमतौर पर तुरंत विफल नहीं होता है। यह एक साल बाद विफल हो जाता है, जब सिस्टम वास्तविक उपयोग में है और कुछ भी बदलना जोखिम भरा लगता है। शैलियों को भारी महसूस करना शुरू होता है. आप DevTools खोलते हैं, नियमों के माध्यम से कूदते हैं, और समझने की कोशिश करते हैं कि क्यों कुछ काम करता है जैसा कि यह करता है. Refactoring मानसिक रूप से टैक्सिंग और समय की खपत महसूस करता है इसलिए आप टिकट को दूर करने के लिए एक और ओवररेड जोड़ते हैं। बुरा सीएसएस न केवल खराब है, यह महंगा है. यही कारण है कि सरल यूआई अद्यतन तीन मिनट के बजाय तीन दिन लेते हैं। कोड कर रहा है . बहुत ज्यादा बहुत अधिक विशिष्टता. बहुत अधिक समय से पहले किए गए निर्णय हैं जो खत्म करने के लिए बहुत कठिन और महंगा हैं। यह लेख इस बारे में है कि इसका कारण क्या है और इसे कैसे रोकना है. चाल या उपकरणों के माध्यम से नहीं, बल्कि कुछ आदतों के माध्यम से जो सीएसएस को सरल, पढ़ने योग्य और परियोजना के विकास के रूप में बदलने के लिए सस्ता बनाते हैं। ये वो बातें हैं जिन्हें मैं पहले सीखना चाहता था। 1. सीएसएस के साथ शुरू करना पहला गलती है मुझे पता है कि लेख सीएसएस के बारे में है, लेकिन सबसे आम गलतियों में से एक जो मैं देखता हूं कि जूनियर एक कार्य में कूदते हैं और एक बार में सब कुछ बनाते हैं। आमतौर पर वे सबसे जटिल हिस्से के साथ शुरू करते हैं या सबसे मजेदार एक। मैं इसे प्राप्त करता हूं. सीएसएस आकर्षक है क्योंकि यह व्यावहारिक है. आप तुरंत परिणाम देखते हैं। यह गलत है. बेहतर दृष्टिकोण सीएसएस को एक तरफ रखना है, रुकना, धीमा करना और मार्कअप के साथ शुरू करना है। यदि आप एक पूरे ऐप का निर्माण कर रहे हैं, तो पृष्ठ कोशिका से शुरू करें. मैनेजॉक, शीर्षक दुरुपयोग, मुख्य अनुभागों पर काम करें. पहले उस पर काम करें. पृष्ठ को खत्म करने के लिए पढ़ें. क्या यह समझ में आता है? केवल शैलियों पर जाने के लिए जब यह करता है. यदि आप एक छोटे से सुविधा पर काम कर रहे हैं, तो एक ही विचार लागू होता है. पहले मार्कअप को बाहर रखें और देखें कि यह एप्लिकेशन के बाकी हिस्सों में कैसे फिट होता है. टैग का इरादा मेल खाते हैं? क्या आप आसपास के शीर्षक क्रम का सम्मान करते हैं? मार्किंग के साथ शुरू करना आपको इरादे के बारे में सोचने के लिए मजबूर करता है, उपस्थिति नहीं। नहीं, जो वे एक HTML-पहले दृष्टिकोण के साथ आप संरचना, अर्थ और प्रतिबंधों को परिभाषित करते हैं जो सिस्टम को सरल और पूर्वानुमान रखते हैं। है जैसे दिखते हैं CSS should adapt to that, not the other way around. जब आप स्टाइलिंग में दौड़ते हैं, तो आप दृश्य संकेतों के आसपास मार्किंग को आकार देने की प्रवृत्ति रखते हैं. अतिरिक्त कवर. गलत टैग. आमतौर पर आप चीजों के साथ समाप्त होते हैं जो अच्छी तरह से, लेकिन सीमेंटिक रूप से गलत हैं, या स्केल करना असंभव है। देखो सबसे पहले मार्कअप करने से, आप एक ठोस नींव में लॉक करते हैं। पहुंच, दस्तावेज़ का वर्णन, कीबोर्ड प्रवाह, और सामग्री सूचकांक को ज्यादातर पहले से ही हल किया जाता है। यह आपको एक अच्छा तरीका भी धीमा करता है. आप जल्दी से मार्जिन मामलों को पकड़ते हैं. आप देखते हैं कि चीजें कहां नहीं हैं. आप कुछ डिजाइन निर्णयों पर वापस धक्का दे सकते हैं. संक्षेप में: HTML-पहले सब कुछ समझ में आता है। 2. जब सीएसएस आप सोचते हैं की तुलना में अधिक करता है एक और आम गलती मैं कोड समीक्षाओं में देखता हूं जो जूनियर करते हैं कभी-कभी आपको यह समझ में नहीं आ रहा है, मैं आपको कुछ सरल उदाहरण दिखाऊंगा। बहुत ज्यादा कहते हैं कि आप सामग्री कॉलम को क्षैतिज रूप से केंद्रित करना चाहते हैं: .entry-content { max-inline-size: 48rem; margin: 0 auto; /* ❌ Avoid this! */ } आप ऑटो मार्जिन का उपयोग करके एक मैक्स चौड़ाई सेट करते हैं और तत्व को केंद्रित करते हैं। हालांकि, आप क्या महसूस नहीं कर सकते हैं कि आप ऊपरी और निचले मार्जिन को शून्य पर भी सेट कर रहे हैं. यदि यह इरादा है, तो ठीक है. अधिकांश समय यह नहीं है. अधिकांश समय संक्षिप्त शब्द का उपयोग सिर्फ इसलिए किया जाता है क्योंकि यह छोटा है. आप इसके बजाय क्या चाहते हैं शायद यह है: .entry-content { max-inline-size: 48rem; margin-inline: auto; /* ✅ Do this */ } एक ही परिणाम. कोई साइड इफेक्ट. अधिक इरादा. एक और सामान्य उदाहरण: .button--secondary { background: var(--color--dark-gray); } यह पृष्ठभूमि रंग सेट करता है, जिसका उपयोग लेकिन यह अन्य पृष्ठभूमि से संबंधित गुणों का एक टुकड़ा भी रीसेट करता है। --color--dark-gray बहुत कुछ है, वास्तव में: पृष्ठभूमि कोई नहीं पृष्ठभूमि स्थिति → 0% 0% कार के पीछे आकार पुनः पुनः पुनः पुनः पुनः पुनः पुनः पुनः पुनः पुनः पृष्ठभूमि मूल → padding-box पृष्ठभूमि-क्लिप → border-box पृष्ठभूमि - स्क्रॉल ज्यादातर समय, यह वह नहीं है जो आप चाहते हैं. यह आसानी से परेशान दुष्प्रभावों का कारण बन सकता है जिन्हें आपको बाद में संबोधित करने की आवश्यकता होगी. इसके बजाय आप क्या चाहते हैं शायद यह है। .button--secondary { background-color: var(--color--dark-gray); } एक ही विचार जैसा पहले था. लेकिन सर्जिकल. केवल बदलें कि आप वास्तव में क्या बदलना चाहते हैं. फिर से, अधिक इरादा। एक ही सिद्धांत अन्य संक्षिप्त संपत्तियों के लिए लागू होता है, जैसे , , , , और अन्य. उन्हें संक्षिप्त हाथों के रूप में उपयोग करते समय सावधान रहें. या संक्षिप्त हाथों का उपयोग बिल्कुल से बचें. border transform transition font बहुत अधिक करने का एक और सामान्य उदाहरण बहुत जल्दी विशिष्ट होना है। a { text-decoration: none; background-image:linear-gradient(to right, currentColor, currentColor); background-position:0%100%; background-repeat: no-repeat; background-size:100%2px; transition: background-size 0.3s; &:hover, &:focus-visible { background-position:100%100%; } } यह स्नैप लिंक के लिए एक एनिमेटेड उतार-चढ़ाव जोड़ता है। समस्या यह है कि हर टैग एक पाठ लिंक है. छवियों को लिंक हो सकते हैं. प्रोफ़ाइल एवाटार लिंक हो सकते हैं. बटन अक्सर एंकर के रूप में चिह्नित किए जाते हैं. <a> अचानक, यह "स्मार्ट" वैश्विक शैली आपके लोगो के नीचे अजीब 2px लाइनों को जोड़ रही है या आपके प्राथमिक बटन पर पृष्ठभूमि ग्रेडिंट को तोड़ रही है। अब, आप परियोजना के बाकी हिस्से को कैस्केड से लड़ने के लिए बिताएंगे, प्रत्येक गैर-टेक्स्ट लिंक के लिए "ओंडो" शैलियों को लिखेंगे जिसे आप काम करते हैं, जब तक कि आप इसे ठीक न करें, बेशक। visual debt आप इसे कई तरीकों से हल कर सकते हैं. एक विकल्प सामग्री के भीतर पाठ लिंक लक्षित करना है. .entry-content:is(h1, h2, h3, h4, h5, h6, p, li) > a { /* styles here */ } लेकिन यहां तक कि यह अभी भी बहुत संकीर्ण या बहुत व्यापक हो सकता है, मार्किंग पर निर्भर करता है. यह एक विशिष्ट HTML संरचना पर निर्भर करता है जो बदल सकता है. मेरा पसंदीदा दृष्टिकोण एक उपयोगिता वर्ग है। .has-animated-underline { /* styles here */ } इसे एक कक्षा में स्थानांतरित करके, आप व्यवहार बनाते हैं यह स्पष्ट है, इरादा है, और - सबसे महत्वपूर्ण बात - आपको उन चीजों को ठीक करने की आवश्यकता नहीं है जो पहले टूटे नहीं थे। opt-in rather than opt-out 3. जब मोबाइल एक Afterthought है मोबाइल वेब ट्रैफ़िक ने 2016 में डेस्कटॉप को वैश्विक स्तर पर पार किया - लगभग दस साल पहले. फिर भी मैं अभी भी डिजाइनरों को डेस्कटॉप कॉम्प पर काम करने और डेस्कटॉप-पहले काम प्रस्तुत करने के लिए अपना अधिकांश समय बिताते हुए देखता हूं, जबकि मोबाइल को डेस्कटॉप का एक सरल "स्टैक" संस्करण माना जाता है। यह अभी भी पीछे की ओर महसूस होता है। इसे पसंद करें या नहीं, हम पहले एक फोन के माध्यम से इंटरनेट का अनुभव करते हैं. यह फिर से बदल सकता है, लेकिन यह आज की वास्तविकता है. वेब के लिए हम कैसे बनाते हैं, इसे प्रतिबिंबित करना चाहिए। अभ्यास में, अब मैं स्टाइलिंग के लिए इस तरह से पहुंचता हूं: मार्कअप को रखें (यह के बारे में बात की 😉)। ब्राउज़र को लगभग 400px तक परिवर्तित करें और ऐप या सुविधा को स्टाइल करें जैसे कि डेस्कटॉप मौजूद नहीं है। एक बार जब यह मोबाइल पर काम करता है, तो ब्राउज़र को डेस्कटॉप में बदलें और शैलियों पर एक दूसरा पास करें। इस तरह से काम करना स्वाभाविक रूप से आपको अपने परियोजना को सुलभ बनाने और छोटे स्क्रीन के लिए तैयार करने के संदर्भ में 80% (रैंडम संख्या जो सही लगती है) मिलती है। यह कार्बनिक रूप से हमें मोबाइल-प्रथम कार्यान्वयन तक ले जाता है। जब मैंने वेब विकास करना शुरू किया, तो मीडिया पूछताछ लगभग एक चीज नहीं थी. हमने फोन पर वेब ब्राउज़ नहीं किया. यह एक डेस्कटॉप-केवल ब्रह्मांड था. फिर आईफोन बाहर आया, और मीडिया पूछताछ प्रतिक्रियाशील लेआउट के लिए मुख्य उपकरण बन गई. वेब सक्षम उपकरणों की संख्या सीमित थी, इसलिए आप कठोर बिंदुओं के एक सेट के साथ बाहर निकल सकते थे: /* phones */ @media (max-width: 480px) {} /* large phones and small tablets */ @media (max-width: 767px) {} /* tablets */ @media (min-width: 768px) and (max-width: 1024px) {} /* desktop */ @media (min-width: 1025px) {} ध्यान दें कि यह मोबाइल-प्रथम भी नहीं है। दृष्टिकोण min-width आज, वास्तविकता अलग है। डिवाइस और स्क्रीन आकारों को अकेले ब्रेकपॉइंट का उपयोग करने के लिए डिजाइन करने के लिए बहुत अधिक हैं. यह अक्सर ऐसे उपकरणों पर भरोसा करना है जो पूरी श्रृंखला में स्वाभाविक रूप से अनुकूलित होते हैं। जैसे : ग्रिड या फ्लेक्सबॉक्स के साथ आंतरिक लेआउट फ्रंट आकारों, अंतराल और आयामों के लिए clamp() का उपयोग करते हुए तरल मूल्यों कंटेनर मांगें मीडिया पूछताछ अभी भी उपयोगी हैं, लेकिन उन्हें पहला उपकरण नहीं होना चाहिए जिसे आप प्राप्त कर सकते हैं। यदि एक लेआउट केवल ब्रेकपॉइंट के कारण काम करता है, तो यह शायद बहुत कठोर है. जब यह उनके बिना काम करता है, तो मीडिया पूछताछ संवेदनशील संरचना के लिए छोटे, इरादेदार समायोजन बन जाती है, नींव नहीं। 4. इसका उपयोग करने के बजाय कैस्केड से लड़ना यह एक और क्षेत्र है जहां मैं अक्सर युवा इंजीनियरों की लड़ाई देखता हूं। कई सीएसएस फ्रेमवर्क और समाधान एक मुख्य विशेषता को हल करने के लिए मौजूद हैं: कैस्केड. और मुझे पता चलता है कि क्यों. यदि आप बहुत अनुभव के बिना सीएसएस में कूदते हैं, तो यह अराजक महसूस कर सकता है. आप एक नियम लिखते हैं और यह कुछ भी नहीं करता है. आप इसे समायोजित करते हैं और अचानक कुछ और टूट जाता है. इसके अलावा, उपयोगकर्ता एजेंट स्टाइल शीट पृष्ठभूमि में अपना काम कर रहा है. यह निराशाजनक है क्योंकि सीएसएस अधिकांश अन्य भाषाओं की तरह कुछ भी नहीं है. जावास्क्रिप्ट में, आप एक मॉड्यूल बना सकते हैं और कुछ भी रिसाव नहीं होता है. Variables remain contained to that module. आप सीएसएस को उसी तरीके से नहीं पहुंच सकते. यदि आप कोशिश करते हैं, तो यह आपको चेहरे पर बहुत कठोर हो जाएगा। प्रत्येक सीएसएस परिवर्तन एक ही समय में दो क्षेत्रों में रहता है: जो चीज आप स्टाइलिंग कर रहे हैं और उस प्रणाली के बाकी हिस्से में प्रवाह करता है। पहले के उदाहरण पर लौटते हुए, आप सिर्फ यह नहीं लिख सकते: a { text-decoration: none; background-image:linear-gradient(to right, currentColor, currentColor); background-position:0%100%; background-repeat: no-repeat; background-size:100%2px; transition: background-size 0.3s; &:hover, &:focus-visible { background-position:100%100%; } } यदि आप ऐसा करते हैं, तो पृष्ठ पर प्रत्येक एंकर पर पृष्ठ से संबंधित गुण लागू होंगे, भले ही वह एंकर पाठ लिंक नहीं हो। ज्यादातर समय, यह वह नहीं है जो आप चाहते हैं। कुछ इंजीनियर इस कठिन तरीके से सीखते हैं और कैस्केड से पूरी तरह से बचकर प्रतिक्रिया देते हैं, जैसे कि एक बच्चे के रूप में एक गर्म ओवन को छूना और इसे फिर से नहीं करना सीखना। मुझे लगता है कि यह एक गलती है क्योंकि यह कई पुनरावृत्ति का कारण बनता है। यहाँ एक नयी परियोजना का एक उदाहरण है जिस पर मैं काम कर रहा था. एक मिश्रण था: @define-mixin focus-state { &:focus-visible { outline: var(--outline--color) var(--outline--style) var(--outline--width); outline-offset: var(--outline--offset); } } इसके बाद इसे कई घटकों में शामिल किया गया था: .button { @mixin focus-state; } a { @mixin focus-state; } .pagination-link { @mixin focus-state; } ...और ऐसा ही है। मैं इसके लिए एक अच्छा कारण नहीं सोच सकता. फोकस परिदृश्यों को बहुत कम अपवादों के साथ एक परियोजना के माध्यम से लगातार दिखना चाहिए। इस सेटिंग में, प्रत्येक मिक्सिन कॉल बार-बार एक ही सीएसएस उत्पन्न करता है। एक अधिक सुरुचिपूर्ण दृष्टिकोण कैस्केड पर भरोसा करना है और इसे वैश्विक रूप से परिभाषित करना है: :focus-visible { outline-color:var(--outline--color); outline-offset:var(--outline--offset); outline-style:var(--outline--style); outline-width:var(--outline--width); } अब प्रत्येक तत्व जो एक दृश्य फोकस राज्य प्राप्त करता है, डिफ़ॉल्ट रूप से एक ही स्टाइलिंग प्राप्त करता है। और उन दुर्लभ मामलों में जहां कुछ अलग होना चाहिए, आप इसे स्थानीय रूप से अपलोड कर सकते हैं: .pagination-link { --outline--offset: -2px; } यह है. सरल, कॉम्पैक्ट, और पूर्वानुमान है। यह विचार ऐसी चीजों के लिए भी लागू होता है जैसे , मार्जिन रीसेट, , और अन्य शैलियों को जो ऐप में लगातार व्यवहार करना चाहिए। box-sizing ::selection text-wrap एक त्वरित हृदय जांच यहां मदद करता है. यदि एक शैली दिखती है प्रत्येक हिस्से के साथ, एक ही अपवाद, यह शायद आपके वैश्विक शैलियों में से एक है। exactly very few कैस्केड को अनदेखा न करें. इसे अपने लाभ के लिए उपयोग करें। 5. विशिष्टता वह जगह है जहां चीजें अलग-अलग हो जाती हैं यह आमतौर पर "मैंने अपना सीएसएस लिखा है लेकिन यह काम नहीं करता है" के पीछे कारण है। मैं गहराई से नहीं जाऊंगा कि विशिष्टता क्या है. एमडीएन पहले से ही है यहां क्या मायने रखता है कि उच्च विशिष्टता तीसरे पक्ष के पुस्तकालयों या किसी और के कोड के साथ काम करते समय दर्द का एक मुख्य स्रोत है। यह वास्तव में अच्छी तरह से करता है इस उदाहरण को लें: .layout > :not(.alignleft):not(.alignright):not(.alignfull):not(.alignwide) { max-width: var(--content-width); margin-left: auto; margin-right: auto; } यहां हम सीधे बच्चों को केंद्रित करते हैं क्षैतिज रूप से और एक मैक्स चौड़ाई लागू करें - सभी बच्चों को छोड़कर , , और . .layout alignleft alignright alignfull alignwide इस कोड की गंध के दो मुख्य कारण हैं। सबसे पहले, यह एक ब्लैकलिस्ट पैटर्न है. हम सब कुछ स्टाइल कर रहे हैं चीजों की एक बढ़ती सूची. समस्या यह है कि "सब कुछ" हमेशा समय के साथ बदलता है. परियोजना बढ़ने के साथ, आप लगभग निश्चित रूप से अधिक अपवाद जोड़ेंगे. एक दिन आप इसे जोड़ना भूल जाएंगे, और कुछ टूट जाएगा. सिवाय दूसरा, प्रत्येक सेलेक्टर जो आप जोड़ते हैं, विशिष्टता को बढ़ाता है। इसका मतलब है कि इसे ऊपर उठाने के लिए एक और मजबूत सेलेक्टर की आवश्यकता होती है, , या हर चीज में फेंक दें दूसरे शब्दों में, आप अधिक जटिलता के साथ जटिलता को ठीक करते हैं। 0.5.0 !important @layer :where() वर्डप्रेस सीएसएस आर्किटेक्चर के बिना शुरू करने और अराजकता के साथ समाप्त होने का एक अच्छा उदाहरण है। body .is-layout-constrained > :where(:not(.alignleft):not(.alignright):not(.alignfull)) { max-width: var(--wp--style--global--content-size); margin-left: auto !important; margin-right: auto !important; } मैं यहां मिश्रित संकेत प्राप्त कर रहा हूं. हम खुद के साथ कोने में हैं पैटर्न, महसूस किया कि यह एक बुरा विचार था, पुनर्प्राप्त इसके बाद ... अनुप्रयोग मुझे यकीन है कि इसके लिए एक कारण था, लेकिन आदमी ... क्या यह निराशाजनक नहीं है। :not() :where() !important आप निश्चित रूप से यह सब कर सकते हैं ... ...या आप अधिक उद्देश्यपूर्ण हो सकते हैं और अपने आप को कुछ शांति खरीद सकते हैं: /* 0.1.0 */ .layout > * { max-width: var(--content-width); margin-left: auto; margin-right: auto; } /* 0.2.0 */ .layout > .alignleft, .layout > .alignright { --content-width: var(--content-width--narrow); } /* 0.2.0 */ .layout > .alignwide { --content-width: var(--content-width--wide); } /* 0.2.0 */ .layout > .alignfull { --content-width: var(--content-width--full); } यह पढ़ना आसान है और इसके बारे में तर्क करना आसान है। अपवाद हैं . 0.1.0 0.2.0 पूर्वानुमान और इरादा। यहां एक और आम तरीका है कि कोई अच्छी वजह के बिना विशिष्टता बढ़ती है: /* ❌ combine element with a class ❌ element nested inside the block ❌ modifier nested inside the block */ a.button { &.button__label {...} &.button--secondary {...} } इस उदाहरण में: यदि a और .button को जोड़ने का कोई कारण नहीं है, तो ऐसा न करें। यदि .button के तहत .button__label को गले लगाने का कोई कारण नहीं है, तो ऐसा न करें। बदलते वर्ग के लिए भी ऐसा ही होता है। यदि आप एक नया घटक भेज रहे हैं, तो आमतौर पर यह है कि आप इसके बजाय चाहते हैं: /* ✅ no element + class combination ✅ elements and modifiers stay flat */ .button {...} .button__icon {...} .button--primary {...} यहाँ मेरे द्वारा अनुसरण की गई उंगलियों का नियम है: डिफ़ॉल्ट रूप से एकल क्लास सेलेक्टर को पसंद करें। स्टैकिंग सेलेक्टरों के बजाय उपयोगिता संस्करणों का उपयोग करें. Source order will help you here. विशेषता को 0.1.0 या 0.1.1 पर रखें। आप भेजने वाली विशेषताओं में 0.2.0 से अधिक मत जाओ। एप्लिकेशन कोड में #id सेलेक्टर और इनलाइन शैलियों से बचें. वे विशिष्टता को उजागर करते हैं और ओवररेड करने के लिए दर्दनाक हैं. उच्च विशिष्टता का उपयोग केवल तीसरे पक्ष के कोड या पुरानी कोड को उजागर करते समय करें जिसे आप अभी तक refactor नहीं कर सकते. Isolate it and move on. नोट है , और :where() @layer @scope मैं इन उपकरणों के बारे में पूरी तरह से जानता हूं. आप विशिष्टता को शून्य तक कम कर सकते हैं अलग-अलग शैलियों के साथ , और scope selectors के साथ . :where() @layer @scope वे शक्तिशाली हैं, और उनके पास अपना स्थान है, लेकिन वे बुरी वास्तुकला को ठीक नहीं करते हैं। एक ही विशिष्टता नियम अभी भी प्रत्येक परत के भीतर और प्रत्येक सीमा के भीतर लागू होते हैं। अपने भविष्य की खुद को कम रखें. आपका भविष्य आपको धन्यवाद देगा.
