Библиотека Интернет Индустрии I2R.ru |
|||
|
Kонтент vs. дизайнЧасто главным преимуществом каскадных таблиц стилей называют разделение контента и дизайна. Действительно ли это так? Ответ на вопрос вы найдете в этой статье. Определения
Контент - это информационная часть документа, в которую входят текст, иллюстративные рисунки, таблицы, графики. Дизайн - это отображение информационной части документа на каком-либо устройстве. Например, на экране монитора это будет визуальное отображение, а в голосовом браузере, соответственно, речевое отображение. Давайте рассмотрим, каким образом на данный момент формируются web-документы и какие явные недостатки отсюда вытекают. Допустим, у нас есть страница, которая представляет собой каталог книг. Каждая книга имеет следующие параметры:
Примерно так представляется анонс книг на сайтах большинства электронных книжных магазинов. Типичная организация анонса выглядит так: слева располагается фотография, справа - название книги, автор, описание, а в самом низу цена. Средствами HTML это реализуется посредством таблицы с одной строкой и двумя столбцами. Допустим, согласно дизайну сайта, название нам надо написать жирным шрифтом Verdana черного цвета, автора - курсивным шрифтом Verdana черного цвета, описание - обычным шрифтом Verdana черного цвета, цену - жирным шрифтом Verdana красного цвета. Ниже следует код, который в точности соответствует такому описанию:
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=10 WIDTH=400> А вот так эта таблица будет выглядеть в браузере.
Если рассматривать код с точки зрения контента и дизайна, то сразу же становится видно, что эти категории в коде переплетаются и с первого взгляда сложно сказать, что есть информация, а что есть средство визуального представления информации. Например, фотография обложки - это файл cover.jpg, однако в теге <IMG> данная информация теряется, потому что она находится в атрибуте SRC, а кроме него тэг <IMG> содержит еще несколько атрибутов. Более того, если в коде присутствуют элементы графического оформления страницы, то отличить элемент оформления от графического элемента контента можно только по расположению элемента IMG в коде. Если обобщить эти рассуждения, то можно сделать вывод, что при такой разметке понятие контент размывается, и отсутствует четкая структурированность информации. Давайте проанализируем, к чему это ведет. Недостатки чистого HTMLСамым очевидным следствием является трудность изменения дизайна страницы. Посмотрите на код. В нем жестко задано, что фотография находится слева, а описание книги - справа. В нем жестко задана общая ширина фотографии и описания. В нем жестко заданы параметры шрифта, такие как начертание, размер и цвет. В нем жестко задано выравнивание фотографии и текста по верхнему краю. А теперь давайте оставим всю информацию прежней, но попытаемся изменить ее представление не странице. Допустим, нам понадобилось:
В этом случае нам понадобиться переписать весь код. Он станет вот таким:
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH=500 BGCOLOR=black><TR><TD> Вот так наши преобразования выглядят в браузере:
Как видите, понадобились коренные изменения в структуре кода на странице и добавление значительных фрагментов. Пришлось воспользоваться вложенными таблицами для создания рамки, потому что иначе средствами HTML такую рамку не реализовать. Причем это совершенно простой и тривиальный пример, но даже на нем ясно видно, что изменение визуального представления информации ведет к коренному изменению структуры страницы. Иными словами, при изменении дизайна изменяется и структура информации. Очевидно, что средствами HTML невозможно добиться разделения контента и дизайна. Но чем же это плохо? Чтобы ответить на этот вопрос, надо рассмотреть принципиальные подходы к созданию сайтов. Подходы к созданию сайтовВо-первых, весь сайт целиком можно сделать только на основе HTML. Плюсы:
Минусы:
Кроме того, можно сделать сайт на основе языка программирования Perl или PHP, с помощью которых можно генерировать HTML-страницы. Информация для наполнения страниц в таком случае содержится в реляционной базе данных, например, MySQL или MSSQL. Для генерации страниц достаточно нескольких шаблонов, а если сайт совсем простой, то и одного. Проблема замедления загрузки сайта решается следующим образом. Все необходимые страницы генерируются заранее, и только потом размещаются на сервере. Фактически, пользователи сразу получают HTML-страницу в ответ на запрос. Плюсы такого подхода:
Минусы:
Очевидно, что простота обновления сайта, в случае реализации его на программном движке, следует из того, что:
Итак, для легко обновляемого сайта необходимы HTML-шаблоны (зачастую с фрагментами PHP и Perl), отдельные скрипты на языках PHP или Perl и реляционная база данных. При этом программисту совершенно необходимо знать хотя бы основы HTML, а верстальщику хотя бы поверхностно ознакомиться с PHP. Но даже несмотря на это, достаточно часто возникают ситуации, когда программисту нужна помощь верстальщика, потому что он не знает некоторых нюансов кода, а верстальщику - помощь программиста, потому что правильная организация шаблонов лучше известна программисту. Вот реальное положение дел в настоящий момент. Как мы уже установили ранее, средствами HTML невозможно добиться приемлемого разделения дизайна от контента. Что же в идеале принесет это пресловутое разделение, к которому всеми силами стремятся многие разработчики стандартов консорциума W3 и простые веб-разработчики. В идеале контент должен создаваться один и только один раз. То есть мы помещаем информацию в какой-либо файл или в базу данных и при изменении дизайна сайта мы никоим образом не должны менять содержимое этого файла или базы данных. Заметьте, фактически база данных+шаблоны+скрипты и есть разделение контента от представления. Информация хранится в базе данных, она четко структурирована и остается неизменной при смене дизайна, но придется полностью переделать шаблоны и внести некоторые исправления в скрипты. Так что долгожданное и совершенно необходимое разделение контента и отображения уже реализовано, к примеру, на основе связки MySQL+PHP+HTML. Почему же на этом не остановиться? Вернемся к нашему идеалу. Кроме неприкосновенности контента нам необходима максимальная простота при изменении дизайна. Более того, нам нужна максимальная простота при внесении небольших исправлений в дизайн сайта. Очевидно, что связка MySQL+PHP+HTML нам желаемой простоты не обеспечивает. Внесение изменений - это достаточно трудоемкий процесс. Допустим, нам понадобилось все заголовки сделать не темно-красными, а черными, тогда придется искать и заменять все тэги <FONT>. В чем же причина этой сложности? Давайте разложим на составляющие нашу связку:
Вот в чем причина, во-первых, с помощью HTML во многих случаях невозможно создать хорошо структурированный документ, во-вторых, с помощью HTML невозможно добиться разделения структуры документа и визуального представления. Итак, мы значительно конкретизировали первоначальную задачу. Нам надо иметь язык разметки, который обеспечивает структурированность документа, а также разделить структуру документа от визуального представления. В конце второй главы я перечислял, в каких случаях HTML хорошо структурирует документы. Это электронные публикации, не более и не менее. Что касается электронных магазинов, он-лайн каталогов, научных баз данных, самых разнообразных реестров и списков, то их с помощью HTML хорошо структурировать совершенно невозможно. Зато это можно сделать с помощью XML. Итак, первая проблема решается следующим образом:
Что дает CSSНам осталось разделить структуру документа от визуального представления. И с недавних пор это стало возможным с помощью каскадных таблиц стилей. Очень часто в среде веб-разработчиков можно услышать мнение, что CSS обеспечивает разделение контента и дизайна. Однако, как вы уже убедились, это не совсем верно. На самом деле CSS обеспечивает всего лишь разделение структуры документа от его визуального представления, и не более того. И контент в чистом виде здесь совершенно не причем. Давайте вернемся к нашему примеру и попытаемся структурировать документ с помощью HTML, а его визуальное представление реализовать исключительно с помощью каскадных таблиц стилей. Вот HTML-код:
<DIV id="brd"> Сравните его с предыдущим и отметьте, насколько он проще воспринимается. Здесь нет нагромождения таблиц и прочих тэгов, которые отвечали за представление документа в браузере, а осталась только логическая структура. Все, что связано с визуализацией, делается с помощью CSS:
В итоге в браузере мы видим совершенно аналогичную картину. И если нам потребуется слегка изменить шрифт или цвет всех заголовков, то изменения надо будет внести в только один раз в таблице стилей для элемента H1. Если нам потребуется немного изменить расположение элементов на странице, то этого можно добиться изменением позиционирования блоков в таблице стилей. Здесь надо отметить, что ни связка HTML+CSS, ни связка XML+CSS не обеспечивают полного разделения структуры документа от визуального отображения. Если нам потребуется коренным образом изменить вид странички в браузере, то все равно придется перестраивать HTML-код, изменяя вложенность блоков, добавляя новые блоки. Но это намного легче и быстрее, чем полностью переписывать все таблицы. Возможно, полное разделение обеспечит связка XML+XSL, однако пока это вопрос остается открытым. Если же говорить о каскадных таблицах стилей, то можно сказать, что они улучшают восприятие кода и существенно облегчают внесение новых элементов дизайна; в некоторой степени обеспечивают разделение структуры документа от визуального представления, но не более того. Контент и дизайн - это не те вещи, которые можно разделить на HTML и CSS. Так что не стоит особо прислушиваться к радужным высказываниям по поводу CSS. Но не стоит и приуменьшать значение каскадных таблиц стилей, потому что их использование дает следующие преимущества:
Согласитесь, не так уж мало для того, чтобы непременно взяться за изучение еще одного языка помимо HTML. По крайней мере, для профессиональной верстки каскадные таблицы стилей совершенно необходимы. |
|
2000-2008 г. Все авторские права соблюдены. |
|