HTML के लिए सख्त पार्सिंग क्यों नहीं चुना गया?

38

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

क्या कोई विशिष्ट कारण है कि HTML को कड़ाई से पार्स क्यों नहीं किया जाता है?

html history parsing

— शुभम
स्रोत

7

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

— ब्रायन

25

@Brian: रोबस्टनेस का मतलब है कि जब आप बकवास प्राप्त करते हैं, तो आपको गिरना नहीं चाहिए। इसका मतलब यह नहीं है कि आपको बकवास का मतलब निकालना होगा।

— मार्जन वेनेमा

2

XHTML सख्त पार्सिंग का उपयोग करता है।

— user16764

3

क्या यह सिर्फ मेरे लिए है, या इनमें से कोई भी जवाब बहुत संतोषजनक नहीं है?

— gsingh2011

2

@ gsingh2011 कोई भी उत्तर संतोषजनक नहीं है, लेकिन मेरा उत्तर सत्य है। हम में से कुछ यहां नेट पर सक्रिय थे जो बहुत पहले :-) लेकिन हाँ, यह आश्चर्यजनक है कि हम ऐसे सरल कारणों के लिए कितना जंक छोड़ रहे हैं।

— रॉस पैटरसन

39

कारण सरल है: पहले ग्राफिकल ब्राउज़रों के समय में, NCSA Mosiac और बाद में नेटस्केप नेविगेटर, लगभग सभी HTML हाथ से लिखे गए थे। ब्राउज़र लेखक (नेटस्केप पूर्व मोज़ेक लोगों द्वारा बनाया गया था) जल्दी से मान्यता प्राप्त है कि गलत HTML को प्रस्तुत करने से इनकार करने पर उपयोगकर्ताओं और वॉइला द्वारा उनके खिलाफ आयोजित किया जाएगा !

— रॉस पैटरसन
स्रोत

7

+1 हाँ, यह है कि यह सब कैसे शुरू हुआ, vi या नोटपैड में। अधिकांश पृष्ठों को बुरे उदाहरण कोड से कॉपी किए जाने के कारण, यह कभी बेहतर नहीं हुआ। इसके अलावा WWW में उछाल आया, इसलिए जो कोई भी टाइप कर सकता है, वह वेब डेवलपर बन सकता है और यह सब तेजी से हो रहा है।

— jqa

1

जाहिर है, @ जुका की टिप्पणी के साथ संयोजन में यह उत्तर सबसे अच्छा संभव स्पष्टीकरण देता है

— शुभम

35

क्योंकि सर्वश्रेष्ठ अनुमान लगाना ब्राउजर बनाने वाले के नजरिए से सही काम है। स्थिति पर विचार करें: आदर्श रूप से, आपके द्वारा प्राप्त HTML पूरी तरह से सही है और कल्पना करने के लिए। एक दम बढ़िया। लेकिन दिलचस्प हिस्सा यह है कि जब एचटीएमएल सही नहीं होता है; चूंकि हम ऐसे स्रोत से इनपुट के साथ काम कर रहे हैं जिसका हमारे ऊपर कोई प्रभाव नहीं है, वास्तव में, हमें इसके लिए तैयार रहना होगा। अब जब ऐसा होता है, तो हम क्या कर सकते हैं? हमारे पास दो विकल्प हैं: ए) विफल, और बी) त्रुटि से उबरने का सबसे अच्छा प्रयास करते हैं। यदि हम विफल होते हैं, तो उपयोगकर्ता के पास बेकार त्रुटि संदेश के अलावा कुछ भी नहीं है, और इसके बारे में वे कुछ भी नहीं कर सकते हैं, क्योंकि वे सर्वर को नियंत्रित नहीं करते हैं। यदि हम सबसे अच्छा प्रयास करते हैं, तो उपयोगकर्ता के पास कम से कम वह पृष्ठ है जिसे हम बना सकते हैं, और अक्सर अनुमान ज्यादातर सही होता है।

इसके साथ एकमात्र वास्तविक समस्या यह है जब आपको त्रुटि संदेशों की आवश्यकता होती है, जो आमतौर पर एक विकास की स्थिति में है - आप यह सुनिश्चित करना चाहते हैं कि आपके द्वारा उत्पन्न HTML सही है, और चूंकि "ब्राउज़र एक्स में काम करता है" "सही" के बराबर नहीं है। हम इसे केवल एक ब्राउज़र के माध्यम से नहीं चला सकते हैं और यह देख सकते हैं कि क्या यह काम करता है: हम सही HTML और गलत HTML के बीच का अंतर नहीं बता सकते हैं जो ब्राउज़र ने आपके लिए तय किया है। यह एक हल करने योग्य समस्या है; ऐसे ब्राउज़र प्लगइन्स हैं जो मानकों के उल्लंघन की रिपोर्ट करते हैं, W3C सत्यापनकर्ता और बहुत सारे अन्य समान उपकरण हैं।

— tdammers
स्रोत

7

खैर, मुझे नहीं लगता कि कोई भी HTML को सेवा देगा जो त्रुटियों को बढ़ाता है। आपको क्या लगता है कि एक संकलक कोड HTML मानने वाले ब्राउज़र से कोई भिन्न है।

— शुभम

1

मैं यहां शुभम से सहमत हूं - "चूंकि हम एक स्रोत से इनपुट के साथ काम कर रहे हैं, जिस पर हमारा कोई प्रभाव नहीं है" गलत है, यह प्रभाव अप्रत्यक्ष है लेकिन कुछ वेब साइटें उस प्रभाव के कारण अभी भी IE6 का समर्थन करती हैं।

— स्टीव 314

2

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

— तदममर्स

2

@ शुभम: आम तौर पर एक कंपाइलर के उपयोगकर्ता को संकलित किए जा रहे स्रोत कोड पर नियंत्रण होगा। यह आमतौर पर वेब पृष्ठों के साथ ऐसा नहीं है।

— सुपरकट

17

HTML लेखक और संलेखन उपकरण भद्दे मार्कअप का उत्पादन करते हैं। ब्राउज़र प्रतिस्पर्धी कारणों से इसके साथ अपना सर्वश्रेष्ठ प्रदर्शन करते हैं: एक ऐसा ब्राउज़र जो किसी भी तरह से अधिकांश वेब पेजों को प्रस्तुत करने में विफल रहता है, उपयोगकर्ताओं द्वारा अस्वीकार कर दिया जाएगा, जो कम से कम इस बात की परवाह नहीं करेंगे कि यह किसकी गलती है।

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

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

— जुक्का के। कोरपेला
स्रोत

15

HTML authors and authoring tools produce crappy markup.- वे ऐसा इसलिए करते हैं क्योंकि ब्राउज़र इसे स्वीकार करते हैं। यदि शुरुआत से ब्राउज़र ने इसे स्वीकार नहीं किया - तो ये उपकरण और लेखक गंदे मार्कअप का निर्माण करने में सक्षम नहीं होंगे

— user93353

3

@GrandmasterB - मुझे लगता है कि आप इस बिंदु को याद करते हैं - यहां तक कि जहां बाजार में सिर्फ एक ब्राउज़र था - यह सख्त पार्सिंग नहीं करता था।

— user93353

3

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

— अधिकतम

3

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

— जुका के। कोरपेला

2

IE वास्तव में अपने बाजार में काफी हिस्सा खो चुका है। लेकिन यह शायद ही है अगर सख्त पार्सिंग के साथ कुछ भी करना है। IE, अपनी विषमताओं के साथ, वेब पर लंबे समय तक शासन करता था ताकि अन्य ब्राउज़रों को अपनी विषमताओं की नकल करने के लिए मजबूर किया जा सके, क्योंकि इतने सारे पृष्ठ अन्यथा अलग हो जाते।

— जुक्का के। कोर्पेला

9

इसकी कमी यह होगी कि HTML एक अन्य गैर-हाइपरलिंक मार्कअप भाषा पर आधारित थी जिसे SGML अक्सर प्रलेखन और मैनुअल और पसंद के लिए उपयोग किया जाता है।

HTML के इतिहास के बारे में एक लेख से :

टिम ने उल्लेख किया था कि प्रारंभिक HTML दस्तावेज़ों में से कुछ एक पुरानी एसजीएमएल भाषा पर आधारित थे जो सर्न पहले से ही उपयोग कर रहे थे: - हमने HTML में शामिल किए गए एसजीएमएल टैगसेट से कुछ टैग शामिल किए हैं और एक बार सीईआरएन पर समर्थित हैं [...] HTML पार्सर उन टैगों को अनदेखा कर देगा जो इसे समझ में नहीं आते हैं, और उन विशेषताओं को अनदेखा कर देंगे जो इसे सर्न-एसजीएमएल टैग के बारे में नहीं समझते हैं ।

[...] अधिकांश प्रारंभिक HTML टैग वास्तव में CERN SGMLGuid भाषा से लिए गए थे, जो स्वयं AAP (एक प्रारंभिक SGML भाषा) का संस्करण था। उदाहरण के लिए, शीर्षक, hn, p, ol और इसी तरह सभी को इस भाषा से लिया जाता है। एकमात्र महत्वपूर्ण परिवर्तन सभी महत्वपूर्ण एंकर () लिंक के अलावा था, जिसके बिना डब्ल्यूडब्ल्यूडब्ल्यू ने नहीं लिया होगा।

मेरे द्वारा बोले गए भाग को ध्यान में रखते हुए, मूल रूप से, उन्होंने SGML सिस्टम में उपलब्ध टैग का एक उपसमुच्चय लागू किया, जिससे वे परिचित थे, नया एंकर <a> टैग जोड़कर, और उनमें से किसी भी एक टैग को अनदेखा करने के लिए चुनना, जो उन्होंने नहीं किया था ' देखभाल के बारे में या wahtever कारण के लिए समर्थन करना चाहते हैं (जैसे ग्रंथ सूची के लिए टैग, "उदाहरण" के लिए xmp, पाठ के ब्लॉक के चारों ओर एक बॉक्स बनाने के लिए "बॉक्स" टैग)। ऐसा करने का सबसे सरल तरीका है मार्कअप को माफ करना जो पार्सर द्वारा ज्ञात नहीं है और अज्ञात मार्कअप को यथासंभव अनदेखा करता है, चाहे इसका कारण उपयोगकर्ता द्वारा खराब मार्कअप टाइप किया गया हो, या मौजूदा दस्तावेजों को परिवर्तित करने का सबसे आसान तरीका। यह नया HTML प्रारूप मौजूदा एसजीएमएल दस्तावेजों में कुछ हाइपरलिंक जोड़ने के लिए है, और जो भी टैग समर्थित या कार्यान्वित नहीं हैं, उन्हें अनदेखा करें।

— जेसिका ब्राउन
स्रोत

एचटीएमएल वाक्य रचना वास्तव में के लिए SGML सन्दर्भ कोंक्रिट सिंटेक्स पर आधारित था प्रपत्र उसके मार्कअप की। लेकिन SGML के पास स्वयं के दस्तावेज़ों को चिह्नित करने के लिए तत्व नहीं थे जो HTML उधार ले सकते थे, HTML तत्व सेट वास्तव में IBM के GML दस्तावेज़ मार्कअप भाषा से मिलता जुलता है , जिसे SGML RCS में अनुवादित किया गया था।

— रॉस पैटरसन

5

यह आंशिक रूप से ब्राउज़र युद्ध का एक ऐतिहासिक अवशेष है

IE और नेटस्केप बाजार पर कब्जा करने के लिए प्रतिस्पर्धा कर रहे थे और नई सुविधाओं को जारी रखते थे जो अधिक से अधिक "भयानक" बनते रहे, और दूसरे ब्राउज़र के लिए डिज़ाइन किए गए पृष्ठों को स्वीकार करने के लिए बाध्य थे।

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

दूसरे भाग के लिए नेटस्केप और IE चाहता था कि HTML आम आदमी के लिए सुलभ हो (जैसा कि उन दिनों सनक था) जिसका अर्थ है कि उपयोगकर्ता जो करना चाहता था उसके बजाय वह करना चाहता था जो वह करने के लिए कहता था और हर झूलने वाले टैग पर ट्रिपिंग करता था।

समस्या को और बदतर बनाना यह है कि कई "ट्यूटोरियल" साइटें हैं जो गलत चीज सिखाती हैं और सोचती हैं कि वे सही हैं क्योंकि वे जो सिखाते हैं वह काम करता है।

अंततः इसका मतलब यह है कि यदि आप अब केवल सख्त HTML के साथ एक ब्राउज़र बनाते हैं तो 99% साइटें बाहर आ जाएंगी और काम नहीं होगा।

— शाफ़्ट सनकी
स्रोत

6

IE बाजार में आने से पहले भी, नेटस्केप ने कभी भी सख्त पार्स नहीं किया था। मुझे 1997 के आरंभ से नेटस्केप याद है।

— user93353

यहां तक कि अगर स्पष्ट मानक थे, तो ब्राउज़र के लिए उन टैगों के बीच अंतर करना मुश्किल होगा जो ब्राउज़र जारी होने के बाद वैध रूप से परिभाषित किए गए थे, बनाम टैग जो कभी नहीं थे और कभी भी वैध नहीं होंगे। यदि "वैकल्पिक" टैग जो एक दस्तावेज़ को बढ़ाता है, लेकिन इसकी शब्दार्थ शुद्धता के लिए आवश्यक नहीं था, इसमें मानक का संस्करण संख्या शामिल है जो उन्हें लागू करता है, तो मानक के 23 संस्करण को लागू करने वाला एक ब्राउज़र चुपचाप एक <o24wowzo>टैग को अनदेखा कर सकता है <o23wowzo>, लेकिन एक पर एक डिजाइन HTML के "मानव पठनीय" पहलू को बिगड़ा होगा।

— सुपरकाट

2

अच्छी तरह से हमने 000 में एक अच्छा सख्त विकल्प स्थापित करने की कोशिश की, लेकिन यह गलत नहीं हुआ क्योंकि लोगों ने "सर्वोत्तम प्रथाओं" का आंख मूंदकर अनुसरण किया, जब उनके गलत मार्कअप सख्त मोड में टुकड़ों में चले गए तो उन्होंने ब्राउज़र को दोषी ठहराया। और ब्राउज़र विक्रेताओं को दोष दिया जाना पसंद नहीं था।

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

यदि आप सख्त-शैली के लेआउट की इच्छा रखते हैं, तो आप अभी भी HTML5 को XML के रूप में परोस सकते हैं। IMO यह एक अच्छा तरीका हो सकता है कि आप कड़े मोड में लेआउट या यूआई कार्य करने के लाभों को पुनः प्राप्त करें, इससे पहले कि आप इसे अन्य लोगों को पास कर दें, जो इसे किसी भी वास्तविक जोखिम के बिना सख्त हो सकते हैं या नहीं कर सकते हैं (इन्हें रोककर doctype टाइप करना है क्योंकि) वे वास्तव में क्विरक्स मोड का पक्ष लेते हैं - 2017 में (इस संपादन के समय) उन्हें गोली मार दी जानी चाहिए। इसलिए यह अभी भी मूल रूप से कुछ शोध कर रहा है। मुझे याद है कि कुछ कैविएट हैं जो हमारे पास एक्सएचटीएमएल के साथ नहीं थे। वास्तव में लेआउट का काम प्रभावित करता है। बस उस शब्द का प्रसार न करें जो "इसे सही तरीके से करने का एकमात्र तरीका है" या इस तरह की बातचीत में खरीदने वाले जुड़वा विचार को निष्क्रिय कर देंगे, फिर से ब्राउज़रों को दोष देंगे, और वे दांत ले लेंगे हमारे द्वारा छोड़े गए एकमात्र सख्त विकल्प में से (2017 संपादित करें:

http://mathiasbynens.be/notes/xhtml5

— एरिक रेपेन
स्रोत