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

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

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

Разбирая дребедень

Вспомним с чего обычно начинаются проблемы с редизайном сайта? Обычно это выглядит очень безобидно: некоторые пункты списков одного типа наверстаны по принципу А, а другие по принципу Б (и хотя неправильность ситуации очевидна, это далеко не редкость при реальной групповой работе).

Примеры верстки

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

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

HTML решение

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

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

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

Семантика (от греч . semantikos — обозначающий) это фактически система обозначений и сопоставлений, которые связывают вещи и понятия между собой. Например, термин «корова», как всем известно, обозначает животное, принадлежащее к определенному типу крупнорогатого скота, определенной в системе обозначений, которые применяют люди, говорящие на русском языке, а тег

<p>

обозначает параграф с системе обозначений HTML. Это разные сущности из разных контекстов.

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

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

Например: обозначая автора как Pupkin, вы невольно заставляете быть PUPKIN — элементом строчного уровня. Хорошая новость в том, что в большинстве случаев так оно и должно быть, а если автор должен быть блоковым элементом, или элементом списка? Дополнительные вложения элементов?

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

Семантика XML

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

А что, если использовать вместо HTML более гибкий XML? XML не содержит в себе «внутренней» семантики, а потому все что Вы сделаете будет обозначать именно то что вы описали. Причем с точностью которую Вы зададите. Это идеальная верстка — которую не сможет отобразить правильно ни один браузер. Если Вы не объясните ему как это надо сделать при помощи XSLT.

Пример простой цитаты:

<автор>Пабло Пикассо
<цитата>
Когда вместе собираются критики, они говорят о Теме, Композиции и Идеи.
Когда вместе собираются художники, они говорят о том, где купить дешевый скипидар.
</цитата>
</автор>

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

«Похожим образом можно использовать и обычные реляционные БД» — скажете вы. И вы будете отчасти правы. Но создание иерархических структур в реляционных базах это работа, которая еще более утомительно чем просто переверстать все страницы. А вот хранить XML -объекты в БД — идеальное решение для больших сайтов.

Наложение систем обозначений

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

Проблемы выбора систем обозначений

Я не знаю, обратили ли Вы внимание на то, что в предыдущем примере мы молчаливо согласились с тем что «цитата принадлежит автору» — логично? Но ведь с другой стороны и «Цитата имеет автора» и с полным правом можно переписать наш пример в виде:

Пример простой цитаты 2:

<цитата>
Когда вместе собираются критики, они говорят о Теме, Композиции и Идеи.
Когда вместе собираются художники, они говорят о том, где купить дешевый скипидар.
<автор>Пабло Пикассо</автор>
</цитата>

От чего же зависит выбор того или иного варианта верстки? Как это повлияет на дальнейшую судьбу страницы? Естественно, что на выбор влияет именно предметная область. Если в веб-документе рассматривается автор, то скорее верен первый вариант, если рассматривается цитата автора — то второй. Конечно при выборе того или иного варианта следует учесть «расширяемость» Вашего внутреннего формата и совместимость его с уже созданными форматами или микроформатами. Вы не обязаны поддерживать их, но совместимость с популярными форматами семантического представления данных может дать Вам и вашему сайту определенные преимущества. Попробуйте начать с просмотра сайта microformats.org.

Пару слов про гибкость

Максимально возможную гибкость сайту можно придать заключив каждое слово в отдельный тэг. Сайт будет абсолютно гибок, но при этом и практически бесполезен — на его правку будет уходить тысячи строк css/xslt. Баланс гибкости и простоты не очевиден.Я практикую следующий элементарный метод:

Я спрашиваю себя : «Что это?» — и если на ум приходит определение семантики какого-либо тега HTML например: «Это просто параграф», «это просто список« — то надо оформить элемент по правилам HTML. Если же на ум приходит, что-то типа «это список документов связанных с текущим», то оформлять его в просто список уже не целесообразно. Безусловно со временем появляется опыт и что-то оформляется через различия html-классов, а что-то через отдельные теги XML. Эти вопросы решаются уже из внутренней структуры объекта верстки.

Подводя итоги

Создавать исходную верстку сайта в XML, а не на HTML — экономически гораздо более выгодно. Не важно используете ли вы статичные страницы или храните их в базе данных. Если само содержание будет семантично по своей природе, Вы всегда сможете изменить сайт быстро и единообразно, вне зависимости от сложности поставленной задачи.

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

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

Одно из самых больших преимуществ использования уровня структурного контроля в сочетании с CSS — это возможность избегать погрешностей отображения браузеров при помощи «хаков» и «уловок», оставляя свое содержание семантически грамотным. Мы не ждем прихода семантического Веба завтра, но когда он придет — мы просто уберем «хаки».

Рекомендую:
EurobyteContentMonsterMutagenKeysSo

Добавь к себе на стену:

Похожие записи


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

  • Комментарии: 0