Жоня вещает..

NunDesign, неоднократно упоминая войну с дизайнерами-верстальщиками, часто поднимает проблему взаимодействия программистов и “визуализаторов”. Я хотел от себя добавить несколько рекомендаций к дизайнерам-верстальщикам, которые (рекомендации) существенно облегчат жизнь программиста. Вещи на столько элементарные, что на них, зачастую, просто тупо забивают..

1. Не мешать ID и CLASS
Иван Сагалаев в своем блоге как-то писал, что в целом разницы нет, но лучше это разделить следующим образом: ID-ы для программистов, а классы - для дизайнеров.
На примитивном уровне так оно и есть. Но корень вопроса в несколько ином месте. ID подразумевает, что элемент с этим идентификатором уникален, а класс (даже исходя из названия), что элемент относится к определенной группе элементов. То есть для некого уникального элемента страницы можно и нужно дать ID (например #mainmenu). Но для набора информационных блоков давать каждому #infoblock будет ошибкой, блок должен описываться классом. А появляется эта ошибка не явно: дизайнер нарисовал как будет выглядеть блок, верстальщик его заверстал (присвоив ID), а потом код блока многократно был вставлен на страницу.
Другой, менее явный, момент, может жить внутри этого блока. Есть прототип блока (DIV.infoblock) в котором вложен DIV#content. С точки зрения логики: внутри блока может быть только один контент. И все же это несколько противоречивое утверждение, поскольку на странице мы “лежит” несколько элементов имеющих одинаковый уникальный идентификатор.
С точки зрения программиста необходимо и достаточно, чтобы внутри элемента страницы не содержалось нескольких элементов с одинаковыми ID.

2. Придерживаться внутренних стандартов
Если на одном сайте, к примеру, пункты меню имеют классы .menuItem, то на другом тоже желательно использовать то же имя класса. Потому что реиспользовать JS-код станет гораздо проще. То же касается комплексных элементов типа шапки, копирайтов и прочего..

3. Использовать CSS по полной
Плохие примеры использования деклараций:

.menuItem {....}
.submenuItem {....}

Лучше пример:

#mainmenu .menuItem {....}
#submenu .menuItem {....}

и при этом пункты как главного, так и под-меню имеют один и тот же класс (ведь они, что одни, что другие — не больше чем пункты)

Туда же относится замена имени класса при активности элемента. Держать в голове что на что меняется просто никому не надо. Достаточно активному элементу добавить еще один класс, пусть даже с примитивным именем “active”. ИМХО разделение на .menuItem и .menuItemActive по-сути проявление лени и/или некомпетенции.

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

5. Не использовать inline-стили для элемента
Точнее их использовать можно, но минимально. Если inline устанавливается больше 1-го свойства — вынести декларацию в отдельный класс и добавить элементу стиль. Если одно свойство устанавливается на 2 и больше элементов — тоже вынести в отдельный класс. Это придаст ясности (например img class=”inlineImage right hidden” выглядит явно лучше чем img class=”inlineImage” style=”float:right; display:none;”) и даст возможность программисту: а) пользоваться инлайн-стилями монопольно; б) по имени класса получать группы элементов.

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

Запись опубликована в Среда, 19.09.2007, 10:37 и размещена в рубрике Web, Рабочее. Вы можете следить за обсуждением этой записи с помощью ленты RSS 2.0. Вы можете оставить отзыв, или обратную ссылку с вашего сайта.