Данная статья - еще один ответ на довольно провокационную статью ( спасибо Fedrusу за ссылку на нее). Та статья, в свою очередь, является своего рода ответом ее автора на обоснованную критику первоначального варианта статьи. Комментарии к критической заметке в очередной раз показали, как живучи многие популярные заблуждения насчет XHTML.

Поскольку год спустя тема невольно всплыла снова, я решил написать свой ответ.

В статье приводятся 15 аргументов, но 7 из них, по сути, сводятся к одному. Я выделил его отдельным — нулевым — пунктом.

С удовольствием именно так и возражу ;). Более того, масса существующих XHTML-страниц (даже валидных!) сверстана таблицами. Взаимно-однозначное увязывание блочной верстки с XHTML, имхо — заблуждение, порожденное незнанием истории вопроса. История же эта ясно говорит о том, что вынос оформления в стили, доступ к элементам форм без мышки и т.п. появились уже в HTML 4, вытеснив (со статусом deprecated и правом на существование лишь в Transitional-страницах) тег <font> и прочие «дремучие» практики эпохи HTML 3.2. А XHTML 1.0 стал всего лишь «переформулированием» этих новых практик, окончательно закрепленных в HTML 4.01, в новом синтаксисе — но с той же самой функциональностью (для Strict-, Transitional- и Frameset-разновидностей обоих языков соответственно). У XHTML 1.1 функциональные отличия от XHTML 1.0 Strict минимальны.

Выходит, противопоставление XHTML обычному порошку табличной верстке — типичное «сравнение теплого с мягким». Табличная разметка vs. блочная — это из другого анекдота холивора. Мы же рассматриваем преимущества одного языка разметки над другим, при прочих равных условиях.

Надеюсь, уже ясно, что в основе «аргументов» 7—12 и 14 лежит ложная посылка :). Но ради полноты картины пройдемся по всем пунктам.


Все-таки, «заменившим» — на мой взгляд, слишком сильно сказано ;). В спецификациях явно не написано «HTML 4.01 obsoleted by XHTML 1.x» или чего-то подобного. «Новое поколение языков разметки» — это да. Но это было идеализированное видение будущего веба, взгляд в него из прошлого. А в настоящем жизнь распорядилась по-своему…


Если «в лоб» сравнивать синтаксис XML и HTML, то все верно — более строгий синтаксис первого не позволит открыть тег 3 раза, а закрыть 2 (к примеру). С этой точки зрения отслеживать формальные ошибки проще, спору нет.

Однако, в реальном мире XHTML интерпретируется браузерами, один из которых всегда, а другие иногда (см. п. 15) интерпретируют его по HTML-ным правилам. По которым вполне легальный (по «законам» XML) тег <div/> как раз считается незакрытым. Ошибка! И валидатор от W3C против нее, увы, бессилен.

И эту возможность двоякой интерпретации (суть HTML-совместимости) приходится все время держать в уме. То есть, фактически, быть «слугой двух господ», совсем как во времена «великой войны» IE4 с NS4…


Любят… «но странною любовью» :). Особенно FF2 (и другие браузеры на базе Gecko 1.8 и ниже), отображающие страницу лишь после полной загрузки.

Про IE (включая бету 8-ки — вроде не старый… ;) лучше промолчу.


В чем «значительное расширение» по сравнению с HTML, из этой формулировки непонятно. А для некоторых «новых и неутвержденных технологий», как показывает практика, и HTML не является противопоказанием (пример — WebForms2.0, часть спецификации HTML5, работающие в Opera 9).

Но если вместо невнятных и отрывочных «рекламных слоганов» и «космических кораблей, бороздящих…» подставить названия конкретных XML-технологий — XSLT, XPath, интеграция с MathML, SVG и т.п. — этот аргумент действительно станет бесспорным. По крайней мере, на сегодняшний день. В этом плане XHTML однозначно рулит (как минимум, везде, кроме IE), потому что в сегодняшнем HTML ничего из вышеперечисленного использовать нельзя…

…или все-таки можно? Если очень хочется… ;) Пока это, конечно, выглядит скорее техническим курьезом, но в будущем HTML 5, похоже, станет нормой (спасибо Ивану Сагалаеву за пример и ссылку).


А HTML 4.01 — разве не является частью семейства стандартов, со всеми вытекающими?


Под метаданными, судя по всему, подразумеваются микроформаты. В определении таковых можно прочитать «Microformats are small bits of HTML that…». Все нужные для них атрибуты присутствуют в HTML 4.01. Безусловно, читать их проще из XML-документа (выбор методов шире), но и в случае HTML эта задача вполне решаема стандартными средствами. 


С точки зрения самой разметки XHTML 1.0 не позволяет ничего такого, чего не позволял бы HTML 4.01, чьим «переводом» на XML-синтаксис он является. Все нужные теги там уже были. И тот же CSS был.


Аналогично. Все нужные теги и атрибуты (accesskey, tabindex и т.д.) доступны в HTML 4.01. Было бы желание и умение их применить…


Ирония судьбы в том, что… доступность для всего вышеперечисленного изначально закладывалась еще в спецификацию HTML 4 (см. последний абзац раздела).

Рациональное зерно в этом пункте есть — для мобильников начала 2000-х возможность использовать компактный и нетребовательный к ресурсам XML-парсер вместо громоздкого HTML-ного была заметным плюсом. Но для сегодняшних мобильников, чьи процессорные мощности как минимум не уступают компьютерам конца середины 90-х (неплохо справлявшихся с парсингом HTML, как мы помним;), это уже едва ли актуально. И, наконец, важный момент, о котором почему-то всегда забывают в этом холиворе: нам ведь мало отобразить «голый» текст, мы хотим отобразить его красиво — не зря ведь мы заготовили специальный стиль для мобильной версии. Минутку! Кто сказал, что парсинг и интерпретация нетривиального CSS — более простая задача, чем парсинг разметки? ;)


Опять же. Это делает не XHTML, а CSS. См. пп. 0 и 7 :)


Комментарии и впрямь излишни — по той же причине, что в предыдущем пункте: сам XHTML тут ни при чем.

Если же сравнивать «в лоб» полностью эквивалентные верстки на XHTML и HTML (обе с вынесенным в CSS оформлением и т.д.), первая очевидно будет тяжелее на сотню-другую байт — атрибут xmlns, пресловутые слеши в empty-тегах и т.п. (шутка ;).


И снова здравствуйте :). Какое отношение имеет XHTML к выносу оформления, мы вроде бы разобрались в пп. 0, 7 и 10. А фраза о том, в какой момент пользователь сможет приступить к прочтению текста, в свете «пикантной» особенности Gecko (см. п.3), на мой взгляд, и вовсе выглядит издевкой. По крайней мере, до релиза FF3 (Gecko 1.9), обязанного исправить ситуацию.


HTML-кодеру легче разобраться в аккуратном и семантичном коде, чем в запутанной мешанине несемантичных div-ов (а то и смеси дивов с таблицами). Оба языка разметки позволяют создавать как первое, так и второе.


Опять см. п. 10. Можно и п.7 — по большому счету, все они про одно и то же. Далеко не про XHTML ;).


Да, обрабатывается. Но при двух условиях: 1) если он отдается как text/html и 2) соблюдаются HTML Compatibility Guidelines. Первое из которых сводит на нет практически все реальные преимущества XHTML, связанные с его XML-ной природой (см. п.4), потому что XHTML, отданный как text/html, парсится всеми браузерами как обычный HTML (притом некорректный). А второе накладывает кучу искусственных ограничений (напр., необходимость двойного экранирования скриптов при невозможности вынести их во внешний файл), что, в свою очередь, чревато ошибками (см. п. 2) и лишней тратой времени. Поддержка же CSS, как и стиль верстки, от языка разметки не зависит!

Итак, от 15 «неоспоримых» преимуществ у нас фактически осталось одно: XML-ность XHTML. Надеюсь, все в курсе, что в браузере оно проявляется лишь в том случае, если страница отдана с правильным Content-type (application/xhtml+xml или application/xml). И ни одна версия IE, к сожалению, не умеет отображать XHTML с таким Content-type по-человечески…

Стоит ли это преимущество того, чтобы использовать XHTML, несмотря на «козни» IE и прочие браузерные разночтения? Конечно, стоит! Если страница разрабатывается для специфической аудитории, в которой процент пользователей IE пренебрежимо мал, зато требуется отображать математические формулы (посредством MathML). Если страница должна активно обмениваться данными с другими приложениями посредством микроформатов. В конце концов, если страницы попросту генерируются инструментом (редактором, движком и т.д.), «заточенным» под XML. В общем, всегда, когда это оправданно (это каждый определяет для себя сам, по балансу плюсов и минусов).

Отделять же структуру от оформления вполне можно и в HTML. Во многих типичных веб-задачах, где нужна кроссбраузерность и поддержка IE, это будет наиболее быстрым и надежным решением. Да и W3C, вернувшийся к разработке HTML 5, явно перестал считать HTML чем-то из вчерашнего дня.

А общий вывод, которым я хотел бы подытожить эту статью — стандарты нужно знать. Знание возможностей, ограничений и области применения каждого инструмента или технологии — лучшая профилактика недоразумений и путаницы, подобных той, с которой началась эта статья. И пусть ваши страницы (неважно, на каком языке) будут валидными, семантичными и одинаково выглядят во всех браузерах! :)

архибольшая статья, много буков, всё не читал

мне лично на всё это побарабану до тех пор пока я вписываюсь в реальные системы.

как считаешь, 
1. нужно ли гоняться за валидностью, или браузеры всегда будут нормально понимать не валидную разметку?
2. к какому стандарту вообще стоит стремится?

Ну извиняюсь. Я старался ужимать как мог, но это предел. Впрочем, если отвлечься от исходной статьи, можно выразить идею одной фразой: XHTML не дает никаких принципиально новых возможностей по сравнению с HTML 4.01, за исключением возможности обрабатывать его с помощью XML-технологий 


Смотря что считать "нормальным пониманием" ;).

В режиме text/html браузеры любую разметку - хоть валидную, хоть нет, хоть с доктайпом (любым), хоть без него - преобразуют в DOM, имеющий мало общего с исходной разметкой. Но чем валиднее разметка, тем предсказуемее результат этого преобразования. Сугубо имхо, для практики более чем достаточно, если страница, невалидная как Strict, может валидироваться как Transitional (для правильного построения DOM этого достаточно, а для браузера разница между Strict и Transitional сводится к переключению между "полустандартным" и полностью стандартным режимом).

Но лучше верстать валидно - лишь в этом случае в любых глюках отображения будет однозначно виноват браузер, а не верстальщик 


Имхо, самые радужные перспективы на сегодня у HTML 5.