क्या यह तालिका में एक HTML फॉर्म सेट करने के लिए अर्थात् सही है?

Question

हम सभी जानते हैं कि लेआउट सहायता के रूप में तालिका का उपयोग करना गलत है।

मैं अक्सर रूपों को संरचनाओं के लिए टेबल का उपयोग करता हूं। क्या यह अर्थात् सही है?

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

धन्यवाद

Answer 1

============

संपादित करें: धन्यवाद @Will मार्टिन। दरअसल, मैंने जांच की, ऐसा लगता है कि संरचना के रूप में तालिका का उपयोग करना अर्थात् सही है क्योंकि यह w3c मानकों के दस्तावेज़ पर प्रदर्शित होता है। यहाँ देखें: http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1

============

मैं एक लेख (दुर्भाग्य से फ्रेंच में) कल कि मूल रूप से कह रहे थे कि आप रूपों की संरचना करने के तालिका का उपयोग नहीं करना चाहिए पढ़ा है । (http://www.alsacreations.com/article/lire/1209-display-inline-block.html)

यह नहीं कहता कि क्यों नहीं, लेकिन यह कहता है कि आपको प्रदर्शन का उपयोग करना चाहिए: इनलाइन-ब्लॉक। हालांकि सावधान रहें, डिस्प्ले: इनलाइन-ब्लॉक एक अच्छा पैरामीटर है लेकिन आईई 7-6 ब्राउज़ करते समय इसमें कमी आई है (आश्चर्य की बात नहीं है)।

इस लेख (अंग्रेजी में) पढ़ें कि 'इनलाइन-ब्लॉक' बताते =>http://robertnyman.com/2010/02/24/css-display-inline-block-why-it-rocks-and-why-it-sucks/

Answer 2

यह राय का मामला नहीं है - वहाँ रूपों के साथ तालिकाओं का उपयोग के साथ दोनों अर्थ और व्यावहारिक समस्याएं हैं।

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

लेकिन जब आपके पास एक ऐसा रूप है जो स्पष्ट रूप से एक तालिका है, तब भी आपको पहले अन्य तरीकों पर विचार करना चाहिए - this article on 24 Ways में दर्शाए गए अनुसार मिश्रण तालिका और रूपों के साथ पहुंच क्षमताएं हैं। वही लेख यह भी दिखाता है कि आप एक ही काम करने के लिए fieldset एस को कैसे अनुकूलित कर सकते हैं, और निश्चित रूप से एक दिलचस्प पढ़ने के लिए बनाता है।

Answer 3

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

Answer 4

यह प्रपत्र पर निर्भर करता है, मुझे लगता है।कुछ रूपों एक तालिका के रूप अर्थपूर्ण हो सकता है - उदाहरण के लिए, एक पर आप कुंजी-मान जोड़ों की एक श्रृंखला है:

<table> 
<tr> 
    <th scope="row"><label for="first-name">First Name:</label></th> 
    <td><input type="text" name="first_name" id="first-name" /></td> 
</tr> 
<tr> 
    <th scope="row"><label for="last-name">Last Name:</label></th> 
    <td><input type="text" name="last_name" id="last-name" /></td> 
</tr> 
<tr> 
    <th scope="row"><label for="color">Favorite Color:</label></th> 
    <td><input type="text" name="color" id="color" /></td> 
</tr> 
</table> 

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

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

<style type="text/css"> 
label { display: block; text-align: right; } 
label input { width: 100px; } 
</style> 

<label for="first-name">First Name: <input type="text" name="first_name" id="first-name" /></label> 

<label for="last-name">Last Name: <input type="text" name="last_name" id="last-name" /></label> 

<label for="color">Favorite Color: <input type="text" name="color" id="color" /></label> 

है कि आप कम HTML के साथ बहुत ही प्रभाव देना होगा:

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

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

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

Answer 5

वेब मानकों प्रोजेक्ट ने एचटीएमएल रूपों में तालिकाओं से बचने के तरीके और कैसे एक पूर्ण ट्यूटोरियल बनाया है।

http://www.webstandards.org/learn/tutorials/accessible-forms/