CSS कोड "एक स्टिफ़ल के साथ"

क्रिस कोयर ने हाल ही में स्मैशिंग मैगज़ीन के पाठकों के सवालों के जवाब दिए। एक सवाल यह था कि सीएसएस कोड को "प्रिय" के साथ कैसे पहचाना जाए:

यदि आपका CSS कार्य कर रहा है तो आप कैसे बता सकते हैं? संकेत क्या संकेत देते हैं कि कोड इष्टतम नहीं है या डेवलपर ने इसे आस्तीन के माध्यम से लिखा है? यदि कोड खराब है या अच्छा है तो आप यह निर्धारित करने के लिए पहले क्या देख रहे हैं?

मुझे लगा कि मैं अपने अनुभव के आधार पर क्रिस के जवाब का विस्तार और पूरक कर सकता हूं।

मैं BSkyB में काम करता हूँ। मैं बड़ी साइटें बनाता हूं - मैं उनमें से एक साल से अधिक समय से काम कर रहा हूं। खराब सीएसएस कोड मुझे बहुत सारी समस्याएं देता है। जब आप महीनों से एक साइट पर काम कर रहे हैं, तो आप बस एक बुरा कोड नहीं दे सकते हैं, और आपको इसे ठीक करना होगा।

मैं सीएसएस कोड की गुणवत्ता, रखरखाव और स्वच्छता का आभास देने के लिए कुछ चीजें साझा करना चाहता हूं, जिन पर मैं सबसे पहले ध्यान देता हूं।

शैलियों को रद्द करें

कोई भी CSS नियम जो पहले से सेट की गई शैलियों को ओवरराइड करता है (शैलियों को रीसेट करने के अलावा) एक वेक-अप कॉल है। कैस्केडिंग स्टाइल शीट, परिभाषा के अनुसार, पिछली परिभाषाओं से विरासत में मिली और उन्हें पूरक करना चाहिए, और उन्हें रद्द नहीं करना चाहिए।

कोई भी परिभाषा जैसे:

border-bottom:none; padding:0; float:none; margin-left:0; 

आमतौर पर कुछ भी अच्छा नहीं होता है। यदि आपको border को रीसेट करना border , तो सबसे अधिक संभावना है कि आपने इसे जल्द ही स्थापित किया है। यह समझाना मुश्किल है, इसलिए मैं एक उदाहरण दूंगा:

 h2{ font-size:2em; margin-bottom:0.5em; padding-bottom:0.5em; border-bottom:1px solid #ccc; } 

यहां हम h2 तत्वों को न केवल फ़ॉन्ट आकार और पैडिंग देते हैं, बल्कि मार्जिन और अंडरस्कोर को भी बाकी सामग्री से शीर्षक को नेत्रहीन रूप से अलग करते हैं। लेकिन यह बहुत अच्छी तरह से हो सकता है कि किसी अन्य स्थान पर हमें या तो खेतों की जरूरत नहीं है या फिर रेखांकित करने की आवश्यकता नहीं है। शायद हम कुछ ऐसा लिखेंगे:

 h2{ font-size:2em; margin-bottom:0.5em; padding-bottom:0.5em; border-bottom:1px solid #ccc; } .no-border{ padding-bottom:0; border-bottom:none; } 

अब हमारे पास कोड की 10 लाइनें और एक बदसूरत वर्ग का नाम है। ऐसा करना बेहतर होगा:

 h2{ font-size:2em; margin-bottom:0.5em; } .headline{ padding-bottom:0.5em; border-bottom:1px solid #ccc; } 

8 लाइनें, शैलियों का कोई रद्दीकरण और एक सुंदर, सार्थक वर्ग नाम नहीं।

स्टाइलशीट नीचे जाना, नियम जोड़ना, दूर नहीं ले जाना। यदि आपको पहले से निर्धारित शैलियों को पूर्ववत करना है, तो सबसे अधिक संभावना है कि आपने उन्हें जल्द ही जोड़ा है।

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

जब मैं देखता हूं कि कुछ नियम पिछले एक को ओवरराइड करते हैं, तो मैं लगभग निश्चित रूप से जानता हूं कि शैलियों को ठीक से व्यवस्थित नहीं किया गया है और इसे फिर से काम करने की आवश्यकता है।

मैजिक नंबर

मैं विशेष रूप से उनसे नफरत करता हूँ! एक जादुई संख्या एक अर्थहीन मूल्य है जिसका उपयोग किया जाता है क्योंकि यह "बस काम करता है।" उदाहरण के लिए:

 .site-nav{ /* [styles] */ } .site-nav > li:hover .dropdown{ position:absolute; top:37px; left:0; } 

top:37px; एक जादू की संख्या है। इसका एकमात्र कारण यह है कि यह पता चलता है कि सूची आइटम 37 पिक्सेल ऊंचे हैं, और ड्रॉप-डाउन सबमेनस मेनू आइटम के नीचे दिखाई देना चाहिए।

समस्या यह है कि ये 37 पिक्सेल शुद्ध संयोग हैं, और आप इस पर पूरी तरह से भरोसा नहीं कर सकते। क्या होगा यदि कोई मेनू आइटम में फ़ॉन्ट का आकार बदलता है, और यह ऊंचाई में 37 पिक्सेल नहीं, बल्कि 29 होगा? क्या होगा यदि Chrome में मेनू आइटम 37 पिक्सेल अधिक है, और IE 36 पिक्सेल में? यह संख्या केवल एक विशिष्ट मामले में काम करती है।

कभी भी, उन मूल्यों का उपयोग न करें जो "बस काम करते हैं।" पिछले उदाहरण में, top:100%; लिखना बेहतर होगा top:100%; top:37px; बजाय top:37px;

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

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

मैजिक नंबर खराब हैं। वे जल्दी से अप्रचलित हो जाते हैं, वे अन्य डेवलपर्स के साथ हस्तक्षेप करते हैं, उन्हें समझाया नहीं जा सकता है, और उन्हें भरोसा नहीं किया जा सकता है।

किसी और के कोड में ऐसी अकथनीय संख्या पर ठोकर खाने से बुरा कुछ नहीं है। यहाँ क्यों है? इसका क्या मतलब है? क्या मैं इसे छू सकता हूं या नहीं? जब भी मैं इस तरह का नंबर देखता हूं तो मैं ये सवाल पूछता हूं। और मुख्य प्रश्न: "आप जादू के बिना एक ही परिणाम कैसे प्राप्त कर सकते हैं?"

प्लेग की तरह जादू की संख्या से भागो!

अत्यधिक संकीर्ण चयनकर्ता

कुछ इस तरह:

 ul.nav{} a.button{} div.header{} 

ये चयनकर्ता हैं, जो पूरी तरह से अनावश्यक शोधन जोड़ते हैं। वे खराब हैं क्योंकि:

• उनका पुन: उपयोग करना लगभग असंभव है;
• वे विशिष्टता बढ़ाते हैं;
• प्रदर्शन उनसे ग्रस्त है।

वास्तव में, वे (और) को इस तरह लिखा जाना चाहिए:

 .nav{} .button{} .header{} 

अब आप .nav to ol , .button को input लागू कर सकते हैं और जल्दी से div को वर्ग के साथ बदल सकते हैं। header तत्व के साथ .header जब हम साइट को HTML5 के अनुरूप बनाते हैं।

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

 ul.nav li.active a{} div.header a.logo img{} .content ul.features a.butto 

उन सभी को बहुत कम या फिर से लिखा जा सकता है:

 .nav .active a{} .logo > img {} .features-button{} 

हर बार जब मैं अत्यधिक विस्तृत चयनकर्ताओं पर ठोकर खाता हूं, तो मैं यह पता लगाने की कोशिश करता हूं कि वे इस तरह से सेट क्यों हैं, और क्या उन्हें कम करना संभव है।

हार्डकोड एब्सोल्यूट वैल्यूज़

जादू की संख्या की तरह, वे अच्छी तरह से नहीं करते हैं। यहाँ एक उदाहरण है:

 h1{ font-size:24px; line-height:32px; } 

यह लिखना बेहतर होगा: line-height:1.333;

line-height:1.333;

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

 h1{ font-size:24px; line-height:32px; } /** * Main site `h1` */ .site-title{ font-size:36px; line-height:48px; } 

और इसलिए हर बार हेडर फ़ॉन्ट आकार बदलता रहता है। यह बहुत बेहतर है:

 h1{ font-size:24px; line-height:1.333; } /** * Main site `h1` */ .site-title{ font-size:36px; } 

ऐसा लगता है कि अंतर छोटा है, लेकिन एक बड़ी परियोजना में यह बहुत महत्व का हो सकता है।

वैसे, यह न केवल line-height पर लागू होता है। लगभग किसी भी निरपेक्ष मूल्य को कोड में हार्ड-कोड किया गया है जो संदिग्ध होना चाहिए।

एकमात्र मामला जब यह वास्तव में पूर्ण मूल्य को हार्डकोड करने के लिए समझ में आता है, तो उन चीजों के साथ काम करना जो हमेशा एक निश्चित आकार होना चाहिए, उदाहरण के लिए, स्प्राइट्स।

क्रूर बल

यह हार्ड-सेट मैजिक नंबरों के कुछ विशेष मामलों में से एक है और कुछ अन्य ट्रिक्स जिनका उपयोग लेआउट कार्य करने के लिए किया जाता है:

 .foo{ margin-left:-3px; position:relative; z-index:99999; height:59px; float:left; } 

यह एक भयानक शैली है! इन सभी बदसूरत नियमों को हर कीमत पर सही जगह पर एक सामान की पूर्ति के लिए कल्पना की गई है। इस तरह के कोड या तो बहुत खराब तरीके से तैयार किए गए लेआउट को इंगित करते हैं, या यह समझने की कमी है कि सीएसएस ब्लॉक मॉडल कैसे काम करता है, या दोनों एक ही समय में।

यदि आपके पास एक सुविचारित लेआउट है और ब्लॉक मॉडल को समझते हैं, तो आपको पाशविक बल का उपयोग करने की संभावना नहीं है। यदि मुझे ऐसा कोड दिखाई देता है, तो मैं तुरंत यह पता लगाने की कोशिश करता हूं कि समस्या क्या है, और क्या इस तरह की बैसाखी लिखने की आवश्यकता से छुटकारा पाने के लिए कुछ कदम पीछे जाना आवश्यक है।

खतरनाक चयनकर्ता

खतरनाक चयनकर्ताओं से मेरा मतलब है कि वे आवश्यकता से अधिक व्यापक हैं। ऐसे चयनकर्ता का सबसे सरल और स्पष्ट उदाहरण है:

 div{ background-color:#ffc; padding:1em; } 

क्यों, क्यों इस कालीन बमबारी के साथ पृष्ठ पर हर div कवर? किसी को एक aside{} चयनकर्ता की आवश्यकता क्यों होगी aside{} ? या header{} , या ul{} ? ऐसे चयनकर्ता बहुत अधिक हैं, आवश्यकता से अधिक व्यापक हैं, और इस तथ्य को जन्म देते हैं कि हमें उन शैलियों को रद्द करना होगा जिनके बारे में हम पहले ही बात कर चुके हैं।

आइए header{} साथ उदाहरण देखें header{} अधिक विस्तार से। कई लोग इस तत्व का उपयोग पेज हेडर बनाने के लिए करते हैं, जो पूरी तरह से सही है। लेकिन अगर आप इसके लिए इस तरह की शैली लिखते हैं:

 header{ padding:1em; background-color:#BADA55; color:#fff; margin-bottom:20px; } 

तो यह पूरी तरह से गलत है। header एलिमेंट जरूरी नहीं कि पूरे पेज की हेडिंग हो। इसका इस्तेमाल कई बार अलग-अलग संदर्भों में किया जा सकता है। एक वर्ग का उपयोग करना बहुत बेहतर है, उदाहरण के लिए .site-header{} ।

ऐसे आम चयनकर्ता के लिए इस तरह की विस्तृत शैलियों को परिभाषित करना बहुत खतरनाक है। जैसे ही आप इस तत्व का पुन: उपयोग करना शुरू करेंगे, वे पूरी तरह से अप्रत्याशित स्थानों पर लीक हो जाएंगे।

सुनिश्चित करें कि आपके चयनकर्ता सही निशाने पर लगे ।

यहाँ एक और उदाहरण है:

 ul{ font-weight:bold; } header .media{ float:left; } 

जब मैं देखता हूं कि शैलियों को किसी तत्व या बहुत सामान्यीकृत वर्ग पर कैसे लागू किया जाता है, जैसा कि इस उदाहरण में, मुझे घबराहट होने लगती है। मुझे पता है कि वे बहुत सार्वभौमिक हैं और मुझे समस्याएं होंगी। इन शैलियों को उन स्थानों पर विरासत में लिया जा सकता है जहां यह पूरी तरह से अवांछनीय होगा, और मुझे उन्हें रद्द करना होगा।

प्रतिक्रियाशील उपयोग!

आप उपयोग कर सकते हैं !important और यह वास्तव में एक महत्वपूर्ण उपकरण है। हालांकि, इसका इस्तेमाल समझदारी से किया जाना चाहिए।

!important सक्रिय रूप से इस्तेमाल किया जाना चाहिए, प्रतिक्रियाशील नहीं।

इसका मतलब यह है कि इसका उपयोग तब किया जा सकता है जब आप पूरी तरह से सुनिश्चित हों कि आपको इस शैली की आवश्यकता होगी ताकि आप पूर्वता ले सकें, और आपको इसके बारे में पहले से पता हो।

उदाहरण के लिए, आप सुनिश्चित हैं कि आप हमेशा त्रुटियों को लाल रंग में देखना चाहते हैं:

 .error-text{ color:#c00!important; } 

भले ही एक त्रुटि संदेश एक ब्लॉक के अंदर प्रदर्शित होता है जिसमें पाठ का रंग नीला है, हम यह सुनिश्चित कर सकते हैं कि त्रुटि लाल रहेगी। हम हमेशा लाल रंग में त्रुटि की रिपोर्ट करना चाहते हैं, और इसलिए हम तुरंत लिखते हैं !important

लेकिन जब हम उपयोग करते हैं !important प्रतिक्रियात्मक रूप से, अर्थात्, एक समस्या के जवाब में, जो पैदा हुई, जब हम भ्रमित हो गए और इसे सुलझाने के बजाय, आगे बढ़ें, तो यह बुरा है।

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

आईडी

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

इसके कारण सरल हैं:

• आईडी का उपयोग केवल एक बार पृष्ठ पर किया जा सकता है;
• वर्ग का उपयोग आप जितना चाहें उतना किया जा सकता है;
• आईडी पर लागू अधिकांश नियम कई वर्गों में बिखरे हुए हो सकते हैं;
• एक वर्ग की तुलना में आईडी 255 गुना अधिक विशिष्ट है ;
• इसका मतलब है कि आपको एक आईडी को आउटवे करने के लिए तत्व में 256 कक्षाएं लागू करने की आवश्यकता होगी।

यदि यह आपके लिए पर्याप्त नहीं है, तो मुझे नहीं पता कि क्या कहना है ...

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

अंत में, थोड़ा व्यायाम। इस समस्या को हल करने की कोशिश करें। संकेत: तो - सुरुचिपूर्ण नहीं; और ऐसा ही।

धुँधली श्रेणी के नाम

एक अस्पष्ट नाम वह है जो विशेष रूप से वर्ग के उद्देश्य का वर्णन नहीं करता है। .card क्लास की कल्पना करें। वह क्या कर रहा है?

यह एक बहुत अस्पष्ट नाम है, और अस्पष्ट नाम दो मुख्य कारणों से खराब हैं:

• आप अनुमान नहीं लगा सकते कि इसका क्या मतलब है;
• यह इतना सामान्य है कि किसी अन्य डेवलपर द्वारा इसे गलती से ओवरराइड किया जा सकता है।

पहला बिंदु बहुत सरल है: क्या मतलब है .card ? वह किस शैली से पूछता है? परियोजना प्रबंधन प्रणाली में कार्य कार्ड? एक ऑनलाइन कैसीनो में एक खेल कार्ड? क्रेडिट कार्ड की छवि? यह कहना कठिन है क्योंकि नाम बहुत अस्पष्ट है। मान लीजिए कि हमारा मतलब क्रेडिट कार्ड से है। तब वर्ग का नाम देना बेहतर होता है। .redit-card-image{} हाँ, बहुत लंबे समय तक, लेकिन बहुत बेहतर!

अस्पष्ट नामों के साथ दूसरी समस्या यह है कि वे गलती से ओवरराइड करने में बहुत आसान हैं। मान लीजिए आप एक ऑनलाइन स्टोर साइट पर काम कर रहे हैं। आप .card वर्ग का उपयोग करते हैं, जिसका अर्थ खाते से .card क्रेडिट .card की संख्या है। और इस समय एक और डेवलपर उपहार खरीदने और उसमें बधाई कार्ड संलग्न करने का अवसर जोड़ता है। और वह .card क्लास को भी कॉल करता है, और इसके लिए अपने स्वयं के नियम लिखता है कि आपके साथ संघर्ष।

अधिक सटीक वर्ग नामों का उपयोग करके इसे आसानी से टाला जा सकता है। .card या .user जैसी .card बहुत धूमिल हैं। वे असंक्रामक हैं और गलती से पुनर्परिभाषित करना आसान है। कक्षा के नाम यथासंभव सटीक होने चाहिए।

निष्कर्ष

तो, हमने "डार्लिंग के साथ" कोड के कुछ उदाहरणों को देखा। ये ऐसी चीजें हैं, जिन्हें हमेशा याद रखना चाहिए और उनकी पूरी ताकत के साथ या उनसे बचना चाहिए, बल्कि उनमें से केवल एक छोटा सा हिस्सा है, वास्तव में, बहुत सारे हैं। जब महीनों और वर्षों तक चलने वाले बड़े प्रोजेक्ट पर काम किया जाता है, तो कोड को अच्छे आकार में रखना महत्वपूर्ण है।

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