HTML или XHTML?

Дата публикации: 12.01.2008

Категория: Верстка веб-сайтов

Комментарии: 39

Тема стара, как мир, но «пройти мимо» я не могу по двум вполне объективным причинам. Первая и главная причина заключается в том, что следующую публикацию я планирую посвятить созданию базового документа, который будет использоваться во всех последующих практических занятиях. В данном контексте необходимо определиться с выбором стандарта, которому этот документ будет соответствовать. Очевидно, что без соответствующей теоретической подготовки сделать правильный выбор не представляется возможным.

В то же время я до сих пор наталкиваюсь в Сети на различный космический бред. Например, такой:

Почему у тебя в примерах разметки инпуты, имг и бр'ы не закрытые???
О каких стандартах идет речь???

Или такой:

По стандарту нужно писать не <br>, а <br />.
<br /> – это тот же перенос строки, просто написанный по правильному...

Или даже вот такой:

Для тэгов, не требующих закрывающего тэга, согласно спецификации HTML указывайте слэш перед закрывающей скобкой после одного (или более) пробела. Например: <br />...

Полиграф ПолиграфовичПодобные заявления просто невозможно оставить без внимания. Так и хочется порой процитировать в ответ доктора Борменталя: «Вы, Шариков, чепуху говорите. И возмутительнее всего то, что говорите ее безапелляционно и уверенно». Ведь прежде чем рассуждать о том или ином синтаксисе в целом или о закрытии «пустых» элементов в частности, необходимо выяснить с каким именно стандартом мы имеем дело.

В данной публикации я постарался обобщить некоторые сведения о различных языках разметки, рассмотреть индивидуальные особенности их синтаксиса и дать определенные рекомендации по их применению, основанные на моем личном опыте и предпочтениях.

HTML

Чарльз ГольдфарбСначала был SGML – стандартный общий язык разметки, прототип которого создал в 1969 году Чарльз Гольдфарб, сотрудник компании IBM. Сам по себе SGML не предназначался для практической разметки документов. Он всего лишь описывал общий синтаксис записи структурных элементов, правила определения новых элементов и различные структурные отношения между этими элементами. Другими словами, SGML являлся своеобразной базой для создания полноценных систем разметки текстовой информации (SGML-приложений).

Тим Бернерс-ЛиSGML приобрел статус международного стандарта в 1986 году, но широкого распространения в то время так и не получил. Важное и знаменательное событие случилось несколько позже. В 1991 году сотрудник CERN (Европейского центра исследований физики элементарных частиц) Тим Бернерс-Ли занимался разработкой системы передачи данных по сети Интернет и взял SGML за основу для создания нового языка разметки гипертекстовых документов. Этот новый язык был назван HTML – HyperText Markup Language.

В июне 1993 года была выпущена версия HTML 1.2, которая включала в себя 44 логических конструкции и полностью разделяла идеологию SGML. Чуть позже, в 1994 году, был образован W3C (Консорциум Всемирной паутины), который перенял полномочия CERN в области стандартизации Веба и начал заниматься подготовкой следующей версии языка разметки гипертекста. Несмотря на то, что единственным серьезным нововведением в HTML 2.0 был механизм форм, процесс подготовки и выпуска этой версии весьма затянулся. Стандарт HTML 2.0 был официально утвержден только в ноябре 1995 года, когда уже во всю обсуждался новый проект – HTML 3.

Так или иначе, но третьей версии HTML увидеть свет было не суждено. Причиной этому послужила все та же скрупулезность и заторможенность Консорциума. Пока специалисты W3C обсуждали новые логические конструкции и поддержку каскадных таблиц стилей (CSS), полным ходом началось коммерческое освоение Веба. Не дожидаясь выхода очередного стандарта, производители браузеров стали активно изобретать свои собственные тэги, «усовершенствуя» язык разметки гипертекста по своему усмотрению. Поскольку такие «усовершенствования» поддерживались только соответствующим «изобретателем», возникла реальная угроза развития Веба во множестве несовместимых форматов. Еще одна неприятность заключалась в том, что большинство этих нестандартных тэгов были визуально-ориентированными и предназначались не для логической разметки, а для улучшения внешнего вида документов. Все это привело к тому, что язык разметки гипертекста стал «браузерозависимым» и перестал разделять идеологию структурной разметки SGML.

В 1996 году HTML представлял из себя некое подобие каши, ингредиентами которой были старые логические конструкции и новые нестандартные тэги, которые в силу своей презентационной направленности затрудняли воспроизведение документов на различных устройствах вывода. Тем не менее, винить во всем произошедшем одних только производителей браузеров тоже нельзя. Каскадные таблицы стилей (CSS), призванные решить проблему разделения структуры и представления, не утверждались в качестве официального стандарта очень долгое время, а ждать этого события неизвестно сколько никто не хотел, да и не мог, поскольку первоочередные потребности пользователей заключались в расширении возможностей именно оформления документов. И вот именно с тех самых пор и началась та самая практика, когда правильная структурная разметка отодвигается на второй план в угоду визуальному украшению документа (более подробно эта тема раскрывается в моих предыдущих публикациях).

Когда специалисты W3C наконец-то осознали, что их незавершенный проект намного отстал от реальности, было принято решение приостановить работу над HTML 3. Возникла парадоксальная ситуация, когда не стандарт стал диктовать условия, а сам был вынужден подстраиваться под текущие версии браузеров. Результатом сложившихся обстоятельств стала наспех «слепленная» Спецификация HTML 3.2, которая была официально утверждена 14 января 1997 года и включала в себя почти все «изобретения» и «улучшения» производителей браузеров. Так или иначе, популярные в то время браузеры стали формально соответствовать требованиям стандарта. Или почти соответствовать...

Сразу после выпуска Спецификации HTML 3.2 наученный горьким опытом Консорциум не стал ждать у моря погоды и решил оперативно проделать своеобразную «работу над ошибками». Результатом такой реабилитации стал принятый в декабре 1997 стандарт HTML 4.0, который четко разделил логические и визуально-ориентированные тэги, а также официально объявил последние нерекомендуемыми к применению (deprecated). Такой подход позволил в некоторой степени восстановить соответствие языка разметки гипертекста идеологическим принципам SGML. Помимо всего прочего, Спецификация HTML 4.0 предусматривала несколько новых конструкций для поддержки многоязычных документов и обеспечения их доступности.

24 декабря 1999 года была утверждена последняя на сегодняшний день версия HTML 4.01. По сравнению с HTML 4.0 новый стандарт кардинальных нововведений не содержал, а подавляющее большинство изменений заключалось в уточнении описаний некоторых атрибутов и исправлении обнаруженных ошибок и опечаток.

Такова краткая историческая справка развития языка разметки гипертекста HTML. И вот уже 8 лет Спецификация HTML 4.01 является официальным стандартом, на основе которого создано огромное количество гипертекстовых документов.

XML

В процессе повествования о развитии HTML я упомянул тот самый злополучный 1996 год неслучайно. Глядя на то, как перерождается язык разметки гипертекста, а также в связи с возникновением некоторых других потребностей, специалисты W3C задумали создать на базе SGML совершенно новый стандарт разметки данных, который был бы не так сложен, как SGML, но и не настолько ограничен в возможностях, как HTML. И такой стандарт действительно был создан. Им стал XML – расширяемый язык разметки, являющийся компактным упрощенным подмножеством языка SGML. Черновая спецификация расширяемого языка разметки появилась в ноябре 1996 года, а официально XML 1.0 был утвержден 10 февраля 1998 года. Впоследствии стандарт неоднократно дорабатывался, и на сегодняшний день нам доступна Спецификация XML 1.0 в четвертой редакции.

Для чего это нужно

Главным и важнейшим достоинством XML является его расширяемость. В отличие от HTML-документа, в котором все допустимые логические конструкции предопределены заранее и жестко заданы в DTD, XML-документ может не иметь DTD и допускает использование любых произвольных тэгов, которые автор документа может придумать сам.

Пример XML-документа:

<?xml version="1.0" encoding="UTF-8"?>
<webstandards>
  <standard>HTML</standard>
  <standard>XML</standard>
  <standard>XHTML</standard>
</webstandards>

Как видите, каждый новый тэг в XML определяется самим фактом своего существования. Это объясняется разным статусом HTML и XML. HTML является приложением SGML, а XML – подмножеством SGML, позволяющим создавать на своей основе другие фиксированные системы разметки документов (XML-приложения).

Другим принципиальным отличием XML от HTML является полноценное разделение аспектов содержания и оформления. Расширяемый язык разметки фокусируется исключительно на логической разметке документов и хранении структурированных данных. Сам по себе XML-документ не выполняет никаких действий и не несет никакой информации о представлении, забота о котором полностью возлагается на стилевые спецификации (CSS или XSL).

Также необходимо отметить, что XML изначально задумывался как платформонезависимое, программнонезависимое и аппаратнонезависимое средство передачи информации. Благодаря этому он обеспечивает совместимость при передаче данных между различными системами. При этом нет никакой необходимости в использовании каких-либо специальных конверсионных программ.

Еще одной целью создания XML было упрощение процесса обработки документов различными программами и системами. Небезызвестно, что невалидный (содержащий синтаксические ошибки) HTML-документ будет в любом случае отображен большинством современных браузеров. Это происходит оттого, что стандарт HTML не предписывает пользовательским агентам проверять синтаксическую корректность документов. В результате браузеры стараются по возможности исправлять допущенные веб-разработчиками ошибки и отображать некорректные HTML-документы «любой ценой». В принципе, такая политика весьма оправдана. К этому вопросу мы еще вернемся чуть позже, а здесь и сейчас мне просто хотелось бы отметить, что подобный подход все-таки имеет один существенный недостаток: из-за того, что браузерам приходится учитывать и обрабатывать различные «нештатные ситуации», их разработка весьма усложняется. При этом нет никаких гарантий, что та или иная синтаксическая ошибка будет одинаково обработана разными браузерами. Как следствие, увеличивается объем программного кода пользовательских агентов, что, в свою очередь, зачастую отражается и на скорости их работы. По оценкам некоторых экспертов, около 50% программного кода браузеров ориентировано именно на обработку различных нестандартных инструкций в документах.

Для того, чтобы упростить процесс обработки документов, стандарт XML ввел понятие well-formedness, которое подразумевает строгое соответствие разметки документа синтаксическим правилам XML. Данный термин не имеет достаточно устоявшегося перевода на русский язык. Наиболее распространены следующие варианты: формальная корректность, синтаксическая корректность, правильное построение, правильное структурирование и даже корректная сформированность. Честно говоря, я сам немного затрудняюсь в выборе наиболее оптимального варианта перевода. Чтобы не возникало излишней путаницы, давайте остановимся на «формальной корректности», поскольку под «синтаксической корректностью» чаще всего понимается валидность. Так или иначе, любой XML-документ обязан быть well-formed (формально корректным).

Синтаксические ошибки в XML-документах не прощаются.
Это является фундаментальным принципом стандарта XML.

StopДругими словами, документ, не являющийся формально корректным, – это не XML-документ. При обнаружении любого несоответствия XML-парсер (синтаксический анализатор) любого пользовательского агента должен прекратить разбор документа и выдать сообщение об ошибке.

Особенности синтаксиса

Спецификация XML 1.0 представляет из себя нечто весьма занятное, способное произвести на неподготовленного читателя массу неизгладимых впечатлений. Довольно интересно читать документ, в котором правила синтаксиса называются «логическими ограничениями для логической структуры», а элементы и атрибуты – «предопределенными единицами размещения». Тем не менее, я не могу сказать, что синтаксические правила расширяемого языка разметки являются чем-то сверхъестественным. Их довольно легко запомнить и использовать в процессе разметки данных. Давайте рассмотрим основные требования, которые предъявляются к формально корректным документам.

  • Документ должен иметь только один корневой элемент.

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

    <?xml version="1.0" encoding="UTF-8"?>
    <document>
      <content>...</content>
      <note>
        <content>...</content>
      </note>
    </document>

    В принципе, Спецификация HTML 4.01 тоже предусматривает для документа единственный корневой элемент <html>…</html>, но для этого элемента, равно как и для некоторых других элементов (head, body и tbody), допускается отсутствие как открывающего, так и закрывающего тэга. Таким образом, если элемент <html>…</html> не указывается явно, границы HTML-документа устанавливаются интерпретатором автоматически. В данном контексте потенциально может возникнуть ситуация, когда совершенно корректная с точки зрения HTML разметка будет нарушать синтаксические требования XML:

    <?xml version="1.0" encoding="UTF-8"?>
    <head>...</head>
    <body>...</body>

  • Все элементы должны иметь открывающий и закрывающий тэг.

    В отличие от HTML, который допускает для некоторых элементов отсутствие закрывающего тэга (colgroup, dd, dt, li, option, p, td, tfoot, th, thead и tr), все элементы в XML-документах обязаны иметь как открывающий, так и закрывающий тэг. Исключение составляют «пустые» (не имеющие содержимого) элементы, для которых может применяться специальная сокращенная форма записи:

    <?xml version="1.0" encoding="UTF-8"?>
    <document>
      <nothing />
    </document>

  • Должна соблюдаться правильная вложенность элементов.

    Все элементы в XML-документе должны вкладываться друг в друга без пересечений. Если между открывающим и закрывающим тэгами элемента A находится открывающий тэг элемента B, то закрывающий тэг элемента B должен идти обязательно до закрывающего тэга элемента А.

    Неправильная вложенность:

    <?xml version="1.0" encoding="UTF-8"?>
    <document>
      <content><note>...</content></note>
    </document>

    Правильная вложенность:

    <?xml version="1.0" encoding="UTF-8"?>
    <document>
      <content><note>...</note></content>
    </document>

  • Имена элементов и атрибутов чувствительны к регистру.

    В отличие от HTML, в котором имена элементов и атрибутов являются регистронезависимыми, XML чувствителен к регистру символов. Это означает, что открывающий тэг <DocumentContent> не будет соответствовать закрывающему тэгу </documentcontent>. Имя элемента в закрывающем тэге должно точно соответствовать имени в открывающем тэге:

    <?xml version="1.0" encoding="UTF-8"?>
    <DocumentContent>...</DocumentContent>

    Также необходимо отметить, что имена элементов и атрибутов в XML не должны содержать пробелов и могут начинаться только с буквы или символа подчеркивания. Помимо этого, не допускаются имена, начинающиеся с комбинации символов xml в любом регистре.

  • Все атрибуты должны быть представлены в виде пар «имя/значение».

    В HTML некоторые атрибуты играют роль булевых переменных (checked, declare, defer, disabled, ismap, multiple, nohref, noresize, readonly, selected) и могут указываться без значения. Синтаксические правила XML не предусматривает подобную минимизацию атрибутов и требуют, чтобы все атрибуты имели явно указанное значение:

    <?xml version="1.0" encoding="UTF-8"?>
    <product>
      <title>Viagra</title>
      <price type="retail">20$</price>
    </product>

  • Значения атрибутов должны заключаться в кавычки.

    В некоторых случаях Спецификация HTML 4.01 позволяет устанавливать значения атрибутов без использования кавычек. В частности, HTML допускает отсутствие кавычек, если значение атрибута содержит только латинские буквы, цифры, дефисы, точки, символы подчеркивания или двоеточия. XML не предусматривает таких «вольностей» ни при каких обстоятельствах. Значения атрибутов должны в обязательном порядке обрамляться одинарными или двойными кавычками:

    <?xml version="1.0" encoding="UTF-8"?>
    <document>
      <practice type='good'>...</practice>
      <practice type="best">...</practice>
    </document>

  • Служебные символы должны экранироваться.

    В XML-документе символ амперсанда (&), левая угловая скобка (<) и правая угловая скобка (>) могут появляться в своем обычном виде только в том случае, если они используются в качестве разметки, либо находятся в пределах комментария, инструкции по обработке документа или секции CDATA. Во всех остальных случаях они должны экранироваться с помощью строковых подстановок &amp;, &lt; и &gt;.

    Кроме того, если в значение атрибута необходимо поместить символ одинарной или двойной кавычки, эти символы тоже должны экранироваться посредством мнемоник &apos; и &quot; во избежание конфликтов с ограничителями значений атрибутов.

Справедливости ради надо отметить, что некоторые из синтаксических правил XML не являются чем-то новым и доселе неведомым. В частности, требование правильной вложенности элементов и предписание экранировать служебные символы можно с таким же успехом обнаружить и в Спецификации HTML 4.01. Это объясняется тем, что предок у языков HTML и XML все-таки общий – SGML. Но здесь необходимо понимать разницу: если в HTML-документах нарушение этих требований в подавляющем большинстве случаев не приводит к каким-то серьезным последствиям, то с XML-документами дело обстоит иначе. Любое несоответствие требованиям формальной корректности должно классифицироваться как фатальная ошибка, при обнаружении которой браузеры обязаны прекратить обработку документа и вывести соответствующее сообщение.

XML-приложения

Как уже говорилось выше, XML – это язык метаразметки, обладающий чуть меньшими возможностями по сравнению с SGML, но точно так же пригодный для создания на своей основе других полноценных систем разметки данных (XML-приложений). Как правило, термин «XML-приложение» означает применение XML к определенной предметной области. На сегодняшний день существует множество различных XML-приложений, позволяющих специальным образом разметить различные математические формулы, архитектурные планы, финансовые документы, музыкальные партитуры и даже реализовать графическое представление молекул химических соединений. Стандартизация таких XML-приложений позволяет определить для них некоторый конечный набор элементов и индивидуальные синтаксические правила, которые впоследствии описываются в соответствующих DTD или XML-схемах.

В таком подходе нет ничего удивительного. Поскольку при создании XML-приложения разработчик сам определяет свои собственные элементы и атрибуты, то ему же и приходится задавать их синтаксис. Наличие DTD может потребоваться различным программам и системам, которые впоследствии будут обрабатывать соответствующий XML-документ. Кроме того, как и в случае с HTML, описанные в DTD правила синтаксиса позволяют ввести понятие валидности XML-документов.

XML-документы, имеющие DTD и соответствующие этому DTD, называют валидными.

В данном контексте необходимо понимать, что формальная корректность (well-formedness) и валидность (validity) – это не одно и то же. Формальная корректность является базовым требованием стандарта XML, а валидность означает соответствие разметки документа синтаксическим правилам, определенным в DTD конкретного XML-приложения. Другими словами, в первую очередь любой XML-документ должен быть well-formed (формально корректным), и только затем, если он имеет в своем составе DTD (или ссылку на внешнее DTD), необходимо позаботиться о его валидности.

В конце 1998 года у специалистов W3C возникла идея: а почему бы не попробовать «обэксэмэлить» HTML? И они попробовали.

XHTML

Расширяемый язык разметки гипертекста XHTML – это одно из наиболее известных XML-приложений. Первая черновая спецификация стандарта появилась в декабре 1998 года, а официально XHTML 1.0 был утвержден 26 января 2000 года. На сегодняшний день также доступна Спецификация XHTML 1.1, которая является еще более новым стандартом разметки гипертекстовых документов.

За переформулированием HTML в одно из приложений XML изначально виделись как минимум три очевидных (или не совсем очевидных) преимущества:

  1. Поскольку все приложения XML имеют общий логический базис, структурные элементы XHTML смогут использоваться в других XML-приложениях. Равно как и наоборот: любой XHTML-документ сможет включать элементы других языков разметки XML.
  2. Формальная корректность XHTML-документов позволит упростить разработку различных пользовательских агентов, что особенно актуально для мобильных устройств и других альтернативных платформ с малыми вычислительными ресурсами.
  3. Поскольку XML фокусируется исключительно на логической разметке и предусматривает весьма строгие правила формальной корректности, XHTML позволит окончательно ликвидировать визуально-ориентированные элементы HTML и призвать веб-разработчиков к созданию синтаксически корректных и эстетически привлекательных документов.
Пример документа XHTML 1.0:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru">
<head>
<title>XHTML-документ</title>
</head>
<body>
  <p>Превед ;-)</p>
</body>
</html>

Давайте рассмотрим некоторые особенности расширяемого языка разметки гипертекста XHTML 1.0.

Объявление XML

В отличие от HTML-документа, XHTML-документ может начинаться не с объявления !DOCTYPE, а с объявления XML:

<?xml version="1.0" encoding="UTF-8"?>

Объявление XML (XML Declaration) является специальной инструкцией по обработке документа (processing instruction), определяющей версию стандарта XML и кодировку символов. В принципе, стандарт XML позволяет не указывать данное объявление, поскольку для любого XML-документа кодировка UTF-8 предусматривается по умолчанию. А если к тому же учесть, что любая инструкция по обработке документа неминуемо вгоняет шестую версию некоторого браузера в quirks mode, использовать данное объявление на сегодняшний день и вовсе не рекомендуется.

Объявление DTD

XHTML 1.0, как и HTML 4.01, предусматривает три разные версии DTD (strict, transitional и frameset), в которых определяются различные наборы элементов и атрибутов. Стандарт XHTML предписывает документам в обязательном порядке содержать одно из перечисленных ниже объявлений !DOCTYPE. Кроме того, от наличия правильного объявления !DOCTYPE зависит отображение документов в браузерах (более подробно этот вопрос уже рассматривался в одной из предыдущих публикаций).

  • Объявление строгого XHTML DTD

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

    Строгое DTD включает в себя все элементы и атрибуты XHTML, за исключением нерекомендуемых и фреймовых конструкций.

  • Объявление переходного XHTML DTD

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

    Переходное DTD включает в себя все элементы и атрибуты строго DTD в совокупности с нерекомендуемыми конструкциями.

  • Объявление XHTML DTD «Набор фреймов»

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

    DTD «Набор фреймов» включает в себя все элементы и атрибуты переходного DTD в совокупности с фреймовыми конструкциями.

Обратите внимание, что во всех DTD корневой элемент документа html указывается в нижнем регистре. Это является еще одним требованием стандарта XHTML, согласно которому в именах элементов и атрибутов не допускаются заглавные буквы. Непосредственное исключение из этого правила составляет только сам элемент !DOCTYPE.

Также хотелось бы отметить, что Transitional DTD в рамках XHTML смотрится несколько парадоксально. Некоторое недоумение вызывает тот факт, что язык, изначально призванный ликвидировать визуально-ориентированные элементы и атрибуты HTML, продолжает поддерживать различные нерекомендуемые конструкции. Специалисты W3C объясняют это «нуждами переходного периода», но я, честно говоря, не совсем понимаю смысл подобной «ходьбы на месте». Правда, надо отдать должное, XHTML 1.1 уже не поддерживает нерекомендуемые конструкции и предусматривает только один тип DTD:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Пространство имен

Поскольку XHTML позволяет использовать в документе элементы других XML-приложений, необходимо как-то определять, к какому именно языку разметки относится тот или иной элемент. Для решения этой задачи был разработан специальный стандарт Namespaces in XML 1.0, позволяющий обеспечить уникальность имен элементов и атрибутов в пределах одного документа.

Именные пространства (namespaces) объявляются с помощью атрибута xmlns, значение которого должно быть ссылкой URI. Любой XHTML-документ обязан иметь единственный корневой элемент <html>…</html> с обозначением пространства имен XHTML:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru">...</html>

Таким образом, любой пользовательский агент сможет однозначно идентифицировать в документе элементы и атрибуты расширяемого языка разметки гипертекста.

Прочие радости

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

Очень важно знать и помнить, что XHTML DTD предусматривает для элементов <script>…</script> и <style>…</style> тип содержимого #PCDATA. Это означает, что внутри этих элементов служебные символы (&, < и >) будут рассматриваться XHTML-парсером как начало или конец разметки. Несложно догадаться, что присутствие этих символов внутри элементов <script>…</script> и <style>…</style> неминуемо нарушит валидность XHTML-документа (в лучшем случае) или его формальную корректность (в худшем случае). С другой стороны, если служебные символы будут проэкранированы с помощью мнемоник &amp;, &lt; и &gt;, неработоспособными окажутся скрипты, синтаксис которых не предусматривает применение таких подстановок.

Чтобы избежать всех этих неприятностей, необходимо заключать содержимое элементов <script>…</script> и <style>…</style> в секции CDATA, которые обрабатываются не как разметка, а как обычные символьные данные.

<script type="text/javascript">
//<![CDATA[
function changecolor() {
var a = document.getElementsByTagName("strong");
for (var i = 0; i < a.length; i++)
a[i].style.color = "#FF0000"; }
//]]>
</script>

<style type="text/css">
/*<![CDATA[*/
body {min-width: 1000px; margin: 0px; padding: 0px;}
body {width: expression(documentElement.clientWidth < 1000 ? "1000px" : "100%");}
/*]]>*/
</style>

Единственное, о чем еще необходимо позаботиться, – это стандартные JS-комментарии (//) и CSS-комментарии (/*…*/), поскольку XML-конструкция CDATA не имеет никакого отношения к синтаксису JavaScript или CSS.

Также необходимо отметить, что стандарт XML не позволяет динамически генерировать разметку до тех пор, пока парсер не закончит ее обработку. Это означает, что в сценариях XHTML-документа не будет работать метод document.write. Для динамического добавления и удаления элементов в XHTML-документе следует использовать только DOM-методы.

Еще одной особенностью XHTML является невозможность описать в DTD исключения для модели содержимого элементов. Другими словами, XHTML DTD не может содержать инструкцию, запрещающую определенному структурному элементу иметь в качестве содержимого какой-нибудь другой конкретный элемент. Тем не менее, Спецификация XHTML 1.0 предусматривает несколько таких правил, которые содержатся вне DTD:

  • Элемент a не должен содержать другие элементы a.
  • Элемент form не должен содержать другие элементы form.
  • Элемент label не должен содержать другие элементы label.
  • Элемент pre не должен содержать элементы big, small, img, object, sub и sup.
  • Элемент button не должен содержать элементы input, select, textarea, label, button, form, fieldset, iframe и isindex.

Ну и напоследок следует отдельно отметить, что XHTML 1.0 Strict не поддерживает атрибут name для идентификации элементов img и form, а XHTML 1.1 не предусматривает данный атрибут даже для элементов a и map. В этом нет ничего удивительного, поскольку первые рекомендации использовать вместо атрибута name атрибут id появились еще в Спецификации HTML 4.01.

Определяемся

Итак, XHTML – это вроде бы хорошо. Это более современный стандарт, расширяющий возможности HTML, упрощающий разработку браузеров и призывающий к синтаксической корректности структурной разметки. Первое преимущество определенно не вызывает никаких сомнений, но вот на втором и третьем «преимуществах» я бы хотел остановиться более подробно.

Обратная совместимость

Вам не кажется несколько странным тот факт, что несмотря на второе преимущество XHTML, разработчики браузеров совсем не спешат этим самым преимуществом воспользоваться? Ни один производитель браузеров почему-то не торопится «упростить» свой продукт. И на это есть одна очень веская причина, которая называется «Текущий контент Всемирной паутины». И пусть этот контент не лезет ни в какие рамки стандартов, но он накоплен за 14 лет и не считаться с ним нельзя.

В самом начале повествования об XML я уже отмечал, что браузеры неспроста придерживаются политики исправления ошибок в документах. Как бы ни была сложна их разработка, как бы ни увеличивался при этом объем их программного кода, первая и главная задача любого браузера – по возможности отобразить пользователю то, что он хочет увидеть.

Другими словами, браузер, который будет отображать только формально корректные XHTML-документы, никому не будет нужен, поскольку в этом случае он практически ничего не будет отображать.

Второе преимущество XHTML оказалось невостребованным.

Ни один производитель браузеров не поддержит стандарт, который не будет обеспечивать обратную совместимость. Ярким примером служит заявление одного из представителей компании Apple:

Мы отказались участвовать в разработке стандарта XHTML 2, поскольку мы не считаем этот стандарт подходящим для Всемирной паутины.

Так или иначе, несмотря ни на какие теоретические выгоды, производители браузеров не прониклись идеями XHTML. Это, в свою очередь, повлияло и на отношение веб-разработчиков к этому стандарту.

Где логика?

Как часто в процессе веб-серфинга вам приходится видеть что-нибудь подобное? Ни разу не видели? Знаете, я тоже. А все потому, что браузеры не проверяют формальную корректность XHTML-документов. Тем не менее, это совсем не означает, что они не умеют этого делать. Предложенная выше ссылка наглядно демонстрирует результат обработки некорректного XHTML-документа. Возникает вполне своевременный вопрос: почему тогда браузеры не поступают аналогичным образом с другими некорректными XHTML-документами?

Дело здесь в том, что они распознают тип документа не по объявлению !DOCTYPE, а по HTTP-заголовку Content-Type, который передается веб-сервером браузеру непосредственно до самого документа. Подобный принцип работы вполне оправдан, поскольку любой пользовательский агент должен заранее знать, какой именно тип документа ему предстоит обработать.

В то же время подавляющее большинство хостинговых компаний настраивают свои сервера таким образом, чтобы документам с расширениями .htm и .html соответствовал тип содержимого text/html:

Content-Type: text/html

Несложно догадаться, что любой файл, полученный браузером с таким HTTP-заголовком, будет обрабатываться как обычный HTML-документ, и никакая формальная корректность при этом проверяться не будет.

Для того, чтобы браузеры могли правильно интерпретировать XHTML-документы, веб-сервер должен передавать их с типом содержимого application/xhtml+xml. Данный тип MIME специально предназначен для XHTML-документов и позволяет задействовать в браузерах синтаксический анализатор XML.

Весьма распространенным заблуждением является мнение, что тип содержимого можно указать при помощи элемента meta, который располагается непосредственно в самом документе:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru">
<head>
<title>XHTML-документ</title>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset="utf-8" />
</head>
<body>...</body>
</html>

В принципе, так оно и есть, но в подавляющем большинстве случаев этот метод не работает, поскольку стандартный HTTP-заголовок веб-сервера (text/html) имеет для браузера больший приоритет.

Настроить веб-сервер надлежащим образом совсем несложно. Для этого необходимо создать в папке с XHTML-документами специальный конфигурационный файл .htaccess и поместить в него следующие инструкции:

AddType application/xhtml+xml .htm
AddType application/xhtml+xml .html

И вот только после этого мероприятия те браузеры, которые имеют встроенный XHTML-парсер, начнут проверять XHTML-документы на соответствие требованиям формальной корректности XML.

На сегодняшний день нет никаких препятствий, которые мешали бы указывать для XHTML-документов правильный тип содержимого. В любом случае браузеры, которые понимают application/xhtml+xml, будут обрабатывать XHTML-документы с использованием синтаксического анализатора XML, а другие браузеры, у которых XHTML-парсера нет, будут интерпретировать эти документы как text/html.

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

  1. Это не нужно веб-разработчикам.

    Все дело в том, что риск допустить ошибку есть всегда. Не так уж и редко обезьяны падают с деревьев, а опытные разработчики ошибаются в самом простом и примитивном. Вам никогда не доводилось случайно указать вместо закрывающего тэга еще один открывающий? ;-)

    Более того, соответствие документа правилам формальной корректности зачастую зависит не только от специалиста по верстке. Нарушить корректность XHTML-документа может программист, который просто не знает о том, что содержимое элемента <script>…</script> необходимо заключать в секции CDATA. Также далеко не все CMS на сегодняшний день умеют везде и всюду экранировать служебные символы. В данном контексте любой комментарий какого-нибудь посетителя может с легкостью приостановить работу всего ресурса. И нет ничего удивительного в том, что ни один разработчик не хочет остаться «крайним», если веб-сайт заказчика перестанет работать по независящим от него причинам.

  2. Это не нужно владельцам веб-сайтов.

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

  3. Это не нужно пользователям веб-сайтов.

    Пользователи приходят пользоваться. Им совсем неинтересно лицезреть в окне браузера сообщение «This page contains the following errors...», если разработчик забыл где-то там проэкранировать левую угловую скобку (<) или амперсанд (&).

  4. Это не работает в Internet Explorer.

    Итак, это никому не нужно. Но давайте все-таки предположим, что это нужно ВАМ. Ну, хочется вам (или уже не хочется?), как самому «правильному» веб-разработчику, передавать XHTML-документы браузеру с правильным типом содержимого application/xhtml+xml.

    • Попытка №1.

      Давайте для начала попробуем открыть в любом браузере корректный XHTML-документ, который передается веб-сервером как application/xhtml+xml. Любой современный браузер отобразит этот документ правильно, но это не означает, что Internet Explorer понимает тип содержимого application/xhtml+xml и имеет встроенный XHTML-парсер.

      В этом можно легко убедиться, если попробовать открыть с помощью Internet Explorer некорректный XHTML-документ. Этот браузер, вопреки предписаниям стандарта, отобразит этот документ как обычный text/html, в то время как другие браузеры выдадут сообщение об ошибке.

    • Попытка №2.

      Internet Explorer действительно не имеет XHTML-парсера, но это совсем не означает, что он не поддерживает общие XML-документы. В данном контексте можно попробовать «заставить» Internet Explorer проверять формальную корректность XHTML-документов, если передавать эти документы не как application/xhtml+xml, а с более общим MIME-типом application/xml.

      Давайте попробуем открыть еще один корректный XHTML-документ с помощью FireFox, Opera или Safari. Этот документ передается веб-сервером как application/xml. Данный тип MIME предназначается для любых XML-документов в принципе и не означает, что передается именно XHTML-документ. Тем не менее, любой из вышеназванных браузеров распознает в этом документе расширяемый язык разметки гипертекста XHTML и отображает этот документ соответствующим образом. Это происходит благодаря указанному в элементе html пространству имен http://www.w3.org/1999/xhtml.

      Теперь можно попробовать открыть этот же документ в Internet Explorer. Как видите, картина наблюдается несколько иная. В отличие от других браузеров, Internet Explorer не обращает на пространство имен никакого внимания и не имеет никаких сведений о семантике XHTML-элементов. Другими словами, этот браузер может проверять формальную корректность XML-документов, но не может применить к XHTML-элементам заданные по умолчанию стилевые спецификации. В результате XHTML-документ отображается в виде дерева элементов, что по вполне понятным причинам никого не устраивает.

    • Попытка №3.

      Есть еще один способ «заставить» Internet Explorer проверять формальную корректность XHTML-документов, но уже с учетом их нормального отображения. Для этого можно воспользоваться XSLT. Обсуждение XSL выходит за рамки данной статьи, поэтому я просто приведу здесь содержимое необходимого XSL-файла:

      <stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform">
      <template match="/">
        <copy-of select="."/>
      </template>
      </stylesheet>

      Данный файл можно подключить к XHTML-документу с помощью следующей инструкции:

      <?xml-stylesheet type="text/xsl" href="transform.xsl"?>

      Давайте теперь попробуем открыть в Internet Explorer XHTML-документ text-xml.html, который передается веб-сервером как text/xml и ссылается на файл transform.xsl. Результатом работы XSL-файла будет преобразование XHTML-документа в HTML-документ (text/html). Таким образом, Internet Explorer сможет сначала проверить формальную корректность XHTML-документа, а затем отобразить его как обычный HTML-документ. Другие браузеры тоже будут обрабатывать этот документ совершенно корректно благодаря указанному пространству имен XHTML.

      Вроде бы проблема решена, но не все так просто. Как уже было отмечено выше, любая инструкция по обработке XML-документа (processing instruction) неминуемо вгоняет шестую версию Internet Explorer в quirks mode. Получается, что решаем одну проблему с парсингом, но получаем при этом другую проблему с рендерингом. Само собой разумеется, что хрен редьки не слаще. Кроме того, при таком подходе могут возникать некоторые проблемы с объектной моделью документа (DOM).

    В общем, можно долго извергать страшные проклятия в адрес корпорации Microsoft, громко топать при этом ногами, но факт остается фактом: ни одна версия Internet Explorer не поддерживает тип содержимого application/xhtml+xml и не проверяет формальную корректность XHTML-документов.

Вот и получается, что подавляющее большинство размещенных в Сети XHTML-документов по своей сути таковыми не являются. В принципе, Спецификация XHTML 1.0 позволяет указывать для XHTML-документов тип содержимого text/html, и именно так все и поступают. Но в таком случае не следует утверждать, что XHTML призывает веб-разработчиков к созданию синтаксически корректных документов и возводить все это в ранг преимущества.

Нет никакого третьего преимущества.

Что касается валидности (validity) XHTML-документов, то она проверяется точно таким же образом, как и валидность HTML-документов: только «вручную» и только с помощью валидатора. Стандарт XML предписывает браузерам проверять только формальную корректность документов (well-formedness), а валидность – совсем необязательно. Как следствие, ни один браузер не проверяет XHTML-документы на соответствие описанным в DTD правилам синтаксиса. И происходит это примерно по тем же самым причинам.

СвиньяВ данном контексте можно предположить, что тот, кого волнует синтаксическая корректность HTML-документов, будет в любом случае проверять их валидатором, а тот, кому на правильность разметки попросту наплевать, не будет пользоваться валидатором даже в случае использования XHTML-синтаксиса. Все зависит от автора.

HTML или XHTML – не суть.
Все зависит от ответственности и аккуратности конкретного веб-разработчика.

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

Правильный HTML

Под «правильным» HTML следует понимать синтаксически корректную разметку с учетом следования нескольким неформальным «правилам хорошего тона».

В первую очередь, если речь идет о синтаксической корректности (валидности) документа, необходимо позаботиться о правильной вложенности структурных элементов и экранировании служебных символов. Как уже говорилось выше, данные требования не являются чем-то новым и присутствуют в Спецификации HTML 4.01. Если вы скажете, что пренебрежение рекомендацией экранировать спецсимволы в некоторых случаях не приводит к невалидности документа, сложно будет с вами не согласиться. Тем не менее, зачем испытывать судьбу? Воспользоваться в необходимых местах строковыми ссылками-мнемониками &amp;, &lt;, &gt; и &quot; совсем несложно. Только не следует забывать о том, что в отличие от XML, в HTML не определена строковая подстановка &apos;. Для экранирования символа одинарной кавычки в HTML-документах можно воспользоваться цифровой подстановкой &#39;.

Помимо собственно правил синтаксической корректности, в HTML есть несколько весьма интересных особенностей, издавна занимающих умы многих великих мыслителей. Один из таких вопросов касается опциональности закрывающих тэгов. Действительно, стандарт HTML явно и недвусмысленно позволяет не указывать их для многих структурных элементов. Тем не менее, да простят меня некоторые читатели за подобную вульгарность:

Незакрытый тэг – это как незастегнутая ширинка.
Вроде и штаны не падают, но что-то с окружающими людьми не так.

© investor

И у меня есть все основания полагать, что это относится не только к XHTML. Давайте все-таки будем указывать закрывающие тэги для всех структурных элементов HTML и назовем такой подход первым неформальным правилом хорошего тона. Само собой разумеется, это правило не должно распространяться на «пустые» структурные элементы HTML.

Другой интересной особенностью HTML является возможность устанавливать значения атрибутов без использования кавычек. Правда, далеко не везде и не всегда, но такая возможность действительно существует. Тем не менее, Спецификация HTML 4.01 содержит следующие рекомендации:

В некоторых случаях разработчики могут устанавливать значения атрибутов без использования кавычек, но мы рекомендуем использовать кавычки даже в тех случаях, когда можно обойтись и без них.

Давайте будем придерживаться этих рекомендаций и назовем это вторым неформальным правилом хорошего тона. Ну и наконец, вы когда-нибудь видели что-нибудь подобное? ▼

<dIV iD="superblock">
  <H1>Добро пожаловать!</h1>
  <P>Мы делаем качиственные сайты!!!</p>
  <aDDreSS>*.narod.ru</AddREss>
</DiV>

А что, вполне себе валидная разметка. Только воспринимать ее как-то трудновато. Давайте будем писать все имена элементов и атрибутов в нижнем регистре. Но только совсем не потому, что так требует стандарт XHTML, а всего лишь по той простой причине, что разметка в этом случае выглядит читабельнее и привлекательнее. И это третье правило хорошего тона.

Вот и получается, что XHTML отличается от правильного HTML только объявлением !DOCTYPE, обозначением пространства имен, закрытием «пустых» элементов и полной формой булевых атрибутов (полная форма последних, кстати, допускается и в HTML).

Если когда-нибудь возникнет необходимость превратить такой HTML в XHTML, это не составит никакого труда. Но что мы получим с того, если просто «тэг в тэг» переведем правильный HTML в XHTML? Да ничего. Ну не вижу я смысла использовать XHTML-синтаксис только лишь потому, что это более новый стандарт. Не стоит руководствоваться принципом «если что-то новее, значит оно лучше». Применение той или иной технологии в первую очередь должно зависеть от того, насколько эта технология оправдана для решения конкретных задач.

HTML – точно такой же официальный и действующий стандарт, как и XHTML.

Я сам являюсь идейным борцом за чистоту структурной разметки, но совершенно не вижу причин, по которым эту «борьбу» необходимо проводить именно в рамках XHTML. Тем более, что некоторое время назад W3C преподнес нам весьма интересный сюрприз.

HTML 5

А ведь сколько говорили раньше, что HTML уже выполнил возложенные на него задачи, исчерпал потенциал своего развития и пятая версия языка разметки гипертекста никогда не увидит свет. Держите.

Это случилось 7 марта 2007 года. W3C официально объявил о возобновлении разработки HTML. При этом было недвусмысленно сказано, что данное событие связано с некоторыми проблемами внедрения XHTML – слабой поддержкой этого стандарта как со стороны производителей браузеров, так и со стороны разработчиков веб-контента.

Совсем недавно появилась черновая спецификация HTML 5. Проект нового стандарта содержит много вкусностей, много разностей, но это уже тема отдельной большой публикации.

Подведем итоги

ПопИтак, если вы собираетесь использовать MathML, SVG, SMIL, RDF или какие-либо другие XML-приложения, выбор XHTML для разметки документов будет оправдан. Еще один случай, когда без XHTML вам точно не обойтись, – это внедрение в документы специального языка LitML (Liturgical Markup Language), который предназначается для разметки церковных проповедей.

Если же вы не собираетесь этого делать или вообще первый раз слышите об этих технологиях, не стоит усложнять себе жизнь без видимых на то причин. Наиболее оптимальный выбор в этом случае – правильный HTML 4.01 Strict:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Важно понять, что то, к чему нас призывают веб-стандарты, – это разделение структуры и представления, семантическая разметка и синтаксическая корректность документов. А какой при этом будет использоваться синтаксис (HTML или XHTML) – вопрос второстепенный.

Комментарии

  • Ссылка на комментарий 13.01.2008 12:20

    Zigzag

    Беларусь, Минск

    http://webdev.lovata.com

    Ты вроде бы все правильно говоришь, но мой выбор XHTML потому, что это более строгий порядок который я люблю и это более строгий самоконтроль.

  • Ссылка на комментарий 13.01.2008 16:49

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    это более строгий порядок

    Понимаешь в чем дело, получается, что весь этот твой «строгий порядок» сводится только лишь к закрытию «пустых» элементов и полной форме булевых атрибутов. Только вот непонятно, какой от этих двух мероприятий толк и почему HTML – это «менее строгий» порядок? ;-)

    это более строгий самоконтроль

    Я недвусмысленно постарался объяснить в публикации, что «строгий самоконтроль» – это когда разработчик проверяет свои документы на соответствие синтаксическим правилам заявленного стандарта (любого). Причем делать это можно только «вручную» и только с помощью валидатора. Совершенно непонятно, почему ты рассматриваешь «строгий самоконтроль» только в контексте XHTML-синтаксиса.

    я люблю

    Вот это, наверное, единственная реальная причина твоего выбора. Просто дело привычки, не более. А порядок и самоконтроль здесь ни при чем.)

  • Ссылка на комментарий 14.01.2008 21:08

    lancer

    Россия, Ставрополь

    Особенно не вникал в XML за не надобностью. Рискну предположить, что это вообще не верно.. мешать XML с HTML.

  • Ссылка на комментарий 19.01.2008 17:07

    Влад Стратулат

    Молдова, Кишинев

    http://www.vladstratulat.com/

    Достаточно запустить свинью в огород, и никакие строжайшие синтаксические правила ей уже не помешают.

    Заветное выражение! :)

    За статью спасибо в любом случае!

    Особенно не вникал в XML за не надобностью. Рискну предположить, что это вообще не верно.. мешать XML с HTML.

    Я "пишу" сайты на "XML/XSLT", и могу заявить что XML с HTML ну никак не мешается. XML даже не "форма" замены HTML.

    Однозначно рекомендую хоть немного осовить его.

  • Ссылка на комментарий 24.01.2008 18:49

    Павел Волокитин

    Россия, Серов

    Для обеспечения работы Content-Type: application/xhtml+xml; я использую следующий код php:

    header("Vary: Accept");
    if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml"))
        header("Content-Type: application/xhtml+xml; charset=utf-8");
    else
        header("Content-Type: text/html; charset=utf-8");

    Ссылка на этот метод предлагается валидатором в случае, если проверяется xhtml 1.1 документ с Content-Type: text/html;. Также там предлагаются другие методы (например, с помощью настроек апача).

    Однако сам валидатор получает страницу с text/html, но главное, что "правильные браузеры" (не мое изречение) получают application/xhtml+xml.

  • Ссылка на комментарий 19.03.2008 15:55

    lancer

    Россия

    Очень важно знать и помнить, что XHTML DTD предусматривает для элементов <script>…</script> и <style>…</style> тип содержимого #PCDATA. Это означает, что внутри этих элементов служебные символы (&, < и >) будут рассматриваться XHTML-парсером как начало или конец разметки. Несложно догадаться, что присутствие этих символов внутри элементов <script>…</script> и <style>…</style> неминуемо нарушит валидность XHTML-документа (в лучшем случае) или его формальную корректность.

    Возникает два вопроса.

    1. А зачем они там вообще нужны... символы <>?

    2. Комментарии в XHTML коде должны тоже быть с CDATA или валидными будут обыкновенные <!--Комментарии -->?

  • Ссылка на комментарий 19.03.2008 20:25

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    А зачем они там вообще нужны?

    В статье приведены два примера, наглядно показывающие зачем они там могут быть нужны. Примеры скриптовых выражений содержат символ "<", который выделен зеленым цветом.

    Комментарии в XHTML коде должны тоже быть с CDATA

    Нет, не должны. Комментарий – это разметка, которая должна интерпретироваться именно как разметка, а не как символьные данные.

  • Ссылка на комментарий 20.03.2008 13:05

    Михаил Валенцев

    Россия

    xhtml, так как работая с разными заказчиками, никогда не знаешь что потребуется им в их проектах, например, что-нибудь типа XPath.

    Вот если разработчик не может усложнить себе жизнь, то есть сверстать тот же самый макет в "xhtml strict", или не понимает что такое отделение оформление от содержания - плохой это разработчик.

    Я сюда не просто так попал - к сожалению, на вашу статью ссылаются не самые лучшие специалисты, с "посмотри он тоже в html верстает и объясняет почему" - это было оправдание верстальщика макету с html4.01 transitional и govnocode.

  • Ссылка на комментарий 20.03.2008 13:54

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    сверстать тот же самый макет в "xhtml strict", или не понимает что такое отделение оформление от содержания

    Вот это вот самое «или» – очень важный момент. При написании данной статьи я старался популярно объяснить, что отделение оформления от содержания не имеет никакого отношения к тому или иному синтаксису (HTML или XHTML). Именно поэтому какие-либо «или» здесь попросту неуместны.

    на вашу статью ссылаются

    В данном случае имеет место не совсем корректный контекст ссылки. Эта публикация не оправдывает html4.01 transitional и тем более govnocode. Как раз-таки наоборот. Она всего лишь объясняет разницу между двумя разными синтаксисами. А основная мысль заключается в том, что верстать валидно и семантически можно совершенно спокойно не только с использованием XHTML, но и в HTML 4.01 Strict. Равно как и наоборот: грязная и невалидная разметка может быть получена не только в HTML, но и с использованием расширяемого языка разметки гипертекста.

  • Ссылка на комментарий 29.12.2008 00:06

    Delaila

    Украина, Киев

    Quirks Mode (Режим обратной совместимости)

    Один из режимов рендеринга в браузерах, при котором документы интерпретируются и отображаются как несоответствующие современным стандартам. Выбор браузером режима обратной совместимости происходит в случае отсутствия в документе объявления !DOCTYPE или указания неполной версии этого объявления. [см. также: Standards Mode]

    А что такое "рендеринг в браузерах"?

  • Ссылка на комментарий 29.12.2008 00:51

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    А что такое "рендеринг в браузерах"?

    В данном конкретном случае под «рендерингом» следует понимать процесс раскладки (визуализации, прорисовки) браузером полученной на этапе парсинга древовидной структуры элементов (X)HTML-документа в соответствии с заданными (например, в CSS) параметрами визуального форматирования.

  • Ссылка на комментарий 19.02.2009 18:10

    Леонид Евстигнеев

    Россия, Санкт-Петербург

    Весьма впечатлён полнотой изложения этого вопроса. Уже читал статьи по этому поводу, но так и не понимал почему xhtml неработает(в смысле не вытесняет html). И всегда интересовал вопрос, почему же страницы объявленные как xhtml полны ошибок. А тут такие примеры и с таким текстом.

    Вобщем стало намного прозрачнее. Хотя хочется побольше строгости как при оформлении так и при рендеренге веб документов, но увы и ах.

    Вобщем большое спасибо за статью.

    Хочется узнать, что html5 нам готовит.

  • Ссылка на комментарий 02.03.2009 10:08

    Константин

    Россия, Энгельс

    http://plastium.narod.ru

    Попал я сюда не случайно. Хочу навести порядок на сайте. По вопросу ухода от HTML задумался только по одной причине - не хочется постоянно менять регистр при наборе кода.

    Но при наборе HTML-кода в нижнем регистре валидатор ругается.

    А когда задумался, то решил, что у XHTML перспективы лучше,

    а проблемы в любой системе бывают.

    Если набранные мной в XHTML-коде страницы будут нормально интерпретироваться хотя-бы IE, Opera и Lynx, то, пожалуй, перейду на него.

    Считаю, в общем, что проблема из разряда - что лучше пить:

    водку или шампанское. Кому что идет, то и наливай.

  • Ссылка на комментарий 02.03.2009 12:42

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    Но при наборе HTML-кода в нижнем регистре валидатор ругается.

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

    решил, что у XHTML перспективы лучше

    В свете заявления представителя компании Apple не могли бы Вы поподробнее изложить свою точку зрения по данному вопросу? Чем именно они лучше?

  • Ссылка на комментарий 20.03.2009 10:59

    Константин

    Россия, Энгельс

    http://plastium.narod.ru

    Ругается валидатор не на регистр. Он вообще не ругается, а вроде как спрашивает, зачем HTML набирается в нижнем регистре. Попробуйте сами отправить страничку и все поймете, у меня с переводом туго.

    Насчет перспектив я возможно погорячился - жизнь покажет.

    По ходу набора выяснил, что мой редактор тщательно проверяет код в XHTML.

    Работать стало легче, любая ошибка тут же всплывает.

    Также выяснилось, что вся присоединенная информация с сервера либо не валидна ни в каком стандарте, либо больше подходит к XHTML. Пробую с этим бороться.

  • Ссылка на комментарий 20.03.2009 11:19

    Константин

    Россия, Энгельс

    http://plastium.narod.ru

    Извините.

    Судя по тому, что на вашу он не ругается, то наверное я опять, что-то напутал.

    Попробую разобраться.

  • Ссылка на комментарий 26.03.2009 17:02

    St.Lukas

    Россия

    http://StLukas.ru

    XHTML +1... потому XSLT :)

  • Ссылка на комментарий 30.06.2009 14:57

    Toxa

    Россия, Москва

    http://toxa.ru/

    Константин, спасибо за публикацию. Доходчиво и полно рассмотрены как различные тонкости, так и смысл в целом. Статья написана грамотно, легко читается. А самое главное — в ней всё правда. Подпишусь под каждым абзацем.

  • Ссылка на комментарий 12.07.2009 13:52

    Мутант

    Россия, Саратов

    Константин

    Россия, Энгельс

    Ну и чушь вы написали, из-за вот такого вашего бреда те кто комментарии читает подумает что это так и есть на самом деле.

  • Ссылка на комментарий 23.07.2009 22:59

    Виталий

    Украина, Херсон

    Очень хорошая статья, прояснила некоторые моменты что к чему, спасибо автору.

  • Ссылка на комментарий 25.08.2009 23:16

    Антон

    Россия, Москва

    Ирония в том, что я видел больше невалидных xHTML (даже strict) доукментов, нежели HTML4 Strict.

    «Строгий порядок и аккуратность» — это миф xHTML. Никто не мешает закрывать кавычки в HTML, делать правильныу вложенность тегов, и т.д.

    В html5 можно будет писать <br> или <br/>, кому как нравится, все будут счастливы.

    Кстати, это первый блог о вебе что я вижу, который проходит валидацию (-:

    И стоит тут html4

  • Ссылка на комментарий 26.11.2009 13:09

    Александр

    Россия, Смоленск

    Действительно хорошая статья для начинающего. Получаешь общее представление о стандартах и языках. Спасибо автору.

  • Ссылка на комментарий 29.11.2009 13:50

    nikola

    Россия

    подскажите плз скрипт который направлет ie на index.html при нвозможности открыть xhtml(для вапа).заранее спс

  • Ссылка на комментарий 11.12.2009 01:23

    Антон

    Россия, Раменское

    Константин, спасибо огромнейшее за статью. В свете прочитанных до этого статей, где было галопом по свету, в этой статье очень подробный анализ, и многое стало ясно и понятно. Еще раз спасибо огромное!

    Кстати, сам верстаю год, и лишь полгода назад впервые услышал про валидность документа. Увидел около 60 ошибок, ужаснулся, начал исправлять... Так и познакомился с правилами... А до этого было - в браузерах основных схоже отображается - и ладненько...

  • Ссылка на комментарий 16.12.2009 23:09

    MVH

    Россия

    Хорошая статья, Константин.

    Только, если исходить из того, что без разницы по какому стандарту верстать (HTML или XHML), лишь бы придерживаться синтаксически верной разметки и следовать «неформальным "правилам хорошего тона"» (фактически формальным для XML), то выходит как раз, что верстать лучше сразу в XHML, т.к. в случае необходимости можно воспользоваться XSL преобразованиями и W3C валидатор будет сообщать об ошибках неформальных правил (вроде незакрытого тега и значения атрибута без кавычек), о которых он не сообщает при указании DOCTYPE HTML.

  • Ссылка на комментарий 18.12.2009 17:49

    Kvr

    Россия

    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru">...</html>

    Поясните, пожалуйста, что означает xml:lang="ru" и lang="ru" ?

    Язык чего определяется в первом и втором случае?

    Это ведь не обязательный параметры?

  • Ссылка на комментарий 18.12.2009 22:02

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    если исходить из того, что без разницы по какому стандарту верстать

    На мой взгляд, это не совсем верное суждение, из которого следовало бы куда-то там исходить. Основная мысль публикации несколько иная: средства реализации должны быть адекватны поставленной задаче.

    верстать лучше сразу в XHML, т.к. в случае необходимости можно воспользоваться XSL преобразованиями и W3C валидатор будет сообщать об ошибках неформальных правил

    Лично я сомневаюсь, что истинное предназначение технологии XSL заключается в преобразовании документов с целью их последующей проверки валидатором. Если уж на то пошло, для проверки соблюдения неформальных правил есть гораздо более простой способ, не требующий каких-либо XSL-преобразований: необходимо просто быть честным и отправлять XHTML-документы клиенту с правильным типом содержимого application/xhtml+xml. В этом случае в качестве валидатора будет выступать практически любой современный браузер.

    Тем не менее, подавляющее большинство ярых приверженцев XHTML совсем не спешат указывать для XHTML-документов правильный тип содержимого. И происходит это по вполне понятным причинам. Только вот смысл использования XHTML в данном случае остается загадкой.

    Так или иначе, идеи XML во «фронтэнде» веба не сработали, развитие XHTML зашло в тупик. Это стало очевидным еще несколько лет назад.

    Поясните, пожалуйста, что означает xml:lang="ru" и lang="ru" ?

    Эти атрибуты определяют язык документа. Первый атрибут предусматривается спецификацией XML. Второй атрибут является стандартным атрибутом HTML и в данном конкретном случае указывается для обеспечения совместимости со старыми пользовательскими агентами (на всякий случай).

    Это ведь не обязательный параметры?

    Совершенно необязательные, но весьма полезные.

  • Ссылка на комментарий 19.12.2009 12:21

    MVH

    Россия

    Лично я сомневаюсь, что истинное предназначение технологии XSL заключается в преобразовании документов с целью их последующей проверки валидатором.

    Вы меня неправильно поняли. "В случае необходимости можно воспользоваться XSL преобразованиями" и "W3C валидатор будет сообщать об ошибках неформальных правил" — это 2 разных аргумента, а не следствие второго из первого. Проверять W3C валидатором неформальные правила (вроде незакрытых тегов) можно конечно же без преобразований XSL (да и я не представляю, что за XSL преобразования могут быть для проверки XHTML документа валидатором).

    Так или иначе, идеи XML во «фронтэнде» веба не сработали, развитие XHTML зашло в тупик. Это стало очевидным еще несколько лет назад.

    Тут я с Вами согласен, т.к. считаю, что веб должен обеспечивать максимальную доступность и сайт не должны лежать из-за незакрытого тега и отдыхающего админа. Хотя и здесь, по идее, есть выход — дать возможность указывать браузеру по умолчанию для большей скорости обрабатывать XHTML как application/xhtml+xml, а в случае, если XHTML документ не well-formed, то заново обрабатывать страницу, как text/html. Это, по идее, позволит быстрее обрабатывать страницы мобильным и т.п. устройствам, в тоже время оставляя возможность просмотра сайта даже в случае XML ошибок.

  • Ссылка на комментарий 19.12.2009 12:24

    MVH

    Россия

    Основная мысль публикации несколько иная: средства реализации должны быть адекватны поставленной задаче.

    Да, но здесь же мы выбираем не между PHP и Java, а между HTML и XHTML. Поэтому, по 2м вышеизложенным причинам я и голосую за XHML (но только как text/html).

  • Ссылка на комментарий 19.12.2009 13:34

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    это 2 разных аргумента, а не следствие второго из первого

    I beg your pardon. Я действительно неверно истолковал некоторые аспекты вашей точки зрения.

    В случае необходимости можно воспользоваться XSL преобразованиями

    Бесспорно. Более того, не только XSL-преобразованиями, но также и другими возможностями (например, возможностью комбинировать различные XML-приложения, о чем я писал в самом конце статьи). Но все это только в том случае, если вероятность возникновения такой необходимости действительно существует. Именно поэтому «средства реализации должны быть адекватны поставленной задаче».

    дать возможность указывать браузеру по умолчанию для большей скорости обрабатывать XHTML как application/xhtml+xml, а в случае, если XHTML документ не well-formed, то заново обрабатывать страницу, как text/html

    Весьма интересное решение, но на практике, как мне кажется, малоприменимое по причине практически полного отсутствия в Сети well-formed-контента. Полагаю, что именно по этой причине разработчики HTML5 решили пойти по другому пути, который подразумевает создание четких правил обработки различных ошибок.

  • Ссылка на комментарий 19.12.2009 13:44

    MVH

    Россия

    Но все это только в том случае, если вероятность возникновения такой необходимости действительно существует.

    Но ведь никогда точно не знаешь, понадобится ли эта необходимость в будущем. ;)

    Весьма интересное решение, но на практике, как мне кажется, малоприменимое по причине практически полного отсутствия в Сети well-formed-контента.

    На мой взгляд это скорее может служить всего лишь некоторым бонусом для средних проектов, ориентированным на создание мобильных сайтов. Т.е. там, где нет возможности нанимать тестеров для постоянного тестирования на ошибки, но где хотят, чтобы их сайт работал как можно быстрее (хотя я не уверен, что сейчас скорость обработки HTML на мобильных настолько актуальна).

  • Ссылка на комментарий 19.12.2009 13:57

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    Но ведь никогда точно не знаешь, понадобится ли эта необходимость в будущем. ;)

    Честно говоря, этот вопрос уже поднимался в комментариях чуть выше. Тем не менее, (вы, наверное, не поверите) но лично я, например, точно знаю. Вот такой я самоуверенный. :)

    хотя я не уверен, что сейчас скорость обработки HTML на мобильных настолько актуальна

    Я бы даже сказал, совершенно неактуальна. По крайней мере по сравнению со всякими громоздкими графическими изображениями, которые мобильникам зачастую приходится загружать. Я просто поленился написать об этом в своем предыдущем комментарии...)

  • Ссылка на комментарий 06.02.2010 18:46

    Валентин

    Россия, Москва

    Отличная статья!!!!!!!

    Вы очень интересно и грамотно преподносите материал, спасибо вам огромное за вашу работу.

    Жалко только что статей на вашем ресурсе мало.

    Очень надеюсь что вы не бросите это занятие и мы увидим ваши новые публикации.

  • Ссылка на комментарий 01.03.2010 15:41

    Арсений

    Россия, Москва

    Мне очень понравилась статья, очень хорошо написана

    Есть несколько замечаний по тексту статьи, о которых не хотелось бы молчать

    #---------------

    На момент выхода статьи (12 января 2008 года, если верить этому сайту), был уже выпущен стандарт XML 1.1

    #---------------

    Стандарт XML (соответственно, XTHML) не предписывает писать пробела в пустом теге <some-xml-tag/>

    [44]       EmptyElemTag       ::=       '<' Name (S Attribute)* S? '/>'

    #---------------

    О поддержке XHTML на сегодняшний день.

    http://webstandards.org.ru/exam/xhtml/document.html сообщает об ошибке парсинга XML во всех последних браузерах Opera, FF, Chrome(webkit). IE7, кажется, виснет, о Safari можно говорить как о браузере, использующем тот же webkit.

    #---------------

    CSS, JS можно как и было лет 10 назад оформлять в комментарии, и это работает

    <script lang="text/css">
    <!--
    ...
    -->
    </script>

    #---------------

    Еще одним существенным применением XHTML являются стили для нестандартных тегов и собственно эти самые тэги: генерация части DOM-дерева без применения JS, который по-разному везде работает, а XSLT вроде как один.

  • Ссылка на комментарий 01.03.2010 20:20

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    На момент выхода статьи (12 января 2008 года, если верить этому сайту), был уже выпущен стандарт XML 1.1

    Вы совершенно правы. Я как-то упустил этот факт из виду, благодарю Вас за интересное замечание.

    Стандарт XML (соответственно, XTHML) не предписывает писать пробела в пустом теге

    http://webstandards.org.ru/exam/xhtml/document.html сообщает об ошибке парсинга XML во всех последних браузерах Opera, FF, Chrome(webkit). IE7, кажется, виснет, о Safari можно говорить как о браузере, использующем тот же webkit.

    К сожалению, при всем желании я так и не смог обнаружить в тексте статьи какие-либо суждения, несогласующиеся с представленными Вами доводами. Как следствие, позвольте поинтересоваться, в каком именно месте публикации Вам удалось найти противоречия?

    CSS, JS можно как и было лет 10 назад оформлять в комментарии, и это работает

    Боюсь, что здесь Вы совершенно точно ошибаетесь.

  • Ссылка на комментарий 28.03.2010 07:06

    DMH

    Россия

    А браузер сильно тормозит, когда ему приходит доктайп xhtml с заголовком text/html?

    По идее закрывающие слеши "/" чужды html-парсеру, браузер пытается их применить, а затем отбрасывает как мусор, тормозя тем самым отображение страницы.

    Или происходит как-то по другому?

    Если действительно тормозит, то получается от xhtml в таком режиме (без заголовка application/xhtml+xml) только вред.

  • Ссылка на комментарий 28.03.2010 21:09

    Константин Ефимов

    Россия, Тольятти

    http://webstandards.org.ru

    А браузер сильно тормозит, когда ему приходит доктайп xhtml с заголовком text/html?

    Я не думаю, что сильно.) В контексте парсинга !DOCTYPE его вообще не интересует и используется только для определения режима рендеринга.

    По идее закрывающие слеши "/" чужды html-парсеру

    Совершенно верно, он таких страстей не ведает. Пользуясь случаем хотелось бы отметить, что весьма интересный эффект можно наблюдать при попытке «скормить» некоторым браузерам какой-нибудь XHTML-документ (с заголовком text/html), в котором присутствует следующая конструкция:

    <script src="script.js" type="text/javascript" />

    А что, вполне себе корректный с точки зрения XML и валидный с точки зрения XHTML синтаксис...)

    получается от xhtml в таком режиме (без заголовка application/xhtml+xml) только вред

    Ну, не то чтобы вред, просто это «нечестно» и в этом нет никакого смысла.

  • Ссылка на комментарий 05.04.2010 09:12

    DMH

    Россия

    Интересно, остались ли ещё браузеры, поддерживающие html-синтаксис вида "<br/>" (это означает "<br>>")?

    Интересно было бы просмотреть в них псевдо xhtml-страницу.

  • Ссылка на комментарий 01.06.2010 16:15

    F^[a].t

    Россия, Киров

    прочитал с !Агромным удовольствием...

    большое спасибо за статью...

 Оставить комментарий 
 *
 *


[не публикуется]  *
 *

Последние комментарии