XHTML5 क्यों नहीं?


53

तो, HTML5 बिग स्टेप फॉरवर्ड है, मुझे बताया गया है। हमने जो अंतिम कदम उठाया, उससे मुझे पता चला कि मैं XHTML का परिचय था। फायदे स्पष्ट थे: सादगी, सख्ती, मानक XML पार्सर और जनरेटर का उपयोग करने की क्षमता वेब पृष्ठों के साथ काम करने के लिए, और इसी तरह।

तब कितना अजीब और निराशा होती है, कि एचटीएमएल 5 में वह सब वापस आ जाता है: एक बार फिर हम एक गैर-मानक वाक्य रचना के साथ काम कर रहे हैं; एक बार फिर, हमें ऐतिहासिक सामान और पार्सिंग जटिलता से निपटना होगा; एक बार फिर हम अपने मानक XML पुस्तकालयों, पार्सर्स, जनरेटर, या ट्रांसफार्मर का उपयोग नहीं कर सकते हैं; और XML (एक्स्टेंसिबिलिटी, नेमस्पेस, मानकीकरण, इत्यादि) द्वारा पेश किए गए सभी फायदे, जो कि W3C ने अच्छे कारणों को धकेलने में एक दशक बिताया, खो गए हैं।

ठीक है, हमारे पास एक्सएचटीएमएल 5 है, लेकिन ऐसा लगता है कि इसे एचटीएमएल 5 एन्कोडिंग की तरह लोकप्रियता नहीं मिली है। उदाहरण के लिए, यह SO प्रश्न देखें । यहां तक ​​कि HTML5 विनिर्देश भी कहता है कि HTML5, XHTML5 नहीं, "अधिकांश लेखकों के लिए सुझाया गया प्रारूप है।"

क्या मेरे तथ्य गलत हैं? अन्यथा, मैं ही ऐसा क्यों हूं जो इस तरह से महसूस करता है? लोग HTML5 को XHTML5 पर क्यों चुन रहे हैं?


6
+1 मैं देखता हूं कि एचटीएमएल 5 में सभी XML फायदे के नुकसान से मैं निराश नहीं हूं।
आर्सेनी मूरज़ेंको

अच्छे सवाल का सम्मान करते हुए, अच्छी तरह से रखा।
कोनराड रुडोल्फ

1
मुझे आशा है कि मैं केवल वही नहीं हूं जो HTML5 में सभी XML के नुकसान के साथ खुश हूं। उदाहरण के लिए, हम मान्य HTML5 की वैध XHTML से तुलना करते हैं। HTML5:, <!DOCTYPE html>Hello WorldXHTML:<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd"><html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body>Hello World</body></html>
zzzzBov

@zzzzBov, आप निश्चित रूप से केवल वही नहीं हैं जो खुश हैं, और इसलिए मैंने पहली बार में यह सवाल पूछा है। भी: आप गंभीरता से नहीं लिखेंगे <!DOCTYPE html>Hello World, क्या आप? इस सत्यापनकर्ता पर प्रयास करें ।
jameshfisher

1
@eegg, जाहिरा तौर पर आप पर कल्पना नहीं पढ़ा है वैकल्पिक शुरू टैग , क्योंकि मैं गंभीरता से होगा लिखना <!DOCTYPE html>Hello World!है, यह पूरी तरह से वैध एचटीएमएल 5 के रूप में। छोटे दस्तावेज़ों का मतलब कम बैंड-ओवरहेड है जो बड़ी कंपनियों के लिए महत्वपूर्ण बचत के बराबर है (क्या आपने देखा है कि Google www.google.com के लिए क्या भेजता है?)।
zzzzBov

जवाबों:


25

मैं पढ़ने की सलाह दूंगा कि हम यहां कैसे पहुंचे? । Mark Pilgrim HTML का एक उत्कृष्ट और संक्षिप्त इतिहास HTML5 तक देता है।

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


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

1
@eegg, आपकी अंतिम पंक्ति वास्तविकता के प्रति आपकी अज्ञानता को दिखाती है। बहुत अच्छा पहले से ही किसी को भी सही मानने से आया है । यह कहने के बजाय कि "यदि आप कोई गलती करते हैं, तो सब कुछ टूट गया है" इसके बजाय यह कहता है, "यदि आप इस प्रकार की गलती करते हैं] तो [यह परिणाम] वही होना चाहिए"। अगर वे प्रकाशित होने के लिए 100% सही वर्तनी, विराम चिह्न, और व्याकरण की होती तो हमारी अलमारियों पर कितनी किताबें होतीं?
zzzzBov

6
@zzzzBov, प्रकाशित पुस्तकों के साथ आपका सादृश्य अजीब है। HTML पार्सर को [यहाँ किसी भी अन्य भाषा] के लिए एक पार्सर की तुलना में अधिक क्षमाशील क्यों होना चाहिए, जहां एक त्रुटि संदेश के साथ एक सिंटैक्स त्रुटि मिलती है? यदि हमारे सी संकलकों ने टूटी हुई वाक्य रचना को चुपचाप पुन: व्याख्या करने के लिए अपनी पूरी कोशिश की तो अराजकता की कल्पना करें।
jameshfisher

@ आईएजी, मैं सोच सकता हूं कि क्या होगा यदि किसी अन्य भाषा के लिए एक पार्सर ने अधिक क्षमाशील तरीके से वाक्यविन्यास त्रुटियों के लिए प्रतिक्रिया व्यक्त की: हम गलत तरीके से गुम हुए कोष्ठकों का शिकार करने में कम समय व्यतीत करेंगे और अर्ध कॉलन और अधिक समय टाइपिंग कार्यात्मक कोड। मैं यह नहीं कह रहा हूं कि अच्छे प्रोग्रामर अभी भी अपने कार्यक्रमों को अच्छी तरह से नहीं बना पाएंगे, लेकिन यह निश्चित रूप से औसत दर्जे के प्रोग्रामर को काम कोड लिखने में मदद करेगा । एक Cकार्यक्रम संभवतः एक कार्यक्रम के समान Pythonहै, जिसमें अर्ध-कॉलोन और कोष्ठक ज्यादातर गायब हो सकते हैं, और जो कुछ बचेगा वह महत्वपूर्ण कोड है।
zzzzBov

"अनुरोधित संसाधन /past.htmlअब इस सर्वर पर उपलब्ध नहीं है और कोई अग्रेषण पता नहीं है।"
मार्को

6

यदि आप xml संगत html5 का उत्पादन करते हैं, और उन्हें xml के साथ माइम प्रकार के रूप में भेजते हैं, तो xml parser का उपयोग उन सभी के लिए किया जाएगा जो अच्छे जैज़ वापस आते हैं;)

संपादित करें: कुछ और जानकारी के लिए देखें: http://wiki.whatwg.org/wiki/HTML_vs._XHTML


"अच्छा जैज" को परिभाषित करें। AFAIK XML के रूप में HTML पार्स करने के लिए कोई फायदा नहीं है। उत्पन्न करना और बदलना अन्य मामले हैं, जो सुविधाजनक हो सकते हैं, लेकिन स्वयं के द्वारा पार्सिंग लाभ प्रदान नहीं करता है, केवल डाउनसाइड्स (यह कॉस्मेटिक बग को घातक बनाता है)।
जोएरी सेब्रेट्स

3
@ जौरी तथ्य यह है कि पार्स करना बहुत आसान है, मेरी किताब में कई कारणों से एक फायदा है (सख्त पार्सिंग त्रुटियों की खोज की सुविधा देता है, बेहतर उपकरण समर्थन क्योंकि उपकरण लिखना आसान है, इनपुट का आसान सैनिटाइजिंग इत्यादि)।
कोनराड रुडोल्फ

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

3

एचटीएमएल 5 पोस्टेल के कानून ("आप जो स्वीकार करते हैं उसमें उदार बनें") को अपनाने वाले ब्राउज़रों का तार्किक और अपरिहार्य निष्कर्ष है।

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

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


3
ब्राउज़रों की प्रतिस्पर्धा में कमी की कहानी काफी हद तक सही है। लेकिन यहाँ एक बात है: यही कारण है कि मानकों-गीक्स मौजूद हैं। यदि सभी ब्राउज़रों ने शुरुआत से ही सीधे और संकीर्ण को लागू किया था, तो W3C जैसे संगठनों को चीजों को नियंत्रण में रखने के लिए यहां रहने की आवश्यकता नहीं होगी। मानकों का पूरा बिंदु क्षति-नियंत्रण है; मानकों के लिए शरीर में ढलान देना और स्वीकार करना अपने बहुत ही उद्देश्य को हरा देता है।
jameshfisher

1
@eegg: HTML5 सभी इनपुट को वैध बनाने के लिए पार्सिंग नियमों को फिर से परिभाषित करता है और अभी भी अनुमानित परिणाम है। यदि सिंटैक्स त्रुटियां असंभव हैं, तो बग की एक पूरी कक्षा को शुरू से खारिज कर दिया जाता है। XML की पार्स त्रुटियां होने की क्षमता एक डिजाइन दोष है, और इसे इस तरह से पहचाना जाना चाहिए।
जोएरी सेबर्ट्स

1
@ जोरी, आपकी स्थिति एचटीएमएल 5 युक्ति के समान प्रतीत होती है, जो इसके पागल तार्किक निष्कर्ष पर ले जाती है। "HTML5 सभी इनपुट को वैध बनाने के लिए पार्सिंग नियमों को फिर से परिभाषित करता है" - ऐसा नहीं है। पार्सिंग त्रुटियों की अवधारणा अभी भी मौजूद है। "अगर सिंटैक्स त्रुटियां असंभव हैं, तो बग की एक पूरी कक्षा को शुरू से खारिज कर दिया जाता है" - शायद यह पैरोडी है? यह तर्क है जो मैंने @pthesis के उत्तर के लिए अपनी टिप्पणी में व्यंग्यात्मक रूप से लिखा है। हाँ, सिंटैक्स त्रुटियों की श्रेणी को हटा दिया जाता है, ब्राउज़र सिंटैक्स सुधार त्रुटियों के एक बड़े वर्ग द्वारा प्रतिस्थापित किया जाता है ।
jameshfisher

2

HTML5 विनिर्देश वास्तव में HTML4 विनिर्देश पर बहुत सुधार किया गया है। विशेष रूप से, त्रुटि स्थितियों और अमान्य मार्कअप से निपटने को वास्तव में मानकीकृत किया जाता है, जिसका अर्थ है कि मानक को सही ढंग से लागू करने वाले सभी ब्राउज़र उसी तरह से अमान्य मार्कअप को संभाल लेंगे।

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

वैध XML के निर्माण में वास्तव में बहुत कम लाभ है, क्योंकि HTML को संभालने के लिए टूल और लाइब्रेरी ठीक-ठीक उपलब्ध हैं (और) XML की तुलना में मनुष्यों के लिए HTML आसान है।


अधिक HTML4 विनिर्देश, हाँ। लेकिन मेरा कहना यह है कि XHTML1.1 उस पर पहले से ही सुधार कर रहा है। उपकरण / पुस्तकालयों एचटीएमएल को संभालने के लिए की तरह हो जाते हैं BeautifulSoup जबकि अद्भुत उपकरण, वे पृष्ठों वे पार्स करने के लिए किए गए थे के साथ मौत हो जाए -।
jameshfisher

1

आपको क्लाइंट साइड पर वैसे भी सरल पार्सर या मानक XML टूल का लाभ कभी नहीं मिलेगा।

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

सर्वर की तरफ आप अभी भी एक्सएमएल टूल का लाभ उठा सकते हैं। XSLT का उपयोग करके XHTML उत्पन्न करना। लेकिन यदि आप विशेष रूप से XML टूलकिन का उपयोग नहीं कर रहे हैं, तो केवल HTML के बजाय XML सिंटैक्स का उपयोग करने में कोई लाभ नहीं है।

(आप सही नहीं हैं कि HTML "गैर मानक" वाक्यविन्यास है। HTML का वाक्य-विन्यास HTML5 युक्ति में श्रमसाध्य विस्तार में निर्दिष्ट है, इसलिए यह XML सिंटैक्स के समान ही एक मानक है। "

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