HTML में लेआउट के लिए टेबल का उपयोग क्यों नहीं करें?




css design (24)

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

क्यूं कर?

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

  • लेआउट से सामग्री को अलग करना अच्छा है
    लेकिन यह एक निराशाजनक तर्क है; Cliche सोच रहा है । मुझे लगता है कि यह सच है कि लेआउट के लिए तालिका तत्व का उपयोग टैब्यूलर डेटा के साथ बहुत कम करना है। तो क्या? क्या मेरे मालिक की देखभाल है? क्या मेरे उपयोगकर्ता परवाह है?

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

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

  • कोड की पठनीयता
    मुझे लगता है कि यह चारों ओर एक और तरीका है। अधिकांश लोग HTML को समझते हैं, कुछ सीएसएस को समझते हैं।

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

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

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

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


I'd like to add that div-based layouts are easer to mantain, evolve, and refactor. Just some changes in the CSS to reorder elements and it is done. From my experience, redesign a layout that uses tables is a nightmare (more if there are nested tables).

Your code also has a meaning from a semantic point of view.


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

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

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

मुझे लगता है कि टेबल बनाम divs आपके आवेदन की जरूरतों के लिए नीचे आता है।

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

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


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

लेआउट से सामग्री को अलग करना अच्छा है लेकिन यह एक दुर्भाग्यपूर्ण तर्क है; क्लिच सोच रहा है।

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

तो क्या? क्या मेरे मालिक की देखभाल है? क्या मेरे उपयोगकर्ता परवाह है?

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

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

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

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

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

कोड की पठनीयता मुझे लगता है कि यह दूसरी तरफ है। अधिकांश लोग एचटीएमएल समझते हैं, सीएसएस को थोड़ा समझते हैं। यह आसान है।

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

एसईओ के लिए टेबल का उपयोग न करना बेहतर है

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

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

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

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

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

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

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

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


This isn't really about whether 'divs are better than tables for layout'. Someone who understands CSS can duplicate any design using 'layout tables' pretty straightforwardly. The real win is using HTML elements for what they are there for. The reason you would not use tables for non-tablular data is the same reason you don't store integers as character strings - technology works much more easily when you use it for the purpose for which it is desgined. If it was ever necessary to use tables for layout (because of browser shortcomings in the early 1990s) it certainly isn't now.


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

इसलिए, एक वेबसाइट जिसका उद्देश्य सामग्री से डिज़ाइन को बनाए रखने का लाभ दिखाना है, अब नियमित रूप से डिज़ाइन में सामग्री डालने के अनजान एसआईएन को नियमित रूप से करता है। (यदि 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>

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

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


Because it's HELL to maintain a site that uses tables, and takes a LOT longer to code. If you're scared of floating divs, go take a course in them. They're not difficult to understand and they're approximately 100 times more efficient and a million times less a pain in the ass (unless you don't understand them -- but hey, welcome to the world of computers).

Anyone considering doing their layout with a table better not expect me to maintain it. It's the most ass-backwards way to render a website. Thank god we have a much better alternative now. I would NEVER go back.

It's scary that some folks might not be aware of the time and energy benefits from creating a site using modern tools.


I was surprised to see some issues were not already covered, so here are my 2 cents, in addition to all the very valid points made earlier:

.1. CSS & SEO:

a) CSS used to have a very significant impact on SEO by allowing to position the content in the page wherever you want. A few years ago, Search Engines were giving a significant emphasis to "on-page" factors. Something at the top of the page was deemed more relevant to the page than something located at the bottom. "Top of the page" for a spider meant "at the beginning of the code". Using CSS, you could organize your keyword-rich content at the beginning of the code, and still position it wherever you liked in the page. This is still somewhat relevant, but on page factors are less and less important for page ranking.

b) When the layout is moved over to CSS, the HTML page is lighter and therefore loads faster for a search engine spider. (spiders don't bother downloading external css files). Fast loading pages is an important ranking consideration for several search engines, including Google

c) SEO work often requires testing and changing things, which is much more convenient with a CSS based layout

.2. Generated content:

A table is considerably easier to generate programmically than the equivalent CSS layout.

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

Generating a table is simple and safe. It is self-contained and integrates well within any template. To do the same with CSS is considerably harder and may be of no benefit at all: hard to edit the CSS stylesheet on the flight, and adding the style inline is no different from using a table (content is not separated from layout).

Further, when a table is generated, the content (in variables) is already separated from the layout (in code), making it as easy to modify.

This is one reason why some very well designed websites (SO for instance) still use table layouts.

Of course, if the results need to be acted upon through JavaScript, divs are worth the trouble.

.3. Quick conversion testing

When figuring out what works for a specific audience, it is useful to be able to change the layout in various ways to figure out what gets the best results. A CSS based layout makes things considerably easier

.4. Different solutions for different problems

Layout tables are usually dissed because "everybody knows divs & CSS" are the way to go.

However the fact remains that tables are faster to create, easier to understand and are more robust than most CSS layouts. (Yes, CSS can be as robust, but a quick look through the net on different browsers and screen resolutions shows it's not often the case)

There are a lot of downsides to tables, including maintenance, lack of flexibility... but let's not throw the baby with the bath water. There are plenty of professional uses for a solution which is both quick and reliable.

Some time ago, I had to rewrite a clean and simple CSS layout using tables because a significant portion of the users would be using an older version of IE with really bad support for CSS

I, for one, am sick and tired of the knee-jerk reaction "Oh noes! Tables for layout!"

As for the "it wasn't intended for that purpose and therefore you shouldn't use it this way" crowd, isn't that hypocrisy? What do you think of all the CSS tricks you have to use to get the darn thing working in most browsers? Were they meant for that purpose?


I guess it's true that using the table element for layout has little to do with tabular data. तो क्या? Does my boss care? Do my users care?

Google and other automated systems do care, and they're just as important in many situations. Semantic code is easier for a non-intelligent system to parse and process.


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


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

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

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

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

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

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


Layout flexibility
Imagine you're making a page with a large number of thumbnails.
DIVs :
If you put each thumbnail in a DIV, floated left, maybe 10 of them fit on a row. Make the window narrower, and BAM - it's 6 on a row, or 2, or however many fit.
TABLE:
You have to explicitly say how many cells are in a row. If the window is too narrow, the user has to scroll horizontally.

Maintainability
Same situation as above. Now you want to add three thumbnails to the third row.
DIVs:
Add them in. The layout will automatically adjust.
TABLE: Paste the new cells into the third row. ऊप्स! Now there are too many items there. Cut some from that row and put them on the fourth row. Now there are too many items there. Cut some from that row... (etc)
( Of course, if you're generating the rows and cells with server-side scripting, this probably won't be an issue. )


It's worth figuring out CSS and divs so the central content column loads and renders before the sidebar in a page layout. But if you are struggling to use floating divs to vertically align a logo with some sponsorship text, just use the table and move on with life. The Zen garden religion just doesn't give much bang for the buck.

The idea of separating content from presentation is to partition the application so different kinds of work affect different blocks of code. This is actually about change management. But coding standards can only examine the present state of code in a superficial manner.

The change log for an application that depends on coding standards to "separate content from presentation" will show a pattern of parallel changes across vertical silos. If a change to "content" is always accompanied by a change to "presentation", how successful is the partitioning?

If you really want to partition your code productively, use Subversion and review your change logs. Then use the simplest coding techniques -- divs, tables, JavaScript, includes, functions, objects, continuations, whatever -- to structure the application so that the changes fit in a simple and comfortable manner.


The fact that this is a hotly debated question is a testament to the failure of the W3C to anticipate the diversity of layout designs which would be attempted. Using divs+css for semantically-friendly layout is a great concept, but the details of implementation are so flawed that they actually limit creative freedom.

I attempted to switch one of our company's sites from tables to divs, and it was such a headache that I totally scrapped the hours of work I had poured into it and went back to tables. Trying to wrestle with my divs in order to gain control of vertical alignment has cursed me with major psychological issues that I will never shake as long as this debate rages on.

The fact that people must frequently come up with complex and ugly workarounds to accomplish simple design goals (such as vertical alignment) strongly suggests that the rules are not nearly flexible enough. If the specs ARE sufficient, then why do high-profile sites (like SO) find it necessary to bend the rules using tables and other workarounds?


लेआउट के लिए एक टेबल खराब नहीं होगा। लेकिन आप उस समय लेआउट को प्राप्त नहीं कर सकते जो आपको केवल एक टेबल के साथ चाहिए। बहुत जल्द आपके पास 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


The whole idea around semantic markup is the separation of markup and presentation, which includes layout.

Div's aren't replacing tables, they have their own use in separating content into blocks of related content (, ). When you don't have the skills and are relying on tables, you'll often have to separate your content in to cells in order to get the desired layout, but you wont need to touch the markup to achieve presentation when using semantic markup. This is really important when the markup is being generated rather than static pages.

Developers need to stop providing markup that implies layout so that those of us who do have the skills to present content can get on with our jobs, and developers don't have to come back to their code to make changes when presentation needs change.


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

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

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

तो आपके उत्तर रखरखाव, अभिगम्यता और एसईओ हैं।

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


Looks like you are just used to tables and that's it. Putting layout in a table limits you for just that layout. With CSS you can move bits around, take a look at http://csszengarden.com/ And no, layout does not usally require a lot of nested divs.

With no tables for layout and proper semantics HTML is much cleaner, hence easier to read. Why should someone who cannot understand CSS try to read it? And if someone considers himself to be webdeveloper then the good grasp of CSS is a must.

SEO benefits come from the ability to have most important content higher up the page and having better content-to-markup ratio.

will


Tables are not in general easier or more maintainable than CSS. However, there are a few specific layout-problems where tables are indeed the simplest and most flexible solution.

CSS is clearly preferable in cases where presentational markup and CSS support the same kind of design, no one in their right mind would argue that font -tags are better than specifying typography in CSS, since CSS gives you the same power than font -tags, but in a much cleaner way.

The issue with tables, however, is basically that the table-layout model in CSS is not supported in Microsoft Internet Explorer. Tables and CSS are therefore not equivalent in power. The missing part is the grid-like behavior of tables, where the edges of cells align both vertically and horizontally, while cells still expand to contain their content. This behavior is not easy to achieve in pure CSS without hardcoding some dimensions, which makes the design rigid and brittle (as long as we have to support Internet Explorer - in other browsers this is easliy achieved by using display:table-cell ).

So it's not really a question of whether tables or CSS is preferable, but it is a question of recognizing the specific cases where use of tables may make the layout more flexible.

The most important reason for not using tables is accessibility. The Web Content Accessibility Guidelines http://www.w3.org/TR/WCAG10/ advice againt using tables for layout. If you are concerned about accessibility (and in some cases you may be legally obliged to), you should use CSS even if tables are simpler. Note that you can always create the same layout with CSS as with tables, it might just require more work.


Also, don't forget, tables don't quite render well on mobile browsers. Sure, the iPhone has a kick-ass browser but everyone doesn't have an iPhone. Table rendering can be peanuts for modern browsers, but it's a bunch of watermelons for mobile browsers.

I have personally found that many people use too many <div> tags, but in moderation, it can be extremely clean and easy to read. You mention that folks have a harder time reading CSS than tables; in terms of 'code' that maybe true; but in terms of reading content (view > source) it is a heck of a lot easier to understand the structure with stylesheets than with tables.


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

यदि यह आपको "डब्ल्यूटीएफ" नहीं कहता है तो आपको वास्तव में कुल-एड्स को खाली करने की ज़रूरत है।

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

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

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


I think that boat has sailed. If you look at the direction the industry has taken you will notice that CSS and Open Standards are the winners of that discussion. Which in turn means for most html work, with the exception of forms, the designers will use divs instead of tables. I have a hard time with that because I am not a CSS guru but thats the way it is.


  • 508 Compliance - the ability for a screenreader to make sense of your markup.
  • Waiting for render - tables don't render in the browser until it gets to the end of the </table> element.

No arguments in DIVs favour from me.

I'd say : If the shoe fits, wear it.

It's worth noting that it's difficult if not impossible to find a good DIV+CSS method of rendering contents in two or three columns, that is consistent on all browsers, and still looks just the way I intended.

This tips the balance a bit towards tables in most of my layouts, and altough I feel guilty of using them (dunny why, people just say it's bad so I try to listen to them), in the end , the pragmatic view is it's just easier and faster for me to use TABLEs. I'm not being payed by the hour, so tables are cheaper for me.





layout