Page 70 - 6108

Назви класів і id повинні за змістом відповідати застосуванню,
наприклад, header, menu, footer, news
5. Вживання Javascript
Все що можна зробити без Javascript, робити без нього. Якщо Javascript
коду багато – потрібно його виносити в окремий файл. Обробники подій теж
краще відокремити і оголошувати в окремому файлі.
Заздалегідь узгодити JavaScript-бібліотеки: PrototypeJS чи jQuery.
Якщо в макеті присутній JS, що змінює DOM – потрібно прослідкувати
його поведінку в Опері, оскільки там часто для відвідувачів надається документ
з кешу.
Якщо при натисканні на посилання відбувається обробка подій, потрібно,
щоб обробники подій повертали false, або ж використати href =
'javascript: void (0)' замість популярного href = '#', щоб
сторінка не поверталася вгору.
6. Ширина сторінки
Для еластичних макетів обов'язково повинна бути задана мінімальна і
максимальна ширина. Для фіксованих дизайнів ширина має бути 960-980
пікселів. В іншому випадку може з’явитися горизонтальний скролінг, що
свідчить про низький професійний рівень розробника.
7. Особливості відображення
Обов’язково вказувати колір фону для body, навіть якщо він білий.
Певна частка відвідувачів встановлює за замовченням фоновий колір браузера,
відмінний від білого, що призводить до відображення не в тому вигляді як

задумав дизайнер.
8. Порядок в файлах
Файлова структура повинна бути стрункою і не містити файлів, які не
використовуються в сайті (HTML-файлів, зображення, стилі, скрипти).
9. Розташування футера у нижньому боці браузера
В макетах, де висота сторінки залежить від контенту (а таких, як правило,
більшість), футер має триматися низу браузера при відсутностості або малій
кількості контенту.
10. Кодування тексту
Обумовити, в якому кодуванні (наприклад, UTF-8, windows1251) має бути
HTML-макет. CSS і JS файли повинні бути в тому ж кодуванні, що і макет,
інакше ймовірність довгого та виснажливого виправлення багів критично
зростає.
11. Використання нестандартних шрифтів
Якщо в макеті використовуються нестандартні шрифти, слід з’ясувати за
якою технологією їх буде втілено: @ font-face, Cufon, Google Font
API чи інше.
12. Використання невалідних фрагментів
Якщо макет не проходить 100%-у HTML-валідацію, варто вживати лише
виправданий невалідний код.
13. Звітність про виправлення
Якщо здача верстки проводиться більш ніж одним етапом (наприклад,
верстальник відправляє сторінки по одній, або якщо йому повертаються на