HTML или XHTML?

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

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

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

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

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

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

Или такой:

По стандарту нужно писать не <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) параметрами визуального форматирования.

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


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

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