HTML में लेआउट के लिए तालिकाओं का उपयोग क्यों नहीं किया जाता है? [बन्द है]

Question

यह सामान्य राय है कि HTML में लेआउट के लिए तालिकाओं का उपयोग नहीं किया जाना चाहिए।

क्यों?

मैंने कभी (या शायद ही कभी ईमानदार होने के लिए) इसके लिए अच्छे तर्क देखे। सामान्य उत्तर हैं:

• सामग्री को लेआउट से अलग करना अच्छा है
  लेकिन यह एक तर्कहीन तर्क है; क्लिच सोच । मुझे लगता है कि यह सच है कि लेआउट के लिए तालिका तत्व का उपयोग करना सारणीबद्ध डेटा के साथ बहुत कम है। तो क्या? क्या मेरे बॉस की परवाह है? क्या मेरे उपयोगकर्ता परवाह करते हैं?
  
  शायद मैं या मेरे साथी डेवलपर्स जिन्हें वेब पेज की देखभाल बनाए रखनी है ... क्या टेबल कम रख-रखाव है? मुझे लगता है कि div और CSS का उपयोग करने की तुलना में तालिका का उपयोग करना आसान है।
  
  वैसे ... क्यों एक div या एक अवधि का उपयोग कर रहा है लेआउट से सामग्री का अच्छा जुदाई और एक मेज नहीं? केवल divs के साथ एक अच्छा लेआउट प्राप्त करने के लिए अक्सर नेस्टेड divs की बहुत आवश्यकता होती है।

• कोड की पठनीयता
  मुझे लगता है कि यह दूसरा तरीका है। ज्यादातर लोग HTML को समझते हैं, कुछ लोग CSS को समझते हैं।

• एसईओ के लिए तालिकाओं का उपयोग न करना बेहतर है
  क्यों? किसी को भी कुछ सबूत दिखा सकते हैं कि यह है? या Google का एक बयान कि तालिकाओं को एक एसईओ परिप्रेक्ष्य से हतोत्साहित किया जाता है?

• टेबल्स धीमे हैं।
  एक अतिरिक्त तत्व तत्व सम्मिलित करना होगा। यह आधुनिक वेब ब्राउज़र के लिए मूंगफली है। मुझे कुछ बेंचमार्क दिखाएं जहां टेबल का उपयोग एक पृष्ठ को काफी धीमा कर देता है।

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

मैं वास्तव में तालिकाओं के बजाय divs + CSS का उपयोग करने के लिए अच्छे तर्कों में दिलचस्पी रखता हूं।

Comments

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

— 16

वहाँ एक नकली क्यू और एक पर है stackoverflow.com/questions/30251/tables-instead-of-divs

— Onorio Catenacci

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

— अर्थेटिक

@Camilo SO अभी भी 20 वीं सदी में रहता है। जेफ स्पष्ट रूप से ulटैग का उपयोग करना नहीं जानता है । इस साइट की सभी सूचियों (बैज, संबंधित प्रश्न, हाल के टैग) पर एक नज़र डालें। वे सभी एकल कॉलम या लंबे पैराग्राफ के साथ अलग हो गए हैं br।

— यी जियांग

@ ब्रैड: कुछ विशिष्ट विवरणों पर निर्भर करता है (कि किसी भी चतुर वापसी के लिए मेरा बाहर निकलना; ;-) DIV का उपयोग दुर्व्यवहार तालिकाओं की तुलना में बेहतर है। एक दस्तावेज़ के दो भाग जो एक दूसरे के साथ रखे जा सकते हैं वे वैध रूप से DIV तत्वों में शामिल हो सकते हैं, लेकिन वे निश्चित रूप से टैब डेटा नहीं हैं। इससे कोई फर्क नहीं पड़ता कि एक विशिष्ट स्टाइल क्या होता है; सामग्री या तो सारणीबद्ध है या नहीं। नोट: मैं डिविटिस की वकालत नहीं कर रहा हूँ :)

— बॉबी जैक

Answer 1

मैं एक के बाद एक आपके तर्कों से गुजरने जा रहा हूं और उनमें त्रुटियों को दिखाने का प्रयास कर रहा हूं।

सामग्री को लेआउट से अलग करना अच्छा है लेकिन यह एक तर्कहीन तर्क है; क्लिच सोच रहा था।

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

तो क्या? क्या मेरे बॉस की परवाह है? क्या मेरे उपयोगकर्ता परवाह करते हैं?

निर्भर करता है। क्या आपका बॉस नुकीले बालों वाला है? तब वह परवाह नहीं कर सकता है। यदि वह सक्षम है, तो वह परवाह करेगी, क्योंकि उपयोगकर्ता करेंगे ।

शायद मैं या मेरे साथी डेवलपर्स जिन्हें वेब पेज की देखभाल बनाए रखनी है ... क्या टेबल कम रख-रखाव है? मुझे लगता है कि डिव और सीएसएस का उपयोग करने की तुलना में एक तालिका का उपयोग करना आसान है।

अधिकांश पेशेवर वेब डेवलपर आपको विरोध करने लगते हैं^{[ प्रशस्ति पत्र की जरूरत ]} । टेबल यही कारण है कि कर रहे हैं वास्तव में कम पोषणीय स्पष्ट होना चाहिए। लेआउट के लिए तालिकाओं का उपयोग करने का मतलब है कि कॉर्पोरेट लेआउट को बदलना वास्तव में हर एक पृष्ठ को बदलना होगा। यह बहुत महंगा हो सकता है। दूसरी ओर, सीएसएस के साथ संयुक्त रूप से अर्थपूर्ण सार्थक HTML का विवेकपूर्ण उपयोग सीएसएस और उपयोग की गई तस्वीरों में इस तरह के बदलावों को सीमित कर सकता है।

वैसे ... क्यों एक div या एक अवधि का उपयोग कर रहा है लेआउट से सामग्री का अच्छा जुदाई और एक मेज नहीं? केवल divs के साथ एक अच्छा लेआउट प्राप्त करने के लिए अक्सर नेस्टेड divs की बहुत आवश्यकता होती है।

डीप नेस्टेड <div>s टेबल लेआउट के रूप में एक एंटी-पैटर्न हैं। अच्छे वेब डिज़ाइनरों को उनमें से कई की आवश्यकता नहीं है। दूसरी ओर, इस तरह के गहरे नेस्टेड डिबों में टेबल लेआउट की कई समस्याएं नहीं हैं। वास्तव में, वे सामग्री में तार्किक रूप से भागों को विभाजित करके सिमेंटिक संरचना में भी योगदान कर सकते हैं।

कोड की पठनीयता मुझे लगता है कि यह दूसरा तरीका है। ज्यादातर लोग html को समझते हैं, कम समझ सीएसएस। यह सरल है।

"ज्यादातर लोग" कोई फर्क नहीं पड़ता। पेशेवर मायने रखते हैं। पेशेवरों के लिए, टेबल लेआउट HTML + सीएसएस की तुलना में कई और अधिक समस्याएं पैदा करते हैं। यह कहने जैसा है कि मुझे GVim या Emacs का उपयोग नहीं करना चाहिए क्योंकि नोटपैड अधिकांश लोगों के लिए सरल है। या यह कि मुझे LaTeX का उपयोग नहीं करना चाहिए क्योंकि MS Word अधिकांश लोगों के लिए सरल है।

तालिकाओं का उपयोग न करना SEO के लिए बेहतर है

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

टेबल्स धीमे हैं। एक अतिरिक्त तत्व तत्व सम्मिलित करना होगा। यह आधुनिक वेब ब्राउज़र के लिए मूंगफली है।

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

मुझे कुछ बेंचमार्क दिखाएं जहां टेबल का उपयोग एक पृष्ठ को काफी धीमा कर देता है।

दुर्भाग्य से, मेरे पास कोई बेंचमार्क डेटा नहीं है। मुझे खुद इसमें दिलचस्पी होगी क्योंकि यह सही है कि इस तर्क में एक निश्चित वैज्ञानिक कठोरता का अभाव है।

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

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

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

Comments

"वास्तव में कॉर्पोरेट लेआउट को बदलने का अर्थ होगा हर एक पृष्ठ को बदलना" - क्या लोग अभी भी हर पृष्ठ पर कॉर्पोरेट लेआउट को दोहरा रहे हैं? मास्टर पेज या यूजर कंट्रोल के साथ .net में हल करना इतना आसान है, इसमें php या क्लासिक एस्प आदि की फाइलें शामिल हैं ... कोई भी व्यक्ति जो कंपनी के लेआउट को कॉपी करता है जैसे कि a ** किकिंग का हकदार है! ;-)

— जॉन मैकइंटायर

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

— क्लेटस

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

— कोनराड रूडोल्फ

एक स्क्रीन रीडर प्राप्त करें और यह एक टेबल लेआउट के साथ एक पृष्ठ पढ़ा है। वह सब है।

— corymathews

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

— कोनराड रूडोल्फ

Answer 2

यहाँ मेरे प्रोग्रामर का जवाब एक सिमलीयर धागे से दिया गया है

शब्दार्थ 101

पहले इस कोड को देखें और सोचें कि यहां क्या गलत है ...

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

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

शब्दार्थ 102

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

निष्कर्ष

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

Comments

क्षमा करें, यह पानी को धारण नहीं करता है। आप mybike के लिए कार का उपयोग नहीं करते क्योंकि आप इसके बजाय "बाइक" वर्ग को परिभाषित करेंगे। आप "<तालिका>" के लिए कुछ और परिभाषित नहीं कर सकते क्योंकि यह एक सरल शब्दार्थ टैग से अधिक है - यह ब्राउज़र को बताता है कि अपनी सामग्री को कैसे प्रस्तुत करना है।

— जिमी

अच्छा सादृश्य, और महान निष्कर्ष। किसी को सही काम करने के लिए किसी के बॉस और / या उपयोगकर्ताओं द्वारा मजबूर क्यों होना चाहिए? क्या कोई भी अपने काम पर गर्व नहीं करता है?

— शेरम पेंडले

मुझे लगता है कि यह काफी अहंकारी पोस्ट है जो कुछ भी नहीं समझाती है लेकिन सवाल का जवाब दिए बिना फिर से वही दावे दोहराती है। मुझे समझ नहीं आ रहा है कि इतने सारे अपवॉट क्यों मिले ????

— मार्क

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

— रिचर्ड ईव

@ थारकुन और रिचर्ड: "शब्दार्थिक रूप से गलत" कैसे व्यक्तिपरक है और कुछ भी नहीं समझाता है?

— विंको वर्सालोविच 17

Answer 3

स्पष्ट उत्तर: सीएसएस ज़ेन गार्डन देखें । यदि आप मुझे बताते हैं कि आप टेबल-आधारित लेआउट के साथ आसानी से ऐसा कर सकते हैं (याद रखें - एचटीएमएल नहीं बदल रहा है) तो हर तरह से लेआउट के लिए टेबल का उपयोग करें।

दो अन्य महत्वपूर्ण चीजें हैं सुलभता और एसईओ।

दोनों इस बात की परवाह करते हैं कि जानकारी किस क्रम में प्रस्तुत की गई है। यदि आपका टेबल-आधारित लेआउट इसे पृष्ठ पर 2 नेस्टेड तालिका की दूसरी पंक्ति के 3 सेल में रखता है, तो आप अपने नेविगेशन को आसानी से पृष्ठ के शीर्ष पर प्रस्तुत नहीं कर सकते।

इसलिए आपके जवाब में स्थिरता, पहुंच और एसईओ हैं।

आलसी मत बनो। चीजों को सही और उचित तरीके से करें, भले ही वे सीखने के लिए थोड़े कठिन हों।

Comments

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

— GvS

मुझे खेद है लेकिन यह सही नहीं है। पाठ अभी भी HTML में है - यह CSSZG डिजाइन की आवश्यकताओं में से एक है। HTML को अपरिवर्तित रहना होगा।

— एर्लैंडो सेप

यदि आप कुछ डिज़ाइनों को करीब से देखते हैं, तो कुछ हेडर में मौजूद टेक्स्ट HTML के टेक्स्ट से अलग है। ऐसा इसलिए है क्योंकि HTML को अदृश्य बनाया गया है, और इसके बजाय एक छवि डाली गई है। (उदाहरण: csszengarden.com/?cssfile=/212/212.css&page=0 ; The? Path? To , Achievement?)

— GvS

क्षमा करें, SEO के लिए कोई भी सबूत नहीं हैं जो div लेआउट बेहतर हैं। इसके अलावा, Google ने खुद कहा है कि HTML सत्यापन उनके लिए कोई मायने नहीं रखता है - थोड़ा अलग मुद्दा है, लेकिन एक टेबल के प्रति लक्षित है क्योंकि वे शायद ही कभी मान्य होते हैं।

— असंतुष्टगीतगोत

“आप में से अधिकांश एक प्रोग्रामर के गुणों से परिचित हैं। वहाँ तीन हैं, ज़ाहिर है: आलस्य, अधीरता, और पति। - लैरी वॉल

— इंक्रेडिबल

Answer 4

यह डुप्लिकेट प्रश्न देखें।

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

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

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

Comments

हाँ सचमुच। मैं देखता हूं कि वह नकल है। मैनें इसे खो दिया। होनहार के अलावा किसी भी कार्रवाई की आवश्यकता है मैं अगली बार अधिक सावधान रहूंगा :-)?

— बेनो रिचर्स

चिंता मत करो। यह अधिक से अधिक सामान्य होगा क्योंकि प्रश्नों की संख्या बढ़ जाती है। मैंने भी कम नहीं किया। हम बस यह सुनिश्चित करना चाहते हैं कि जितना संभव हो सके वे अंततः एक आम स्रोत की ओर इशारा करें।

— जोएल कोएहॉर्न

मुझे वास्तव में यह उत्तर पसंद है। शब्दार्थ टैग का उपयोग करना केवल परंपरा का विषय नहीं है, यह उन अस्पष्ट गैर-ब्राउज़रों (स्क्रीन रीडर, स्क्रीन स्क्रैपर्स, विभिन्न पार्सर्स) को आपके पृष्ठ पर विभिन्न वस्तुओं को सही ढंग से वर्गीकृत करने की अनुमति देता है।

— फैंटम वाटसन

मैं उम्मीद कर रहा था कि कोई इसका उल्लेख करेगा। अभिगम्यता सर्वोच्च प्राथमिकता होनी चाहिए!

— एंड्रयू

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

— पीटर

Answer 5

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

इसलिए, एक वेबसाइट जिसका उद्देश्य सामग्री से डिजाइन रखने का लाभ दिखाना है, अब नियमित रूप से डिजाइन में सामग्री डालने का UNSPEAKABLE SIN करता है। (यदि HTML फ़ाइल में सेक्शन हेडिंग को बदलना था, तो प्रदर्शित किया जाने वाला सेक्शन हेडिंग नहीं होगा)।

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

Comments

आप मतलब है कि वे कर रहे हैं <h1>Some Text</h1>और फिर अपनी सीएसएस में h1 { background-image('foo.jpg'); text-indent:-3000px }:? यह ऐसा करने का सही तरीका है क्योंकि आप स्टाइल-कम HTML में अधिकतम शब्दार्थ जानकारी को बरकरार रख रहे हैं। या हो सकता है कि मैंने आपको गलत समझा।

— करण

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

— एम्ब्रोसैचपेल

@ अम्ब्रोस: क्योंकि फ्रिगिन साइट का पूरा बिंदु कंटेंट और स्टाइल के पृथक्करण को प्रदर्शित करना है। कंटेंट एंड स्टाइल को अलग-अलग लोगों द्वारा ठीक से संभाला जाना चाहिए, जिनमें से किसी को भी "याद" नहीं करना चाहिए कि दूसरा क्या बदल गया है।

— जेम्स कर्रन

श्री एस एंड एन: जो मामलों को और भी बदतर बना देगा। आपको सही शैली में गतिशील रूप से नई छवियां उत्पन्न करनी होंगी। तो अब आप CSS से बिज़नेस लेयर कोड पर स्टाइल कर रहे हैं।

— जेम्स कर्रन

@ नाम: सामग्री और शैली हमेशा अलग-अलग लोगों द्वारा नियंत्रित नहीं की जा सकती। जब सामग्री को स्टाइल किया जाता है, तो सहयोग होना चाहिए। <h1><img src="something.png"></h1>किसी भी अधिक से अधिक बनाए रखने योग्य कैसे है <h1 class="something image">Something</h1>? या तो उदाहरण में कुछ। png को अद्यतन करने की आवश्यकता है। लेकिन दूसरा उदाहरण कहीं अधिक सुलभ है।

— जोश

Answer 6

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

Comments

अच्छा बिंदु, हालांकि आप टेबल आधारित लेआउट में कोशिकाओं को छिपाने के लिए सीएसएस का उपयोग कर सकते हैं, उदाहरण के लिए प्रिंट करने योग्य संस्करण में नेविगेशन को दबाने के लिए, सीएसएस लेआउट आपको केवल डेटा छिपाने के पीछे बहुत अधिक लचीलापन देता है।

— Cory हाउस

मैंने अपने एक आवेदन के साथ इसे मारा; लड़का तब खुश था जब मुझे एहसास हुआ कि स्क्रीन पर जितने प्रिंट थे उतने ही पृष्ठों के लिए कुछ प्रिंट सीएसएस के साथ "प्रिंटर फ्रेंडली" संस्करण बनाना कितना आसान था।

— लॉरेंस डोल

Answer 7

लेआउट के लिए एक तालिका यह खराब नहीं होगी। लेकिन आप उस लेआउट को प्राप्त नहीं कर सकते हैं जिसकी आपको ज्यादातर समय एक मेज के साथ जरूरत होती है। बहुत जल्द आपके पास 2 या तीन नेस्टेड टेबल हैं। यह बहुत बोझिल हो जाता है।

• यह पढ़ने के लिए बहुत मुश्किल है। यह राय नहीं है। उन पर बिना किसी पहचान के निशान के साथ और अधिक नेस्टेड टैग हैं।

• प्रस्तुति से सामग्री को अलग करना एक अच्छी बात है क्योंकि यह आपको उस चीज़ पर ध्यान केंद्रित करने की अनुमति देता है जो आप कर रहे हैं। दोनों को मिलाने से फूले हुए पन्ने निकलते हैं जिन्हें पढ़ना मुश्किल है।

• शैलियों के लिए सीएसएस आपके ब्राउज़र को फ़ाइलों को कैश करने की अनुमति देता है और बाद के अनुरोध बहुत तेज होते हैं। यह बहुत बड़ा है।

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

• टेबल्स शैली के लिए कठिन हैं। आपके पास उनके साथ बहुत अधिक लचीलापन नहीं है (यानी आपको किसी तालिका की शैलियों को पूरी तरह से नियंत्रित करने के लिए अभी भी HTML विशेषताओं को जोड़ने की आवश्यकता है)

मैंने शायद 4 साल में गैर-सारणीबद्ध डेटा के लिए तालिकाओं का उपयोग नहीं किया है। मैंने पीछे मुड़कर नहीं देखा।

मैं वास्तव में एंडी बुद्ध द्वारा सीएसएस महारत पढ़ने का सुझाव देना चाहूंगा । यह बढ़िया है।

छवि ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg

Comments

मैं इस पुस्तक की अत्यधिक अनुशंसा कर सकता हूं

— याकूब टी। नीलसन

बॉक्स मॉडल, चयनकर्ताओं और स्थिति के लिए अच्छे उदाहरण हैं।

— केएमएन

Answer 8

सामग्री को लेआउट से अलग करना अच्छा है
लेकिन यह एक तर्कहीन तर्क है; क्लिच सोच

यह एक विचलित तर्क है क्योंकि HTML टेबल लेआउट हैं! सामग्री तालिका में डेटा है, प्रस्तुति तालिका ही है। यही कारण है कि HTML से CSS अलग करना कई बार बहुत मुश्किल हो सकता है। आप प्रस्तुति से सामग्री को अलग नहीं कर रहे हैं, आप प्रस्तुति को प्रस्तुति से अलग कर रहे हैं! नेस्टेड डिव का ढेर टेबल से अलग नहीं है - यह टैग का एक अलग सेट है।

सीएसएस से HTML को अलग करने के साथ दूसरी समस्या यह है कि उन्हें एक दूसरे के अंतरंग ज्ञान की आवश्यकता है - आप वास्तव में उन्हें पूरी तरह से अलग नहीं कर सकते। HTML में टैग लेआउट सीएसएस फ़ाइल के साथ कसकर युग्मित है चाहे आप कुछ भी करें।

मुझे लगता है कि आपके एप्लिकेशन की जरूरतों के लिए टेबल बनाम डीआईएस नीचे आते हैं।

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

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

Comments

स्क्रीन्रेडर्स तालिकाओं के साथ काम करता है ठीक है .. यह तरीका है कि टेबल स्क्रीन्रेडर्स के साथ सौदा नहीं करते हैं यही समस्या है। तालिका-आधारित लेआउट में जानकारी को दुर्गम तरीके से प्रस्तुत करने की संभावना है। इस बारे में सोचें कि राइट-साइड नेविगेशन कैसा दिखेगा। यह पृष्ठ के बहुत नीचे होगा।

— एरलैंडो सेप

ठीक है, तब समझ में आता है - धन्यवाद!

— 17 की 26

सिर्फ इसलिए कि <table> या <div> के पास अधिकांश स्क्रीन एजेंटों में एक डिफ़ॉल्ट प्रस्तुति है, उन्हें सिमेंटिक तत्वों के बजाय प्रस्तुति तत्वों के बराबर नहीं किया जाता है।

— मार्क ब्रैकेट

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

— 17 का 26

"मैंने काम करने के लिए दिन बिताने की कोशिश की" - अगर मैं कुछ जानने की कोशिश कर रहा हूं तो कुछ घंटों से अधिक समय लगता है, मैंने इसे स्टैकऑवरफ्लो समुदाय में डाल दिया। सही तरीके से कुछ करना नहीं जानते हुए भी इसे सही तरीके से नहीं करने का कोई बहाना नहीं है। खासतौर पर तब जब हमारी उँगलियों पर सभी उत्तर हों।

— डेवडेव

Answer 9

CSS / DIV - यह सिर्फ डिजाइन लड़कों के लिए काम है, है ना। सैकड़ों घंटे मैंने DIV / CSS मुद्दों को डिबग करने में बिताए हैं, मार्कशीट के कुछ हिस्से को एक अस्पष्ट ब्राउज़र के साथ काम करने के लिए इंटरनेट पर खोज रहा है - यह मुझे पागल कर देता है। आप एक छोटा सा बदलाव करते हैं और पूरा लेआउट भयावह रूप से गलत हो जाता है - जहां पर उस में तर्क है। इस तरह से कुछ 3 पिक्सेल बढ़ते हुए घंटे बिताते हुए फिर कुछ और 2 पिक्सेल दूसरे को उन सभी को प्राप्त करने के लिए। यह सिर्फ मुझे किसी भी तरह सादा गलत लगता है। सिर्फ इसलिए कि आप एक शुद्धतावादी हैं और कुछ "सही काम करने के लिए नहीं है" इसका मतलब यह नहीं है कि आपको इसका उपयोग nth डिग्री और सभी परिस्थितियों में करना चाहिए, खासकर अगर यह आपके जीवन को 1000 गुना आसान बनाता है।

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

इन सभी CSS / DIV के तर्क होने का एकमात्र कारण CSS की कमी के कारण पहली जगह है और क्योंकि ब्राउज़र एक दूसरे के साथ संगत नहीं हैं और यदि वे थे, तो दुनिया के आधे वेब डिजाइनर नौकरी से बाहर हो जाएंगे ।

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

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

बिंदु में मामला - इस चर्चा के आधार पर मैंने कुछ मौजूदा tds और trs को divs में बदल दिया। इसके बारे में 45 मिनट गड़बड़ करने के लिए एक दूसरे के बगल में सब कुछ प्राप्त करने की कोशिश कर रहा है और मैंने हार मान ली। 10 सेकंड के बाद वापस टीडीएस - काम करता है - सीधे दूर - सभी ब्राउज़रों पर, और कुछ नहीं करना है। कृपया मुझे समझने की कोशिश करें - मुझे किसी अन्य तरीके से करने के लिए आपके पास क्या औचित्य है!

Comments

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

— डैनियल स्जाबो

पता है कि साइटवाइड परिवर्तन क्या प्रबंधित करना आसान बनाता है? एमवीसी और टेम्पलेट सिस्टम

— जियाओ

कृपया मुझे गलत न समझें - मैं अभी भी CSS का उपयोग करता हूं लेकिन मैं इसका उपयोग स्टाइल (रंग, पृष्ठभूमि चित्र और आगे) लगाने के लिए करता हूं न कि लेआउट के लिए। सीएसएस ब्राउज़र के पार बहुत अधिक सुसंगत प्रतीत होता है जब केवल शैली को नियंत्रित करने के लिए उपयोग किया जाता है। जहां यह त्रुटिपूर्ण है और बड़े पैमाने पर नीचे गिरता है, वह तरीका है जिसमें लेआउट दोनों ब्राउज़रों में निर्दिष्ट और कार्यान्वित किया जाता है। क्या किसी ने कभी ASP.NET MasterPages को DIV के साथ मज़बूती से काम करने की कोशिश की है? यह लगभग असंभव है!

— टिम ब्लैक

Answer 10

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

यदि वह आपको "डब्ल्यूटीएफ" नहीं कहता है, तो आपको वास्तव में अब कूल-ऐड को नीचे रखना होगा।

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

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

आह। पर्याप्त वेंटिंग। आगे बढ़ो और अपने सिर को वापस रेत में चिपका दो।

Comments

"सीएसएस ज़ीलॉट्स" (जैसा कि आप इसे डालते हैं) इस तथ्य से अनभिज्ञ नहीं हैं। अगले सीएसएस युक्ति में सीएसएस में लेआउट के साथ समस्याओं को ठीक करने के लिए सिर्फ एक नहीं, बल्कि दो समाधान हैं। टेम्प्लेट लेआउट: w3.org/TR/css3-layout और ग्रिड पोजिशनिंग: w3.org/TR/css3-grid यह स्पर्धा ऐनक पेश नहीं करता है। 2 चश्मा वास्तव में एक दूसरे के पूरक हैं। हालांकि इस टिप्पणी को लिखने के समय तक, कोई भी ब्राउज़र इसे लागू नहीं करता है, फिर भी।

— दान हर्बर्ट

+1: मैं पूरी तरह सहमत हूं। आपको "इसे काम पर लाने के लिए" नहीं होना चाहिए (हालांकि मुझे टेबल भी पसंद नहीं है)।

— 3lectrologos

यह 100% वास्तव में मुझे कैसा लगता है। काश मैं आपको शीर्ष उत्तर तक पहुंचा सकता।

— bobwienholt

Answer 11

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

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

Answer 12

हाल के प्रोजेक्ट से html का एक भाग यहां दिया गया है:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

और यहां टेबल आधारित लेआउट के समान कोड है।

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

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

एक और बात के बारे में सोचने के लिए: filesizes । मैंने पाया है कि टेबल-आधारित लेआउट आमतौर पर अपने सीएसएस समकक्षों के आकार से दोगुना होते हैं। हमारे hig-speed ब्रॉडबैंड पर जो बहुत बड़ा मुद्दा नहीं है, लेकिन यह डायल अप मोडेम के साथ है।

Comments

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

— श्री शाइनी और न्यू 安 Sh

हाँ, लेकिन यह मत भूलो कि जबकि HTML सीएसएस-कम लेआउट में दो बार बड़ा हो सकता है, DIV + CSS लेआउट का उपयोग करने से सीएसएस फ़ाइल के लिए अतिरिक्त HTTP अनुरोध (कम से कम) होगा, साथ ही बैंडविड्थ उपयोग के लिए खुद ही फाइल करो।

— सुनहरा अनुपात

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

— user151841

आपने div + css के अनुकूल डिज़ाइन को चुना है और दिखाया है कि यह टेबल-आधारित डिज़ाइन में अधिक क्रिया है? तो क्या: यह केवल एक डिज़ाइन बनाना आसान होगा जो टेबल-आधारित लेआउट के अनुकूल था और हुप्स दिखाएगा कि आपको इसे सीएसएस में दोहराने के लिए कूदना होगा।

— ड्रेमन

@Draemon: शायद आप एक उदाहरण देना चाहते हैं?

— बॉबी जैक

Answer 13

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

आपके कोड का अर्थ अर्थ के दृष्टिकोण से भी है।

Comments

मेरा सपना एक ग्राफिक डिज़ाइनर का रहा है जो मेरे द्वारा प्रदान किए गए ऑब्जेक्ट्स / डेटा को लेता है और उन्हें बिना किसी पेज पर डाले बिना मुझे CSS, DIV, TABLE ... के बारे में परवाह करने की जरूरत है ... :)

— Manrico Corazzi

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

— रिचर्ड ईव

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

— निक वान ब्रंट

Answer 14

DIV में कोई तर्क मेरे पक्ष में नहीं है।

मैं कहूंगा: यदि जूता फिट बैठता है, तो इसे पहनें।

यह ध्यान देने योग्य है कि दो या तीन कॉलम में सामग्री प्रदान करने का एक अच्छा DIV + CSS तरीका खोजना असंभव नहीं है, जो कि सभी ब्राउज़रों पर संगत है, और अभी भी मेरे इरादे के अनुरूप है।

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

Comments

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

— १४

Answer 15

सीएसएस लेआउट आमतौर पर पहुंच के लिए बहुत बेहतर होते हैं, बशर्ते कि सामग्री एक प्राकृतिक क्रम में आती है और एक स्टाइलशीट के बिना समझ में आती है। और यह केवल स्क्रीन रीडर नहीं है जो टेबल-आधारित लेआउट के साथ संघर्ष करते हैं: वे मोबाइल ब्राउज़र के लिए एक पृष्ठ को ठीक से प्रस्तुत करने के लिए बहुत कठिन बनाते हैं।

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

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

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

Answer 16

तथ्य यह है कि यह एक गर्म बहस वाला प्रश्न है, लेआउट डिजाइनों की विविधता का अनुमान लगाने के लिए W3C की विफलता का एक वसीयतनामा है जिसे प्रयास किया जाएगा। शब्दार्थ-अनुकूल लेआउट के लिए divs + css का उपयोग करना एक बेहतरीन अवधारणा है, लेकिन कार्यान्वयन के विवरण इतने त्रुटिपूर्ण हैं कि वे वास्तव में रचनात्मक स्वतंत्रता प्रदान करते हैं।

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

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

Answer 17

मुझे लगता है कि यह सच है कि लेआउट के लिए तालिका तत्व का उपयोग करना सारणीबद्ध डेटा के साथ बहुत कम है। तो क्या? क्या मेरे बॉस की परवाह है? क्या मेरे उपयोगकर्ता परवाह करते हैं?

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

Comments

हाँ, उदाहरण के लिए ब्लॉग के लिए इंजन ब्लॉग पोस्ट से टिप्पणियों को अलग करता है। कल्पना कीजिए कि लेआउट को तालिकाओं के साथ स्टाइल किया गया था ..

— उमर आबिद

-1: यदि आप लेआउट के लिए तालिकाओं का उपयोग करते हैं तो Google बिल्कुल भी परवाह नहीं करता है।

— टॉम एंडरसन

@ टॉम एंडरसन इसलिए नहीं क्योंकि उनके पास लेआउट के लिए तालिकाओं का उपयोग करने के साथ एक मुद्दा है, लेकिन सिर्फ इसलिए कि गैर-तालिका HTML अधिक अर्थपूर्ण हो जाती है।

— सियजयोज

Answer 18

एक वेबसाइट के साथ काम करना था जिसमें कुछ एप्लिकेशन द्वारा उत्पन्न नेस्टेड तालिकाओं की 6 परतें शामिल थीं, और इसे अमान्य HTML उत्पन्न करने के बाद, यह वास्तव में एक मामूली बदलाव के लिए इसे तोड़ने के लिए 3 घंटे का काम था।

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

इसके अलावा, जावास्क्रिप्ट के साथ यह प्रयास करें। एक टेबल टेबल सेल को एक स्थान से दूसरे स्थान पर दूसरे स्थान पर ले जाना। बल्कि यह प्रदर्शन करने के लिए जटिल है जहां div / स्पैन सिर्फ कॉपी-पेस्ट-वार काम करेगा।

"क्या मेरा मालिक परवाह करता है"

अगर मैं आपका बॉस होता। आपको परवाह होगी। ;) यदि आप अपने जीवन को महत्व देते हैं।

Comments

एक ऐसी वेबसाइट के साथ काम करना पड़ा, जिसमें स्पैन और डिव टैग्स का एक बहुत बड़ा सूप था और जब किसी एक तत्व को बदलने पर इसकी नाजुकता देखी गई तो पूरे पेज को तोड़ दिया जाएगा (और हेडिंग टैग्स के बजाय

— डिव

Div का उपयोग स्पष्ट रूप से आपके कोड को जादुई रूप से अच्छा नहीं बनाता है। टैग के उपयुक्त शब्दार्थ प्रयोग के लिए बहुत कुछ कहा जाना है।

— केंट फ्रेड्रिक

Answer 19

लेआउट लचीलापन
कल्पना करें कि आप बड़ी संख्या में थंबनेल के साथ एक पृष्ठ बना रहे हैं।
DIVs :
यदि आप प्रत्येक थंबनेल को DIV में रखते हैं, तो बाईं ओर तैरते हैं, हो सकता है कि उनमें से 10 पंक्ति में फिट हों। खिड़की को संकरा बनाएं, और BAM - यह एक पंक्ति में 6 है, या 2, या फिर कई फिट है।
टेबल:
आपको स्पष्ट रूप से कहना है कि एक पंक्ति में कितने सेल हैं। यदि विंडो बहुत संकीर्ण है, तो उपयोगकर्ता को क्षैतिज रूप से स्क्रॉल करना होगा।

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

Answer 20

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

Answer 21

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

मैंने व्यक्तिगत रूप से पाया है कि बहुत से लोग बहुत सारे <div>टैग का उपयोग करते हैं , लेकिन मॉडरेशन में, यह बहुत साफ और पढ़ने में आसान हो सकता है। आप उल्लेख करते हैं कि लोगों के पास तालिकाओं की तुलना में सीएसएस पढ़ने में कठिन समय है; 'कोड' के संदर्भ में जो शायद सच है; लेकिन पठन सामग्री (दृश्य> स्रोत) के संदर्भ में यह टेबल के साथ स्टाइलशीट के साथ संरचना को समझना बहुत आसान है।

Comments

आपके पास अच्छा बिंदु; लेकिन मोबाइल उपकरणों के लिए IMHO UI इनपुट सीमाओं को ध्यान में रखते हुए पूरी तरह से अलग होना चाहिए।

— मानरिको कोराज़ी

सच; यही कारण है कि मैंने कई बार एक अलग दृष्टिकोण का उपयोग करना शुरू कर दिया है। MVC मॉडल में, मेरे विचार पॉप-आउट सिर्फ XML कच्चे डेटा यानी सामग्री। फिर एक और MVC मॉडल से शुरू करें जहां xml कच्चा डेटा = मॉडल; देखें = html / css; नियंत्रक = xsl। XSL स्टाइलशीट मोबाइल के लिए अनावश्यक डेटा को शुद्ध करती है।

— स्वाति १

Answer 22

लगता है कि आप सिर्फ तालिकाओं के अभ्यस्त हैं और यह बात है। किसी तालिका में लेआउट रखना आपको उस लेआउट के लिए सीमित करता है। CSS के साथ आप बिट्स को इधर-उधर कर सकते हैं, http://csszengarden.com/ पर एक नज़र डालें और नहीं, लेआउट को बहुत अधिक नेस्टेड डिव की आवश्यकता नहीं है।

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

एसईओ लाभ पृष्ठ से सबसे महत्वपूर्ण सामग्री अधिक होने और बेहतर सामग्री-टू-मार्कअप अनुपात रखने की क्षमता से आते हैं।

http://www.hotdesign.com/seybold/

Answer 23

• 508 अनुपालन - अपने मार्कअप की समझ बनाने के लिए एक स्क्रीनरीडर की क्षमता।
• रेंडर की प्रतीक्षा कर रहे हैं - टेबल ब्राउज़र में तब तक रेंडर नहीं करते हैं जब तक कि यह </table>तत्व के अंत तक न पहुंच जाए।

Comments

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

— 14

Answer 24

सिमेंटिक मार्कअप के आसपास का पूरा विचार मार्कअप और प्रस्तुति का पृथक्करण है, जिसमें लेआउट शामिल है।

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

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

Answer 25

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

Answer 26

तालिका लेआउट का उपयोग करने वाले उपकरण लेआउट बनाने के लिए आवश्यक कोड की मात्रा के कारण असाधारण रूप से भारी हो सकते हैं। SAP का नेटवेवर पोर्टल डिफ़ॉल्ट रूप से उनके पृष्ठों को लेआउट करने के लिए TABLE का उपयोग करता है।

मेरे वर्तमान टमटम में SAP पोर्टल का एक होम पेज है, जिसका HTML 60K से अधिक वजन का है और पृष्ठ के भीतर तीन बार गहरी, सात बार जाता है। जावास्क्रिप्ट में जोड़ें, उनके अंदर समान तालिका मुद्दों के साथ 16 iframes का दुरुपयोग, अत्यधिक भारी सीएसएस आदि, और पृष्ठ का वजन 5MB से अधिक है।

पृष्ठ का वजन कम करने के लिए समय निकालना ताकि आप उपयोगकर्ताओं के साथ आकर्षक गतिविधियाँ करने के लिए अपने बैंडविड्थ का उपयोग कर सकें।

Answer 27

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

प्रस्तुति से सामग्री को अलग करने का विचार आवेदन को विभाजित करना है इसलिए विभिन्न प्रकार के कार्य कोड के विभिन्न ब्लॉकों को प्रभावित करते हैं। यह वास्तव में परिवर्तन प्रबंधन के बारे में है। लेकिन कोडिंग मानक केवल सतही तरीके से कोड की वर्तमान स्थिति की जांच कर सकते हैं।

एक एप्लिकेशन के लिए परिवर्तन लॉग जो कोडिंग मानकों पर "प्रस्तुति से अलग सामग्री" पर निर्भर करता है, ऊर्ध्वाधर सिलोस में समानांतर परिवर्तनों का एक पैटर्न दिखाएगा। यदि "सामग्री" में परिवर्तन हमेशा "प्रस्तुति" में परिवर्तन के साथ होता है, तो विभाजन कितना सफल होता है?

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

Comments

पहले दो वाक्यों के लिए +1।

— शॉन मैकमिलन

Answer 28

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

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

यह डरावना है कि कुछ लोगों को आधुनिक उपकरणों का उपयोग करके साइट बनाने से होने वाले समय और ऊर्जा लाभों के बारे में पता नहीं हो सकता है।

Answer 29

टेबल्स सीएसएस की तुलना में सामान्य आसान या अधिक रख-रखाव में नहीं हैं । हालांकि, कुछ विशिष्ट लेआउट-समस्याएं हैं जहां टेबल वास्तव में सबसे सरल और सबसे लचीला समाधान हैं।

सीएसएस उन मामलों में स्पष्ट रूप से बेहतर है जहां प्रेजेंटेशनल मार्कअप और सीएसएस एक ही तरह के डिजाइन का समर्थन करते हैं, उनके दाहिने दिमाग में कोई भी यह तर्क नहीं देगा fontकि-CSS सीएसएस में टाइपोग्राफी को निर्दिष्ट करने से बेहतर है, क्योंकि सीएसएस आपको font-tags की तुलना में समान शक्ति देता है , लेकिन बहुत साफ तरीका है।

हालाँकि, तालिकाओं के साथ समस्या यह है कि मूल रूप से CSS में टेबल-लेआउट मॉडल Microsoft इंटरनेट एक्सप्लोरर में समर्थित नहीं है। टेबल्स और सीएसएस इसलिए सत्ता में बराबर नहीं हैं । अनुपलब्ध भाग तालिकाओं के ग्रिड जैसा व्यवहार है, जहां कोशिकाओं के किनारों को लंबवत और क्षैतिज रूप से संरेखित किया जाता है, जबकि कोशिकाओं में अभी भी अपनी सामग्री को शामिल करने के लिए विस्तार होता है। यह व्यवहार कुछ आयामों को हार्डकोड किए बिना शुद्ध सीएसएस में प्राप्त करना आसान नहीं है, जो डिजाइन को कठोर और भंगुर बनाता है (जब तक हमें इंटरनेट एक्सप्लोरर का समर्थन करना है - अन्य ब्राउज़रों में यह आसानी से उपयोग करके हासिल किया जाता है display:table-cell)।

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

तालिकाओं का उपयोग नहीं करने का सबसे महत्वपूर्ण कारण पहुंच क्षमता है। वेब कंटेंट एक्सेसिबिलिटी गाइडलाइंस http://www.w3.org/TR/WCAG10/ सलाह लेआउट के लिए टेबलों का उपयोग करके फिर से। यदि आप पहुंच के बारे में चिंतित हैं (और कुछ मामलों में आप कानूनी रूप से बाध्य हो सकते हैं), तो आपको सीएसएस का उपयोग करना चाहिए, भले ही टेबल सरल हो। ध्यान दें कि आप हमेशा सीएसएस के साथ तालिकाओं के साथ एक ही लेआउट बना सकते हैं , इसके लिए बस अधिक काम की आवश्यकता हो सकती है।

Answer 30

मुझे यह देखकर आश्चर्य हुआ कि कुछ मुद्दे पहले से ही कवर नहीं किए गए थे, इसलिए यहां मेरे 2 सेंट हैं, पहले किए गए सभी बहुत ही मान्य बिंदुओं के अलावा:

.1। सीएसएस और एसईओ:

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

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

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

.2। उत्पन्न सामग्री:

समतुल्य सीएसएस लेआउट की तुलना में एक तालिका प्रोग्रामेटिक रूप से उत्पन्न करने के लिए काफी आसान है।

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

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

इसके अलावा, जब एक तालिका उत्पन्न होती है, तो सामग्री (चर में) पहले से ही लेआउट (कोड में) से अलग हो जाती है, जिससे इसे संशोधित करना आसान होता है।

यह एक कारण है कि कुछ बहुत अच्छी तरह से डिज़ाइन की गई वेबसाइटें (उदाहरण के लिए SO) अभी भी टेबल लेआउट का उपयोग करती हैं।

बेशक, यदि परिणामों को जावास्क्रिप्ट के माध्यम से कार्य करने की आवश्यकता होती है, तो divs परेशानी के लायक हैं।

.3। त्वरित रूपांतरण परीक्षण

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

.4। विभिन्न समस्याओं के लिए अलग-अलग समाधान

लेआउट टेबल आमतौर पर भंग कर दिए जाते हैं क्योंकि "हर कोई divs & CSS जानता है" जाने का रास्ता है।

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

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

कुछ समय पहले, मुझे तालिकाओं का उपयोग करके एक साफ और सरल सीएसएस लेआउट को फिर से लिखना पड़ा क्योंकि उपयोगकर्ताओं का एक महत्वपूर्ण हिस्सा IE के पुराने संस्करण का उपयोग कर रहा होगा जो सीएसएस के लिए वास्तव में खराब समर्थन के साथ है।

मैं, एक के लिए, घुटने के झटका प्रतिक्रिया के बीमार और थका हुआ हूं "ओह नो! लेआउट के लिए टेबल्स!"

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