IZONE - http://www.izcity.com/ - бесплатный софт, вэб-сервисы, ресурсы для раскрутки, свежие номера журнала "Internet Zone".

Контент vs. дизайн

FireFalcon

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

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

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

  • Название
  • Автор
  • Краткое описание
  • Фотография обложки
  • Цена

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

<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=10 WIDTH=80%> <TR VALIGN=TOP> <TD><IMG SRC="../img/cover_kirsanov.jpg" WIDTH="100" HEIGHT="132" BORDER="0" ALT=""></TD> <TD><FONT FACE="Verdana" SIZE="2"><B>Веб-дизайн</B></FONT><BR> <FONT FACE="Verdana" SIZE="1"><I>Д. Кирсанов</I><BR> Книга написана замечательно. В каждой главе видна тщательная работа с материалом и столь же тщательный подбор слов и метафор. Нигде Дмитрий не позволяет себе обойтись штампом, общими словами и описанием того, в чем сам не разобрался.<BR></FONT> <FONT FACE="Verdana" SIZE="2" COLOR=red><B>104 руб.</B></FONT> </TD> </TR> </TABLE>

А вот так эта таблица будет выглядеть в браузере.

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

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

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

  • перенести название книги, автора и цену вправо от фотографии обложки и выровнять их по правому краю;
  • описание книги выровнять не по верхнему краю, а по центру;
  • изменить весь шрифт на Arial;
  • увеличить шрифт названия книги на одну единицу;
  • увеличить общую ширину фотографии и описания с 400 до 450 пикселей.
  • сделать рамку шириной в один пиксель.

В этом случае нам понадобиться переписать весь код. Он станет вот таким:

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

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

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

Минусы:

  • сложность обновления веб-сайта;
  • сложность создания больших сайтов с числом страниц более 30-40;

Кроме того, можно сделать сайт на основе языка программирования Perl или PHP, с помощью которых можно генерировать HTML-страницы. Информация для наполнения страниц в таком случае содержится в реляционной базе данных, например, MySQL или MSSQL. Для генерации страниц достаточно нескольких шаблонов, а если сайт совсем простой, то и одного. Проблема замедления загрузки сайта решается следующим образом. Все необходимые страницы генерируются заранее, и только потом размещаются на сервере. Фактически, пользователи сразу получают HTML-страницу в ответ на запрос. Плюсы такого подхода:

  • относительная простота обновления ресурса;
  • относительная простота изготовления больших сайтов, потому что в данном случае число страниц практически не имеет значения.

Минусы:

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

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

  1. информация содержится в базе данных, поэтому она уже прилично структурирована;
  2. для полной смены дизайна необходимо переделать всего несколько шаблонов. Хотя если сайт очень большой, то число шаблонов доходит до 30, а это уже немало.

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

Вот реальное положение дел в настоящий момент. Как мы уже установили ранее, средствами HTML невозможно добиться приемлемого разделения дизайна от контента. Что же в идеале принесет это пресловутое разделение, к которому всеми силами стремятся многие разработчики стандартов консорциума W3 и простые веб-разработчики. В идеале контент должен создаваться один и только один раз. То есть мы помещаем информацию в какой-либо файл или в базу данных и при изменении дизайна сайта мы никоим образом не должны менять содержимое этого файла или базы данных. Заметьте, фактически база данных+шаблоны+скрипты и есть разделение контента от представления. Информация хранится в базе данных, она четко структурирована и остается неизменной при смене дизайна, но придется полностью переделать шаблоны и внести некоторые исправления в скрипты. Так что долгожданное и совершенно необходимое разделение контента и отображения уже реализовано, к примеру, на основе связки MySQL+PHP+HTML. Почему же на этом не остановиться?

Вернемся к нашему идеалу. Кроме неприкосновенности контента нам необходима максимальная простота при изменении дизайна. Более того, нам нужна максимальная простота при внесении небольших исправлений в дизайн сайта. Очевидно, что связка MySQL+PHP+HTML нам желаемой простоты не обеспечивает. Внесение изменений - это достаточно трудоемкий процесс. Допустим, нам понадобилось все заголовки сделать не темно-красными, а черными, тогда придется искать и заменять все тэги <FONT>. В чем же причина этой сложности? Давайте разложим на составляющие нашу связку:

  • В базе данных хранится чистая информация, которая сама по себе структурирована, но эта структура никоим образом не влияет на структуру документа.
  • Скрипты PHP обеспечивают взаимодействие информации из базы данных с HTML-шаблонами.
  • HTML-шаблоны определяют структуру документа и визуальное представление документа.

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

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

В конце второй главы я перечислял, в каких случаях HTML хорошо структурирует документы. Это электронные публикации, не более и не менее. Что касается электронных магазинов, онлайн каталогов, научных баз данных, самых разнообразных реестров и списков, то их с помощью HTML хорошо структурировать совершенно невозможно. Зато это можно сделать с помощью XML. Итак, первая проблема решается следующим образом:

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

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

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

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

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

Здесь надо отметить, что ни связка HTML+CSS, ни связка XML+CSS не обеспечивают полного разделения структуры документа от визуального отображения. Если нам потребуется коренным образом изменить вид странички в браузере, то все равно придется перестраивать HTML-код, изменяя вложенность блоков, добавляя новые блоки. Но это намного легче и быстрее, чем полностью переписывать все таблицы.

Возможно, полное разделение обеспечит связка XML+XSL, однако пока это вопрос остается открытым. Если же говорить о каскадных таблицах стилей, то можно сказать, что они улучшают восприятие кода и существенно облегчают внесение новых элементов дизайна; в некоторой степени обеспечивают разделение структуры документа от визуального представления, но не более того. Контент и дизайн - это не те вещи, которые можно разделить на HTML и CSS. Так что не стоит особо прислушиваться к радужным высказываниям по поводу CSS. Но не стоит и приуменьшать значение каскадных таблиц стилей, потому что их использование дает следующие преимущества:

  1. в большинстве случаев уменьшается объем кода;
  2. появляется возможность контролировать вывод страниц на принтер;
  3. увеличивается логичность кода;
  4. код становится более гибким, а изменять его становится проще;
  5. значительно увеличивается контроль над визуальным представлением документа.

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

Источник: http://www.web-anatomy.f2s.com/

 


Copyright © "Internet Zone", http://www.izcity.com/, info@izcity.com