Tại sao không phải là XHTML5?

53

Vì vậy, HTML5 là Bước tiến lớn, tôi đã nói. Bước cuối cùng mà chúng tôi biết là tôi đã giới thiệu XHTML. Những lợi thế rất rõ ràng: đơn giản, nghiêm ngặt, khả năng sử dụng các trình phân tích cú pháp và trình tạo XML tiêu chuẩn để làm việc với các trang web, v.v.

Sau đó, thật kỳ lạ và bực bội khi HTML5 đó cuộn lại tất cả: một lần nữa chúng ta làm việc với một cú pháp không chuẩn; một lần nữa, chúng ta phải đối phó với sự phức tạp trong lịch sử và phân tích cú pháp; một lần nữa, chúng ta không thể sử dụng các thư viện, trình phân tích cú pháp, trình tạo hoặc trình biến đổi XML tiêu chuẩn của mình; và tất cả các lợi thế được giới thiệu bởi XML (khả năng mở rộng, không gian tên, tiêu chuẩn hóa, v.v.), rằng W3C đã dành một thập kỷ thúc đẩy vì những lý do chính đáng, đã bị mất.

Tốt thôi, chúng tôi có XHTML5, nhưng có vẻ như nó chưa được phổ biến như mã hóa HTML5. Xem câu hỏi SO này , ví dụ. Ngay cả đặc tả HTML5 cũng nói rằng HTML5, không phải XHTML5, "là định dạng được đề xuất cho hầu hết các tác giả."

Tôi có sai sự thật không? Nếu không, tại sao tôi là người duy nhất cảm thấy như vậy? Tại sao mọi người chọn HTML5 trên XHTML5?

— jameshfisher
nguồn

6

+1 Tôi thấy rằng tôi không phải là người duy nhất nản lòng với việc mất tất cả các lợi thế XML trong HTML5.

— Arseni Mourzenko

Honking câu hỏi tốt, cũng đặt.

— Konrad Rudolph

1

Tôi hy vọng tôi không phải là người duy nhất vui mừng khi mất tất cả các nhược điểm của XML trong HTML5. Ví dụ: hãy so sánh HTML5 hợp lệ với XHTML hợp lệ. HTML5 : <!DOCTYPE html>Hello World, XHTML:

<?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, bạn chắc chắn không phải là người duy nhất vui mừng, và đó là lý do tại sao tôi hỏi câu hỏi này ngay từ đầu. Ngoài ra: bạn sẽ không nghiêm túc viết <!DOCTYPE html>Hello World, phải không? Hãy thử điều đó trên trình xác nhận này .

— jameshfisher

1

@eegg, rõ ràng bạn chưa đọc thông số kỹ thuật trên các thẻ bắt đầu tùy chọn , vì tôi thực sự sẽ viết <!DOCTYPE html>Hello World!, vì đó là HTML5 hoàn toàn hợp lệ. Các tài liệu ngắn hơn có nghĩa là ít băng thông hơn, tương đương với khoản tiết kiệm đáng kể cho các công ty lớn (bạn đã thấy những gì google gửi cho www.google.com chưa?).

— zzzzBov

25

Tôi khuyên bạn nên đọc Làm thế nào chúng ta đã đến đây? . Mark Pilgrim cung cấp một lịch sử tuyệt vời và ngắn gọn về HTML cho đến HTML5.

Về cơ bản, sự hiểu biết của tôi là nhiều trang web thậm chí không tận dụng "X" của XHTML vì chúng không chỉ định loại MIME phù hợp cho nó.

— pthesis
nguồn

18

Vâng. Tóm tắt của tôi về câu chuyện đó sẽ là: "Này, không ai tuân thủ đặc điểm kỹ thuật. Có lẽ chúng ta có thể khiến họ tuân thủ đặc điểm kỹ thuật bằng cách chỉ định rằng mọi người có thể mắc bất kỳ lỗi nào họ muốn. Cuối cùng, tất cả các tài liệu của chúng tôi sẽ không có lỗi và tuân thủ các tiêu chuẩn. " Không có gì tốt có thể đến từ việc viết một đặc tả với giả định ban đầu rằng không ai tôn trọng thông số kỹ thuật.

— jameshfisher

1

@eegg, dòng cuối cùng của bạn cho thấy sự thiếu hiểu biết của bạn với thực tế. Rất nhiều điều tốt đã đến từ việc cho rằng không ai hoàn hảo . Thay vì thông số kỹ thuật, "nếu bạn mắc lỗi, mọi thứ đều bị hỏng", thay vào đó, nó nói, "nếu bạn mắc [loại sai lầm này] thì [kết quả này] là điều nên xảy ra". Có bao nhiêu cuốn sách sẽ được lên kệ của chúng tôi nếu chúng phải được viết đúng 100% chính tả, dấu câu và ngữ pháp để chúng được xuất bản?

— zzzzBov

6

@zzzzBov, sự tương đồng của bạn với những cuốn sách được xuất bản thật kỳ lạ. Tại sao trình phân tích cú pháp HTML phải dễ tha thứ hơn trình phân tích cú pháp cho [bất kỳ ngôn ngữ nào khác ở đây], khi gặp lỗi cú pháp với thông báo lỗi? Hãy tưởng tượng sự hỗn loạn mà chúng ta sẽ gặp phải nếu trình biên dịch C của chúng ta cố gắng hết sức để âm thầm diễn giải lại cú pháp bị hỏng.

— jameshfisher

@eegg, tôi có thể hình dung điều gì sẽ xảy ra nếu trình phân tích cú pháp cho bất kỳ ngôn ngữ nào khác phản ứng với lỗi cú pháp theo cách dễ tha thứ hơn: chúng tôi sẽ dành ít thời gian hơn để tìm kiếm dấu ngoặc sai và thiếu dấu hai chấm và mất nhiều thời gian hơn để nhập mã chức năng. Tôi không nói rằng các lập trình viên giỏi sẽ vẫn không làm cho chương trình của họ được hình thành tốt, nhưng chắc chắn nó sẽ giúp các lập trình viên tầm thường viết mã làm việc. Một Cchương trình có thể sẽ trông giống với một Pythonchương trình hơn ở chỗ các dấu chấm phẩy và dấu ngoặc có thể biến mất và phần còn lại là mã quan trọng.

— zzzzBov

Tài nguyên /past.htmlđược yêu cầu không còn khả dụng trên máy chủ này và không có địa chỉ chuyển tiếp.

— VÒNG

6

Nếu bạn sản xuất html5 tương thích xml và gửi chúng với xml dưới dạng mime, thì trình phân tích cú pháp xml sẽ được sử dụng tất cả những gì nhạc jazz hay trở lại;)

EDIT: thấy rằng để biết thêm thông tin: http://wiki.whatwg.org/wiki/HTML_vs._XHTML

— deadalnix
nguồn

Xác định "nhạc jazz hay". AFAIK không có lợi thế để phân tích HTML dưới dạng XML. Tạo và chuyển đổi là những vấn đề khác, những vấn đề này có thể thuận tiện, nhưng việc phân tích cú pháp tự nó không mang lại lợi thế, chỉ có nhược điểm (nó làm cho lỗi mỹ phẩm gây tử vong).

— Joeri Sebrechts

3

@Joeri Thực tế là việc phân tích cú pháp dễ dàng hơn rất nhiều là một lợi thế trong cuốn sách của tôi, vì nhiều lý do (phân tích cú pháp chặt chẽ tạo điều kiện cho việc tìm lỗi, hỗ trợ công cụ tốt hơn vì các công cụ dễ viết hơn, vệ sinh đầu vào dễ dàng hơn, v.v.).

— Konrad Rudolph

Bạn cũng có thể cung cấp một số chức năng không có sẵn trong html tiêu chuẩn, như micin xhtml với các nội dung xml khác và thông thường sử dụng tất cả các chức năng xml, không gian tên cho ví dụ. trình phân tích cú pháp html có thể sửa mã nguồn xấu - lỗi mỹ phẩm khi bạn gọi chúng - nhưng những sửa lỗi đó có giá. Giá là trình duyệt cần phải biết những gì nó có thể tìm thấy trong mã, do đó hạn chế các chức năng có sẵn.

— deadalnix

3

HTML5 là kết luận hợp lý và không thể tránh khỏi của các trình duyệt áp dụng luật của Postel ("Hãy tự do trong những gì bạn chấp nhận").

Khi một trình duyệt có đủ thị phần áp dụng nguyên tắc này, các trình duyệt khác buộc phải tuân theo, không chỉ là tự do bằng cách chấp nhận nội dung không tuân thủ, mà còn hiển thị nó giống như đối thủ của họ. HTML5 là kết quả hợp lý của tình huống đó: các nhà cung cấp trình duyệt đã quyết định rằng vì họ sẽ không từ chối bất kỳ nội dung nào là không hợp lệ (ít nhất, không phải ở cấp độ HTML - Javascript là một vấn đề khác!) Họ cũng có thể ngồi quanh bảng và đồng ý một giải thích cho bất cứ điều gì tác giả nội dung có thể ném vào họ. Trong môi trường này, họ đã không phản ứng tử tế với các tiêu chuẩn - các chuyên viên máy tính nói với họ rằng nếu họ từ chối nội dung không đúng từ từ đó, họ sẽ không gặp rắc rối này.

Vì vậy, bạn và tôi có thể hét lên từ bên lề và nói với các nhà cung cấp trình duyệt và người dùng của họ rằng thế giới sẽ là một nơi tốt hơn nếu họ không tin John Postel, nhưng thiệt hại đã được thực hiện và rất khó để hoàn tác nó.

— Michael Kay
nguồn

3

Câu chuyện về sự chậm chạp cạnh tranh của trình duyệt là đủ đúng. Nhưng đây là điều: đó là lý do tại sao các chuyên viên máy tính tiêu chuẩn tồn tại. Nếu tất cả các trình duyệt đã thực thi thẳng và thu hẹp ngay từ đầu, các tổ chức như W3C sẽ không cần phải ở đây để giữ mọi thứ trong tầm kiểm soát. Toàn bộ điểm của các tiêu chuẩn là kiểm soát thiệt hại; cho các cơ quan tiêu chuẩn để nhượng bộ và chấp nhận sự trì trệ đánh bại chính mục đích của nó.

— jameshfisher

1

@eegg: HTML5 xác định lại các quy tắc phân tích cú pháp để làm cho tất cả các đầu vào hợp lệ và vẫn có các hậu quả có thể dự đoán được. Nếu lỗi cú pháp là không thể, cả lớp lỗi sẽ được loại trừ ngay từ đầu. Khả năng có các lỗi phân tích cú pháp của XML là một lỗ hổng thiết kế và phải được công nhận như vậy.

— Joeri Sebrechts

1

@Joeri, vị trí của bạn dường như là của thông số HTML5, được đưa đến kết luận logic điên rồ của nó. "HTML5 xác định lại các quy tắc phân tích cú pháp để làm cho tất cả đầu vào hợp lệ" - không. Khái niệm phân tích lỗi vẫn tồn tại. "Nếu lỗi cú pháp là không thể, cả lớp lỗi được loại trừ ngay từ đầu" - có lẽ đây là sự nhại lại? Logic này là những gì tôi mỉa mai châm biếm trong bình luận của tôi cho câu trả lời của @pthesis. Có, loại lỗi cú pháp được loại bỏ, được thay thế bằng một lớp lỗi sửa lỗi cú pháp trình duyệt lớn hơn .

— jameshfisher

2

Đặc tả HTML5 thực sự đã được cải thiện rất nhiều so với đặc tả HTML4. Cụ thể, việc xử lý các điều kiện lỗi và đánh dấu không hợp lệ thực sự được chuẩn hóa, có nghĩa là tất cả các trình duyệt thực hiện đúng tiêu chuẩn sẽ xử lý đánh dấu không hợp lệ theo cùng một cách.

HTML được viết bởi con người thường xuyên hơn không (thường kết hợp với một số loại ngôn ngữ tạo khuôn mẫu) và con người mắc lỗi. Miễn là tất cả các trình duyệt xử lý các lỗi cú pháp theo cùng một cách, thì quy tắc "tự do trong những gì bạn chấp nhận" là hoàn toàn chấp nhận được.

Thực sự có rất ít lợi thế trong việc tạo ra XML hợp lệ, vì các công cụ và thư viện để xử lý HTML là (gần như) có sẵn và HTML dễ dàng cho con người viết hơn XML.

— Trưởng khoa
nguồn

Qua đặc tả HTML4 , vâng. Nhưng quan điểm của tôi là XHTML1.1 đã được cải thiện về điều đó. Các công cụ / thư viện để xử lý HTML có xu hướng giống như BeautifulSoup - trong khi các công cụ tuyệt vời, chúng sẽ chết cùng với các trang chúng được tạo để phân tích cú pháp.

— jameshfisher

1

Bạn sẽ không bao giờ nhận được lợi ích của trình phân tích cú pháp đơn giản hơn hoặc các công cụ XML tiêu chuẩn ở phía máy khách.

Có hàng tỷ trang trên web bằng HTML, một số trang được viết bởi những người đã chết từ lâu, vì vậy chúng sẽ không bao giờ được cập nhật lên XML. Vì vậy, nếu bạn muốn tạo một tác nhân người dùng thường hữu ích, bạn phải có khả năng phân tích cú pháp HTML cũ. Có thể cho rằng XHTML chỉ giới thiệu độ phức tạp bổ sung vì nó yêu cầu một chế độ phân tích cú pháp mới bên cạnh phân tích cú pháp HTML mà bạn đã phải hỗ trợ.

Về phía máy chủ, bạn vẫn có thể tận dụng các công cụ XML bằng cách. tạo XHTML bằng XSLT. Nhưng nếu bạn không sử dụng cụ thể một chuỗi công cụ XML, thì không có lợi ích gì trong việc sử dụng cú pháp XML thay vì chỉ HTML.

(Bạn không chính xác rằng HTML là cú pháp "không chuẩn". Cú pháp của HTML được chỉ định chi tiết cần thiết trong thông số HTML5, do đó, nó cũng giống như cú pháp XML.)

— JacquesB
nguồn