css - सीएसएस विस्फोट का प्रबंधन




organization (10)

सीएसएस में शीर्षक नहीं लिखें

बस फाइलों में खंडों को विभाजित करें। कोई सीएसएस टिप्पणियां, बस यही होनी चाहिए, टिप्पणियां।

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

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

यदि आपको शीर्षक लिखना है, तो फ़ाइल की शुरुआत में एक टीओसी है

टीओसी में शीर्षलेख आपके द्वारा बाद में लिखने वाले शीर्षकों के बराबर होना चाहिए। शीर्षकों की खोज करना दर्द है। समस्या को जोड़ने के लिए, किसी को भी यह मानने का अनुमान है कि आपके पहले हेडर के बाद आपके पास दूसरा हेडर है? ps। टीओसी लिखते समय प्रत्येक पंक्ति की शुरुआत में डॉक्टर की तरह * (स्टार) को न जोड़ें, यह टेक्स्ट को चुनने के लिए इसे और अधिक परेशान करता है।

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

ब्लॉक के बाहर नहीं, नियमों के साथ या भीतर टिप्पणियां लिखें

सबसे पहले, जब आप स्क्रिप्ट संपादित करते हैं तो 50/50 मौका होता है, आप नियम ब्लॉक के बाहर क्या है (विशेष रूप से यदि यह टेक्स्ट का एक बड़ा ग्लोब है) पर ध्यान देना होगा)। दूसरा, वहां (लगभग) कोई मामला नहीं है जहां आपको बाहर "टिप्पणी" की आवश्यकता होगी। यदि यह बाहर है, तो यह शीर्षक का 99% समय है, इसलिए इसे इस तरह रखें।

पृष्ठ को घटकों में विभाजित करें

अवयवों में position:relative होनी चाहिए position:relative , कोई padding और कोई margin नहीं, अधिकांश समय। यह% नियमों को बहुत सरल बनाता है, साथ ही साथ बहुत सरल absolute:position इजाजत देता है absolute:position तत्वों की absolute:position ', क्योंकि यदि कोई पूर्ण स्थित कंटेनर है तो पूर्ण स्थान तत्व top , right , bottom , left गुणों की गणना करते समय कंटेनर का उपयोग करेगा।

एचटीएमएल 5 दस्तावेज़ में अधिकांश डीआईवी आमतौर पर एक घटक होते हैं।

एक घटक भी कुछ ऐसा है जिसे पृष्ठ पर एक स्वतंत्र इकाई माना जा सकता है। लेमेन के शब्दों में एक घटक की तरह कुछ व्यवहार करें यदि ब्लैकबॉक्स की तरह कुछ इलाज करना समझ में आता है।

क्यूए पेज उदाहरण के साथ फिर से जा रहे हैं:

#navigation
#question
#answers
#answers .answer
etc.

पृष्ठ को घटकों में विभाजित करके, आप अपने काम को प्रबंधनीय इकाइयों में विभाजित करते हैं।

एक ही लाइन पर एक संचयी प्रभाव के साथ नियम रखो।

उदाहरण के लिए border , margin और padding (लेकिन outline नहीं) सभी आपके द्वारा स्टाइल किए गए तत्व के आयामों और आकार में जोड़ते हैं।

position: absolute; top: 10px; right: 10px;

यदि वे सिर्फ एक पंक्ति पर पठनीय नहीं हैं, कम से कम उन्हें निकट निकटता में रखें:

padding: 10px; margin: 20px;
border: 1px solid black;

जब संभव हो तो शॉर्टेंड का प्रयोग करें:

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

एक चयनकर्ता दोहराना कभी नहीं

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

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

चयनकर्ताओं के रूप में TAG का उपयोग करने से बचें, जब आप आईडी / कक्षाओं का उपयोग कर सकते हैं

डीआईवी और स्पैन टैग से पहले अपवाद अपवाद है: आपको कभी भी उनका उपयोग कभी नहीं करना चाहिए! ;) केवल कक्षा / आईडी संलग्न करने के लिए उनका उपयोग करें।

इस...

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

इस तरह लिखा जाना चाहिए:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

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

या यदि आप अधिक स्पष्टता पसंद करते हैं:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

border-collapse संपत्ति होने का कारण एक विशेष संपत्ति है जो किसी table लागू होने पर ही समझ में आता है। यदि .statistics एक table नहीं है तो इसे लागू नहीं करना चाहिए।

सामान्य नियम बुरा हैं!

  • यदि आप कर सकते हैं जेनेरिक / जादू नियम लिखने से बचें
  • जब तक कि यह एक सीएसएस-रीसेट / अनारेट के लिए न हो, तब तक आपके सभी सामान्य जादू को कम से कम एक रूट घटक पर लागू होना चाहिए

वे आपको समय नहीं बचाते हैं, वे आपके सिर को विस्फोट करते हैं; साथ ही रखरखाव एक दुःस्वप्न बनाओ। जब आप नियम लिख रहे हों, तो आप जान सकते हैं कि वे कहां आवेदन करते हैं, हालांकि इस बात की कोई गारंटी नहीं है कि आपका नियम बाद में आपके साथ गड़बड़ नहीं करेगा।

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

इस तरह की सामग्री ...

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

... प्रोग्रामिंग भाषा में वैश्विक चर का उपयोग करने के समान समस्या है। आपको उन्हें दायरा देना होगा!

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

मूल रूप से जो इस प्रकार पढ़ता है:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

जब भी मुझे पता है कि एक घटक एक पृष्ठ पर एक सिंगलटन है, तो मुझे आईडी का उपयोग करना पसंद है; आपकी जरूरतें अलग हो सकती हैं।

नोट: आदर्श रूप से, आपको बस इतना लिखना चाहिए। चुनिंदा में अधिक घटकों का उल्लेख करना हालांकि कम घटकों का उल्लेख करने की तुलना में अधिक क्षमाशील गलती है।

आइए मान लें कि आपके पास एक pagination घटक है। आप इसे अपनी साइट के कई स्थानों पर उपयोग करते हैं। जब आप एक सामान्य नियम लिखेंगे तो यह एक अच्छा उदाहरण होगा। आइए कहें कि आप display:block अलग-अलग पेज नंबर लिंक display:block करें और उन्हें एक गहरा ग्रे पृष्ठभूमि दें। उनके लिए दृश्यमान होने के लिए आपको इस तरह के नियम होना चाहिए:

.pagination .pagelist a {
    color: #fff;
}

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

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

इससे आपके सफेद लिंक काले हो जाएंगे, जिन्हें आप नहीं चाहते हैं।

इसे ठीक करने का गलत तरीका यह है:

.pagination .pagelist a {
    color: #fff !important;
}

इसे ठीक करने का सही तरीका यह है:

#answers .header .pagination .pagelist a {
    color: #fff;
}

जटिल "तर्क" टिप्पणियां काम नहीं करती :)

यदि आप कुछ लिखते हैं: "यह मान ब्लाह-ब्लाह पर निर्भर है, ब्लाह-ब्ला की ऊंचाई के साथ संयुक्त", यह केवल अपरिहार्य है कि आप एक गलती करेंगे और यह सब कार्ड के घर की तरह गिर जाएगी।

अपनी टिप्पणियां सरल रखें; यदि आपको "लॉजिकल ऑपरेशंस" की आवश्यकता है तो उन सीएसएस टेम्पलेटिंग भाषाओं में से एक SASS या LESS तरह विचार करें।

मैं रंगीन फूस कैसे लिखूं?

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

जैसे।

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

विचार सरल है, आपका रंग फूस बेस स्टाइल से स्वतंत्र स्टाइलशीट है, जिसे आप कैस्केड करते हैं।

कम नाम, कोड को पढ़ने में आसान बनाते हुए, कम स्मृति की आवश्यकता होती है

कम नामों का उपयोग करना बेहतर है। आदर्श रूप से बहुत सरल (और संक्षिप्त!) शब्दों का उपयोग करें: पाठ, शरीर, शीर्षलेख।

मुझे सरल शब्दों का संयोजन भी समझना आसान होता है, इसके बाद लंबे "उचित" शब्दों का सूप होता है: पोस्टबॉडी, पोस्टहेड, यूजरइन्फो इत्यादि।

शब्दावली को छोटा रखें, इस तरह यदि कुछ अजनबी आपके स्टाइल-सूप को पढ़ने में आते हैं (जैसे कुछ हफ्तों के बाद खुद को;)) केवल यह समझने की आवश्यकता है कि शब्दों का उपयोग कहां किया जाता है, जहां हर चयनकर्ता का उपयोग किया जाता है। उदाहरण के लिए मैं इसका उपयोग करता हूं .this तब भी होता है जब कोई तत्व माना जाता है कि "चयनित आइटम" या "वर्तमान आइटम" इत्यादि।

अपने आप के बाद साफ करो

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

यदि आपने सुझाव दिया है, तो आपकी शैली में कुछ कंटेनरों को काले-बक्से (घटक) के रूप में माना जाता है, आपके चयनकर्ताओं में उन घटकों का उपयोग किया जाता है, और सबकुछ एक समर्पित फ़ाइल में रखा जाता है (या एक फ़ाइल को टीओसी और हेडर के साथ सही ढंग से विभाजित), फिर आपका काम काफी आसान है ...

आप फ़ायरफ़ॉक्स एक्सटेंशन डस्ट-मी सिलेक्टर (टिप: इसे अपने साइटमैप.एक्सएमएल पर इंगित करें) जैसे टूल का उपयोग कर सकते हैं ताकि आप अपने सीएसएस नूक और कार्नीज़ में छिपे हुए कुछ जंक ढूंढ सकें।

एक unsorted.css फ़ाइल रखें

मान लें कि आप एक क्यूए साइट स्टाइल कर रहे हैं, और आपके पास पहले से ही "उत्तर पृष्ठ" के लिए स्टाइलशीट है, जिसे हम answers.css कॉल करेंगे। यदि आपको अब बहुत सी नई सीएसएस जोड़ने की ज़रूरत है, तो इसे unsorted.css स्टाइलशीट में जोड़ें, फिर अपने answers.css स्टाइलशीट में answers.css प्रतिक्रिया दें।

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

  • आपके समाप्त होने के बाद रीफैक्टर करना तेज़ है, फिर नियमों की खोज करना है (जो शायद मौजूद नहीं है) और कोड इंजेक्ट करें
  • आप उन चीज़ों को लिखेंगे जिन्हें आप हटा देंगे, कोड इंजेक्शन करने से कोड को निकालना मुश्किल हो जाता है
  • मूल फ़ाइल में शामिल होने से आसानी से नियम / चयनकर्ता डुप्लिकेशन होता है

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

लेकिन अब समस्या यह है कि मैंने देखा है कि मुझे "सीएसएस विस्फोट" मिल रहा है। सीएसएस फ़ाइल के भीतर सर्वोत्तम व्यवस्थित करने और अमूर्त डेटा को कैसे तय करना है, यह तय करना मेरे लिए मुश्किल हो रहा है।

मैं वेबसाइट के भीतर बड़ी संख्या में div टैग का उपयोग कर रहा हूं, जो भारी तालिका-आधारित वेबसाइट से आगे बढ़ रहा है। तो मुझे बहुत सारे सीएसएस चयनकर्ता मिल रहे हैं जो इस तरह दिखते हैं:

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

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

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


1. SASS 2. Compass पर एक नज़र डालें


क्या मैं LESS सुझाव दे सकता हूं

जैसा कि पहले उल्लेख किया गया है, यह एसएएसएस के समान है।

यह प्रति अभिभावक वर्ग सीएसएस को बनाए रखने में मदद करता है।

उदाहरण के लिए

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

यह क्या करता है: लागू चौड़ाई: # child1 और # child2 दोनों के लिए 100%।

इसके अलावा, # child1 विशिष्ट सीएसएस # मूल से संबंधित है।

यह प्रस्तुत करेगा

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}

जैसा कि मेरे सामने कहा गया था: ओओसीएसएस में जाओ। सास / कम / कम्पास उपयोग करने के लिए मोहक है, लेकिन जब तक वेनिला सीएसएस का सही तरीके से उपयोग नहीं किया जाता है तब तक सास / कम / कम्पास केवल चीजों को और खराब कर देगा।

सबसे पहले, कुशल सीएसएस के बारे में पढ़ें। Google पेज स्पीड आज़माएं और पढ़ें कि सउडर्स ने कुशल सीएसएस के बारे में क्या लिखा है।

फिर, ओओसीएसएस दर्ज करें।

  • कैस्केड के साथ काम करना सीखें। (आखिरकार, हम इसे कैस्केडिंग स्टाइलशीट कहते हैं)।
  • जानें कि ग्रैन्युलरिटी सही कैसे प्राप्त करें (ऊपर-नीचे की बजाय नीचे-ऊपर)
  • Learn how to separate structure and skin (what is unique, and what are the variations of these objects?)
  • Learn how to separate container and content.
  • Learn to love grids.

It will revolutionize every single bit about writing css. I am totally renewed and love it.

UPDATE: SMACSS is similar to OOCSS, but easier to adapt generally speaking.


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

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

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

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

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

ग्राहक की विशिष्ट ज़रूरतों का विश्लेषण करने के लिए आप पर निर्भर है, तदनुसार इन चिंताओं को संतुलित करें।


यह एक बहुत अच्छा सवाल है। जहां भी मैं देखता हूं, सीएसएस फाइलें कुछ समय बाद नियंत्रण से बाहर हो जाती हैं - खासकर, लेकिन न केवल एक टीम में काम करते समय।

निम्नलिखित नियम हैं जिन्हें मैं स्वयं का पालन करने की कोशिश कर रहा हूं (ऐसा नहीं कि मैं हमेशा प्रबंधन करता हूं।)

  • जल्दी रिफैक्टर, अक्सर प्रतिक्रियाक। अक्सर सीएसएस फाइलों को साफ करें, एक ही कक्षा की कई परिभाषाओं को एक साथ फ्यूज करें। अप्रचलित परिभाषा तुरंत हटा दें।

  • बग फिक्सिंग के दौरान सीएसएस जोड़ते समय, एक टिप्पणी छोड़ दें कि परिवर्तन क्या करता है ("यह सुनिश्चित करना है कि बॉक्स आईई <7 में गठबंधन छोड़ दिया गया है)

  • अनावश्यकता से बचें, उदाहरण के लिए .classname और .classname:hover में एक ही चीज़ को परिभाषित करना।

  • स्पष्ट संरचना बनाने के लिए टिप्पणियों /** Head **/ का उपयोग करें।

  • एक प्रीटीफायर टूल का उपयोग करें जो स्थिर शैली को बनाए रखने में मदद करता है। मैं Polystyle उपयोग करता Polystyle , जिसके साथ मैं काफी खुश हूं ($ 15 खर्च करता है लेकिन पैसा अच्छी तरह बिताया जाता है)। मुझे यकीन है कि आस-पास के आसपास भी मुफ्त हैं (अपडेट: उदाहरण के लिए सीएसएस टिडी पर आधारित कोड ब्यूटीफायर , एक ओपन-सोर्स टूल जिसका मैंने अभी तक उपयोग नहीं किया है लेकिन बहुत दिलचस्प लग रहा है।)

  • समझदार कक्षाएं बनाएं। इस पर कुछ नोट्स के लिए नीचे देखें।

  • अर्थशास्त्र का प्रयोग करें, डीआईवी सूप से बचें - उदाहरण के लिए मेनू के लिए <ul> s का उपयोग करें।

  • यथासंभव कम स्तर पर सबकुछ परिभाषित करें (उदाहरण के लिए body में एक डिफ़ॉल्ट फ़ॉन्ट परिवार, रंग और आकार) और जहां संभव हो वहां inherit उपयोग करें

  • यदि आपके पास बहुत जटिल सीएसएस है, तो शायद एक सीएसएस प्री-कंपाइलर मदद करता है। मैं जल्द ही उसी कारण के लिए xCSS में देखने की योजना बना रहा हूं। चारों ओर कई अन्य हैं।

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

  • यदि एक टीम में काम करना है , तो संस्करण नियंत्रण का उपयोग करने पर विचार करें। यह उन चीज़ों को बनाता है जो ट्रैक करना बहुत आसान है, और उन संघर्षों को संपादित करना जो हल करना बहुत आसान है। यह वास्तव में इसके लायक है, भले ही आप HTML और CSS में "बस" हों।

  • साथ काम न करें !important । न केवल इसलिए कि IE = <7 इसके साथ सौदा नहीं कर सकता है। एक जटिल संरचना में, महत्वपूर्ण उपयोग अक्सर उस व्यवहार को बदलने के लिए प्रेरित होता है जिसका स्रोत नहीं मिल सकता है, लेकिन यह दीर्घकालिक रखरखाव के लिए जहर है

समझदार कक्षाओं का निर्माण

इस तरह मैं समझदार वर्गों को बनाना पसंद करता हूं।

मैं पहले वैश्विक सेटिंग्स लागू करता हूं:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

फिर, मैं पृष्ठ के लेआउट के मुख्य अनुभागों की पहचान करता हूं - उदाहरण के लिए शीर्ष क्षेत्र, मेनू, सामग्री और पाद लेख। अगर मैंने अच्छा मार्कअप लिखा है, तो ये क्षेत्र एचटीएमएल संरचना के समान होंगे।

फिर, मैं सीएसएस कक्षाओं का निर्माण शुरू करता हूं, जितना संभव हो सके उतना वंश और समझदार, और संबंधित वर्गों को समूहीकृत करना।

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

पूरे सीएसएस संरचना को एक वृक्ष के रूप में सोचें जो आपके द्वारा जड़ से आगे की विशिष्ट परिभाषाओं को दूर करता है। आप कक्षाओं की संख्या को यथासंभव कम रखना चाहते हैं, और आप जितना संभव हो उतना ही खुद को दोहराना चाहते हैं।

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

सबसे पहले, सामान्य विशेषताओं को menu नामक वर्ग में परिभाषित करें:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

फिर, तीनों मेनू में से प्रत्येक की विशिष्ट विशेषताओं को परिभाषित करें। स्तर 1 40 पिक्सेल लंबा है; स्तर 2 और 3 20 पिक्सल।

नोट: आप इसके लिए कई कक्षाओं का भी उपयोग कर सकते हैं लेकिन इंटरनेट एक्सप्लोरर 6 में कई कक्षाओं के साथ समस्याएं हैं , इसलिए यह उदाहरण id एस का उपयोग करता है।

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

मेनू के लिए मार्कअप इस तरह दिखेगा:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

यदि आपके पास पृष्ठ पर अर्थात् समान तत्व हैं - जैसे कि इन तीन मेनू - पहले समानताओं को काम करने और उन्हें कक्षा में रखने का प्रयास करें; फिर, विशिष्ट गुणों को तैयार करें और उन्हें कक्षाओं में लागू करें या, यदि आपको इंटरनेट एक्सप्लोरर 6, आईडी का समर्थन करना है।

विविध HTML युक्तियाँ

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

  • यदि संभव हो, तो प्रत्येक पृष्ठ के शरीर को एक अनूठी कक्षा दें: <body class='contactpage'> इससे स्टाइल शीट में पृष्ठ-विशिष्ट tweaks जोड़ना बहुत आसान हो जाता है:

    body.contactpage div.container ul.mainmenu li { color: green }
    
  • मेनू स्वचालित रूप से बनाते समय, अधिक स्टाइल को बाद में व्यापक स्टाइलिंग की अनुमति देने के लिए जितना संभव हो उतना सीएसएस संदर्भ जोड़ें। उदाहरण के लिए:

    <ul class="mainmenu">
     <li class="item_first item_active item_1"> First item </li> 
     <li class="item_2"> Second item </li> 
     <li class="item_3"> Third item </li> 
     <li class="item_last item_4"> Fourth item </li> 
    </ul>
    

    इस तरह, प्रत्येक मेन्यू आइटम को इसके अर्थपूर्ण संदर्भ के अनुसार स्टाइल के लिए एक्सेस किया जा सकता है: चाहे यह सूची में पहला या आखिरी आइटम हो; चाहे वह वर्तमान में सक्रिय आइटम है; और संख्या से।

ध्यान दें कि ऊपर दिए गए उदाहरण में उल्लिखित कई वर्गों का यह असाइनिंग IE6 में ठीक से काम नहीं करता है । आईई 6 को कई वर्गों से निपटने में सक्षम बनाने के लिए एक workaround है; मैंने अभी तक यह कोशिश नहीं की है लेकिन डीन एडवर्ड्स से आने वाले बहुत ही आशाजनक दिखते हैं। तब तक, आपको उस वर्ग को सेट करना होगा जो आपके लिए सबसे महत्वपूर्ण है (आइटम नंबर, सक्रिय या पहले / आखिरी) या आईडी का उपयोग करने का सहारा लेना होगा। (आईई 6 बूओ!)


CSS ब्लोट का मुकाबला करने के लिए मैंने देखा सबसे अच्छा तरीका ऑब्जेक्ट ओरिएंटेड सीएसएस सिद्धांतों का उपयोग कर रहा है।

वहाँ एक OOCSS ढांचा भी है जो बहुत अच्छा है।

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

यहां महत्वपूर्ण बात यह है कि 'ऑब्जेक्ट्स' या अपनी साइट और उनके साथ आर्किटेक्ट में ब्लॉक पैटर्न बनाने की पहचान करें।

फेसबुक ने अपने फ्रंट एंड कोड (एचटीएमएल / सीएसएस) में बहुत सी बचत प्राप्त करने के लिए ओओसीएसएस, निकोल सुलिवान के निर्माता को नियुक्त किया। हां, आप वास्तव में न केवल अपने सीएसएस में बचत प्राप्त कर सकते हैं, बल्कि आपके एचटीएमएल में भी, जो इसकी आवाज़ से आपके लिए बहुत संभव है, जैसा कि आप table आधारित लेआउट को बहुत सारे div में परिवर्तित करने का उल्लेख करते हैं

ओओसीएसएस के कुछ पहलुओं में एक और शानदार दृष्टिकोण समान है, शुरुआत के लिए स्केलेबल और मॉड्यूलर होने के लिए अपने सीएसएस को योजना और लिखना है। जोनाथन स्नूक ने SMACSS बारे में एक शानदार लेखन और पुस्तक / ईबुक किया है SMACSS

मुझे आपको कुछ लिंक के साथ हुक करने दें:
विशाल सीएसएस की 5 गलतियों - (वीडियो)
विशाल सीएसएस की 5 गलतियों - (स्लाइड)
सीएसएस ब्लोट - (स्लाइड)


A lot of times I will see individuals break the file out into sections, with a heading comment between sections.

कुछ इस तरह

/* Headings and General Text */

.... stuff here for H1, etc..

/* Main page layout */

.... stuff here for layout page setup etc.

It works pretty well and can make it easy to go back later and find what you are working on.


The core principles for sensible CSS, extracted from CSS Refactoring: From append-only to modular CSS

Write in SASS. You'd be insane to forego the advantages of variables, mixins, and so on.

Never use an HTML ID for styling; always use classes . HTML IDs, when used correctly, appear only once in the whole page, which is the complete opposite of re-usability — one of the most basic goods in sensible engineering. Moreover, it's really hard to override selectors containing IDs and often the only way to overpower one HTML ID is to create another ID, causing IDs to propagate in the codebase like the pests they are. Better to leave the HTML IDs for unchanging Javascript or integration test hooks.

Name your CSS classes by their visual function rather than by their application-specific function. For example, say ".highlight-box" instead of ".bundle-product-discount-box". Coding in this way means that you can re-use your existing style-sheets when you role out side-businesses. For example, we started out selling law notes but recently moved into law tutors. Our old CSS classes had names like ".download_document_box", a class name that makes sense when talking about digital documents but would only confuse when applied to the new domain of private tutors. A better name that fits both existing services — and any future ones — would be ".pretty_callout_box".

Avoid naming CSS classes after specific grid information. There was (and still is) a dreadful anti-pattern in CSS communities whereby designers and creators of CSS frameworks (cough Twitter Bootstrap ) believe that "span-2" or "cols-8" are reasonable names for CSS classes. The point of CSS is to give you the possibility to modify your design without affecting the markup (much). Hardcoding grids sizes into the HTML thwarts this goal, so it is advised against in any project expected to last longer than a weekend. More on how we avoided grid classes later.

Split your CSS across files . Ideally you would split everything into "components"/"widgets" and then compose pages from these atoms of design. Realistically though, you'll notice that some of your website pages have idiosyncrasies (eg a special layout, or a weird photo gallery that appears in just one article). In these cases you might create a file related to that specific page, only refactoring into a full-blown widget when it becomes clear that the element will be re-used elsewhere. This is a tradeoff, one that is motivated by practical budgetary concerns.

Minimise nesting. Introduce new classes instead of nesting selectors. The fact that SASS removes the pain of repeating selectors when nesting doesn't mean that you have to nest five levels deep. Never over-qualify a selector (eg don't use "ul.nav" where ".nav" could do the same job.) And don't specify HTML elements alongside the custom class name (eg"h2.highlight"). Instead just use the class name alone and drop the base selector (eg the previous example should be ".highlight"). Over-qualifying selectors doesn't add any value.

Create styles for HTML elements (eg "h1") only when styling base components which should be consistent in the whole application. Avoid broad selectors like "header ul" because it's likely that you have to override them in some places anyway. As we keep saying, most of the time you want to use a specific, well-named class whenever you want a particular style.

Embrace the basics of Block-Element-Modifier. You can read about it for example on here. We used it quite lightly, but still it helped us a lot in organising CSS styles.


You should look at BEM .

Theory

BEM is an attempt to provide a set of instructions for organising and naming css selectors in an attempt to make things more re-usable and modular and to avoid clashes between selectors of the sort that often leads to spaghetti code and specificity headaches.

When it's used correctly it actually has some very positive effects.

  • Styles do what you expect when they're added to an element
  • Styles don't leak and effect only what they're added to
  • Styles are completely decoupled from document structure
  • Styles don't need to be forced to over-ride each other

BEM works well with SASS to bring an almost object oriented style to CSS. You can build modular files, that handle the display of a single UI element and contain variables, such as colours and 'methods' such as how internal elements are handled. While a hardcore OO programmer might balk at this idea, in fact, the applied concepts bring in a lot of the nicer parts of OO structures, such as modularity, loose coupling and tight cohesion and context free re-usability. You can even build in a way that looks like an encapsulated object by using Sass and the & operato r.

A more in depth article from Smashing Magazine can be found here ; and one from Harry Roberts of CCS Wizardry (who anyone involved in css should have a read of) is here .

In Practice

I've used this, several times, along with having used SMACSS and OOCSS meaning I have something to compare them too. I've also worked in some big messes, often of my own, inexperienced creation.

When I use BEM in the real world I augment the technique with a couple of extra principles. I utilise utility classes - a good example is a wrapper class:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

And I also rely somewhat on the cascade and specificity. Here the BEM module would be .primary-box and the .header would be the context for a specific over-ride

.header {
  .primary-box {
    color: #000;
  }
}

(I try my hardest to make everything as generic and context free as possible, meaning a good project almost everything is in the modules which are re-usable)

One final point I'd make here is that however small and un-complex your project may appear you should do this from the start, for two reasons:

  • projects increase in complexity, so laying good foundations is important, css included
  • even a project that appears simple because it's built on WordPress has little JavaScript can still be very complex in the CSS - OK, you don't have to do any server side coding, so that part is simple, but the brochure-wear front end has twenty modules and three variations of each: you've got some very complex css there!

Web Components

In 2015 we are starting to look at Web Components. I don't know a huge amount about these yet, but they look to bring all front end functionality together in self contained modules, effectively trying to apply the sorts of principles from BEM to the front end as a whole and componentise dispersed but wholly coupled elements such as DOM fragments, Js (MVC) and CSS that all build the same UI widget.

By doing this theyb will address some of the original issues that exist with css which we've tried to solve with things like BEM, while along the way making some of the other front end architecture more sane.

There's some further reading here and also a framework Polymer here which is well worth a look

Finally

I also think this is an excellent, modern best practice css guide - designed specifically for stopping large css projects from getting messy. I try to follow most of these.





organization