HTML सत्यापन: क्या यह इसके लायक है?


52

यह सुनिश्चित करने के क्या फायदे और नुकसान हैं (यदि कोई है) तो सुनिश्चित करें कि सभी पेज गैर-वैध HTML होने की तुलना में मान्य हैं जो कि सभी प्रमुख ब्राउज़रों पर काम करते हैं?

इसके अलावा, जावास्क्रिप्ट के बाद वैध HTML होना महत्वपूर्ण होने के रूप में निष्पादित होता है?


5
यह आपके प्रश्न का उत्तर नहीं देता है, लेकिन ... आपके पृष्ठ पर एक सिद्धांत रखने से ब्राउज़र को quirks मोड के बजाय मानक मोड में रखा जाएगा। मैं क्या मतलब है देखने के लिए quirks मोड देखें।
इवान प्लाइस

1
@ इवान प्लाइस - हालांकि कोई भी डॉक्टर नहीं । कुछ DOCTYPES वास्तव में quirks या लगभग मानक मोड को ट्रिगर करते हैं। HTML5 कल्पना इसे और अधिक विस्तार से बताती है।
लूसीसुबल

1
@luiscubal HTML 5 में नया है क्योंकि en.wikipedia.org/wiki/Quirks_mode से यह कहा गया है कि ... यदि एक पूर्ण DOCTYPE मौजूद है तो ब्राउज़र मानक मोड का उपयोग करेगा, और यदि यह अनुपस्थित है तो ब्राउज़र quirks मोड का उपयोग करेगा । "।
इवान प्लाइस

@ ईवन प्लास पिछले HTML संस्करणों के बारे में निश्चित नहीं है, लेकिन HTML5 विशेष रूप से बताता है कि प्राचीन DOCTYPES के साथ क्या करना है: whatwg.org/specs/web-apps/current-work/multipage
...

1
@ ईवन पट्टिका दूसरे शब्दों में, "डीटीडी एचटीएमएल 2.0 लेवल 1" क्विज़ मोड को ट्रिगर करता है।
1

जवाबों:


42

मुझे लगता है कि यह निश्चित रूप से करने योग्य है , लेकिन आपको सत्यापन के लिए कभी भी गुलाम नहीं होना चाहिए - यह एक मूर्ख खेल है।

http://www.codinghorror.com/blog/2009/03/html-validation-does-it-matter.html

  1. अपने HTML को मान्य करें। जानते हैं कि इसका क्या अर्थ है मान्य HTML मार्कअप। टूलींग को समझें। अधिक जानकारी हमेशा कम जानकारी से बेहतर होती है। अंधा क्यों उड़ता है?

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


3
मैं यह दूसरा होगा। मैंने जावास्क्रिप्ट पुस्तकालयों के साथ बहुत सारे मुद्दे देखे हैं जिन्हें अमान्य HTML पर दोषी ठहराया जा सकता है। कई नेस्टेड फॉर्म और अवैध रूप से बंद टैग प्रमुख अपराधी हैं। जैसे जेफ कहते हैं कि गुलाम मत बनो, लेकिन शिकायत मत करो जब jQuery काम नहीं करता है क्योंकि आपका पृष्ठ वैध HTML (XHTML, HTML 5 या जो आप एक सिद्धांत के रूप में चुनते हैं) नहीं है।
गारेथ फ़रिंगटन

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

@MarcoDemaio क्यों दुखी है? एक ग्राहक और एक अंतिम-उपयोगकर्ता के रूप में, मैं इस बारे में अधिक चिंतित हूं कि साइट सभी ब्राउज़रों पर काम करती है या नहीं (जिनमें से अधिकांश मानकों को शुरू करने के लिए अनुपालन नहीं हैं) की तुलना में यह मान्य है या नहीं। मान्य HTML वास्तव में कोई फर्क नहीं पड़ता। Google, Facebook, Twitter, इस साइट आदि किसी भी संबंधित साइट के पास मान्य मार्कअप नहीं है। क्यों? क्योंकि मान्य HTML कुछ नहीं करता है, लेकिन पृष्ठ को ब्लोट करें और अपनी बैंडविड्थ लागत बढ़ाएं।
NullUserException

एक ही चीज पूरी तरह से इंडेंट मार्कअप के लिए जाती है। यह और भी बेकार है, यह बैंडविड्थ की 100% बर्बादी है और इसका कोई व्यावहारिक उपयोग नहीं है।
NullUserException

@NullUserException: मुझे लगता है कि यह दुखद है क्योंकि मुझे पता चला है कि मान्य वेबसाइटें आमतौर पर सभी ब्राउज़रों पर बहुत बेहतर प्रस्तुत करती हैं। एलन के उत्तर के लिए मेरी टिप्पणी देखें: webmasters.stackexchange.com/a/373/1429 मेरे द्वारा सहेजी गई वेबसाइट को सत्यापित करना और अभी भी मुझे भारी मात्रा में बचाता है। सही इंडेंटेड मार्कअप के बारे में मैंने कभी इसके बारे में चश्मा नहीं सुना। मुझे 3 स्थानों द्वारा इंडेंट करना पसंद है, और आप एक द्वारा इंडेंट करना पसंद कर सकते हैं।
मार्को डेमैयो

32

मैं मान्य HTML को एक सार्थक लक्ष्य मानता हूं, लेकिन इसे अच्छी वेबसाइटों के निर्माण के रूप में देखा नहीं जा सकता।

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

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


22

मुझे लगता है कि यह इसके लायक है, क्योंकि मैंने सत्यापन की मांग करके कई मार्कअप और तर्क त्रुटियों को पकड़ा है। यह उन "जरूरी लेकिन पर्याप्त नहीं" चीजों में से एक है। मान्य मार्कअप, कोड की तरह जो त्रुटियों (चेतावनियों) से मुक्त (या JSlint के माध्यम से) संकलन करता है, चेतावनी और संकेत, यह सही होने के लिए एक अच्छा पहला कदम है।


+1 इस पर पूरी तरह सहमत हैं। जेएस और हाउ-थिंग्स-डिसप्लाइड बग्स के बाद चलने वाले पृष्ठों की भारी मात्रा में समय की बचत होती है, जो इतने रहस्यमय प्रतीत होते हैं, और केवल एक कीड़े या बंद किए गए HTML टैग के कारण होते हैं। FF addon Html Validator [ addons.mozilla.org/en-US/firefox/addon/html-validator/] जैसे टूल के अलावा यह आपके सभी पृष्ठों को स्थानीय रूप से मान्य करने के लिए सख्त है।
मार्को डेमायो

9

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


8

अपने आप में सत्यापन इतना महत्वपूर्ण नहीं है, क्योंकि कुछ ब्राउज़र 100% अनुरूप हैं और नियम की व्याख्या करने के तरीके पर 100% स्पष्ट नहीं है।

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

नीचे, वैध होने के कारण खेल के शीर्ष पर बने रहना आसान है और व्यापक दर्शकों के साथ जितना संभव हो उतना संगत होना चाहिए।


4

सबसे अच्छा तरीका यह सीखना है कि कौन सा अवैध HTML खराब है, और कौन सा अवैध HTML मायने नहीं रखता है।

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

हालाँकि, XHTML के <br>बजाय उपयोग करने से <br />कोई फर्क नहीं पड़ता - सभी ब्राउज़र समस्याओं के बिना लाइन ब्रेक के रूप में दोनों की व्याख्या करेंगे। targetलिंक पर विशेषता का उपयोग करना अमान्य है, लेकिन सबसे खराब स्थिति यह है कि ब्राउज़र एक नई विंडो में लिंक नहीं खोलता है।


targetसंक्रमणकालीन XHTML में मान्य है, और केवल masochists सख्त उपयोग करते हैं। क्लोजिंग स्लैश को छोड़ने से आपका पेज अवैध XML हो जाएगा, जो संभवतः स्क्रीन स्क्रेपर्स को भ्रमित करेगा। यदि आप XHTML का उपयोग करना चुनते हैं, तो आपका पृष्ठ कम से कम XML मान्य होना चाहिए।
TGR

1
@ टैग: मजेदार, मुझे लगा कि मसोचिस्ट गैर-मानक मोड को पसंद करते हैं। यहां तक ​​कि संक्रमणकालीन सिद्धांतों की अपनी समस्याएं हैं ("लगभग मानकों" मोड आदि का उपयोग करके)
डिसएगंटंटल्डगेट

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

3

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

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

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


मैं सहमत हूं - अपने वेब पेज को मान्य करें, लेकिन कुछ परिस्थितियों में, आप चेतावनियों को नजरअंदाज करना चुन सकते हैं, जब तक आप जानते हैं कि वे वहां क्यों हैं
केसबेश

3

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

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


2
Google ने स्पष्ट रूप से कहा है कि अमान्य HTML का रैंकिंग पर कोई प्रभाव नहीं है। हालाँकि मैं वह मामला देख सकता हूँ जहाँ HTML इतनी विकृत है कि पृष्ठ पर वास्तविक सामग्री को मकड़ियों द्वारा पढ़ा नहीं जा सकता है - हालाँकि इस मामले में यह लगभग निश्चित है कि ब्राउज़र प्रतिपादन समस्याओं का प्रदर्शन करना शुरू कर देंगे।
असंतुष्टGoat

@DisgruntledGoat तुम सही हो, यहाँ उस के लिए एक संदर्भ है: youtube.com/watch?v=FPBACTS-tyg
जेसनबिरच

@DisgruntledGoat जाहिर है ... Google अपने आप में अमान्य HTML से भरा है, और मुझे याद है कि उन्होंने कहा था कि वे वास्तव में परवाह नहीं करते हैं और यह एक अच्छी बात है कि अवैध HTML का मतलब है कि तेजी से लोड समय का मतलब है।
NullUserException

3

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


2

सत्यापन उपयोगी है क्योंकि यह आपको कुछ कठिन-से-पकड़ने की त्रुटियों जैसे स्पॉट करने में मदद कर सकता है

<input name=foo value=<?php echo htmlspecialchars($_GET['foo']); ?> />

या अप्रत्याशित ब्राउज़र व्यवहार (उदाहरण के लिए, aफ़ायरफ़ॉक्स में कभी-कभी बदसूरत तरीके से ब्लॉक तत्वों को डाल सकता है)।


2

एक बिंदु जो अभी तक किसी ने भी उल्लेख नहीं किया है वह यह है कि अवैध एचटीएमएल धीमी गति प्रदान कर सकता है जबकि प्रदर्शन करते समय ब्राउज़र गैर मानक HTML की समझ बनाने की कोशिश कर रहा है।


अगर मैं कर सकता तो मैं इसे कम कर देता। मुझे अत्यधिक संदेह है कि इसका कोई भी असरदार प्रभाव है; मैं वैध मार्कअप पृष्ठ के साथ और अधिक लोड (विशेष रूप से धीमी / मोबाइल कनेक्शन पर) के लिए और अधिक समय की आवश्यकता के साथ संबंधित होगा ।
NullUserException

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

1

वैध html होने का कोई नुकसान नहीं है। वहाँ एक कारण है कि पहली जगह में एक कल्पना क्यों है और चीजों को कैसे काम करना चाहिए इसे परिभाषित करने के लिए बहुत प्रयास किया जा रहा है।

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

इसलिए, ऐनक को पूरा करने और वैध html लिखने के लिए आपके लिए अच्छा है, कोई नुकसान नहीं।


यदि आप कल्पना को पूरा करते हैं, तो हम आपको किन सर्च इंजनों की उच्च रैंकिंग देते हैं?

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

@kinopiko: यदि कोई हैं, तो यह कोई भी प्रमुख नहीं है (Google, Yahoo, Bing, Ask)। एक के बाद पूरा गड़बड़ है कि एक अनुभवी (मानव) वेब डेवलपर नहीं पढ़ सकते हैं शायद आप में बाधा जाएगा कोड की, लेकिन कुछ "अवैध" विशेषताओं का उपयोग करते हुए रैंकिंग पर बिल्कुल शून्य प्रभाव पड़ता है।
असंतुष्टGoat

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

1

कुछ HTML सत्यापन त्रुटियों के कारण गैर-स्पष्ट लेआउट मुद्दे (जैसे गलत तरीके से नेस्टेड / अशुद्ध टैग), जावास्क्रिप्ट बग (जैसे एक idसे अधिक बार उपयोग करना ), और कुछ उपयोगकर्ताओं के लिए समस्याएँ (जैसे altछवियों पर सार्थक या रिक्त विशेषता शामिल नहीं) हो सकती हैं।

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


1

एक बिंदु जिसका किसी ने उल्लेख नहीं किया है वह है भविष्य के ब्राउज़र के विकास। हालाँकि आज के सभी ब्राउज़र अमान्य मार्कअप को अपेक्षाकृत अच्छी तरह से संभालते हैं, लेकिन ऐसा हमेशा नहीं हो सकता है।

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


मुझे कहना है कि मुझे आश्चर्य है कि अगर यह सच है।

2
हाँ, मैं किसी भी ब्राउज़र को <font>टैग या उसके ilk के लिए समर्थन छोड़ने वाला नहीं देख सकता ।
असंतुष्टGoat

मैं यह नहीं देखता कि समस्या क्या है - भविष्य में अमान्य या अमान्य मार्कअप का समर्थन बदल सकता है । अधिकांश ब्राउज़रों में (X) HTML के अपूर्ण कार्यान्वयन को देखना, निश्चित रूप से आप मान्य मार्कअप के साथ सुरक्षित रहना चाहते हैं। वैध मार्कअप से जुड़ी कोई लागत नहीं है, केवल यह जानने के अलावा कि आप क्या कर रहे हैं।
CJM

1

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


  • DTD- आधारित (HTML4, XHTML1 @ W3C) - इसके लायक नहीं हो सकता है। DTD आदिम है और, उदाहरण के लिए, अधिकांश विशेषताओं की वैधता की जांच नहीं कर सकता है। आप ज्यादातर संस्थाओं और नेस्टिंग के बारे में त्रुटियों को समझने के लिए कठिन हो जाएंगे।

  • HTML5 सत्यापनकर्ता - हाँ । निश्चित रूप से। एचटीएमएल 5 अधिक व्यावहारिक है और कुछ हानिरहित निर्माणों की अनुमति देता है जो त्रुटियां हुआ करती थीं। ओटोह हेनरी के सत्यापनकर्ता वास्तविक समस्याओं की खोज करने में बहुत अधिक गहन और बेहतर हैं।


जेएस-जनरेट कोड की वैधता मायने रखती है, क्योंकि ब्राउज़र डोम पर काम करते हैं, भले ही यह कैसे बनाया गया हो। यदि आप उपयोग करते हैं document.write(), तो आपको सिंटैक्स सही करने के लिए भी ध्यान रखना होगा (यह पृष्ठ स्रोत के रूप में उसी पार्सर से गुजरता है)।


1

यहां तक ​​कि अगर आपका HTML सभी प्रमुख ब्राउज़रों पर काम करता है, तो भी यह करने योग्य है क्योंकि यह कभी-कभी googlebot जैसे खोज इंजन क्रॉलर के साथ समस्या पैदा कर सकता है। उदाहरण के लिए इसे देखें:

http://www.codeproject.com/KB/server-management/Google_Indexing_Problem.aspx


0

Google और बिंग एक सीएसएस कारक के रूप में CSS या HTML सत्यापन का उपयोग कभी नहीं करेंगे और न ही करेंगे।

अधिकांश वेबसाइटों में दर्जनों से सैकड़ों त्रुटियां हैं और आपको उनके बारे में चिंता करने की आवश्यकता नहीं है क्योंकि सभी खोज इंजन इस बात की परवाह करते हैं कि पेज कैसे प्रस्तुत होता है। बस सुनिश्चित करें कि आपकी वेबसाइट सभी प्रमुख ब्राउज़रों और Google के फ़ेच में सही तरीके से प्रस्तुत हो ।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.