लोग डिव के साथ टेबल क्यों बना रहे हैं?

Question

आधुनिक वेब विकास में मैं इस पैटर्न पर अधिक बार आ रहा हूं। यह इस तरह दिख रहा है:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

और CSS में कुछ इस तरह है:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

^{* (वर्ग नाम केवल उदाहरण हैं; वास्तविक जीवन में वे सामान्य वर्ग नाम हैं जो दर्शाते हैं कि तत्व क्या है)}

मैंने हाल ही में खुद भी ऐसा करने की कोशिश की है ... क्योंकि आप जानते हैं, हर कोई इसे कर रहा है।

लेकिन मैं अभी भी नहीं मिला। हम यह क्यों कर रहे हैं? यदि आपको एक मेज की आवश्यकता है, तो बस एक ब्लास्ट करें <table>और उसके साथ किया जाए। हां, भले ही यह लेआउट के लिए हो। सारणी के अनुसार सामान रखने के लिए टेबल क्या हैं।

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

सारी दुनिया के लिए यह मुझे ऐसा लगता है जैसे आपके रास्ते में मनमानी अनावश्यक बाधाएँ डालना और फिर उन्हें दरकिनार करने के लिए अतिरिक्त काम करना।

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

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

तो ... एक शेख़ी से एक सुसंगत प्रश्न में इसे बदलने की कोशिश में: मैं क्या याद कर रहा हूं? एक वास्तविक से अधिक "अशुद्ध-तालिका" का उपयोग करने के वास्तविक लाभ क्या हैं ?

डुप्लिकेट लिंक के बारे में: यह किसी अन्य टैग या किसी चीज़ का उपयोग करने का सुझाव नहीं है। यह एक <table>बनाम का उपयोग करने के बारे में एक सवाल है display:table।

Comments

@JuhaUntinen: कि ... लगता है की संभावना नहीं है। स्रोत?

— पॉल डी। वेट

@ PaulD.Waite - यह वास्तव में आज भी सच है, मुझे लगता है। अन्य उत्तर पढ़ें। जब तक तालिका नहीं है table-layout:fixed, उसे प्रदर्शित होने से पहले पूरी तरह से लोड करने की आवश्यकता होगी। आधुनिक ब्रॉडबैंड के साथ यह प्रभाव कम ध्यान देने योग्य है।

— विल्क्स-

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

— 15

वापस पुराने दिनों में भी हम टेबल के साथ divs की नकल करते थे।

— वायट बार्नेट

किसी ने पढ़ा कि वे लेआउट के लिए तालिकाओं का उपयोग करने वाले नहीं थे और इसका मतलब यह था कि वे तालिकाओं का उपयोग करने वाले नहीं थे। मैं इस प्रवृत्ति का पता लगाता हूं।

— केसी

Answer 1

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

छोटी स्क्रीन पर उत्तरदायी तालिकाओं का लेआउट बदल जाता है - कभी-कभी कुछ कॉलम छिपे होते हैं या कॉलम समामेलित होते हैं, उदाहरण के लिए नाम और ईमेल पता बड़ी स्क्रीन पर अलग हो सकते हैं, लेकिन छोटी स्क्रीन पर एक सेल में गिर जाते हैं, इसलिए जानकारी स्क्रॉल किए बिना पढ़ी जा सकती है।

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

सीएसएस-ट्रिक्स पर उत्तरदायी तालिकाओं का एक बहुत अच्छा अवलोकन है ।

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

Comments

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

— विल्क्स-

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

— आप

@Vilx: आपने जो सवाल उठाया है, वह है " लोग डिव से टेबल क्यों बना रहे हैं ", जो कि आपको जवाब मिल रहा है। उदाहरण के लिए, आप स्क्रीन पाठकों की परवाह नहीं कर सकते हैं, लेकिन यह नहीं बदलता है कि एक्सेसिबिलिटी कई लोगों के लिए एक वास्तविक चिंता है, और (खोज इंजन के साथ) प्रमुख कारण कई लोग शब्दार्थ HTML चुनते हैं।

— जैक्सबीस 19

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

— cimmanon

मेरा मानना ​​है कि यह उत्तर थोड़ा भ्रामक है। उत्तरदायी तालिकाओं का अच्छा डिज़ाइन है, लेकिन यह प्रश्न से स्वतंत्र है कि क्या आपको <table> या <div> का उपयोग करना चाहिए - आप या तो एक ही दृश्य प्रभाव का उपयोग कर सकते हैं। दरअसल, यह संरचना और प्रस्तुति के अलगाव के विचार में मुख्य है। यह सच है कि IE के पुराने संस्करणों ने तालिका की शैली को ओवरराइड करने की अनुमति नहीं दी थी, लेकिन IE के पुराने संस्करणों ने प्रदर्शन का समर्थन नहीं किया: तालिका या तो, आप उत्तरदायी तालिका का उपयोग नहीं कर सकते थे।

— जाकबीस

Answer 2

सवाल यह है कि क्या डेटा शब्दार्थ रूप से एक तालिका है (यानी दो आयामों में तार्किक रूप से व्यवस्थित डेटा की एक इकाई) या आप दृश्य लेआउट के लिए ग्रिड का उपयोग करते हैं, उदाहरण के लिए, क्योंकि आप साइडबार का विस्तार करना चाहते हैं या ऐसा कुछ करना चाहते हैं।

यदि आपकी जानकारी शब्दार्थ है, तो आप एक <table>-टैग का उपयोग करते हैं। यदि आप लेआउट प्रयोजनों के लिए एक ग्रिड चाहते हैं, तो आप कुछ अन्य उपयुक्त HTML तत्वों का उपयोग करते display:tableहैं और स्टाइल शीट में उपयोग करते हैं।

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

---

ठीक है, क्यों न <table>केवल उस चीज़ के लिए हर चीज़ का उपयोग किया जाए जो शब्दार्थ रूप से एक तालिका है? नेत्रहीन यह स्पष्ट रूप से एक ही है (चूंकि तालिका तत्व बस display:elementडिफ़ॉल्ट शैली शीट में है)।

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

<table>बनाम display:tableचर्चा सिर्फ अर्थ मार्कअप का उपयोग कर के और अधिक सामान्य सिद्धांत का एक मामला है। उदाहरण के लिए देखें: कोई व्यक्ति ठीक से और शब्दार्थ से क्यों परेशान होगा? या सर्च इंजनों के लिए सिमेंटिक मार्कअप को अधिक भार क्यों दिया जाता है?

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

यहां तक ​​कि अगर आप अक्षम उपयोगकर्ताओं की परवाह नहीं करते हैं, तो प्रस्तुति को सामग्री से अलग रखने से आपको लाभ मिलता है। उदा। आपके तीन कॉलम लेआउट को वैकल्पिक स्टाइलशीट का उपयोग करके मोबाइल पर एकल कॉलम में प्रस्तुत किया जा सकता है।

Comments

@ विलक्स- क्यों <em>और <strong>बजाय उपयोग <b>और <i>? क्योंकि <b>और <i>टैग के शब्दार्थ के बारे में नहीं हैं। <table>है अर्थ अर्थ। इसका उपयोग किसी ऐसी चीज़ के लिए करना जो एक तालिका नहीं है, दस्तावेज़ के अर्थ को समझने में कठिन बनाती है।

@ Vilx- The book <i>Peoplesoft</i> is the <em>best</em> book on the subject. लाना <i>चारों ओर सबसे अच्छा गलत होगा कि कुछ की तुलना में अलग मतलब है क्योंकि <i>पुस्तक का शीर्षक के आसपास। अधिक के लिए, देखें और टैग क्यों हटाए गए हैं? <b><i>और बीच क्या अंतर है <b>और <strong>, <i>और <em>?

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

— रिच रीमर

@ विलक्स-: जब आप कहते हैं कि आप अपने उपयोगकर्ताओं के अनुभव के बारे में परवाह करते हैं, तो आप केवल अपने उपयोगकर्ताओं का सबसेट का मतलब समझते हैं। मार्कअप का सही तरीके से उपयोग करने का मुख्य कारण जिस तरह से आप वर्णन कर रहे हैं, वह एक्सेसिबिलिटी के लिए है, जो सीधे अक्षम उपयोगकर्ताओं के उपयोगकर्ता अनुभव से संबंधित है। ये वे लोग हैं जो आपको सही तरीके से काम करने और इन सम्मेलनों को अनदेखा करने से लाभान्वित होने का मतलब है कि उनके वेब अनुभव को कठिन बना सकते हैं।

— रॉबी

@ विलक्स-, हां, एक स्क्रीन रीडर एक <table> को <div> से बहुत अलग तरीके से व्यवहार करता है। <div> s को ज्यादातर अनदेखा किया जाता है और क्रमिक रूप से पढ़ा जाता है। एक <तालिका के अंदर> इसे अलग-अलग नेविगेशन कीस्ट्रोक्स / कमांड ("जंप टू सेल टू द राइट", "कॉलम और पंक्ति शीर्षक पढ़ें", और इसी तरह) प्रदान करना है, और अलग-अलग स्थान की जानकारी देता है (जब रीडिंग स्ट्रीम एक तालिका में प्रवेश करती है। यह "टेबल 3, पंक्ति 1 कॉलम 1,

— लोरम इप्सम

Answer 3

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

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

यह सब डेवलपर ने किया है, <table>सीएसएस वर्ग नामों के साथ मूल मार्कअप को दोहराता है । इसका मतलब है जैसे ही यह लेआउट एक तालिका नहीं है, वर्ग के नाम बाधाओं पर हैं।

इस डेवलपर को जो करना चाहिए था, उस पर विचार करें कि तालिका में क्या जानकारी है - क्या यह एक थंबनेल गैलरी है? ठीक है फिर:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

अब मैं कुछ अनुकूली CSS बना सकता हूँ:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

क्यों divs और तालिकाओं नहीं

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

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

आपकी पसंद अब विस्तृत स्क्रीन सामग्री (तालिकाओं) और साइडबार या संकीर्ण स्क्रीन सामग्री (divs) के लिए अलग-अलग मार्कअप का उत्पादन करने के लिए है - जिसका अर्थ है कि आपके सर्वर साइड स्क्रिप्ट को इस बात से अवगत होना होगा कि यदि आप इस प्रोग्राम का निर्माण कर रहे हैं तो सामग्री कहां जा रही है - या आपके पास अपना सर्वर साइड स्क्रिप्ट आउटपुट एक ही मार्कअप है (क्योंकि यह परवाह नहीं करनी चाहिए कि आप इसे कहां डाल रहे हैं) और विभिन्न स्थितियों के लिए अलग-अलग CSS नियमों का उपयोग करें।

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

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

Comments

वर्ग के नाम वास्तव में सिर्फ एक उदाहरण थे। वास्तविक जीवन में वे ज्यादातर ठीक से वर्णनात्मक हैं। वैसे भी, आपके उदाहरण में, आप <div>इसके बजाय का उपयोग क्यों करते हैं <table>? यह क्या लाभ प्रदान करता है?

— विलेक्स-

हम्म ... ठीक है, आपके मामले में आप वास्तव में मीडिया प्रश्नों के माध्यम से एक ही HTML के दो अलग-अलग प्रतिनिधित्व करते हैं। ठीक है, यह एक अच्छा उपयोग-मामला है। लेकिन अगर यह मामला नहीं था, और आप पहले से ही जानते होंगे कि यह थंबनेल गैलरी केवल एक ही स्थान पर और केवल सारणीबद्ध प्रारूप में प्रदर्शित होगी - क्या आप <table>तब या अभी भी उपयोग करेंगे display:table? क्योंकि, ठीक है, एक तरह से यह है सारणीबद्ध डेटा। सिवाय इसके कि "डेटा" चित्र है, लेकिन फिर भी।

— विल्क्स-

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

— होरस्कॉल

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

— एरिक किंग

ठीक है, ठीक है, कि यह थोड़ा खींच रहा था। :) अच्छा, आपने मुझे कुछ सोचने के लिए दिया है! उसके लिये आपका धन्यवाद! मैं अभी भी 100% आश्वस्त नहीं हूं, लेकिन कम से कम इसके साथ कुछ करना है। :)

— विल्क्स-

Answer 4

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

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

टेबल ख़राब होने के कारण यह और खराब हो गया।

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

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

तो, सवाल पूछने के लिए +1।

Comments

DOCTYPE के बारे में ऑफटॉपिक: मैंने सोचा था कि, हालांकि सैद्धांतिक अंतर था (और सत्यापनकर्ताओं ने इसे गंभीरता से लिया था), अभ्यास ब्राउज़रों में वास्तव में उनके बीच अंतर नहीं था। ठीक है, शायद एचटीएमएल / एक्सएचटीएमएल फ्लेवर के बीच कुछ मामूली बदलाव थे, लेकिन कम से कम संस्करण और डीटीडी जानकारी का उपयोग नहीं किया गया था। यही कारण है कि एचटीएमएल 5 ने पूरी चीज को वैसे भी गिरा दिया और बस चला गया <!DOCTYPE html>और यही कारण है कि IE6 जैसे पुराने ब्राउज़रों में भी काम करना होता है। क्या मुझे कुछ याद आया?

— विल्क्स-

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

— 19

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

— 19

रुको, इसलिए अलग - अलग सिद्धांत हैं जो एक ही दस्तावेज़ को अलग तरीके से प्रस्तुत करते हैं? कौन सा? ध्यान रहे मैं विभिन्न सिद्धांतों के बारे में बात कर रहा हूं, न कि सिद्धांत बनाम सिद्धांत की कमी (उर्फ quirksmode)।

— विलेक्स-

@Vilx: यह कुछ अधिक जटिल है, क्योंकि कुछ सिद्धांत मार्ग क्विर्क्स मोड (जैसे कोई सिद्धांत नहीं) और कुछ अन्य सिद्धांत (html5 सिद्धांत सहित) ट्रिगर मानक मोड को ट्रिगर करते हैं, और यहां तक ​​कि कुछ तृतीय सिद्धांत भी हैं जो तीसरे "लगभग-मानक" को ट्रिगर करते हैं "कुछ ब्राउज़रों में मोड।

— जाकबीस

Answer 5

अगर मुझे यहाँ थोड़ा "मेटा" मिल सकता है, तो यह मेरे दिमाग में दो समस्याएँ लाता है:

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

दो: कोई व्यक्ति एक समस्या देखता है और इसे रोकने के लिए एक नियम का प्रस्ताव करता है। अन्य लोग इस नियम का मूल्य देखते हैं। फिर वे मूल नियम की परवाह किए बिना इस नियम के प्रति अंध भक्ति पर जोर देते हैं कि इसे हल करना था और / या इसके बावजूद कि यह और क्या समस्या पैदा करता है। मैंने कई वार्तालाप किए हैं, जहां कोई कहता है, "आपको एक्स करना चाहिए क्योंकि यह नियम है", और फिर मैं पूछता हूं, "लेकिन हम एक्स क्यों करते हैं?", और वे मुझे चकरा देने वाले और उत्साह से देखते हैं और कहते हैं, "लेकिन मैंने अभी आपको बताया! क्योंकि यह नियम है! " मैं उत्तर देता हूं, "लेकिन यह समस्या को हल करने की तुलना में अधिक समस्या पैदा करता है। मुझे लगता है कि हम वाई करने के लिए बेहतर होंगे।" और फिर व्यक्ति कहता है, "नहीं, देखो, मैं तुम्हें दिखाता हूं। देखो, यह इस पुस्तक में यहीं है। एक्स नियम है।"

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

इतने सारे लोगों ने समाधान प्रस्तावित किया: तार्किक रूप से "टेबल" नहीं हैं चीजों के लेआउट को नियंत्रित करने के लिए टेबल टैग का उपयोग न करें। सीएसएस का उपयोग करें।

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

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

Comments

पिछले पैराग्राफ को wrt - आप उन तत्वों के लिए HTML5 विनिर्देश पढ़ा है, है ना? w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/ html / wg / draft / html / master / semantics.html # ol-ol-element - विशेष रूप से, यदि आदेश कोई फर्क पड़ता है, तो ol तत्व का उपयोग करें (क्योंकि यह संरचनात्मक भाग है) - आप अभी भी इसे बुलेट सूची के रूप में प्रस्तुत कर सकते हैं CSS का उपयोग करना

— HorusKol

और यदि आप अन्य दो उत्तरों को यहां देखते हैं, तो आप देखेंगे कि न तो केवल "क्योंकि यह नियम है" - वे दोनों नियम के लिए बहुत स्पष्ट औचित्य

— बताते हैं

हम्म, मुझे लगता है कि मैंने कुछ ऐसा कहा: "कोई व्यक्ति किसी समस्या को देखता है और इसे रोकने के लिए एक नियम का प्रस्ताव करता है। अन्य लोग इस नियम का मूल्य देखते हैं। फिर वे इस नियम के प्रति अंध भक्ति पर जोर देते हैं, मूल समस्या की परवाह किए बिना। हल करने के लिए और / या परवाह किए बिना कि यह और क्या समस्याएं पैदा करता है। " मैं इस बात से इनकार नहीं करता कि नियम के पीछे उचित सोच है। मैं अभी निष्कर्ष से सहमत नहीं हूं। निश्चित रूप से मैं कह सकता हूं, "आपके पास एक अच्छा बिंदु है, लेकिन फिर भी मैं असहमत हूं।" और निश्चित रूप से आप इस बात से इनकार नहीं करते कि ऐसे लोग हैं जो पेशेवरों और विपक्षों को नहीं समझते हैं और कहते हैं ...

— Jay

... "क्योंकि यह नियम है"। मैंने वर्षों से ऐसे लोगों के साथ, इस विशेष मुद्दे पर और कई अन्य लोगों के साथ कई वार्तालाप किए हैं। जो लोग किसी नियम के पेशेवरों और विपक्षों पर चर्चा करने से इनकार करते हैं, क्योंकि यह नियम, चर्चा का अंत है।

— Jay

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

— डेविड डब्ल्यू

Answer 6

यहां पहले से ही महान जवाब के टन हैं। लेकिन मैं जोड़ना चाहता था कि tableतत्वों की प्रतिपादन सीमाएँ हैं जो divतत्वों के लिए मौजूद नहीं हैं । कोशिश करो और है कि आभासी स्क्रॉल (जैसे: करता है एक मेज बनाने SlickGrid , DataTables , और अन्य) और आप अत्यंत कष्ट निराश हो जाएगा। यह सिर्फ काम नहीं करता है। अधिकांश (सभी?) आधुनिक जावास्क्रिप्ट ग्रिड divएस का उपयोग करते हैं क्योंकि सीएसएस अधिक लचीला प्रतिपादन की अनुमति देता है।

अन्य सीमाएँ भी हैं। मेरा सामान्य नियम यह है कि अगर मैं एक ही स्क्रीन पर पूरी तालिका देखने जा रहा हूं, और मैं नहीं चाहता कि इसके लिए कोई कस्टम / रेंडरिंग का उपयोग किया जाए, तो मैं एक tableतत्व का उपयोग करता हूं , अन्यथा मैं divs के साथ जाता हूं क्योंकि मैं परिणामों को नियंत्रित कर सकता हूं , और अधिक आसानी से।

Answer 7

एचटीएमएल और सीएसएस ने लचीलेपन की एक डिग्री विकसित की है जिसका अर्थ है कि यहां तक ​​कि वैचारिक रूप से "ब्लॉक" तत्व जैसे <div>(एचटीएमएल का सबसे पुराना और सबसे सामान्य रूप ब्लॉक सामग्री) को ब्लॉक के रूप में प्रदर्शित करने की आवश्यकता नहीं है:

div { display: inline; }

जैसा कि आप ध्यान दें, <div>अनुकरण <table>और उसके साथी यात्रियों को पुनर्खरीद किया जा सकता है । दरअसल, अधिकांश टैग कर सकते हैं। उनके विशेष भूमिकाओं को देखते हुए, मुझे शक है आप उपयोगी तरह मैक्रो टैग को पुन: मैप सकता है <html>, <head>, <body>, और <script>, लेकिन "आम" की तरह टैग <div>, <p>, <b>, <em>, <span>, और <pre>? पकड़े जाने के लिए। इनलाइन टैग ब्लॉक बनाएं, ब्लॉक इनलाइन, पूर्व स्वरूपित टैग प्रवाह, स्थिर वाले फ्लोट करते हैं। पागल हो, अगर तुम चाहो तो!

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

मुझे नहीं लगता कि यह कहना जल्दबाजी होगी कि प्रतिस्थापन भी आवश्यक है। कम से कम, यह बेहद सुविधाजनक है । एक लंबे समय के लिए, HTML नहीं था <menu>, <section>या <aside>तत्वों। फिर भी हर जगह वेब पेज और ऐप्स में मेनू, सेक्शन और साइडबार होते हैं। कैसे? क्योंकि एचटीएमएल सूची तत्वों ( <ul>, <ol>, और <li>) आसानी से पुनः प्रयोजन रहे थे और कुछ उपयोगों के मेनू कंटेनर और हिस्से के रूप में फिर से वर्गीकृत। <div>के लिए में खड़ा कर सकता है <article>, <section>, <aside>, <figure>, और <summary>। एचटीएमएल 5 ने कुछ पूर्व-उपयोग किए गए मामलों के लिए, और कुछ के साथ बीस्पोक तत्वों को जोड़ा है। यह आम, वास्तविक दुनिया के उपयोग को समायोजित करने के लिए एक महान अद्यतन और सुधार है।

फिर भी, बहुत से सामान्य मुहावरे बने हुए हैं जिनमें बीस्पोक टैग या शब्दार्थ मॉडल नहीं हैं । पेज, फुटनोट्स, पुल-कोट्स, कमेंट स्ट्रीम, संबद्ध अवतार, "लाइक," सबहेड्स और सबटाइटल जैसी चीजें जो मैं और कई अन्य लोग हर दिन इस्तेमाल करते हैं। हम क्या करने के लिए हैं? हम क्या कर सकते हैं। कक्षाओं और आईडी के साथ "पास लेकिन निष्प्रभावी" तत्वों को फिर से रखने और अगले पांच या दस या फिर कई वर्षों तक हमारे काम का समर्थन करने के लिए जब तक एचटीएमएल 6 या एचटीएमएल 7 पकड़ता है। HTML / CSS की "हाँ, यह सिद्धांत रूप में एक एक्स है, लेकिन हम इसे टैग करने जा रहे हैं और इसके साथ काम करते हैं क्योंकि Y" की क्षमता अविश्वसनीय रूप से सुविधाजनक है। अपरिहार्य, वास्तव में। यह वेब सामग्री को फ्लेक्स बनाता है, और भंगुर नहीं होता है।

इससे भी आगे जाने पर, "सिमेंटिक मार्कअप" में अतार्किक सीमाएँ हैं । यह किसी भी प्रकार की कठोर संरचना का सच है जिसे आप सामग्री के लिए कल्पना कर सकते हैं।

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

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

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

Comments

यह प्रश्न का उत्तर देने के लिए कहीं भी कैसे जाता है?

— होरसकॉल

IMO, यह इस बात के अंतर्निहित प्रश्न पर चर्चा करता है कि डिजाइनर, डेवलपर्स और सामग्री कार्यकर्ता विशिष्ट, उद्देश्य-निर्मित तत्वों (जैसे ) के स्थान पर जेनेरिक तत्वों ( <div>और <span>) का उपयोग करने का चयन क्यों करते हैं <table>। यह उन टैगों की तुलना में थोड़ा अधिक मेटा है, लेकिन यह सीधे पैटर्न और उपयोग के सिद्धांतों से बोलता है।

— जोनाथन यूनिस

@ हर्सकोल वास्तव में, यहां सभी उत्तरों में से, यह सबसे अधिक सुसंगत है, और आपके उत्तर का समर्थन करता है। मैं कहूंगा कि वे अच्छी तरह से मेष करेंगे।

— जोनाथन यूनिस

मुझे नहीं पता कि क्या मैं इसके विपरीत div(जेनेरिक के रूप में) table(उद्देश्य-निर्मित) के रूप में जाऊंगा । वे दोनों उद्देश्य-निर्मित हैं, दो अलग-अलग (अभी तक आंशिक रूप से अतिव्यापी) उद्देश्यों के लिए। यह, मेरा मानना ​​है, सवाल का दिल है।

— एरिक किंग

@ EricKing यह कहना उचित है कि divइसका एक उद्देश्य है। लेकिन divऔर spanबहुत जरूरत नहीं है विशिष्ट इच्छित उद्देश्य है कि table, thead, tdआदि है। यदि आप divसाइडबार के लिए शरारती तत्वों का उपयोग करते हैं, तो उद्धरण, अनुभाग समूह, आदि -। दस्तावेज़ में कहीं भी बहुत अधिक नहीं होगा, कोई भी बाहर नहीं जाएगा । एक unenclosed साथ कर रही प्रयास करें thead, tdया li। इसके बजाय "उद्देश्य-निर्मित," शायद "उद्देश्य-विशिष्ट" या "एक विशिष्ट इच्छित भूमिका के साथ।"

— जोनाथन यूनिस

Answer 8

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

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

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