सीएसएस दर्शन

सभी को नमस्कार! यह घोषणा करने का समय है कि हम फरवरी के अंत से पहले एक नई सीएसएस पुस्तक जारी करने की योजना बना रहे हैं, जो कि उन सभी के लिए अनुशंसित है, जिन्हें पहले से ही मैकफारलैंड में महारत हासिल है (जबकि यह अभी भी उपलब्ध है, हम जनवरी में अगले ओवरपेक्चर करने की योजना बनाते हैं)।

आज आपको कीथ ग्रांट (जून में प्रकाशित) द्वारा एक लेख का अनुवाद करने के लिए आमंत्रित किया गया है, जिसमें लेखक सीएसएस पर अपना दृष्टिकोण निर्धारित करता है और वास्तव में समझाता है कि वह अपनी पुस्तक में क्या बात करना चाहता था। हम पढ़ते हैं और टिप्पणी करते हैं!



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

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

सीएसएस प्रतिरोधी

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

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

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

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

.portfolio { display: grid; grid-template-columns: repeat(auto-fit, minmax(400px, 1fr)); } .portfolio__item { display: inline-block; max-width: 600px; } 

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

"सुरक्षा" व्यवहार की यह घटना सीएसएस के साथ काम करने का एक अभिन्न अंग है, लेकिन यह अधिकांश पारंपरिक प्रोग्रामिंग भाषाओं के लिए विदेशी है।

सीएसएस घोषणात्मक

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

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

आपको बहुत से चरों पर विचार करना होगा। CSS का सार प्रक्रिया को व्यवस्थित करना है ताकि आपको इन सभी चरों के बारे में चिंता न करनी पड़े। प्रतिबंधों की एक प्रणाली को परिभाषित करें। भाषा स्वयं विवरणों का ध्यान रखती है।

सरल उदाहरण है

आइए ऐसे सीएसएस नमूने को देखें: font-size: 2em । यह कोड क्या करता है? "फ़ॉन्ट का आकार बढ़ाता है," आप कहते हैं। लेकिन यह सब नहीं है। यह कंटेनर के अंदर पाठ लाइनों के हाइफ़नेशन को भी ठीक करता है, क्योंकि अब कम शब्द प्रत्येक पंक्ति में फिट होते हैं। तदनुसार, यह अक्सर पाठ लाइनों की संख्या को बढ़ाता है, और कंटेनर की ऊंचाई भी बढ़ाता है ताकि ये नई लाइनें इसमें फिट हो सकें। जब आप कंटेनर की ऊंचाई बदलते हैं, तो इस कंटेनर के नीचे पृष्ठ पर स्थित सभी पाठ उसी के अनुसार बदल जाएंगे। अंत में, उपरोक्त कोड स्थानीय em मान भी सेट करता है। अन्य सभी गुणों का मान जो em इकाइयों को निर्धारित करने के लिए उपयोग किया गया था, em फिर से गणना करना होगा।

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

यदि आप चाहते हैं कि इसमें से कुछ भी न हो, तो आप यह भी कर सकते हैं। आप max-height और overflow: auto साथ कंटेनर की ऊंचाई को गंभीर रूप से सीमित कर सकते हैं overflow: auto गुण। आप आंतरिक मार्जिन को फिर से परिभाषित कर सकते हैं ताकि उन्हें rem या px की इकाइयों में मापा जाए, अर्थात, फ़ॉन्ट आकार के बाद उनकी पुनरावृत्ति न हो। यह सीएसएस के साथ काम करने के एक दिलचस्प पहलू का खुलासा करता है: कभी-कभी आप ब्राउज़र को यह नहीं बताते हैं कि उसे क्या करना चाहिए, लेकिन वास्तव में, इसे कुछ भी करने से मना करें।

ग्रिड के लाभ

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

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

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

सीएसएस संदर्भ संवेदनशील है

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

दूसरा, अधिक सूक्ष्म कारण यह है कि CSS और आपके डिज़ाइन निर्णय दोनों पृष्ठ के संदर्भ पर निर्भर करते हैं। मान लें कि हम एक पृष्ठ पर निम्नलिखित सीएसएस शैलियों को एक तत्व पर लागू करते हैं:

 .the-thing { position: absolute; top: 10px; left: 10px; } 

यह कोड क्या करेगा? बिल्कुल नहीं पता कि यह तत्व DOM के भीतर कहां स्थित है, और बाकी पेज पर कौन से स्टाइल लगाए गए हैं, हम इस सवाल का जवाब नहीं दे सकते हैं। निरपेक्ष प्लेसमेंट निकटतम पूर्वज तत्व के सापेक्ष किया जाता है, और यह स्थिति अलग-अलग निकलेगी, जो इस बात पर निर्भर करता है कि किस प्रकार के पूर्वजों से संबंधित है, और किस प्रकार का प्लेसमेंट इसके लिए लागू किया गया था।

इसके अलावा, आपकी क्षमता (या असंभव) एक दूसरे पर तत्वों को ओवरले करने के लिए काफी हद तक इस बात पर निर्भर करेगी कि ये दो तत्व DOM में कहाँ स्थित हैं। DOM में फेरबदल करने वाले तत्व नाटकीय रूप से तत्वों के लेआउट को प्रभावित कर सकते हैं और वे कैसे ओवरलैप कर सकते हैं। यही कारण है कि दस्तावेज़ प्रवाह और ओवरले संदर्भ मौलिक (यद्यपि कभी-कभी जटिल) विषय होते हैं।

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

उदाहरण के लिए, यदि आप टाइल में से किसी एक पर शीर्षक बढ़ाते हैं, तो यह उपयोगकर्ता के लिए अधिक स्पष्ट हो जाएगा, और इस वजह से, स्क्रीन पर अन्य तत्व कम महत्वपूर्ण प्रतीत होंगे। यहां सीमाएं भौतिकी के विमान में नहीं होती हैं, जैसे कि पुल के निर्माण में; हम अधिक "मानवीय" कानूनों के बारे में बात कर रहे हैं जो मानवीय धारणा को प्रभावित करते हैं। पृष्ठ के तत्व स्क्रीन पर प्रतिबिंबित होते हैं, जिसकी अपनी भौतिक विशेषताएं होती हैं, और काम करते समय भौतिक दुनिया की वास्तविकताओं को ध्यान में रखना आवश्यक होता है और हम इसे कैसे देखते हैं।

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

परिणाम

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