Веб-стандарты: подведем итоги

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

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

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

Кандидатам философских наук посвящается...

Священные войны?

Веб-стандарты, валидность, семантическая верстка... На сегодняшний день эти термины уже знакомы даже начинающим веб-разработчикам, не говоря уже о высококвалифицированных специалистах в сфере веб-технологий. Но все-таки до сих пор с завидной постоянностью на различных конференциях Рунета возникают бурные религиозные споры «DIV vs TABLE», которые зачастую перерастают в банальный флейм, в котором уже сложно найти истину. Но истина – она все равно есть. Ее не может не быть. И, честно говоря, весьма удручает, когда какой-нибудь далеко не начинающий веб-разработчик или даже какой-нибудь «руководитель центра разработки веб-приложений» начинает вдруг со всей присущей ему серьезностью утверждать, что использование таблиц для представления нетабличных данных ни в коей мере не противоречит веб-стандартам, а все преимущества семантической верстки – это не более, чем «лже-доводы»...

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

Модное слово или объективная реальность?

Веб-стандарты – это открытые, незащищенные какими-либо патентами спецификации и рекомендации W3C. Здесь мне хочется сделать небольшое отступление, чтобы познакомить вас с двумя наиболее авторитетными организациями в области стандартизации Всемирной паутины:

W3C – Консорциум Всемирной паутины (World Wide Web Consortium) – организация, разрабатывающая и внедряющая технологические стандарты для сети Интернет. Консорциум возглавляет Тим Бернерс-Ли, изобретатель HTTP, HTML, URI и автор множества других разработок в сфере информационных технологий.

WaSP – Рабочая группа по стандартизации Web (Web Standards Project) – добровольная организация, созданная независимой группой веб-разработчиков и активно пропагандирующая современные концепции веб-технологий. Одна из главных задач WaSP – поддержка разработчиков веб-контента и программного обеспечения в контексте более полной реализации рекомендаций W3C.

Как видите, знаменитая контора «Рога и Копыта», учрежденная Остапом Бендером, имеет довольно мало общего с W3C и WaSP. Отсюда можно предположить, что доверять рекомендациям этих двух организаций, в принципе, можно.

С момента своего образования в 1994 году Консорциум Всемирной паутины проделал огромную работу, выпустив более 80 технических спецификаций и рекомендаций. В числе одобренных Консорциумом технологий – язык разметки гипертекста HTML (HyperText Markup Language), расширяемый язык разметки гипертекста XHTML (Extensible HyperText Markup Language), каскадные таблицы стилей CSS (Cascading Style Sheets), объектная модель документов DOM (Document Object Model) и многие другие, получившие общее название «веб-стандарты».

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

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

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

Спецификация включает в себя много разнообразной и полезной информации. Помимо собственно справочника, детально рассматривающего все элементы и атрибуты языка разметки гипертекста, она описывает место HTML во Всемирной паутине, рассказывает о SGML (Standard Generalized Markup Language) – стандартном общем языке разметки, предлагает нашему вниманию краткий исторический обзор развития HTML, содержит важные рекомендации и замечания по созданию HTML-документов. Но ключевыми моментами в Спецификации все же являются синтаксические правила языка разметки гипертекста и определение семантики его элементов. Вот о них-то и пойдет дальше речь.

Валидность

Правила синтаксиса

Валидность – это одно из свойств HTML-документа, подразумевающее соответствие кода синтаксическим правилам языка разметки гипертекста. В Спецификации HTML 4.01 правила синтаксиса определяются в трех различных DTD – Определениях Типа Документа (strict, transitional и frameset), которые представляют из себя внушительные по объему перечни различных конструкций SGML и отличаются друг от друга поддержкой различных элементов и атрибутов.

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

Итак, правила синтаксиса определяют:

  • какие элементы могут присутствовать в документе
  • какие элементы должны присутствовать в документе
  • обязателен ли открывающий тэг элемента
  • обязателен ли закрывающий тэг элемента
  • может ли элемент иметь содержимое
  • какое именно содержимое может иметь элемент
  • какие атрибуты может иметь элемент
  • какие атрибуты обязан иметь элемент
  • какие значения может принимать атрибут
  • допустимые строковые ссылки-мнемоники

В принципе, ничего особо сложного. На практике все это сводится к тому, что элемент <p>…</p>, например, может иметь содержимое уровня текста (непосредственно сам текст и любые инлайн-элементы), но не должен иметь содержимого уровня блока (заголовки, списки, другие параграфы и т.п.). В то же время элемент <br> не может иметь содержимого вообще (т.е. является «пустым»), а для элемента <img> в обязательном порядке должен быть указан атрибут alt. Вот такие нехитрые правила, знание которых позволяет создавать синтаксически корректные документы.

На веб-сайте W3C существует специальный инструмент – валидатор, который позволяет проверить любой документ на соответствие описанным в DTD правилам синтаксиса. Здесь важно отметить, что согласно требованиям Спецификации в самом начале любого HTML-документа должен находиться элемент !DOCTYPE, который объявляет версию HTML и DTD для данного документа. Документ, который не содержит элемента !DOCTYPE, не пройдет проверку на валидность, поскольку валидатор не будет знать, с синтаксисом какой версии HTML и каким DTD ему сверяться.

!DOCTYPE и браузеры

Немаловажен еще и тот факт, что от наличия правильного объявления !DOCTYPE зависит не только соответствие HTML-документа стандарту, но также и отображение этого документа в браузерах. Дело в том, что браузеры могут отображать документы с использованием различных режимов рендеринга. И именно от объявления !DOCTYPE зависит, будет ли документ отображен в режиме соответствия современным стандартам (standards mode) или в режиме совместимости со старыми версиями браузеров (quirks mode).

Любое из перечисленных ниже объявлений !DOCTYPE гарантированно включает браузеры в режим соответствия стандартам (standards mode):

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

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

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

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

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

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

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

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

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

В то же время отсутствие объявления !DOCTYPE или неполная его версия включают в браузерах режим обратной совместимости (quirks mode). В этом режиме браузеры намеренно отклоняются от требований современных стандартов, поскольку считают, что предлагаемый им для отображения документ тоже не соответствует стандартам и его необходимо отобразить так, как это сделали бы их предки – Internet Explorer 5, Netscape 6 и т.п. Естественно, что наиболее предпочтительным является стандартный режим рендеринга (standards mode), так как только в этом режиме браузеры надлежащим образом отображают соответствующие современным стандартам документы.

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

Преимущества и достоинства

Итак, какие же преимущества предоставляет нам валидность документа? Эти преимущества можно рассматривать как с практической, так и с эстетической стороны.

На практике валидность позволяет обрести уверенность, что созданный нами документ будет корректно обработан и отображен большинством браузеров не только нынешнего, но и будущих поколений. В данном контексте нельзя не вспомнить одного общеизвестного «деятеля», пропагандирующего ересь космического масштаба о том, что «Лучший валидатор – это браузер». Все бы хорошо, да только вот какой именно браузер? Firefox? Opera? Internet Explorer? Как насчет речевых браузеров или нестандартных устройств вывода? Завтра появятся новые Firefox, Opera, IE, Бог знает что еще, и далеко не факт, что невалидный документ отобразится в них так же, как он выглядит в браузерах, доступных нам на сегодняшний день. Не проще ли изначально при помощи известных средств свести риск потенциальной несовместимости к минимуму?

Лучший валидатор – это ВАЛИДАТОР.

Более того, особенно удручает, что благодаря стараниям того же «деятеля», в некоторых неокрепших умах поселилась навязчивая идея о том, что валидность и корректное отображение документов в Internet Explorer – это просто несовместимые вещи! Ну, бред же, в самом деле... Нельзя отрицать, что у этого браузера есть определенные проблемы с поддержкой современных стандартов, но уж что-что, а синтаксическая корректность документов ему еще никогда не мешала...

С другой стороны, валидность подразумевает понятный и удобочитаемый код, а также подчеркивает профессионализм его автора. Здесь можно провести аналогию с правилами правописания русского языка. Дело в том, что сейчас развелось множество различных форм написания – начиная от «падонкаффского» диалекта и заканчивая транслитерацией. Но согласитесь, что намного приятнее читать текст, написанный без орфографических, грамматических и синтаксических ошибок, нежели очередной опус изобретателя «новаго живаго великарускаго языка»...

Семантика

Структурная разметка

Прежде чем дать определение термину «семантика», необходимо разобраться с другим термином – «структура документа».

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

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

<h1>Заголовок</h1>
<p>Абзац текста</p>
<cite>Источник цитаты</cite>

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

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

Семантическая верстка

В отличие от правил синтаксиса, Спецификация HTML 4.01 описывает семантику элементов не замысловатыми SGML-конструкциями, а простым человеческим языком. В ней ясно и недвусмысленно сказано, что элемент <p>…</p>, например, предназначен для разметки абзацев текста, а элемент <table>…</table> – для представления табличных данных.

Но вот в чем беда: существует на свете определенная категория людей, которая этот простой человеческий язык понимает плохо. Многие ее представители прекрасно понимают C++, Delphi, PHP в конце концов, но вот с простым человеческим языком – проблема! Более того, проблема не только с языком, но и с логикой. Ведь совсем не сложно догадаться, что, если некое абстрактное «что-то» имеет какой-то смысл или какое-то определенное предназначение, логичнее всего и использовать это «что-то» именно по его прямому назначению. Никто обычно не забивает гвозди головой: для этого существует молоток.

Именно таким тернистым путем мы незаметно подошли к определению семантической разметки, или, как ее еще называют, семантической верстки:

Семантическая верстка – это грамотный выбор элементов HTML для описания структуры документа, исходя из смыслового, логического предназначения этих элементов.

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

Нельзя не заметить, что существует большое многообразие терминов, которыми в наши дни принято величать семантическую верстку. И как ее, бедную, только не называют: CSS-верстка, блочная верстка, «дивная» верстка... Быть может, именно из-за последних двух терминов и возникло одно из самых распространенных заблуждений, заключающееся в том, что суть семантической верстки – это «выкинуть из верстки таблицы и заменить их дивами». Это суждение в корне неверно. Если вам, к примеру, необходимо представить на веб-странице какой-нибудь прайс-лист в том виде, в котором он отображается в Microsoft Excel™, и вы при этом не воспользуетесь элементом <table>…</table> – это тоже будет нарушением семантики. Для представления табличных данных должна использоваться именно табличная модель – строки и столбцы.

В то же время, использование таблиц для управления визуальным расположением других элементов (табличная верстка) – это использование элемента <table>…</table> по той простой причине, что он может или должен выглядеть в браузерах определенным образом. Обратите внимание, что именно выглядеть, а не нести какой-либо смысловой нагрузки.

Разделение структуры и представления

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

Рекомендуемая Спецификацией HTML 4.01 концепция разделения структуры и представления в очередной раз призывает нас использовать язык разметки гипертекста только для описания структуры документа (содержания), а для визуального представления этой структуры (оформления) предлагается другой официально утвержденный W3C стандарт – каскадные таблицы стилей CSS (Cascading Style Sheets). Стилевые спецификации представляют из себя совершенно отдельный по отношению к структурной разметке «информационный слой» и специально предназначены для визуального форматирования структурных элементов документа.

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

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

Вывод на основании вышеизложенного можно сделать следующий: семантическая верстка – это более широкое понятие, которое подразумевает следование концепции разделения структуры и представления, но приравнивать данную концепцию к термину «семантическая верстка» нельзя. Это разные вещи.

Семантическая корректность

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

Не изобретен пока еще такой искусственный разум, который смог бы отличить таблицу с реальными и полезными данными от табличной верстки, когда в ячейках таблицы содержится различный оформительский мусор. Очевидно, что ни один валидатор не сможет вам указать на семантические ошибки, если вы, к примеру, для описания заголовка воспользуетесь элементом параграфа или будете пользоваться структурным элементом неупорядоченного списка <ul>…</ul> только лишь для задания отступов. Семантическая корректность – это такое свойство документа, которое может быть проверено только человеком – criteria that can only be checked by a human.

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

Преимущества и достоинства

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

  • Уменьшение объема кода

    Благодаря следованию концепции разделения структуры и представления наблюдается значительное сокращение объема HTML-кода. В результате мы получаем более «легкие» документы, которые передаются по сети намного быстрее, нежели обильно приправленная визуально-ориентированными элементами и атрибутами табличная модель. Кроме того, поскольку браузерам намного проще интерпретировать правильно структурированные документы – вывод таких документов на экран также происходит быстрее.

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

    Табличная верстка с визуально-ориентированными элементами и атрибутами HTML:

    <table width="100%" cellspacing="0" cellpadding="5" border="0">
      <tr>
        <th align="right">
          <a href="#"><font size="3">Активные темы</font></a>
          &middot;
          <a href="#"><font size="3">Администрация</font></a>
          &middot;
          <a href="#"><font size="3">Активные сегодня</font></a>
          &middot;
          <a href="#"><font size="3">Самые активные</font></a>
        </th>
      </tr>
    </table>

    Семантическая разметка:

    <ul>
      <li><a href="#">Активные темы</a></li>
      <li><a href="#">Администрация</a></li>
      <li><a href="#">Активные сегодня</a></li>
      <li><a href="#">Самые активные</a></li>
    </ul>

    Благодаря применению каскадных таблиц стилей, эти фрагменты кода могут выглядеть в браузерах совершенно идентично. При этом в семантическом варианте мы обходимся без таблицы с вложенными в нее элементами <tr>…</tr> и <th>…</th>, без нерекомендуемого элемента <font>…</font> и нерекомендуемого атрибута align, а также без явно присутствующих в коде разделителей &middot; между ссылками.

  • Кэширование представления

    Помимо уменьшения объема HTML-кода, существует еще одно преимущество разделения структуры и представления: вынесенные в отдельный файл стилевые спецификации всегда кэшируются браузерами. Это означает, что в отличие от табличной разметки, которую браузер загружает каждый раз для каждой конкретной веб-страницы, семантическая разметка позволяет браузеру один раз закэшировать все относящиеся к представлению стилевые инструкции и впоследствии извлекать их уже из кэша. Причем этот механизм будет работать для всех страниц веб-сайта, поскольку все документы, как правило, ссылаются на один и тот же CSS-файл.

    Также нельзя не обратить внимание на то, что, согласно концепции разделения структуры и представления, все декоративные графические изображения (не несущие какой-либо смысловой нагрузки и не имеющие никакого отношения к структуре документа) должны быть представлены не элементами <img>, а при помощи стилевых спецификаций, которые позволяют задать фоновое изображение для любого элемента HTML. Заданные в отдельном CSS-файле фоновые изображения кэшируются браузерами более активно, нежели находящаяся непосредственно в HTML-коде графика. Если в файл стилевых спецификаций не вносятся никакие изменения, браузеры, как правило, даже не обращают внимание на возможные изменения графических файлов с фоновыми изображениями. Для отображения таких изменений в большинстве случаев приходится принудительно обновить окно браузера.

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

  • Лучшая индексация поисковыми роботами

    С точки зрения разделения структуры и представления поисковому роботу предлагается чистая структурная разметка, не обогащенная различным оформительским мусором. Преимущество тут заключается в том, что роботу не приходится весь этот мусор разгребать. Очевидно, что документ, в котором нет визуально-ориентированных элементов и атрибутов, проиндексируется быстрее и эффективнее.

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

    Свое влияние на индексацию документа оказывает и грамотная структурная разметка. Нет, вопреки мнению некоторых «специалистов», поисковые роботы при индексации документов не вырезают все тэги подряд, обращая свое внимание только на контент. Они внимательно анализируют содержащиеся в документе структурные элементы и прекрасно отличают заголовок от параграфа, список от цитаты и таблицу от логического блока <div>…</div>. Более того, не просто отличают, но и делают соответствующие выводы. Так или иначе, например, любому заголовку (при условии, что он описан именно элементом заголовка) будет отдано больше предпочтения, нежели заброшенному в ячейку таблицы «безымянному» фрагменту текста.

  • Совместимость с различными устройствами

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

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

    Нельзя также забывать, что для людей с физическими недостатками существуют специальные программы для чтения с экрана, которые запросто могут быть сбиты с толку при обнаружении в документе элемента <table>…</table>, если он используется не по своему семантическому назначению. Как следствие, табличная верстка понижает доступность веб-сайтов для людей с ограниченными физическими возможностями.

    Ну и напоследок: вы еще помните те самые страшные ссылки с диким названием «Версия для печати»? Создание отдельных версий документов, предназначенных для вывода на печать, уже давно потеряло всякий смысл благодаря каскадным таблицам стилей, которые позволяют задавать отдельные стилевые правила не только для визуальных, но и для печатающих устройств. С помощью CSS можно легко скрыть ненужные при печати элементы (разнообразные меню, новостную ленту, презентационные блоки) и вывести на печать только основной контент документа.

Конформность

Вот мы и рассмотрели основные аспекты Спецификации HTML 4.01 – синтаксические правила языка разметки гипертекста и семантическое назначение его элементов. И теперь, в соответствии с названием данной статьи, мы должны подвести определенные итоги.

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

На основе всего вышеизложенного можно сделать два очень важных вывода:

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

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

К сожалению, на сегодняшний день в Сети наблюдается весьма низкий уровень следования современным стандартам. Именно это отчасти и побудило меня к написанию данной статьи. И если предложенный вашему вниманию материал заставит некоторых читателей хотя бы задуматься о необходимости следования рекомендациям W3C и WaSP – это уже хорошо. Это будет означать, что время, потраченное мной на подготовку этой статьи, было потрачено не впустую.

P.S. «Моя хата с краю – ничего не знаю...»

Однажды мне был задан вопрос: «Каким же это веб-стандартам противоречит табличная верстка?» Действительно, каким? Обратимся все к той же Спецификации HTML 4.01, которая содержит недвусмысленные рекомендации относительно использования таблиц:

11.1. Введение.

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

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

2.4. Создание документов HTML 4.

Мы рекомендуем авторам и разработчикам рассмотреть следующие общие принципы при работе с HTML 4.

2.4.1. Разделение структуры и представления.

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

По этому поводу на веб-сайте W3C есть и другие, более конкретные рекомендации:

HTML is a structural language, which means it is – or should be – used to add structure into a text through tags. The table tag should then only be used to format data into a table to relate columns with rows.

But since the apparition of tables in HTML, it has been very often used for layout purpose, usually split a web page into columns. Besides the fact that it breaks the meaning of HTML, it doesn't help either in various cases that we could summarize by the difficulty to parse or render a table in some context (disabilities, view port restrictions, ...)

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

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

Еще раз хочу обратить ваше внимание, что все вышеизложенное – это всего лишь рекомендации. Но, как мы уже знаем, веб-стандарты – это и есть рекомендации. Рекомендации самой авторитетной организации в области стандартизации Всемирной паутины. Так почему бы в таком случае этим рекомендациям не следовать?

Совсем недавно мне пришлось наблюдать, как в одной дискуссии веб-разработчиков понятие «конформности» было названо «расщеплением разума». Что поделать – всегда были, есть и будут люди, которые не принимают очевидное. Их терзают постоянные сомнения, мучают и раздирают внутренние комплексы, но в то же время они твердо считают, что просто не могут делать что-то неправильно. Подобным «специалистам» совершенно нет никакого дела до рекомендаций W3C и WaSP. И они упорно будут продолжать размещать в Сети невалидный код и верстать таблицами, руководствуясь принципом «пофик, все равно пахает». Что же, каждому – свое. Хотя, некоторые иногда еще добавляют: «и свое – не каждому...» :-)

Комментарии

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

    mike

    Россия, Великий Новгород

    Вывод на основании вышеизложенного можно сделать следующий

    Или просто выводы:

    1. Статья тяжело читаема. Из-за того, что автор хоть и говорит, что не является разработчиком W3C стандартов, но явно "пытается им быть". Говорите проще, ваша статья должна быть направлена в первую очередь на новичков, которых еще можно склонить "воевать за свой фронт".

    2. Статья общирна по объему. Это конечно хорошо, обзорные статьи тоже нужны, но тут явно напрашивается разбиение на несколько ключеввых тем, например: "Из иcтории стандартов", "Валидность и семантика", "Доктайпы", "Реалии жизни верстальшика"...

    3. После прочтения так и не почувствовал, что автор ответил себе на вопрос о причинах появления и не угосания "войн". И главная причина тому, что в статье опять-таки не сказано о "минусах и недостатках" пропагандируемой технологии.

    4. А может не стоит возводить тут проблемы, "жизнь в сети" пока тем и хороша, что развивается по законам "чистой конкуренции", зачем нам монополии, бюрократия и всевидящее око ?!

    Успехов в вашем начинании

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

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

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

    http://webstandards.org.ru

    Спасибо за отзыв и внимание к изложенному материалу.

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

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

    Статья общирна по объему.

    К сожалению, в противном случае «подвести итоги» мне бы не удалось.

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

    Странно, честно говоря...

    Основные причины перечислены довольно явно – некомпетентность и лень. И на мой взгляд именно благодаря этим двум основным причинам и возникают различные «минусы и недостатки» пропагандируемой технологии... ;-)

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

    mike

    Россия, Великий Новгород

    Очень жаль что прихождится все объяснять на пальцах, но попроую еще раз (коротко, времени излагать длиную мысль нет):

    1. неоднократное использование "воин" - это желание "поддеть" вас, за не совсем корректное использование, не надо "поддевать" меня, не я же писал статью и ввел этот термин.

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

    3. Хотел вам дать понять не говоря это прямо, что наличие двух подходов к верстке, есть вполне объективные причины. И помимо "некомпетентности и лени" есть следующие:

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

    2) технологический вакуум - стандарт это хорошо, но еще лучше стандарт который развивается с учетом требований времени. А вот здесь большая "дырка от бублика": позволю напомнить вам, что первые браузеры были текстовые, а что сейчас модно?: гламурность, юзабилити, корпоративные стили и т.д. О чем это говорит - о том что базисы на котором стоился инет и стандарты устаревают быстрее чем бы хотелось. Яркий пример появление флеша, как технологии которой пытались заткнуть вакуум (и заработать на этом за одно ... см пункт1 :)

    3) хотелось бы вспомнить появление Delphi и "войну" ее сторонников с Сишниками. Тоже в начале говорили, ну типа это не серьезно, только студентам для учебных целей пойдет. А что имеем сейчас ? страшно подумать а прошло каких-то лет 5-7. Вывод табличная верстка - это зачатки своей философии (опять таки из-за вакуума в идеологии постоения веба .. хотя нет люди там умные думали ... но немного не додумали ... вспоминаем стандарт VRML который так и не пошел в массы)

    надеюсь то что я написал наведет и на другие мысли

    PS: форма добавления коммента не юзабельна, думаю стоит над ней подумать еще

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

    garA

    Россия, Казань

    Кандидатам философских наук посвящается...

    не много ли внимания? ;)

  • Спасибо за статью. Действительно отличное описание всех нюансов. Особенно про валидность. Спасибо.

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

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

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

    http://webstandards.org.ru

    неоднократное использование "воин" - это желание "поддеть" вас

    Ну, если других способов «поддеть» меня не существует – это безусловно радует...) Но может быть гораздо логичнее все же принять очевидное, а не заниматься «поддеванием»?

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

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

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

    Как же в данном контексте можно охарактеризовать нежелание некоторых веб-разработчиков изучить блочную модель и сопутствующие ей специальные CSS-директивы? Некомпетентность и лень в чистом виде... ;-)

    деньги - сайты все-таки в более половины процентов случаев создаются для дела->бизнеса->выгоды->денег

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

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

    broker

    Украина, Бердянск

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

    ... "жизнь в сети" пока тем и хороша, что развивается по законам "чистой конкуренции", зачем нам монополии, бюрократия и всевидящее око ?!

    P.S. насчет юзабилити формы думаю предварительный просмотр сделать и сменить дизайн кнопок.

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

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

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

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

    http://webstandards.org.ru

    Спасибо за отзыв.)

    "жизнь в сети" пока тем и хороша, что развивается по законам "чистой конкуренции", зачем нам монополии, бюрократия и всевидящее око ?!

    Честно говоря, немного непонятно о каких именно монополиях и бюрократии идет речь. В процессе своего повествования я неоднократно старался подчеркнуть, что веб-стандарты – это не стандарты в традиционном понимании. Это всего лишь рекомендации. И следовать этим рекомендациям или нет – личное дело каждого.)

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

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

    broker

    Украина, Бердянск

    Честно говоря, немного непонятно о каких именно монополиях и бюрократии идет речь. В процессе своего повествования я неоднократно старался подчеркнуть, что веб-стандарты – это не стандарты в традиционном понимании. Это всего лишь рекомендации. И следовать этим рекомендациям или нет – личное дело каждого.)

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

    т.к. статья немного в философском стиле, то и комментарии пошли философские :)

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

    Lock

    Россия

    To minimize these problems, authors should use style sheets to control layout rather than tables.

    Чтобы минимизировать эти проблемы, авторы должны использовать для управления выводом CSS, а не таблицы.

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

    The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells.

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

    lancer

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

    Табличники - просто лентяи. И ненадо выгараживать свою лень.. зачатками философии.

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

    DARKMAN

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

    http://darkman.kiev.ua

    Хорошая статья. Хоть с вебом знаком давно - сделал много полезных выводов для себя. :) Жду от Вас переработанного скина для ИПБ ))

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

    Евгений Мулдашев

    Россия, Балаково

    Константин, большое Вам спасибо за материал. Он помог мне понять суть.

    К сожалению, на сегодняшний день в Сети наблюдается весьма низкий уровень следования современным стандартам. Именно это отчасти и побудило меня к написанию данной статьи. И если предложенный вашему вниманию материал заставит некоторых читателей хотя бы задуматься о необходимости следования рекомендациям W3C и WaSP – это уже хорошо. Это будет означать, что время, потраченное мной на подготовку этой статьи, было потрачено не впустую.

    Отвечаю за себя - не впустую.

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

    Удачи Вам!

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

    dvdfanat

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

    http://dvdfanat.land.ru

    Благодарю за статью.

    Давно искал нечто подобное для понимания идеологии веб-проектирования

    с уважением dvdfanat

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

    Max

    Украина

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

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

    Антон Шевчук

    Украина, Харьков

    http://anton.shevchuk.name

    Интересная статья, даешь больше...

    ...только RSS почините :(

  • Хорошая статья. Нашел поиском по слову "верстка" (не хватало информации по данной теме). Нашел здесь все что интересовало - спасибо.

    P.S: по поводу объема статьи - не много/не мало: смотря на заголовок (''Веб-стандарты: подведем итоги''), считаю написано хорошо и по сути.

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

    Argus

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

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

    Буквально вчера сам наткнулся на ТОГО нехорошего человека, который распространяет "ересь" по поводу валидатора. Был по меньшей мере взбешен (стараешься тут начинающим объяснить, насколько вадилность важна, а тот, кого слушают и почетают сотни тысяч, всё рушит из-за непонятной прихоти).

    Спасибо ещё раз. Обязательно поставлю на эту статью ссылку, когда доделаю свою подборку материалов для начинающих (и не очень) html-кодеров.

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

    Art-Analyzer

    Казахстан

    http://art-analyze.narod.ru

    Отличейшая статья. Она почти окончательно дала мне определиться как нужно верстать страницы. Конечно я все понял и до этого прочев только учебник по HTML/XHTML (благо он старается следовать стандартам Консорциума), но эта статья четко дала понимание небрежности и неаккуратности в коде. Вообще сначала делаk страницы так что можно было вешаться посмотрев на код (Frontpage жу как никак без всяких чисток :)), щас переделываю все так чтобы был более менее нормальным. Есть успехи, но надо их закрепить. Сейчас займусь чтением первоисточника а именно стандартов Консорциума.

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

    olga

    Россия

    Спасибо за статью, мне понравилось

  • Ссылка на комментарий 05.06.2009 03:36

    FAY

    Украина, Севастополь

    Низкий поклон и огромное спасибо за статью и за ваш труд.

    Прочитал на одном дыхании, очень многое для себя уяснил.

    В голове теперь четко сформированное понятие о семантической и валидной верстке:)

    Объем статьи четко в себе умещает все вопросы, нет никакой воды. Поэтому я не считаю её большой.

    (пусть ленивые так считают)

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

    В общем, пишите ещё :)

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

    nemo

    Россия

    Очень полезный сайт, спасибо автору

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

    l_sing

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

    Спасибо за статью, хорошее резюме из многих источников и ссылки!

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

    sinonim

    Россия

    http://blogka.ru

    Статья супер, так глубоко, спасибо

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

    Антон

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

    Спасибо за статью. Объем порадовал - лучше подробнее да побольше, чем отделаться словами - так не верстают. Спасибо за разъяснение слов "семантика" и "валидность".

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

    Ну что тут скажешь. Во-первых, вот это деление на - применять таблицы лишь там, где есть таблицы. За год верстки таблицами я уже всюду вижу таблицу :) В вашем примере, естественно, таблицу применять, где очевиден список - просто бред и некомпетентность. Таблицу применяют в основном для удобства верстки резинового сайта - верстальщику легко понять, что куда поедет при каком расширении. В остальных случаях применять таблицу абы куда - странно. Хоть я и верстал таблицами, но таблицы дают у меня основную структуру, внутри её ячеек частенько верстаю блоками.

    На каждый аргумент против таблиц можно дать свой ответ. Он в какой-то мере опровергает ненужность таблиц, и все опять таки сводится к тому, что W3C так делать не рекомендует. Соглашусь, там сидят очень опытные люди, инженеры, которые видят то, что я не вижу и вряд ли когда-нибудь смогу увидеть, разве что лет 10 спустя... И все же.

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

    Не буду вдаваться в подробности и философские рассуждения, в них я слаб, да и опыта мало. Предпочитаю все же конкретные вопросы. Из ответов на них можно сделать выводы.

    Вот пример. У нас есть сайт со списком новостей. Соответственно, можно этот список сверстать как таблицу - 1 столбец, множество ячеек, в каждой ячейке - новость (дата, тело, заголовок и так далее); а можно - блоками (каждый блок - заголовок, дата, тело и так далее). Является ли табличная верстка в данном случае - не семантичной?

    А если не является, и нужно верстать блоками, то почему тогда та же таблица из Excel в один столбец уже верстаться должна таблицей?

    Вот эта грань мне кажется очень не резкой...

    И вопрос немного не в тему. Всякий ли стиль нужно переносить в отдельный файл CSS?

    Словом, у нас есть заголовки, и мы делаем их так:

    <h4>Заголовок<h4>

    и в css файле пишем следующее:

    h4 {

    font-size:1.2em;

    color:blue;

    }

    далее, в сайте мы видим такую ситуацию - нужно заголовок слегка опустить.

    то есть у нас

    <h4 style="margin-top:5px">Заголовок<h4>

    Должны ли мы выносить все это в отдельный css, если такой случай встретиться у нас всего один раз на сайте?

    То есть надо ли писать

    <h4 class="otstup">Заголовок<h4>

    .otstup {

    ...

    }

    ну или

    #otstup {

    ...

    }

    Как вы считаете?

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

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

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

    http://webstandards.org.ru

    Сам всегда верстал таблицами. Теперь пытаюсь освоить блоки.

    Если Вы внимательно ознакомитесь с еще одной публикацией, Вы наверняка сможете осознать, что никакой «верстки блоками», равно как и «верстки таблицами», в природе не существует. Существует «семантическая верстка» и «неряшливое безобразие с полным отсутствием логики».

    За год верстки таблицами я уже всюду вижу таблицу

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

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

    Если надлежащим образом ознакомиться с моделью визуального форматирования CSS, понять «что куда поедет» будет так же легко, как и при использовании таблиц.

    при таблицах визуализация так же отделяется и переносится в стили

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

    Является ли табличная верстка в данном случае - не семантичной?

    Ответ на этот вопрос находится чуть выше: «табличной верстки» на самом деле попросту не существует.

    почему тогда та же таблица из Excel в один столбец уже верстаться должна таблицей

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

    Всякий ли стиль нужно переносить в отдельный файл CSS?

    Теоретически использование HTML-атрибута style, конечно же, допускается. Тем не менее, настоятельно рекомендую не злоупотреблять подобными решениями. К тому же практика показывает, что «всего один раз» имеет большие шансы превратиться со временем в «несколько раз».

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

    Антон

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

    Если Вы внимательно ознакомитесь с еще одной публикацией, Вы наверняка сможете осознать, что никакой «верстки блоками», равно как и «верстки таблицами», в природе не существует. Существует «семантическая верстка» и «неряшливое безобразие с полным отсутствием логики».

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

    Если надлежащим образом ознакомиться с моделью визуального форматирования CSS, понять «что куда поедет» будет так же легко, как и при использовании таблиц.

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

    Неоправданное использование таблиц уже само по себе является определенной визуализацией (безотносительно CSS). Т.е. в данном случае мы уже не можем полноценно отделить структуру от оформления.

    А не является ли визуализацией использование блоков? Они также имеют определенную форму, как и таблица. Если вы имеете ввиду, что таблица по умолчанию рисуется с границами... Но вы, вероятно, имеете ввиду смысл таблицы. А разве блок по смыслу не является прямоугольником?

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

    Ваша правда. Получается, таблица из одной колонки - скорее, ненумерованный список.

    Теоретически использование HTML-атрибута style, конечно же, допускается. Тем не менее, настоятельно рекомендую не злоупотреблять подобными решениями. К тому же практика показывает, что «всего один раз» имеет большие шансы превратиться со временем в «несколько раз».

    Дело все в ТЗ на сайт. Если сайт верстает дизайнер, где от странички к страничке у него меняются отступы, плавно сменяются цвета заголовков и так далее... То можно, конечно, сказать, что дизайнер плох. Но если стоит задание воплотить его мечту, с точностью до пикселя, а отступы у заголовков разнятся... То логичнее написать, к примеру,

    h1 {

    color:red;

    margin:5px 0px;

    }

    и потом в случае надобности дописывать <h1 style="margin-top:6px"> , чем создавать под такой случай класс, мучаясь, как бы назвать это извращение.

    Или другой пример. Мы создаем таблицу, у которой первая строка имеет высоту 43 пикселя, вторая 27, третья 35 и так далее. Вы предлагаете для каждого <tr> указывать его класс, или все же логичнее написать <tr style="height:43px">?

    Кстати, четвертый раз пишу вам комментарий, и "три волшебных буквы" указываю всегда верно во второй раз, первый раз не принимает. Пишу в Mozilla Firefox 3.5.5

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

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

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

    http://webstandards.org.ru

    Это означает разметку структуры документа блоками, что и соответствует смыслу блоков.

    Но не соответствует смыслу семантической корректности. Соблюдение веб-стандартов проявляется отнюдь не в блоках, а в правильной семантике структурных элементов (в частности).

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

    Без определенных знаний и умений вообще все всегда сложнее.

    А не является ли визуализацией использование блоков?

    Конечно, является. Именно поэтому необходимо верстать не блоками, а семантически.

    Вы предлагаете для каждого <tr> указывать его класс

    Да, предлагаю.

    пишу вам комментарий, и "три волшебных буквы" указываю всегда верно во второй раз

    По определенным соображениям «три волшебных цифры» имеют срок годности (с момента открытия веб-страницы), который составляет 15 минут.

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

    Антон

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

    Но не соответствует смыслу семантической корректности. Соблюдение веб-стандартов проявляется отнюдь не в блоках, а в правильной семантике структурных элементов (в частности).

    Постойте, разве не вы приводили в пример код:

    <div id="header">
      <h1>Название проекта</h1>
      <p>Краткое описание проекта</p>
    </div>

    <div id="content">
      <h2>Название публикации</h2>
      <p>Содержание публикации</p>
    </div>

    <div id="footer">
      <address>Контактная информация</address>
      <p>Информация об авторских правах</p>
    </div>

    Что это, как не разметка структуры документа блоками?

    Да и как еще документ можно разбить на три колонки, как можно добиться футера, который был бы всегда внизу, как не средствами блоков?

    А не является ли визуализацией использование блоков?

    Конечно, является. Именно поэтому необходимо верстать не блоками, а семантически.

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

    Я, возможно, неверно понимаю термин визуализация. Как недостаток верстки таблицами вы указали следующее:

    Неоправданное использование таблиц уже само по себе является определенной визуализацией (безотносительно CSS).

    А с другой стороны

    А не является ли визуализацией использование блоков?

    Конечно, является. Именно поэтому необходимо верстать не блоками, а семантически.

    То есть и то, и другое является визуализацией. А это - вроде как зло?

    Вы предлагаете для каждого <tr> указывать его класс

    Да, предлагаю.

    Но в чем смысл? Я всегда видел в переносе стилей в классы (и соответственно в отдельный файл css) следующие причины: во-первых, если данный стиль используется неоднократно, то корректировка данного стиля должна осуществляется в одном месте; во-вторых, кэширование фона, который вынесен в файл css. В данном случае высота строки в таблице вряд ли еще когда-нибудь будет равна 41px. Зачем мне делать отдельный класс, скажем,

    .height41px {

    height:41px;

    }

    ?

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

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

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

    http://webstandards.org.ru

    Что это, как не разметка структуры документа блоками?

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

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

    Антон

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

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

    Спасибо большое и за те ответы, что дали выше. Буду разбираться.

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

    Александр

    Беларусь, Брест

    Спасибо огромное за статью, Константин!! )

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