एकल विशाल .css फ़ाइल बनाम एकाधिक छोटी विशिष्ट .css फ़ाइलें? [बन्द है]

Question

वहाँ एक एकल राक्षस .css फ़ाइल है कि शैली तत्व है कि लगभग हर पृष्ठ पर इस्तेमाल किया जाएगा होने का कोई फायदा है?

मैं सोच रहा हूं कि प्रबंधन में आसानी के लिए, मैं विभिन्न प्रकार के CSS को कुछ फाइलों में खींचना चाहता हूं, और मेरे मुख्य में हर फाइल को शामिल करना <link />क्या यह बुरा है?

मैं सोच रहा हूं कि यह बेहतर है

1. positions.css
2. buttons.css
3. tables.css
4. copy.css

बनाम

1. site.css

क्या आपने किसी भी तरह से एक के बाद एक बनाम के साथ देखा है?

Comments

यह वास्तव में एक पुराना सवाल है, लेकिन उसी समस्या का सामना करते हुए मैंने पाया कि मुझे लगता है कि यह सबसे अच्छा समाधान है , अगर इस पृष्ठ पर कोई और मिलता है। कई फाइलें जो PHP के साथ संपीड़ित होती हैं और एक अनुरोध के माध्यम से भेजी जाती हैं।

— फ्रांसिस्को प्रेसेनिया

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

— चेस फ्लोरल

यह केवल हर बार सीएसएस बदले जाने पर चलाया जाएगा, और फिर आपको परिणामस्वरूप सीएसएस फ़ाइल को शामिल करना होगा।

— फ्रांसिस्को प्रेसेंसिया

Answer 1

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

Sass और LESS के पास वेरिएबल्स, नेस्टिंग और अन्य तरीकों का अतिरिक्त लाभ है, जिससे CSS को लिखने और बनाए रखने में आसानी होती है। अत्यधिक, अत्यधिक की सिफारिश की। मैं व्यक्तिगत रूप से अब Sass (SCSS सिंटैक्स) का उपयोग करता हूं, लेकिन पहले LESS का उपयोग करता था। दोनों महान हैं, समान लाभ के साथ। एक बार जब आपने सीएसएस को संकलक के साथ लिखा है, तो यह संभावना नहीं है कि आप एक के बिना करना चाहते हैं।

http://lesscss.org

http://sass-lang.com

यदि आप रूबी के साथ गड़बड़ नहीं करना चाहते हैं, तो मैक के लिए यह कम संकलक महान है:

http://incident57.com/less/

या आप CodeKit (उसी लोगों द्वारा) का उपयोग कर सकते हैं:

http://incident57.com/codekit/

WinLess कमज़ोर करने के लिए एक Windows GUI है

http://winless.org/

Comments

यहाँ मेरे स्वीकृत उत्तर को बदलना, क्योंकि यह वास्तव में इन दिनों जाने का रास्ता है। जब मैंने मूल रूप से पूछा तो मुझे ऐसा नहीं लग रहा है कि सास या लेस ने वास्तव में अभी तक नहीं लिया है।

— नैट

Answer 2

इसका उत्तर देना कठिन है। दोनों विकल्पों में मेरे विचार में उनके पक्ष और विपक्ष हैं।

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

मेरी राय दो चीजों में से एक होगी।

1) यदि आप जानते हैं कि आपके सीएसएस को बदलने से पहले आपने इसे बदल दिया है, तो मैं विकास चरण में (पठनीयता के लिए) कई सीएसएस फ़ाइलों का निर्माण करूंगा, और फिर लाइव (http अनुरोधों को कम करने के लिए) लाइव होने से पहले उन्हें मैन्युअल रूप से संयोजित करूंगा।

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

या तो विकल्प के साथ मैं अत्यधिक http अनुरोधों को कम करने के लिए क्लाइंट पक्ष पर कैशिंग की सिफारिश करूंगा।

संपादित करें:
मुझे यह ब्लॉग मिला जो दिखाता है कि सीएसएस को रनटाइम के अलावा कुछ और नहीं बल्कि कोड का उपयोग कैसे किया जाता है। एक नज़र डालने के लायक (हालांकि मैंने इसे अभी तक खुद परखा नहीं है)।

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

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

Comments

कम HTTP अनुरोधों के अलावा, एकल अखंड फ़ाइल का कोई लाभ है? मेरा सीएसएस समय के साथ बदल सकता है, लेकिन उपयोगकर्ताओं की संख्या काफी कम होगी, जो उच्च गति कनेक्शन के माध्यम से सबसे अधिक पहुंच वाले होंगे। इसलिए मुझे लगता है कि कई फ़ाइलों का लाभ कम http अनुरोधों से कहीं अधिक होगा ...

— नैट

कम HTTP अनुरोध का कारण है। आगंतुकों को बनाए रखना प्राथमिकता # 1 है, इसलिए यदि आपका पृष्ठ धीमा है, तो उनके ठहरने की संभावना कम है। यदि आपके पास गठबंधन करने की क्षमता है (मुझे लगता है कि आप asp.net का उपयोग कर रहे हैं) तो मैं इसे करने की अत्यधिक सलाह दूंगा। यह दोनों दुनिया में सबसे अच्छा है।

— फ्लोरेल

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

— इस्ले आर्डवार्क

आप अलग-अलग स्टाइल शीट के साथ सुविधाओं का निर्माण और परीक्षण कर सकते हैं और उन्हें एक निर्माण के समय में एक मोंगो में जोड़ सकते हैं। इस तरह आप एक mongo फाइल नहीं बल्कि कई छोटी फाइल को बनाए रख रहे हैं। हम ऐसा करने के साथ ही व्हाट्सएप और टिप्पणियों के सभी को संक्षिप्त करते हैं जो मनुष्यों को पढ़ने में आसान बनाते हैं लेकिन आपके वेब पृष्ठों के लिए अर्थहीन हैं।

— कोई वापसी नहीं

यह जवाब अब अद्यतन किया जाएगा कि http2 कम अनुरोधों के लाभ को कम करता है।

— डीडी।

Answer 3

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

Comments

@ रैंडी साइमन - लेकिन क्या होगा अगर हम हमेशा सीधे ftp पर css एडिट करते हैं।

— जितेंद्र व्यास

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

— रैंडी साइमन

@RandySimon YUI कंप्रेसर लिंक टूट गया है।

— सुधार

Answer 4

आप दोनों दुनिया चाहते हैं।

आप कई सीएसएस फ़ाइलें चाहते हैं क्योंकि आपकी पवित्रता बर्बाद करने के लिए एक भयानक बात है।

उसी समय, एकल, बड़ी फ़ाइल होना बेहतर है।

समाधान में कुछ तंत्र है जो एक फाइल में कई फाइलों को मिलाता है।

एक उदाहरण कुछ इस तरह है

<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />

फिर, allcss.php स्क्रिप्ट फाइलों को समेटने और उन्हें डिलीवर करने का काम संभालती है।

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

यह आपको दोनों दुनिया का सर्वश्रेष्ठ देता है। जेएस के लिए भी बढ़िया काम करता है।

Comments

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

— चेस फ्लोरल

@ChaseFlorell - तुम सिर्फ संपीड़न / यह एक बार minification और कैश करना

— Siler

@ बॉयलर, मुझे पता है, इसीलिए मैंने अपना जवाब पोस्ट किया है। stackoverflow.com/a/2336332/124069

— चेस फ्लोरल

Answer 5

आपके पृष्ठों के लोडिंग-टाइम के लिए केवल एक सीएसएस फाइल रखना बेहतर है, क्योंकि इसका मतलब है HTTP अनुरोध कम।

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

तो, दोनों मामलों में अच्छे कारण हैं ...

एक समाधान जो आपको दोनों विचारों में से सबसे अच्छा करने की अनुमति देगा:

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

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

Answer 6

ऐतिहासिक रूप से, एक सीएसएस फ़ाइल होने में मुख्य लाभ x में से एक HTTP1.1 का उपयोग करते समय गति लाभ है।

हालांकि, मार्च 2018 तक 80% से अधिक ब्राउज़र अब HTTP2 का समर्थन करते हैं जो ब्राउज़र को एक साथ कई संसाधनों को डाउनलोड करने की अनुमति देता है और साथ ही संसाधनों को पहले से खाली करने में सक्षम बनाता है। सभी पृष्ठों के लिए एक एकल सीएसएस फ़ाइल होने का अर्थ है आवश्यक फ़ाइल आकार से बड़ा। उचित डिजाइन के साथ, मुझे इसके कोड को आसान बनाने के अलावा अन्य करने में कोई फायदा नहीं दिखता है।

सबसे अच्छा प्रदर्शन के लिए HTTP2 के लिए आदर्श डिजाइन होगा:

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

Comments

यह स्वीकृत आधुनिक उत्तर आरई प्रदर्शन होना चाहिए। कुछ अन्य उत्तर पुराने हैं।

— SparrwHawk

यदि आप एक एसपीए (एकल पृष्ठ ऐप) का निर्माण कर रहे हैं, तो मैं सबसे अच्छा डिजाइन यह तर्क दूंगा कि आपके सभी सीएसएस और जेएस को दो पूर्ण फाइलों में बनाया जाए। "app.js" और "seller.js" सभी html, और स्टाइल्स को JS को वेंडर में इनलाइन पर संकलित किया गया है। इसका मतलब है कि "bootstrap.css और bootstrap.js" सभी विक्रेता में हैं। js और इसे sourcemaps के साथ छोटा किया जाता है। vendor.min.js "। एप्लिकेशन के साथ एक ही बात है, सिवाय अब आप जेएस इनलाइन ट्रांसपिलर के लिए एक एचटीएमएल का उपयोग करते हैं, यहां तक ​​कि आपके एप्लिकेशन एचटीएमएल जेएस फ़ाइल में भी हैं। आप उन्हें एक CDN पर होस्ट कर सकते हैं और ब्राउज़र उन्हें कैश करेंगे। तुम भी शैलियों और जे एस में छवियों को संकलित कर सकते हैं।

— रयान मान

Answer 7

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

यह IE के सभी संस्करणों के लिए है।

देखें रॉस Bruniges ब्लॉग और MSDN AddRule पेज ।

Answer 8

एक टिपिंग बिंदु है जिस पर एक से अधिक सीएसएस फ़ाइल रखना फायदेमंद है।

1M + पृष्ठों वाली एक साइट, जिसका औसत उपयोगकर्ता कभी भी केवल 5 में से देखने की संभावना रखता है, इसमें अपार अनुपात की एक स्टाइलशीट हो सकती है, इसलिए एक बड़े प्रारंभिक डाउनलोड के द्वारा प्रति पृष्ठ लोड पर एक अतिरिक्त अनुरोध के ओवरहेड को बचाने की कोशिश करना गलत है। अर्थव्यवस्था।

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

प्रत्येक साइट के लिए टिपिंग बिंदु अलग-अलग होगा, हालांकि कोई कठिन और तेज़ नियम नहीं है। यह प्रति पृष्ठ अद्वितीय सीएसएस की मात्रा, पृष्ठों की संख्या और उन पृष्ठों की संख्या पर निर्भर करेगा जो साइट का उपयोग करते समय औसत उपयोगकर्ता की औसत संख्या की संभावना है।

Comments

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

— डोमिनिक पी

Answer 9

मेरे पास आमतौर पर मुट्ठी भर सीएसएस फाइलें हैं:

• रीसेट और वैश्विक शैलियों के लिए एक "वैश्विक" सीएसएस फ़ाइल
• "मॉड्यूल" पृष्ठों के लिए विशिष्ट सीएसएस फाइलें जो तार्किक रूप से समूहीकृत हैं (शायद चेकआउट विज़ार्ड या हर चीज में हर पेज)
• पृष्ठ पर ओवरराइड के लिए "पेज" विशिष्ट सीएसएस फाइलें (या, व्यक्तिगत पृष्ठ पर इसे ब्लॉक में रखें)

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

Comments

यह वही है जो मैं करता हूं, और यह मेरे लिए अच्छा काम कर रहा है। आपको प्रत्येक पृष्ठ के लिए 3 सीएसएस फाइलें मिलती हैं, जो बहुत ही उचित है

— रिकार्डो न्यून्स

Answer 10

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

Comments

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

— चेस फ्लोरल

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

— रॉबस्टो

साइट गति का परीक्षण करने के लिए उपयोग करने के लिए एक महान उपकरण YSlow के साथ संयोजन के रूप में Firebug है। इससे आपको अपनी साइट की गति का सटीक प्रतिनिधित्व मिल सकता है।

— फ्लोरल फेल

Answer 11

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

Answer 12

यहाँ सबसे अच्छा तरीका है:

1. सभी साझा कोड के साथ एक सामान्य सीएसएस फ़ाइल बनाएं
2. टैग पर या प्रत्येक पृष्ठ के लिए विशेषता शैली = "" का उपयोग करके एक ही पृष्ठ में सभी विशिष्ट पृष्ठ सीएसएस कोड डालें

इस तरह से आपके पास सभी साझा कोड और एक html पृष्ठ के साथ केवल एक सीएसएस है। वैसे (और मुझे पता है कि यह सही विषय नहीं है) आप अपनी छवियों को बेस 64 में भी एन्कोड कर सकते हैं (लेकिन आप इसे अपने जेएस और सीएसएस फ़ाइलों के साथ भी कर सकते हैं)। इस तरह आप 1 से भी अधिक http अनुरोधों को कम करते हैं।

Answer 13

SASS और LESS यह सब वास्तव में एक म्यूट पॉइंट बनाते हैं। डेवलपर प्रभावी घटक फ़ाइलों को सेट कर सकता है और उन सभी को संकलित कर सकता है। SASS में आप आसानी से पढ़ने के लिए विकास में कंप्रेस्ड मोड को बंद कर सकते हैं और उत्पादन के लिए इसे वापस टॉगल कर सकते हैं।

http://sass-lang.com http://lesscss.org

अंत में एक एकल सीमांकित सीएसएस फ़ाइल वह है जो आप उस तकनीक की परवाह किए बिना चाहते हैं। कम सीएसएस, कम HTTP अनुरोध, सर्वर पर कम मांग।

Answer 14

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

मैं अपने सीएसएस को HTTP हेडर में "टेक्स्ट / सीएसएस" माइम प्रकार के साथ एक PHP फ़ाइल के रूप में सेवा करता हूं। इस तरह मेरे पास सर्वर साइड पर कई सीएसएस फाइलें हो सकती हैं और यूजर द्वारा अनुरोध किए जाने पर PHP में उन्हें एक ही फाइल में धकेलना शामिल है। प्रत्येक आधुनिक ब्राउज़र सीएसएस कोड के साथ .php फ़ाइल प्राप्त करता है और इसे .css फ़ाइल के रूप में संसाधित करता है।

Comments

तो अगर मैं ASP.NET का उपयोग कर रहा हूँ। एक .XX जेनेरिक हैंडलर जाने के लिए आदर्श मार्ग होगा, जो दोनों दुनिया के सर्वश्रेष्ठ को प्राप्त करने के लिए उन्हें एक फाइल में जोड़ता है?

— नैट

हां, मैं आपके सीएसएस को रनटाइम पर संयोजित करने के लिए एक IHttpHandler का उपयोग करूंगा (ऊपर मेरे उत्तर में # 2 देखें)

— 18

@ नैट: जब मैं ASP.Net में काम कर रहा था तो हमने उसी चीज़ को पूरा करने के लिए टेम्पलेट फ़ाइलों का उपयोग किया।

— रॉबस्टो

@ रोबो, क्या आप बता सकते हैं कि टेम्पलेट फ़ाइल क्या है? मुझे नहीं लगता कि मैंने कभी इसके बारे में सुना है। मैंने App_Themes का उपयोग किया है, लेकिन यह अभी भी CSS को संयोजित नहीं करता है।

— चेस फ्लोरल

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

— चेस फ्लोरल

Answer 15

आप प्रदर्शन के लिए बस एक सीएसएस फ़ाइल का उपयोग कर सकते हैं और फिर इस तरह से अनुभागों पर टिप्पणी कर सकते हैं:

/******** Header ************/
//some css here

/******* End Header *********/


/******** Footer ************/
//some css here

/******* End Footer *********/

आदि

Comments

इसे बनाए रखना आसान नहीं है, क्योंकि मुझे अभी भी असंबंधित सीएसएस के माध्यम से स्क्रॉल करने की आवश्यकता है जो मुझे मिल रहा है ...

— नैट

@ नैट: क्या आपने सभ्य खोज कार्यक्षमता वाले टेक्स्ट एडिटर पर स्विच करने पर विचार किया है? मेरी व्यक्तिगत प्राथमिकता एक एकल सीएसएस फ़ाइल है और मैं इसके माध्यम से कभी स्क्रॉल नहीं करता। मैं सिर्फ "/ classname" टाइप करता हूं (मैं एक vi व्युत्पन्न का उपयोग करता हूं) और bam - मैं उस कक्षा में हूं।

— डेव शेरोहमान

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

— रॉबस्टो

यदि आप जिस वर्ग की तलाश कर रहे हैं उसका नाम याद नहीं है तो क्या होगा? या आप कैसे तय करते हैं कि एक नया वर्ग कहां जोड़ा जाए?

— नैट

अगर यह सिर्फ एक युगल पृष्ठ वेबसाइट है, तो यह वास्तव में एक सौदे का बड़ा हिस्सा नहीं है। बस चीजों को करने का एक और तरीका सुझा रहे हैं।

— कैटफ़िश

Answer 16

मैं अपनी css फ़ाइलों से निपटने के लिए और पठनीयता के लिए कई अलग-अलग फ़ाइलों का उपयोग करने के लिए Jammit का उपयोग कर रहा हूँ । Jammit उत्पादन में तैनाती से पहले फ़ाइलों के संयोजन और संपीड़ित करने के सभी गंदे काम करता है। इस तरह, मुझे विकास में कई फाइलें मिली हैं लेकिन उत्पादन में केवल एक ही फाइल है।

Answer 17

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

देखें: https://benfrain.com/css-performance-revisited-selectors-bloat- सस्ती-tyles/

बंडल स्टाइलशीट के फायदे: - पेज लोड प्रदर्शन

बंडल किए गए स्टाइलशीट नुकसान: - धीमा व्यवहार, जो स्क्रॉलिंग, अन्तरक्रियाशीलता, एनीमेशन के दौरान तड़प पैदा कर सकता है,

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

यह जानने के लिए कि प्रति पेज कौन से साझा किए गए घटकों की आवश्यकता है, और जटिलता को कम करने के लिए, उन सभी घटकों को घोषित करना अच्छा होगा जो इस विशेष पृष्ठ का उपयोग करते हैं - उदाहरण के लिए:

<style href="global.css" rel="stylesheet"/>
<body data-shared-css-components="x,y,z">

Answer 18

मैंने CSS विकास के लिए एक व्यवस्थित दृष्टिकोण बनाया है। इस तरह मैं एक मानक का उपयोग कर सकता हूं जो कभी नहीं बदलता है। पहले मैंने 960 ग्रिड सिस्टम के साथ शुरुआत की। फिर मैंने बुनियादी लेआउट, मार्जिन, पैडिंग, फोंट और आकारों के लिए सीएसएस की एकल लाइनें बनाईं। मैं फिर उन्हें आवश्यकतानुसार एक साथ स्ट्रिंग करता हूं। यह मुझे अपनी सभी परियोजनाओं में एक सुसंगत लेआउट रखने और एक ही सीएसएस फ़ाइलों का उपयोग करने की अनुमति देता है। क्योंकि वे विशिष्ट नहीं हैं। यहाँ एक उदाहरण दिया गया है: ---- div class = "c12 bg0 m10 p5 white fl" / div --- इसका मतलब है कि कंटेनर में 12 कॉलम हैं, bg0 का उपयोग 5 के 10px पैराग्राफ का मार्जिन है, पाठ सफेद है और यह तैरता है बाएं। मैं इसे हटाकर या जोड़कर आसानी से बदल सकता था - जिसे मैं "प्रकाश" शैली कहता हूं- इन सभी विशेषताओं के साथ एक एकल वर्ग बनाने के बजाय; पेज को कोड करते हुए मैं केवल सिंगल स्टाइल को जोड़ती हूं। यह मुझे शैलियों के किसी भी संयोजन को बनाने की अनुमति देता है और मेरी रचनात्मकता को सीमित नहीं करता है या मुझे भारी संख्या में शैलियों का निर्माण करने का कारण बनता है जो समान हैं। आपकी स्टाइल शीट बहुत अधिक प्रबंधनीय हो जाती है, कम से कम हो जाती है और आपको इसे बार-बार उपयोग करने की अनुमति देती है। यह विधि मैंने तेजी से डिजाइन के लिए शानदार पाया है। मैं भी पहले PSD में डिजाइन नहीं करता हूं, लेकिन ब्राउज़र में जो समय बचाता है। इसके अलावा क्योंकि मैंने अपनी पृष्ठभूमि और पेज डिज़ाइन विशेषताओं के लिए एक नामकरण प्रणाली भी बनाई है, मैं बस एक नई परियोजना बनाते समय अपनी छवि फ़ाइल को बदल देता हूं। (मेरे नामकरण प्रणाली के अनुसार bg0 = शरीर की पृष्ठभूमि) इसका मतलब है कि अगर मैं पहले एक सफेद था एक परियोजना के साथ पृष्ठभूमि बस इसे काले रंग में बदलने का मतलब है कि अगली परियोजना bg0 पर एक काली पृष्ठभूमि या दूसरी छवि होगी .....

Comments

क्या आप जानते हैं कि पैराग्राफ किस लिए हैं?

— Em1

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

— शाम