सीएसएस सिद्धांतों

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


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


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


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


मैं अलग से सीएसएस फ़ाइलों और चित्रों की संरचना का उल्लेख करूँगा । चित्रों और teseseski को सही ढंग से वितरित करने के लिए एक हजार और एक तरीके हैं। लेकिन बहुत कम गलत हैं।
सभी भयानक तरीकों में से सबसे भयानक याद रखें - केवल user.css user.css और डैडी छवियों के साथ, मुझे माफ़ करें, वहां शर्मीली। कुछ चतुर लोगों का अनुमान है कि संसाधनों में किसी प्रकार की संरचना होनी चाहिए और उपसर्गों और प्रत्ययों के साथ चित्रों को नाम देना चाहिए। उदाहरण के लिए, " article-bg.png " या " product-li-bg.png "। चलो सीएसएस से दूर जाते हैं और ऐसे डेवलपर की हार्ड ड्राइव की कल्पना करते हैं। फ़िल्में एक ही फ़ोल्डर में हैं, लेकिन वे ऐसी फ़ाइलों को नाम देते हैं, आइए alien_life_documental_discovery.avi हैं: " alien_life_documental_discovery.avi " या " pelmeni_vs_pyatigorsk_kvn_2008_polufinal.avi "। बड़ी संख्या में फ़ाइलों के साथ, इस छोटे से ढेर में नेविगेट करना असंभव है। एक अन्य लेख के लिए पुस्तकालयों (आईट्यून्स, विंडोज मीडिया प्लेयर या इस तरह) के ऑटो-सॉर्टर्स के विषय पर विवाद छोड़ दें
कोई कम भयानक, लेकिन लेआउट के अधिक सटीक रणनीति और लेआउट के दौरान नामकरण इस तरह की स्थिति के रूप में सेवा कर सकते हैं। चित्र एक फ़ोल्डर में स्थित नहीं हैं, लेकिन सबफ़ोल्डर्स में स्थित हैं। सभी प्रकार के बैकग्राउंड को images/bgs में डाला जाता है, आइकन्स images/icons फोल्डर में होते हैं। गलत संसाधन वर्गीकरण के कारण यह विधि असफल है। उपयोग की समानता के द्वारा अलग-अलग चित्रों को नहीं, लेकिन तार्किक समानता द्वारा महान व्यावहारिकता लाएंगे - समाचार से संबंधित सभी चित्रों को images/news bg.png में डाल दिया जाना चाहिए और " bg.png ", " li.png ", " first-item.png " । यह व्यवस्था संसाधनों के बंटवारे की भविष्यवाणी करती है, जिसके परिणामस्वरूप संसाधनों को आसानी से नियंत्रित किया जाता है।
दो अलग-अलग संस्थाओं के लिए छवियों के पुन: उपयोग के बारे में तार्किक प्रश्न बना हुआ है। एक उदाहरण एक डिज़ाइन है जिसमें हाल ही में समाचारों की सूची में एक लाइन उत्पादों की सूची में एक तत्व के रूप में एक ही पृष्ठभूमि है। इस मामले में, कई समाधान हैं। उदाहरण के लिए, पृष्ठभूमि को दो अलग-अलग फ़ोल्डरों के articles और products में दोहराया जा सकता है। यह उसी कारण से किया जाना चाहिए कि उपयोगकर्ता के लिए पासवर्ड में न्यूनतम संख्या और लेख शीर्षक की न्यूनतम लंबाई एक चर नहीं होनी चाहिए। या, एक विकल्प के रूप में, इकाई को एक अधिक सामान्य नाम से बदलें और एक फ़ोल्डर बनाएं articles और news_items , लेकिन किसी भी तरह अधिक सामान्य - publications , या ऐसा कुछ। दो संस्थाओं के बीच एक आम इकाई के लिए नाम चुनने की दुविधा तनावपूर्ण है। एक ही प्रकार की दो अलग-अलग संस्थाओं के मामले में, उन्हें कुछ कसौटी के अनुसार सामान्यीकृत किया जा सकता है, क्योंकि डिजाइनर पहले ही ऐसा कर चुके हैं। "मुख्य पृष्ठ और एक आंतरिक" के अल्प डिजाइन के मामले को हम नैदानिक ​​नहीं मानते हैं।
फ़ाइल स्थानों के लिए एक त्वचा एल्गोरिथ्म भी आम है। इस मामले में, चित्रों के सापेक्ष पथ को सीएसएस-फाइलों के अंदर इंगित किया गया है, और स्टाइल शीट और चित्रों को एक साझा फ़ोल्डर में रखा गया है। उदाहरण के लिए, साइट की जड़ में, themes फ़ोल्डर के अंदर, stylesheets और images फ़ोल्डर बनाएं। यह किसी भी तरह से images फ़ोल्डर के अंदर फ़ोल्डर संरचना को प्रभावित नहीं करता है। कृपया ध्यान दें कि कुछ चौखटे आपकी अपनी शैलियों को एकीकृत करने का एकमात्र तरीका प्रदान करते हैं। इसलिए, लेआउट शुरू करने से पहले रूपरेखा का ज्ञान आवश्यक है। लेकिन यह पूरी तरह से अलग कहानी है।
और सीएसएस फाइलों में, पृष्ठभूमि इस तरह इंगित की जाती है:

 background-image: url(../images/articles/bg.png) 

बजाय निरपेक्ष पथ (जड़ से) का संकेत देने के।

 background-image: url(/images/articles/bg.png) 

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

 <a href="#" onclick="editMe(); return false;"> <p>Lorem ipsum dolor set...</p> </a> 

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

प्रलेखन से : One possible cause for this message is that you have attempted to put a block-level element (such as "<p>" or "<table>") inside an inline element (such as "<a>", "<span>", or "<font>").

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