काम को अंतिम रूप देने पर डब्ल्यू 3 सी एक्सएचटीएमएल/सीएसएस सत्यापन कितना महत्वपूर्ण है?

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

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

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

मेरा दृष्टिकोण यह सुनिश्चित करने के लिए होता है कि मैं सभी पृष्ठों पर पूरी तरह से मान्य कर सकता हूं, हालांकि मैं अभी भी पृष्ठ को एप्लिकेशन/एक्सएचटीएमएल + एक्सएमएल के बजाय टेक्स्ट/एचटीएमएल के रूप में भेजता हूं, इसलिए मुझे कुछ याद आ रही घटना में कोई बदसूरत एक्सएमएल त्रुटियां नहीं हैं।

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

यद्यपि यहां लेने के लिए व्यावहारिकता का एक निश्चित तत्व है। मैं निश्चित रूप से एक क्लाइंट की साइट के लिए वैध होने के लिए कर सकता हूं, लेकिन मैं अपनी जगह पर अधिक जोखिम लेने के इच्छुक हूं।

मुझे लगता है कि यह केवल "तकनीकी" लोग हैं जो वास्तव में "100% मानक अनुपालन" की देखभाल करते हैं। मेरे सामान्य पृष्ठ उपभोक्ता (= उपयोगकर्ता) परवाह नहीं करते हैं यदि "मेनू सीमा चित्र तत्व" के लिए कोई alt-विशेषता नहीं है।

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

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

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

ए) वही देखना चाहिए

बी) मानकों के अनुरूप जितना संभव हो, लेकिन इतना गुदा नहीं है कि यह काम खत्म करने को रोकता है

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

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

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

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

डोम एक बहुत ही बुनियादी कदम है जिसके साथ एक वेब ब्राउज़र शुरू होता है। इसका मुख्य प्रवाह है:

1. डीओएम पेड़ बनाने के लिए HTML को पार्स करना
2. पेड़ निर्माण प्रस्तुत करें
3. रेंडर पेड़ का लेआउट
4. रेंडर पेड़ पेंटिंग

चरण 1 सामग्री का पेड़ देता है, टैग को DOM नोड्स में बदल दिया जाता है। चरण 2 स्टाइलिंग जानकारी युक्त रेंडर पेड़ देता है।

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

आखिरकार, डोम भी आपकी जावास्क्रिप्ट घटनाओं का आधार है। इसलिए, इसकी मान्यता इंटरैक्शन परत में भी मदद करती है।

सिवाय इसके कि वैधकर्ता स्वयं इतने सकारात्मक गुदा हैं,  जब भी कोई त्रुटि या चेतावनी ध्वजांकित होती है जब भी एक -मोज़- या -webkit या -o- i.e. ब्राउज़र विशिष्ट योग्यता अवधि का उपयोग किया जाता है। वे भी चाहते हैं कि आप 0 या अन्य इकाइयों के बजाय 0px निर्दिष्ट करें शून्य शून्य है जो भी वैधकर्ता इसे जांचना चाहता है!

बस वर्डप्रेस बीसलेवन style.css को सत्यापित करने का प्रयास करें, यह 140 विषम त्रुटियों को फेंकता है जो ऊपर की सभी प्रकृति हैं या वैधकर्ता पार्स त्रुटियों से ठीक हो रहा है

यदि आप गेहूं को चोटी से सॉर्ट नहीं कर सकते हैं तो वैधकर्ता बेकार हैं !!!

हमें उन वैधताओं की आवश्यकता है जो ब्राउज़र विशिष्ट योग्यता शर्तों को पहचानते हैं!