История изменений
Исправление EXL, (текущая версия) :
Какой смысл в особом диалекте XML для HTML если можно использовать обычный XML?
Как предполагали раньше смысл был и начинание было неплохим. Например, парсеры XHTML сайтов делаются гораздо проще и API у XHTML-страничек по сути детерминировано и поддаётся валидации.
Вообще задумка была хорошая, так как XML-подобные парсеры для XHTML намного проще для реализации и DOM на их основе менее ресурсоёмок, чем у HTML-парсеров с той кучей механизмов вроде компенастора ошибок что там есть.
Повсеместное использование XHTML серьёзно бы облегчило браузеры и сделало их производительнее, а загрузку и показ страниц более быстрой.
Но стоит помнить, что в IT всегда набирают популярность, становятся стандартом и побеждают наиболее идиотские решения: PHP, CMake, Bash/Shell, X11, Make и др., тогда как адекватно спроектированное решение выкидывают на помойку. Так и в случае XHTML vs. HTML.
Вся вина этой технологии в том, что она не стала повсеместной и распространённой. Web-макакам прошлых лет, лабающим сайты на PHP как попало и пихающими теги куда придётся, лишь бы прожевалось браузером, этот XHTML бил по рукам и по морде, что им не нравилось. Так оно и не взлетело. Какой смысл думать об стройности и валидируемости отдаваемоего сервером документа, когда наговняканную PHP-лапшой страницу HTML-парсер обмажет компенсатором ошибок и кряхтя-пыхтя, по пути взяв энергию на пару деревьев, но покажет пользователю?
Исходная версия EXL, :
Какой смысл в особом диалекте XML для HTML если можно использовать обычный XML?
Нет ну раньше как предполагали смысл-то был. Например, парсеры XHTML сайтов делаются гораздо проще и API у XHTML-страничек по сути детерминировано и поддаётся валидации.
Вообще задумка была хорошая, так как XML-подобные парсеры для XHTML намного проще для реализации и DOM на их основе менее ресурсоёмок, чем у HTML-парсеры с той кучей механизмов вроде компенастора ошибок что там есть.
Повсеместное использование XHTML серьёзно бы облегчило браузеры и сделало их производительнее.
Но стоит помнить, что в IT всегда набирают популярность, становятся стандартом и побеждают наиболее идиотские решения: PHP, CMake, Bash/Shell, X11, Make и др., тогда как адекватно спроектированное решение выкидывают на помойку. Так и в случае XHTML vs. HTML.
Вся вина этой технологии в том, что она не стала повсеместной и распространённой. Web-макакам прошлых лет, лабающим сайты на PHP как попало и пихающими теги куда придётся, лишь бы прожевалось браузером, этот XHTML бил по рукам и по морде, что им не нравилось. Так оно и не взлетело. Какой смысл думать об стройности и валидируемости отдаваемоего сервером документа, когда наговняканную PHP-лапшой страницу HTML-парсер обмажет компенсатором ошибок и кряхтя-пыхтя, по пути взяв энергию на пару деревьев, но покажет пользователю?