Vậy chuyện gì đã xảy ra với XHTML5?
Trang đó là bản nháp cho cả xhtml5 và html5? Vì vậy, không có sự khác biệt giữa các loại tài liệu?
Vậy chuyện gì đã xảy ra với XHTML5?
Trang đó là bản nháp cho cả xhtml5 và html5? Vì vậy, không có sự khác biệt giữa các loại tài liệu?
Câu trả lời:
Vào năm 2012 tại thời điểm viết bài, rõ ràng W3C đã quyết định từ bỏ XHTML cho HTML 5. Quyết định này được thúc đẩy bởi một số lý do:
Chỉ có vài người thực sự quan tâm đến XHTML. Hầu hết các trang web được viết bằng HTML đơn giản.
Thậm chí ít thực sự hiểu XHTML là gì và làm thế nào để sử dụng nó. Thay vào đó, quá nhiều trang web giả vờ phục vụ XHTML đã sử dụng các tiêu đề sai Content-Type: application/xhtml+xml
.
Ngay cả khi bạn hoàn toàn hiểu XHTML là gì và những gì phải là tiêu đề, điều này thực sự khó khăn với một số trình duyệt tào lao không chấp nhận / hỗ trợ application/xhtml+xml
loại nội dung. Điều này có nghĩa là bạn phải thay đổi tiêu đề theo trình duyệt.
Phần XML của XHTML cũng gây ra một số tình huống kỳ lạ mà các nhà phát triển phải giải quyết. Một INVALID_STATE_ERR: DOM Exception 11
thông báo xuất hiện khi bạn gán văn bản chứa các ký tự HTML (như é
) cho một thành phần trong trang XHTML. Khi bạn gặp lỗi này với thông báo rất hữu ích của nó trong một ứng dụng web lớn sau khi thực hiện một yêu cầu AJAX, bạn thực sự không biết đó có phải là lỗi của JQuery, AJAX hay điều gì khác không.
Viết mã HTML 5 không có nghĩa là trộn lẫn các thẻ xung quanh. Nếu bạn đam mê XML và XHTML, bạn vẫn có thể viết mã HTML 5 trông rất gần với XML.
Trong những ngày đầu của điện thoại di động, XHTML rất thú vị đối với các thiết bị di động không mạnh lắm. Phân tích cú pháp XML dễ dàng hơn nhiều so với HTML. Giờ đây, với các thiết bị di động lõi kép, thực sự không có vấn đề gì nếu chúng phải phân tích cú pháp XML hợp lệ hoặc HTML bẩn đầy các bản hack và thẻ hỗn hợp.
Thông số kỹ thuật của tháng 10 năm 2014 đề cập đến cú pháp XHTML . Hiện tại, vẫn chưa rõ liệu có một thứ như ngôn ngữ XHTML mới (không phải cú pháp ) hay không và nếu có, vị trí của XHTML sẽ như thế nào, cũng không phải là tiêu chuẩn XHTML mới của các trình duyệt chính.
XHTML5 là một từ đồng nghĩa với "HTML5 được tuần tự hóa dưới dạng XML".
Có nhiều cú pháp cụ thể khác nhau có thể được sử dụng để truyền tài nguyên sử dụng ngôn ngữ trừu tượng này, hai trong số đó được xác định trong đặc tả này.
...
Cú pháp cụ thể thứ hai là cú pháp XHTML, là một ứng dụng của XML. Khi một tài liệu được truyền với loại MIME XML, chẳng hạn như application / xhtml + xml, thì nó được xử lý như một tài liệu XML bởi các trình duyệt Web, được bộ xử lý XML phân tích cú pháp. Các tác giả được nhắc nhở rằng việc xử lý XML và HTML khác nhau; đặc biệt, ngay cả các lỗi cú pháp nhỏ cũng sẽ khiến tài liệu được gắn nhãn XML không được hiển thị đầy đủ, trong khi chúng sẽ bị bỏ qua trong cú pháp HTML. Thông số kỹ thuật này xác định phiên bản 5.0 của cú pháp XHTML, được gọi là "XHTML 5".
Ngoài ra, có một tài liệu hay về cách viết các đa giác HTML5 (các trang, có thể được tuần tự hóa cả dưới dạng HTML5 và XML thông thường) tại đây:
http://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5
Và một trình xác nhận thậm chí!
Ngày nay, nó hiếm khi được gọi là XHTML5 (và thậm chí hiếm khi được sử dụng hơn), vì về cơ bản nó vẫn là HTML5, nhưng nó vẫn ở đó.
Nói một cách đơn giản: mọi thay đổi đối với thông số HTML5 cũng là một thay đổi ngầm định, tương ứng với XHTML5.
HTML5 là một tiêu chuẩn thực tế và de jure ! XHTML là có, như là tiêu chuẩn cũng có.
Khuyến nghị của W3C ngày 28 tháng 10 năm 2014
Tiêu đề của tiêu chuẩn chứa chuỗi "và XHTML" , vì vậy, chúng tôi đang nói về quyết định cuối cùng của W3C là hợp nhất HTML và XHTML thành một tiêu chuẩn duy nhất ; và tiêu chuẩn này cho thấy cách tuần tự hóa một tệp HTML thành tệp XHTML và ngược lại.
XHTML
bộ phận và ghi chú quan trọng:
application/xhtml+xml
Theo tóm tắt của LF Sikos
XHTML5 là tuần tự hóa XML của HTML5. Cú pháp được mô tả bởi đặc tả HTML5. Tuy nhiên, không nên nhầm lẫn vì XHTML5 là một ứng dụng của XML. Nói cách khác, HTML5 và XHTML5 có từ vựng giống hệt nhau nhưng quy tắc phân tích cú pháp khác nhau.
Tài liệu HTML5 cũng có thể là tài liệu XML hợp lệ. Đánh dấu này thường được gọi là ngôn ngữ đa ngôn ngữ của người Viking. Đó là ngôn ngữ chồng chéo của các tài liệu là các tài liệu HTML5 và XML cùng một lúc. Tuần tự hóa HTML5 và XHTML5 tương thích chéo. Tuy nhiên, XHTML5 có cú pháp chặt chẽ hơn. Hơn nữa, một số phần của XHTML5 không hợp lệ trong HTML5, ví dụ: hướng dẫn xử lý.
Vì vậy, nói một cách nghiêm túc (và được nhấn mạnh bởi @vaxquis) "XHTML chỉ là một cú pháp để tuần tự hóa XML", không có DTD hoặc loại lược đồ XML nào khác .
Một số người không thích nói "XHTML5 là XHTML". Câu hỏi phải được chia thành một Câu hỏi thường gặp nhỏ về "khi nào tôi có thể sử dụng nó dưới dạng XHTML". Đây là WIKI, vui lòng sửa nếu có một số "hiểu lầm" ...
Có một số vấn đề trong "hội tụ HTML5-to-XHTML5 / XHTML5-to-HTML5" hoàn hảo và chung chung, bạn phải thực hiện "lựa chọn cá nhân" và mất thông tin. Vì bối cảnh sẽ có câu trả lời khác nhau:
Nói lỏng lẻo : CÓ. Có rất nhiều ví dụ (đơn giản) trong đó ánh xạ là hoàn hảo và có thể đảo ngược.
Nói đúng ra : KHÔNG. Xem thêm @vaxquis bình luận bên dưới và câu trả lời cũ trong trang này. Một số vấn đề điển hình:
Vâng, bạn có thể. Ngay cả các mảnh vỡ nối tiếp.
Có, nhưng không nhanh và dễ dàng hơn DTD cũ ... Xem các trình xác nhận phức tạp, dưới dạng trình xác thực.nu
Vâng, bạn có thể. Hãy giải thích những gì bạn có thể.
Một số khung, như Cocoon , sử dụng " chuỗi XSLT ". Các đầu ra HTML5 và XHTML5 có thể được sử dụng làm "đầu ra cuối cùng trong chuỗi" ... Tất nhiên, trong các bước trung gian, HTML5 không thể được sử dụng vì không phải là XML, nhưng XHTML5 có thể được sử dụng.
Vấn đề xác thực ở trên lại xuất hiện ở đây: không có quy ước mạnh, do đó, đôi khi, ít rõ ràng hơn về "cấu trúc tiêu chuẩn XHTML" xuất hiện. Trong tình huống đó, bạn phải chú ý đến "quy ước của bản thân" và nhất quán.
saveXML()
phương thức không?Đúng. Đây là một tình huống điển hình trong đó các khuyến nghị nối tiếp được sử dụng. XML sẽ hợp lệ, mã XHTML5 được ánh xạ từ trạng thái HTML5 và DOM ban đầu ... Nhưng, trong một số cấu trúc, một số thông tin có thể bị mất, như đã nhận xét ở trên.
Có tiếc là XHTML đã biến mất.
Thêm 1 lý do nữa cho câu trả lời tuyệt vời của MainMa:
Khi XHTML được tạo, nó được sử dụng bởi WebApps để phục vụ nội dung có cấu trúc sẽ được hiểu bởi các phần mềm không phải trình duyệt, sẽ không có trình phân tích cú pháp HTML tag-soup. Đối với ScreenReaders XHTML vẫn rất tuyệt, nhưng đối với bất kỳ loại phần mềm nào khác, WebService phù hợp với nhu cầu đó và họ chủ yếu sử dụng XML hoặc JSON. Bản thân SOAP có Lược đồ XML riêng, đơn giản hơn XHTML và hướng theo hoạt động.
Theo như tôi biết, thậm chí không có 1 WebApp nào trên thế giới phục vụ cùng một thông điệp HTTP cho cả trình duyệt và các máy khách khác. Ngay cả kiến trúc REST, có nghĩa là phục vụ cùng một đại diện cho một nội dung trong nhiều loại nội dung dựa trên sở thích của khách hàng, không được sử dụng để phục vụ các trình duyệt XHTML / feed.
Ví dụ, trong Java EE, bằng cách sử dụng Eclipse, chúng ta có thể triển khai một tệp chiến tranh duy nhất chứa Servlets + JSP để phục vụ HTML, cùng với Axis2 để phục vụ WebService. Đơn giản là dễ dàng phát triển các phần mềm riêng biệt dành cho trình duyệt và WebService hơn là có một phần mềm phức tạp, duy nhất phục vụ tất cả.
Lý do chính khiến REST bị từ chối chính xác là sự phức tạp (và nó có nghĩa là đơn giản!) Khi phát triển một máy chủ phục vụ cùng một nội dung cho bất kỳ loại khách hàng nào mà không biết gì về nó. Và thật khó để xử lý nhu cầu phát triển nhanh của Web, cùng với việc giữ một định nghĩa ổn định sẽ không buộc các máy khách không phải trình duyệt được cập nhật mỗi khi XHTML thay đổi, nói rằng nó giữ XHTML hợp lệ khi được xây dựng bởi nhiều mô-đun khác nhau.
Theo cùng một cách, rất khó để phát triển ứng dụng khách không có trình duyệt phân tích tài liệu XHTML, thậm chí nó còn hợp lệ, vì tất cả các yếu tố XML đó có nghĩa là cấu trúc bố cục được trình duyệt hiển thị và không có nghĩa là giữ nội dung.
Nếu những người áp dụng REST đã phàn nàn về độ phức tạp XML của SOAP, thì WAY đơn giản hơn XHTML đối với trình duyệt, hãy tưởng tượng việc xử lý XHTML đối với nhiều loại máy khách, máy chủ và máy khách khó đến mức nào.
Trong thực tế: sử dụng HTML, giống như XML nếu bạn muốn, để xây dựng WebSites cho trình duyệt và bất kỳ loại giải pháp WebService nào cho các máy khách không có trình duyệt.
NHƯNG, tôi cũng nghĩ rằng XHTML5 phải được tạo. XHTML 1.1 (ok, 1.0, 1.1 không sử dụng được) sẽ trở nên lỗi thời với HTML5 và chúng tôi vẫn cần một trình xác nhận chấp nhận các yếu tố của HTML5 và xác thực tính phù hợp của XML.