वहां कई सीएसएस पद्धतियां हैं, और मुझे उन सभी से नफरत है। कुछ अधिक (टेलविंड और अन्य) और कुछ कम (बीईएम, ओओसीएसएस, आदि)। लेकिन आख़िरकार, उन सभी में खामियाँ होती हैं।

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

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

निर्मित तत्व

सामान्य नियम के रूप में, मैं जितना संभव हो सके अंतर्निहित तत्व प्रकारों का उपयोग करने का प्रयास करता हूं, और जितना संभव हो उतना कम अतिरिक्त फ़्लफ़ के साथ।

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

div.btton को बटन में बदलना चाहिए

कस्टम तत्व

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

मैंने बिना किसी जावास्क्रिप्ट के कस्टम तत्व नामों का उपयोग किए जाने के कई उदाहरण नहीं देखे हैं, लेकिन यह स्पष्ट HTML लिखने के लिए आश्चर्यजनक रूप से ठोस विकल्प साबित हुआ है जो कि जैसा मैं चाहता हूं वैसा दिखता है।

डिज़ाइन के संदर्भ में पूरी तरह से अलग-अलग तत्वों में, समय के साथ, ऐसी आवश्यकताएं विकसित होने की अधिक संभावना होती है जिन्हें केवल जावास्क्रिप्ट के साथ लागू किया जा सकता है, जो आपको उन लोगों को लागू करने के लिए एक स्पष्ट मार्ग देता है जिन्हें HTML में किसी भी बदलाव की आवश्यकता नहीं होती है और न ही सीएसएस.

div.vsep को वर्टिकल-सेपरेटर में बदलना चाहिए

कक्षाओं

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

एक खतरनाक बटन एक बटन है।खतरा

गुण

तत्वों को संशोधित करने के कुछ तरीके सरल ऑन/ऑफ स्विच नहीं हैं जिनके लिए कक्षाएं उपयोगी हैं, बल्कि वे कुंजी-मूल्य जोड़े की तरह व्यवहार करते हैं।

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

हममें से उन लोगों के लिए जिन्हें अभी भी उम्मीद है कि attr() फ़ंक्शन एक दिन केवल सामग्री से अधिक के लिए सीएसएस में अपना रास्ता बना सकता है, यह भविष्य-प्रूफिंग की एक अतिरिक्त परत भी है।

आईडी

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

इस प्रकार, आईडी का उपयोग कम से कम और केवल तभी किया जाना चाहिए जब एक दस्तावेज़ में एक से अधिक तत्व रखने का कोई मतलब नहीं हो।

व्यावहारिक और पठनीयता दोनों अर्थों में कक्षाओं पर लाभ कम हैं, इसलिए कक्षाओं के पक्ष में गलती करना आमतौर पर सबसे अच्छा विचार है जब तत्व और स्टाइल के बीच कोई स्पष्ट 1-से-1 संबंध की पहचान नहीं की जा सकती है।

इनलाइन सीएसएस

किसी भी वास्तविक दुनिया के एप्लिकेशन में कुछ बिंदु पर ऐसे तत्व होंगे जिन्हें जिस संदर्भ में वे दिखाई देते हैं उसमें उन्हें सौंदर्यपूर्ण रूप से अधिक सुखद बनाने के लिए व्यक्तिगत बदलाव की आवश्यकता होती है।

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

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

सीधे शब्दों में कहें तो चौड़ाई: 100px का सार्वभौमिक रूप से परिभाषित अर्थ है, जबकि .width-100 का कुछ भी मतलब हो सकता है।

उपयोगिता वर्ग

बहुत ही दुर्लभ अवसरों पर, तत्व-विशिष्ट शैलियाँ इतनी जटिल हो जाती हैं कि उन्हें स्पष्ट रूप से रेखांकित करना पठनीयता को नुकसान पहुँचाएगा, या असंभव भी है (उदाहरण के लिए यदि इसके लिए मीडिया प्रश्नों की आवश्यकता है)।

इन मामलों में, उपयोगिता वर्ग मूल रूप से एकमात्र विकल्प हैं, भले ही वे बदसूरत हों।

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

मुझे यह दर्शाने के लिए उपयोगिता वर्गों को उपसर्ग करने का विचार पसंद है कि वे तत्व में कुछ प्रकार की कार्यक्षमता जोड़ते हैं, सामान्य वर्गों के विपरीत, जो निर्दिष्ट करते हैं कि तत्व किस प्रकार का है।

लाल फ्लोटिंग बटनबटन>

---

और यह इसके बारे में था। बेशक, कोई भी दो परियोजनाएं एक जैसी नहीं होती हैं, और व्यावहारिक बने रहने के लिए कभी-कभी नियमों को थोड़ा मोड़ना पड़ता है, लेकिन कुल मिलाकर, यह तय करने के लिए मेरी रूपरेखा है कि स्क्रीन पर किसी चीज़ को एक निश्चित तरीके से कैसे दिखाया जाए।

आपके क्या विचार हैं? क्या आप इससे नफरत करते हैं? क्या आपको लगता है इसका कोई मतलब है? मुझे एक टिप्पणी में बताएं?