Tại sao phân tích cú pháp nghiêm ngặt không được chọn cho HTML?

Tôi thường tự hỏi tại sao phân tích cú pháp nghiêm ngặt không được chọn khi tạo HTML. Trong hầu hết lịch sử Internet, các trình duyệt đã chấp nhận bất kỳ loại đánh dấu nào và cố gắng hết sức để phân tích nó. Quá trình làm giảm hiệu suất, cho phép mọi người viết vô nghĩa và gây khó khăn cho việc ngừng các tính năng lỗi thời.

Có một lý do cụ thể tại sao HTML không được phân tích cú pháp nghiêm ngặt không?

Lý do rất đơn giản: Tại thời điểm các trình duyệt đồ họa đầu tiên, NCSA Mosiac và sau đó là Netscape Navigator, hầu như tất cả HTML đều được viết bằng tay. Các tác giả trình duyệt (Netscape được xây dựng bởi những người cũ của khảm) đã nhanh chóng nhận ra rằng việc từ chối hiển thị HTML không chính xác sẽ bị người dùng và voila chống lại họ !

Bởi vì đưa ra dự đoán tốt nhất là điều nên làm, từ quan điểm của một nhà sản xuất trình duyệt. Xem xét tình huống: lý tưởng nhất là HTML bạn nhận được là hoàn toàn chính xác và theo thông số kỹ thuật. Thật tuyệt. Nhưng phần thú vị là những gì xảy ra khi HTML không chính xác; vì chúng tôi đang xử lý đầu vào từ một nguồn mà chúng tôi không có ảnh hưởng đến, thực sự, chúng tôi phải chuẩn bị cho việc này. Bây giờ khi điều đó xảy ra, chúng ta có thể làm gì? Chúng tôi có hai lựa chọn: a) thất bại và b) nỗ lực hết sức để khắc phục lỗi. Nếu chúng tôi thất bại, người dùng không có gì ngoài một thông báo lỗi vô dụng và họ không thể làm gì được vì họ không kiểm soát máy chủ. Nếu chúng tôi nỗ lực hết sức, người dùng có ít nhất những gì chúng tôi có thể tạo ra cho trang và thường thì dự đoán là chủ yếu.

Vấn đề thực sự duy nhất với vấn đề này là khi bạn cần thông báo lỗi, thường là trong tình huống phát triển - bạn muốn đảm bảo rằng HTML bạn tạo là chính xác và vì "hoạt động trong trình duyệt X" không tương đương với "chính xác", chúng tôi không thể đơn giản chạy nó thông qua trình duyệt và xem nó có hoạt động không: chúng tôi không thể phân biệt sự khác biệt giữa HTML chính xác và HTML không chính xác mà trình duyệt đã sửa cho bạn. Đây là một vấn đề có thể giải quyết được mặc dù; có các plugin trình duyệt báo cáo các vi phạm tiêu chuẩn, có trình xác nhận W3C và nhiều công cụ tương tự khác.

Các tác giả HTML và các công cụ tác giả tạo ra đánh dấu crappy. Các trình duyệt làm hết sức mình với nó vì lý do cạnh tranh: một trình duyệt không hiển thị hầu hết các trang web theo bất kỳ cách hợp lý nào sẽ bị người dùng từ chối, những người không quan tâm đến việc đó là lỗi của ai.

Nó khá khác với những gì việc triển khai ngôn ngữ lập trình làm. Trình biên dịch và trình thông dịch làm việc trên mã có thể được giả định là do người lập trình viết, trong khi mọi người và anh trai của anh ta có thể viết HTML mà không cần đào tạo tối thiểu hoặc không có. Theo một nghĩa nào đó, đánh dấu HTML là mã, nhưng đó là dữ liệu chứ không phải là hướng dẫn ngôn ngữ lập trình và truyền thống (tốt) trong phần mềm là chấp nhận dữ liệu.

Về nguyên tắc XHTML áp đặt các quy tắc phân tích cú pháp (XML) nghiêm ngặt, do đó, một tài liệu XHTML được cung cấp với loại nội dung XML sẽ chỉ được hiển thị nếu nó được định dạng tốt theo nghĩa XML - nếu không, chỉ có lỗi đầu tiên được truyền đến người dùng. Điều này không bao giờ trở nên phổ biến trong việc soạn thảo web - hầu như tất cả các XHTML, xung quanh được phục vụ dưới dạng văn bản / html và được xử lý như súp thẻ truyền thống theo cách rất tự do, chỉ với một số độ lệch tâm mới.

Tóm lại, HTML sẽ dựa trên một ngôn ngữ đánh dấu không liên kết khác có tên là SGML thường được sử dụng cho tài liệu và hướng dẫn sử dụng và những thứ tương tự.

Từ một bài viết về lịch sử của HTML:

Tim đã đề cập rằng một số tài liệu HTML ban đầu dựa trên ngôn ngữ SGML cũ mà CERN đã sử dụng: - Chúng tôi đã đưa vào HTML một số thẻ từ bộ thẻ SGML được sử dụng tại và từng được hỗ trợ tại CERN [...] Trình phân tích cú pháp HTML sẽ bỏ qua các thẻ mà nó không hiểu và sẽ bỏ qua các thuộc tính mà nó không hiểu về các thẻ CERN-SGML .

[...] hầu hết các thẻ HTML ban đầu thực sự được lấy từ ngôn ngữ CML SGMLGuid, bản thân nó là một biến thể của AAP (ngôn ngữ SGML ban đầu). Ví dụ, tiêu đề, hn, p, ol, v.v ... tất cả đều được lấy từ ngôn ngữ này. Sự thay đổi căn bản duy nhất là việc bổ sung tất cả các liên kết neo () quan trọng mà WWW sẽ không thực hiện.

Về cơ bản, đã lưu ý đến phần tôi đã in đậm, họ đã triển khai một tập hợp con các thẻ có sẵn trong hệ thống SGML mà họ quen thuộc, thêm thẻ <a> neo mới và chọn bỏ qua bất kỳ thẻ nào trong số nhiều thẻ họ đã không ' Không quan tâm hoặc muốn hỗ trợ cho lý do wahtever (chẳng hạn như thẻ cho danh sách thư mục, xmp cho thẻ "ví dụ", "hộp" để vẽ một hộp xung quanh một khối văn bản, v.v.). Vì vậy, cách đơn giản nhất để làm điều đó là tha thứ cho đánh dấu mà trình phân tích cú pháp không biết và bỏ qua đánh dấu không xác định tốt nhất có thể, bất kể nguyên nhân là do người dùng nhập đánh dấu xấu hay cách nhanh nhất dễ dàng nhất để chuyển đổi tài liệu hiện có sang định dạng HTML mới này là để thêm một số siêu liên kết vào các tài liệu SGML hiện có và bỏ qua mọi thẻ không được hỗ trợ hoặc triển khai.

Đây là một phần tàn dư lịch sử của cuộc chiến trình duyệt

IE và Netscape đang cạnh tranh để chiếm lĩnh thị trường và tiếp tục phát hành các tính năng mới ngày càng trở nên "tuyệt vời" hơn và buộc phải chấp nhận các trang được thiết kế cho trình duyệt khác.

Điều này có nghĩa là trình duyệt chấp nhận và bỏ qua các thẻ không xác định một cách im lặng, sau khi các ủy ban bắt đầu tham gia ... bạn cũng có một ủy ban thiết kế công cụ và kết quả là rất nhiều phiên bản khác nhau (với một số thông số kỹ thuật mơ hồ) mà trình duyệt muốn hỗ trợ hầu hết chúng và tạo một trình phân tích cú pháp riêng cho từng phiên bản sẽ rất lớn. Vì vậy, dễ dàng hơn (tương đối) để sử dụng một trình phân tích cú pháp duy nhất với các chế độ khác nhau.

Đối với một phần khác, Netscape và IE muốn html có thể truy cập được đối với người bình thường (cũng như mốt ngày nay), điều đó có nghĩa là cố gắng làm những gì người dùng muốn thực hiện thay vì những gì anh ta nói phải làm và vấp phải mọi thẻ lủng lẳng.

Làm cho vấn đề tồi tệ hơn là cũng có một số trang web "hướng dẫn" dạy sai và nghĩ rằng họ đúng vì những gì họ dạy đều hiệu quả.

Cuối cùng, điều này có nghĩa là nếu bây giờ bạn tạo một trình duyệt chỉ phân tích cú pháp html nghiêm ngặt thì 99% các trang web ngoài đó sẽ không hoạt động.

Vâng, chúng tôi đã cố gắng thiết lập một tùy chọn nghiêm ngặt tốt đẹp trong những năm 000 nhưng điều đó không thành công vì mọi người tuân theo "thực tiễn tốt nhất" một cách mù quáng, đổ lỗi cho các trình duyệt khi đánh dấu không chính xác của họ đi vào chế độ nghiêm ngặt. Và các nhà cung cấp trình duyệt không muốn bị đổ lỗi.

Họ tuyên bố đó là vì họ muốn web dễ truy cập hơn đối với những người không chuyên nhưng không ai bị ngừng sử dụng HTML 4 ở dạng nhẹ nhàng nhất.

Điều đó nói rằng, bạn vẫn có thể phục vụ HTML5 dưới dạng XML nếu bạn muốn bố cục theo kiểu nghiêm ngặt. IMO có thể là một cách tốt để gặt hái những lợi ích của việc bố trí hoặc giao diện người dùng làm việc ở chế độ chặt chẽ hơn trước khi bạn chuyển nó cho những người khác, những người có thể hoặc không muốn nó nghiêm ngặt mà không có bất kỳ rủi ro thực sự nào (cấm họ loại bỏ tài liệu vì họ thực sự ủng hộ chế độ kỳ quặc - vào năm 2017 (thời điểm chỉnh sửa này) họ nên bị bắn. Vì vậy, về cơ bản nó vẫn còn một số nghiên cứu. Tôi dường như nhớ lại rằng có một số cảnh báo mà chúng tôi không có với XHTML mà không Thực sự không ảnh hưởng đến công việc bố trí. Chỉ cần đừng lan truyền rằng đó là "cách duy nhất để làm đúng" hoặc những người sinh đôi mua vào kiểu nói chuyện đó sẽ đánh cắp ý tưởng, đổ lỗi cho các trình duyệt một lần nữa và họ sẽ lấy răng trong số các lựa chọn nghiêm ngặt duy nhất chúng tôi còn lại. (chỉnh sửa năm 2017:

http://mathiasbynens.be/notes/xhtml5