Так, на жаль, XHTML пішов.
Додавання ще 1 причини до чудової відповіді MainMa:
Коли XHTML був створений, WebApps мав на меті використовувати для подачі структурованого контенту, який зрозумів би програмне забезпечення, що не переглядає браузер, який не матиме HTML-парсери з теговими супами. Для ScreenReaders XHTML як і раніше чудово, але для будь-якого іншого програмного забезпечення WebServices підходять, що потребують, і вони в основному використовують XML або JSON. Сам SOAP має власну XML-схему, простішу, ніж XHTML та орієнтовану на роботу.
Наскільки я знаю, у світі не існує навіть 1 WebApp, який обслуговує те саме повідомлення HTTP як для браузерів, так і для інших клієнтів. Навіть архітектура REST, яка мала на меті обслуговувати одне і те ж представлення вмісту в декількох типах вмісту, виходячи з уподобань клієнта, не використовується для обслуговування браузерів XHTML / feed.
Наприклад, в Java EE, використовуючи Eclipse, ми можемо розгорнути унікальний файл війни, що містить сервлети + JSP для обслуговування HTML, а також Axis2 для обслуговування WebService. Розробити окремі програмні засоби, призначені для браузерів та WebService, просто простіше, ніж мати унікальне, складне програмне забезпечення, яке обслуговує їх усіх.
Основною причиною відхилення REST є саме складність (і малося на увазі просто!) Розробити сервер, який обслуговує той самий контент для будь-якого типу клієнтів, нічого про це не знаючи. І також важко впоратися з необхідністю швидко розвиватися в Інтернеті, а також зберігати стабільне визначення, яке не змусить клієнтів, які не переглядають браузер, оновлюватись кожного разу, коли XHTML змінюється, скажімо, щоб він зберігав XHTML дійсним, коли він побудований багатьма різними модулями.
Таким же чином, дуже важко розробити клієнт, який не переглядає браузер, який аналізує документ XHTML, навіть якщо він є дійсним, через всі ті елементи XML, які призначені для структурування макетів, що надаються браузером, а не призначені для вмісту вмісту.
Якщо прихильники REST вже скаржаться на складність XML SOAP, яка є НАЙКРАЩО простішою, ніж XHTML, призначена для браузера, уявіть, як важко обробляти XHTML для декількох типів клієнтів, сервера та клієнта.
На практиці: використовуйте HTML, схожий на XML, якщо хочете, для створення веб-сайтів для браузерів та будь-якого рішення WebService для клієнтів, які не користуються браузером.
Але я також думаю, що XHTML5 потрібно створити. XHTML 1.1 (нормально, 1,0, 1,1 є непридатним) застаріє за допомогою HTML5, і нам ще потрібен валідатор, який приймає елементи HTML5 і підтверджує правильність XML.