เหตุใดการแยกวิเคราะห์ที่เข้มงวดจึงไม่ถูกเลือกสำหรับ HTML

38

ฉันมักจะสงสัยว่าทำไมการแยกวิเคราะห์ที่เข้มงวดไม่ได้ถูกเลือกเมื่อสร้าง HTML สำหรับประวัติอินเทอร์เน็ตส่วนใหญ่เบราว์เซอร์ยอมรับมาร์กอัปทุกชนิดและพยายามอย่างดีที่สุดในการแยกวิเคราะห์ กระบวนการลดประสิทธิภาพลงทำให้ผู้คนสามารถเขียนซึ่งพูดพล่อยๆและทำให้ยากต่อการยกเลิกคุณสมบัติที่ล้าสมัย

มีเหตุผลเฉพาะหรือไม่ที่ทำไมการแยกวิเคราะห์ HTML จึงไม่เข้มงวด?

html history parsing

— Shubham
แหล่งที่มา

7

คุณอาจพบบทความ Joels, ชุดหูฟัง Martianเป็นที่สนใจ นอกจากนี้ยังมีข้อความพิเศษคือRFC 793: Robustness Principleซึ่งระบุไว้อย่างชัดเจนว่าการใช้งาน TCP ควรพยายามอย่างดีที่สุดในการแยกขยะ หลักการนี้ได้ถูกนำไปใช้กับเบราว์เซอร์

— Brian

25

@Brian: ความแข็งแกร่งหมายความว่าคุณไม่ควรล้มเมื่อคุณได้รับอึ มันไม่ได้หมายความว่าคุณต้องทำให้รู้สึกแย่

— Marjan Venema

2

XHTML ใช้การแยกวิเคราะห์อย่างเข้มงวด

— user16764

3

มันเป็นเพียงฉันหรือไม่มีคำตอบเหล่านี้พอใจมาก?

— gsingh2011

2

@ gsingh2011 ไม่มีคำตอบใดที่พอใจ แต่คำตอบของฉันคือความจริง พวกเราบางคนที่นี่มีความเคลื่อนไหวในเน็ตเมื่อนานมาแล้ว :-) แต่ใช่มันเป็นเรื่องที่น่าประหลาดใจว่าเราเหลือขยะมากแค่ไหนด้วยเหตุผลง่ายๆ

— Ross Patterson

39

เหตุผลง่าย ๆ : ในขณะที่เบราว์เซอร์กราฟิกแรก NCSA Mosiac และ Netscape Navigator ในภายหลัง HTML เกือบทั้งหมดเขียนด้วยมือ ผู้เขียนเบราว์เซอร์ (Netscape ถูกสร้างขึ้นโดยกลุ่มคนอดีต Mosaic) ได้รับการยอมรับอย่างรวดเร็วว่าการปฏิเสธที่จะแสดง HTML ที่ไม่ถูกต้องจะถูกควบคุมโดยผู้ใช้และvoila!

— Ross Patterson
แหล่งที่มา

7

+1 ใช่นั่นคือทั้งหมดที่เริ่มต้นใน vi หรือ notepad ด้วยการคัดลอกหน้าส่วนใหญ่จากโค้ดตัวอย่างที่ไม่ดีมันไม่เคยดีขึ้นเลย รวมถึง WWW ที่เฟื่องฟูดังนั้นใครก็ตามที่สามารถพิมพ์ได้กลายเป็นนักพัฒนาเว็บและมันก็เป็นเรื่องของการทำให้เสร็จเร็ว

— jqa

1

เห็นได้ชัดว่าคำตอบในการเชื่อมต่อนี้กับความคิดเห็นของ @ Jukka ให้คำอธิบายที่ดีที่สุด

— Shubham

35

เนื่องจากการคาดเดาที่ดีที่สุดเป็นสิ่งที่ถูกต้องที่จะทำจากมุมมองของผู้ผลิตเบราว์เซอร์ พิจารณาสถานการณ์: นึกคิดว่า HTML ที่คุณได้รับนั้นถูกต้องสมบูรณ์และตรงตามข้อกำหนด เยี่ยมมาก แต่ส่วนที่น่าสนใจคือสิ่งที่เกิดขึ้นเมื่อ HTML ไม่ถูกต้อง เนื่องจากเรากำลังจัดการกับข้อมูลจากแหล่งที่เราไม่มีอิทธิพลจริง ๆ เราต้องเตรียมพร้อมสำหรับสิ่งนี้ ตอนนี้เมื่อสิ่งนั้นเกิดขึ้นเราจะทำอย่างไร เรามีสองตัวเลือก: a) ล้มเหลวและ b) พยายามอย่างดีที่สุดในการกู้คืนจากข้อผิดพลาด หากเราล้มเหลวผู้ใช้ไม่มีสิ่งใดนอกจากข้อความแสดงข้อผิดพลาดที่ไร้ประโยชน์และไม่มีสิ่งใดที่พวกเขาสามารถทำได้เนื่องจากพวกเขาไม่ได้ควบคุมเซิร์ฟเวอร์ หากเราพยายามอย่างดีที่สุดผู้ใช้จะมีอย่างน้อยสิ่งที่เราสามารถทำได้จากหน้าเว็บและบ่อยครั้งที่การเดานั้นถูกต้องที่สุด

ปัญหาที่แท้จริงเพียงอย่างเดียวคือเมื่อคุณต้องการข้อความแสดงข้อผิดพลาดซึ่งโดยทั่วไปอยู่ในสถานการณ์การพัฒนา - คุณต้องการตรวจสอบให้แน่ใจว่า HTML ที่คุณสร้างนั้นถูกต้องและเนื่องจาก "งานในเบราว์เซอร์ X" ไม่เท่ากับ "ถูกต้อง" เราไม่สามารถเรียกใช้ผ่านเบราว์เซอร์และดูว่าทำงานได้หรือไม่: เราไม่สามารถบอกความแตกต่างระหว่าง HTML ที่ถูกต้องกับ HTML ที่ไม่ถูกต้องซึ่งเบราว์เซอร์ได้แก้ไขให้คุณแล้ว นี่เป็นปัญหาที่แก้ไขได้ มีปลั๊กอินของเบราว์เซอร์ที่รายงานการละเมิดมาตรฐานมีเครื่องมือตรวจสอบ W3C และเครื่องมืออื่น ๆ ที่คล้ายกันมากมาย

— tdammers
แหล่งที่มา

7

ฉันไม่คิดว่าจะมีใครแสดง HTML ที่ทำให้เกิดข้อผิดพลาด ทำไมคุณถึงคิดว่าคอมไพเลอร์สมมติว่าโค้ดต่างจากเบราว์เซอร์ที่สมมติว่า HTML

— Shubham

1

ฉันเห็นด้วยกับ Shubham ที่นี่ - "เนื่องจากเรากำลังจัดการกับข้อมูลจากแหล่งที่เราไม่มีอิทธิพล" เป็นเท็จอิทธิพลเป็นทางอ้อม แต่เว็บไซต์บางแห่งยังคงรองรับ IE6 เนื่องจากอิทธิพลดังกล่าว

— Steve314

2

@Shubham: คอมไพเลอร์แตกต่างกันเพราะจุดประสงค์ไม่ได้แปลงซอร์สโค้ดที่เครื่องอ่านได้ให้อยู่ในรูปแบบที่มนุษย์สามารถย่อยสลายได้ แต่เป็นการแปลงซอร์สโค้ดที่มนุษย์สามารถอ่านได้ให้เป็นสิ่งที่สะดวกกว่าสำหรับคอมพิวเตอร์ รูปแบบ) ด้วยคอมไพเลอร์คุณแก้ไขอินพุตและคุณดีใจที่โค้ดไม่ได้ทำให้เกิดการผลิต เมื่อใช้เบราว์เซอร์คุณจะสาปแช่งผู้สร้างเบราว์เซอร์หรือผู้เขียนเว็บไซต์ แต่ไม่ว่าจะด้วยวิธีใดคุณจะไม่ได้เห็นหน้าเว็บ

— tdammers

2

@Shubham: โดยทั่วไปผู้ใช้คอมไพเลอร์จะมีการควบคุมซอร์สโค้ดที่ถูกรวบรวม โดยทั่วไปไม่ใช่กรณีที่มีหน้าเว็บ

— supercat

17

ผู้เขียน HTML และเครื่องมือการเขียนสร้างมาร์กอัปเส็งเคร็ง เบราว์เซอร์พยายามอย่างดีที่สุดด้วยเหตุผลด้านการแข่งขัน: เบราว์เซอร์ที่ไม่สามารถแสดงหน้าเว็บส่วนใหญ่ในลักษณะที่สมเหตุสมผลจะถูกปฏิเสธโดยผู้ใช้ซึ่งจะไม่สนใจสิ่งที่เป็นความผิดของมัน

มันค่อนข้างแตกต่างจากการใช้งานภาษาโปรแกรม คอมไพเลอร์และล่ามทำงานบนโค้ดที่สามารถเขียนโดยโปรแกรมเมอร์ในขณะที่ทุกคนและพี่ชายของเขาสามารถเขียน HTML ด้วยการฝึกอบรมขั้นต่ำหรือไม่ก็ได้ HTML มาร์กอัปเป็นโค้ดในแง่หนึ่ง แต่เป็นข้อมูลแทนที่จะเป็นคำแนะนำในการเขียนโปรแกรมภาษาและประเพณี (ดี) ในซอฟต์แวร์คือต้องทนกับข้อมูล

ในหลักการ XHTML กำหนดกฎการแยกวิเคราะห์ที่เข้มงวด (XML) ดังนั้นเอกสาร XHTML ที่ให้บริการกับประเภทเนื้อหา XML จะแสดงเฉพาะเมื่อมีรูปแบบที่ดีในแง่ XML - มิฉะนั้นเฉพาะข้อผิดพลาดแรกที่สื่อสารกับผู้ใช้ สิ่งนี้ไม่เคยได้รับความนิยมในการเขียนเว็บ - เกือบทั้งหมด“ XHTML” รอบ ๆ ทำหน้าที่เป็นข้อความ / html และประมวลผลเป็นซุปแท็กแบบดั้งเดิมในทางเสรีนิยมเพียงแค่มีสิ่งแปลกใหม่บางอย่าง

— Jukka K. Korpela
แหล่งที่มา

15

HTML authors and authoring tools produce crappy markup.- พวกเขาทำเพราะเบราว์เซอร์ยอมรับ หากจากจุดเริ่มต้นเบราว์เซอร์ไม่ยอมรับมัน - เครื่องมือและผู้เขียนเหล่านี้จะไม่สามารถหนีจากการผลิตมาร์กอัปเส็งเคร็ง

— user93353

3

@ แกรนด์มาสเตอร์บี - ฉันคิดว่าคุณพลาดประเด็น - แม้จะเป็นเพียงเบราว์เซอร์เดียวในตลาด - มันไม่ได้ทำการแยกวิเคราะห์อย่างเข้มงวด

— user93353

3

ข้อความตลก: คุณบอกว่าถ้าเบราว์เซอร์ไม่สามารถแยกวิเคราะห์ไซต์ที่ไม่ถูกต้องมันจะเสียส่วนแบ่งตลาด แต่เพียงแค่ดูที่: แต่ไม่ดีมันไม่เสียส่วนแบ่งการตลาด มันเพียงบังคับให้นักพัฒนาที่ยากจนเขียนแฮ็คสกปรกในการใช้ API เก่า ... และอย่าให้ฉันเริ่มต้นด้วยการกำหนดเวอร์ชันเป็น ...

— Max

3

ในตอนแรกเบราว์เซอร์ถูกเขียนขึ้นอย่างเร่งรีบเพื่อจัดการกับภาษามาร์กอัปที่ไม่ได้สรุปและไม่มีข้อกำหนดอย่างเป็นทางการ - ไม่มีกฎการแยกวิเคราะห์ที่เข้มงวด (HTML 2.0 ในปี 1995 เป็นชื่อที่ใช้ SGML แต่มันก็สายเกินไปที่จะนำไปใช้จริง)

— Jukka K. Korpela

2

IE ได้สูญเสียส่วนแบ่งการตลาดไปค่อนข้างมาก แต่นี่อาจมีเล็กน้อยถ้ามีอะไรเกี่ยวข้องกับการแยกวิเคราะห์อย่างเข้มงวด IE ที่มีความแปลกประหลาดปกครองเว็บไว้นานพอที่จะบังคับให้เบราว์เซอร์อื่น ๆ เลียนแบบสิ่งแปลกประหลาดส่วนใหญ่เพราะหน้าเว็บจำนวนมากจะแยกออกจากกัน

— Jukka K. Korpela

9

สิ่งที่สั้นก็คือ HTML นั้นใช้ภาษามาร์กอัปที่ไม่ใช่ไฮเปอร์ลิงก์อื่นที่เรียกว่า SGML ซึ่งมักใช้สำหรับเอกสารและคู่มือและอื่น ๆ

จากบทความเกี่ยวกับประวัติของ HTML:

Tim ได้กล่าวว่าเอกสาร HTML ต้น ๆ บางส่วนนั้นใช้ภาษา SGML แบบเก่าที่ CERN ใช้อยู่แล้ว: - เราได้รวมแท็ก HTML บางส่วนจากชุด SGML ที่ใช้ในและสนับสนุน CERN [... ] ตัวแยก HTML จะไม่สนใจแท็กที่มันไม่เข้าใจและจะไม่สนใจแอตทริบิวต์ที่มันไม่เข้าใจของแท็กเซิร์น-SGML

[... ] แท็ก HTML ต้นส่วนใหญ่ถูกนำมาจากภาษา CERN SGMLGuid ซึ่งตัวเองเป็นตัวแปรของ AAP (เป็นภาษา SGML ยุคแรก) ตัวอย่างเช่นชื่อเรื่อง, hn, p, ol และอื่น ๆ นั้นมาจากภาษานี้ การเปลี่ยนแปลงที่รุนแรงเพียงอย่างเดียวคือการเพิ่มลิงค์ anchor () ที่สำคัญทั้งหมดโดยที่ WWW จะไม่ถูกถอดออก

การจดบันทึกส่วนที่ฉันทำไว้เป็นตัวหนาโดยพื้นฐานแล้วพวกเขาใช้ส่วนย่อยของแท็กที่มีอยู่ในระบบ SGML ที่พวกเขาคุ้นเคยเพิ่มสมอแท็ก <a> ใหม่และเลือกที่จะไม่สนใจแท็กจำนวนมากที่พวกเขาไม่ได้ใช้ ' ไม่สนใจหรือต้องการเหตุผลสนับสนุน wahtever (เช่นแท็กสำหรับรายการบรรณานุกรม xmp สำหรับแท็ก "ตัวอย่าง", "กล่อง" เพื่อวาดกล่องล้อมรอบข้อความ ฯลฯ ) ดังนั้นวิธีที่ง่ายที่สุดในการทำเช่นนั้นคือการให้อภัยมาร์กอัปซึ่งไม่รู้จักโดย parser และละเว้นมาร์กอัพที่ไม่รู้จักดีที่สุดเท่าที่จะทำได้ไม่ว่าผู้ใช้จะพิมพ์มาร์กอัปที่ไม่ดีหรือไม่ รูปแบบ HTML ใหม่นี้คือการเพิ่มการเชื่อมโยงหลายมิติไปยังเอกสาร SGML ที่มีอยู่และไม่สนใจสิ่งที่แท็กไม่ได้รับการสนับสนุนหรือนำไปใช้

— เจสสิก้าบราวน์
แหล่งที่มา

ไวยากรณ์ HTML นั้นอ้างอิงจาก SGML Reference Concrete Syntax สำหรับ รูปแบบของมาร์กอัป แต่ SGML เองไม่มีองค์ประกอบสำหรับการทำเครื่องหมายเอกสารที่ HTML สามารถยืมได้ชุดองค์ประกอบ HTML นั้นคล้ายกับภาษามาร์กอัปเอกสารGML ของ IBMซึ่งแปลเป็น SGML RCS

— Ross Patterson

5

นี่คือส่วนที่เหลือประวัติศาสตร์ของสงครามเบราว์เซอร์

IE และ netscape กำลังแข่งขันกันเพื่อแย่งชิงตลาดและยังคงปล่อยฟีเจอร์ใหม่ ๆ ที่ยอดเยี่ยมขึ้นเรื่อย ๆ และบังคับให้ยอมรับหน้าเว็บที่ออกแบบมาสำหรับเบราว์เซอร์อื่น

ซึ่งหมายความว่าเบราว์เซอร์ยอมรับและไม่สนใจแท็กที่ไม่รู้จักอย่างเงียบ ๆ หลังจากที่คณะกรรมการเริ่มเข้ามามีส่วนร่วม ... คุณมีคณะกรรมการที่ออกแบบสิ่งต่าง ๆและผลที่ตามมาก็คือเวอร์ชั่นต่าง ๆ มากมาย พวกเขาและการสร้างโปรแกรมแยกวิเคราะห์สำหรับแต่ละรุ่นจะมีขนาดใหญ่โต ดังนั้นจึงค่อนข้างง่ายต่อการใช้โปรแกรมวิเคราะห์คำเดียวที่มีโหมดแตกต่างกัน

อีกส่วนหนึ่ง netscape และ IE ต้องการให้ html สามารถเข้าถึงได้สำหรับคนทั่วไป (เช่นเดียวกับสมัยนั้น) ซึ่งหมายถึงการพยายามทำสิ่งที่ผู้ใช้ต้องการจะทำแทนสิ่งที่เขาพูดและทำแท็กห้อยอยู่ทุกแท็ก

การทำให้ปัญหาแย่ลงคือมีไซต์ "กวดวิชา" หลายแห่งที่สอนสิ่งที่ผิดและคิดว่าถูกต้องเพราะสิ่งที่สอน

ท้ายที่สุดนี่หมายความว่าหากคุณสร้างเบราว์เซอร์ที่มีการแยกวิเคราะห์ html ที่เข้มงวดเพียง 99% ของไซต์ที่ออกมานั้นจะไม่ทำงาน

— วงล้อประหลาด
แหล่งที่มา

6

ก่อนที่ IE จะเข้าสู่ตลาด Netscape ก็ไม่เคยทำการแยกวิเคราะห์อย่างเข้มงวด ฉันจำ Netscape ได้ตั้งแต่ต้นปี 1997

— user93353

แม้ว่าจะมีมาตรฐานที่ชัดเจน แต่เบราว์เซอร์จะแยกความแตกต่างระหว่างแท็กที่ถูกต้องตามกฎหมายหลังจากเปิดตัวเบราว์เซอร์กับแท็กที่ไม่เคยมีและจะไม่ถูกต้องตามกฎหมาย หาก "ตัวเลือก" แท็กซึ่งเพิ่มเอกสาร แต่ไม่จำเป็นต้องมีความถูกต้องความหมายของมันรวมถึงหมายเลขรุ่นของมาตรฐานที่นำมาใช้พวกเขาแล้วเบราว์เซอร์ซึ่งดำเนินการรุ่นที่ 23 ของมาตรฐานที่เงียบอาจละเลย<o24wowzo>แท็ก แต่ความพ่ายแพ้ที่<o23wowzo>แต่เช่น การออกแบบจะทำให้ส่วน HTML "ที่มนุษย์อ่านไม่ได้"

— supercat

2

ทีนี้เราพยายามที่จะสร้างตัวเลือกที่เข้มงวดที่ดีในยุค 000 แต่มันก็ไม่ได้ตื่นตระหนกเพราะคนที่ปฏิบัติตาม "แนวทางปฏิบัติที่ดีที่สุด" สุ่มสี่สุ่มห้ากล่าวโทษเบราว์เซอร์เมื่อมาร์กอัปที่ไม่ถูกต้องของพวกเขาไปเป็นชิ้น ๆ ในโหมดเข้มงวด และผู้ขายเบราว์เซอร์ไม่ชอบถูกตำหนิ

พวกเขาอ้างว่าเป็นเพราะพวกเขาต้องการให้ผู้ใช้ที่ไม่ใช่มืออาชีพเข้าถึงได้ง่ายขึ้น แต่ไม่มีใครหยุดใช้ HTML 4 ในรูปแบบที่ผ่อนปรนที่สุด

ที่กล่าวว่าคุณยังคงสามารถให้บริการ HTML5 เป็น XML หากคุณต้องการรูปแบบที่เข้มงวด IMO อาจเป็นวิธีที่ดีในการเก็บเกี่ยวประโยชน์ของการทำโครงร่างหรือ UI ทำงานในโหมดที่เข้มงวดกว่าก่อนที่คุณจะส่งต่อไปยังผู้อื่นที่อาจหรืออาจไม่ต้องการให้เข้มงวดโดยไม่มีความเสี่ยงที่แท้จริง (ยกเว้นพวกเขาคัดลอกประเภทเอกสารออกเพราะ พวกเขาชอบโหมด quirks จริง ๆ - ในปี 2560 (เวลาของการแก้ไขนี้) พวกเขาควรจะถูกยิงดังนั้นมันยังคงมีอยู่โดยทั่วไป แต่ทำวิจัยบางอย่างฉันดูเหมือนจะจำได้ว่ามีบางถ้ำที่เราไม่ได้มี XHTML ที่ไม่ได้ ส่งผลกระทบต่อรูปแบบการทำงานจริงๆอย่าเพิ่งกระจายคำว่า "วิธีเดียวที่จะทำถูกต้อง" หรือ twits ที่ซื้อเข้ามาในการพูดคุยแบบนั้นจะทำให้ความคิดของคุณเบาบางเบราว์เซอร์อีกครั้ง จากทางเลือกที่เข้มงวดอย่างเดียวที่เราทิ้งไว้ (2017 แก้ไข:

http://mathiasbynens.be/notes/xhtml5

— Erik Reppen
แหล่งที่มา