Лекції з дисципліни "Веб-дизайн"

Лекція 12: Верстання сторінки (кодинг)

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

Верстання сторінок – це процес написання HTML чи XML коду сторінки, при якому сторінка набуває вигляд, подібний до дизайну макету. Безумовно, існують і інші технології розмітки тексту, які підтримуються браузерами, проте, найпоширенішим варіантом є верстання сторінок за допомогою мови HTML та стилів CSS.

До HTML верстки можна застосувати два підходи щодо розподілення елементів сегментів у різних місцях.

Таблична верстка

Таблична верстка — умовна назва методу верстання HTML-документів, при якому за  структурну основу для розташування текстових чи графічних елементів документа використовуються таблиці.

Метод широко застосовувався до появи стандартів CSS, оскільки на той момент не було іншої можливості точно розташувати елементи на сторінці. Таблиці є спроможними автоматично змінювати свої розміри відповідно до вмісту, і навпаки, тримати точні розміри певних комірок, дозволяють швидко і зручно розставити по комірках різнорідну текстову чи графічну інформацію.

Таблиці в HTML можуть бути вкладеними, що дозволяє створювати цілі ієрархії таблиць при верстанні складних сторінок, окремі елементи яких мають зберігати своє розташування і розмір на екрані незалежно від розміру вікна браузера, тоді як інші елементи, навпаки, мають змінюватися в розмірах або змінювати своє розташування щодо решти об'єктів документа.

Таблична верстка на тепер є застарілою і практично не використовується.

Блокова верстка

На відміну від табличного способу розташування даних блокова верстка не потребує чіткої прив'язки кожного логічного блоку до певної комірки. Блокова верстка базується на абсолютно інших принципах розташування і взаємодії за допомогою блокових елементів  <div> і <span>.

HTML-тег <div></div> є контейнером для тексту, зображень та інших елементів сторінки. При створенні HTML-макета теги div  розміщуються на сторінці, в них додається вміст, і вони позиціонуються в різних місцях.

На відміну від комірок таблиці, які існують лише всередині рядків і стовпців таблиці, теги div  можна помістити в будь-яке місце веб-сторінки. Теги div можна позиціонувати абсолютно (вказати координати x і y) або відносно (вказати відстань до інших елементів сторінки).

Для спрощення роботи можна скористатися генераторами структури сторінки які створюють HTML сторінку з кодом загальної структури і  CSS сторінку з загальними стилями. Як приклад таких генераторів є шаблонізатор Dreamweaver, онлайн генератори CSStemplater.com і  CSScreator.com.

Типова структура сторінки для HTML4

Типова структура сторінки для HTML5

Досвідчені верстальники пишуть код шаблонів сторінок вручну і застосовують до них стилі CSS.

Правильно зверстана сторінка:

•Легкий і зрозумілий код сторінки. Код сторінки компактній, коментований, не захаращений зайвими стилями.

•Блокова верстка дуже «дружньо» відноситься до позиціонування. Блоки можуть перекривати один одного, розробник вказує, який з блоків буде зверху.

•Блокова верстка дозволяє розмістити блок, що відображає будь-яку частину сторінки на початку html-коду. Це буде доречним при застосуванні певних технологій просування сайтів.

•Максимально ідентично відображає сторінку в різних браузерах при різних роздільних здатностях екрану.

Перевірка HTML і CSS коду

Перевіряти код сторінки сайту необхідно, коли здійснюються кардинальні зміни в структурі сайту. Акуратний верстальник прагне це робити якнайчастіше. Перевірку HTML і CSS коду краще робити з використанням програм-валідаторів чи Інтернет-сервісів, які відображають знайдені помилки відповідно до стандартів W3C.

Кращим валідатором за допомогою якого можна перевірити любу сторінку, що розташована в Інтернеті або на локальному комп'ютері є Валідатор Консорціуму W3C  http://validator.w3.org/

Сучасні браузери підтримують стандарти W3C значно краще, ніж їх попередні версії. Якщо правильний код відповідає певним формальним правилам, його легше інтерпретувати й обробляти, він швидше аналізується і відображається в браузері, з ним легше працювати пошуковим і індексуючим системам.

Піклуючись відповідність коду до стандартів W3C, не треба впадати в крайнощі і думати, що якщо сторінка успішно перевірена валідатором, то вона автоматично є якісною і ефективною. Грамотний код - це важливий, але далеко не єдиний показник якості сторінки.

1. Перевірка відстежує синтаксичні помилки.

Під час верстання розробник може здійснити дрібні помилки, наприклад, неправильно вкладені теги, пропущені дужки чи лапки, які важко відстежити в надвеликому масиві коду.  Автоматизована система швидко виявляє ці недоречності і безперечно буде корисною.

2. Перевірка сторінок сайту визначає коректність відображення в різних браузерах

Сторінка може містити HTML і CSS елементи, які не відображаються в якомусь з популярних браузерів. Тому, відвідувач з таким браузером побачить або некоректне відображення коду або отримає непрацюючий динамічний елемент, наприклад випадне меню чи слайдер.

Правильний HTML код, зазвичай, гарантує вірне функціонування сайту, втім браузери можуть мати певні особливості в дотриманні існуючих HTML і CSS стандартів.

3. Пошукова видимість

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

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

4. Професіоналізм у створенні сайту

Перевірка веб-сайту в різних браузерах свідчить про професійний підхід. Непрацюючі або некоректно відображені елементи свідчать, що веб-дизайнер не знає тонкощів своєї роботи або ставиться до неї недбало, що в підсумку відбивається на престижі сайту.

Причини, за яких нехтують перевіркою

1. Перевірка не надає гарантії, що сторінка буде відображатися коректно у всіх браузерах

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

2. Обмеження часу на виправлення сайту

Верстальник може мати в роботі значну кількість проектів і йому складно знайти час, щоб виправити всі розміщені сторінки, оскільки вони вже функціонують в Інтернеті. Такі розробники вважають, що краще витратити цей час, роблячи роботу, яка дійсно є продуктивною.

3. Відвідувач не перевіряє вихідний код

Пересічний відвідувач сайту навряд чи буде виявляти помилки HTML і CSS коду. Для нього важливо, як виглядає сторінка сайту в веб браузері.

Найпоширеніші вимоги до HTML та CSS-коду

1. Кросбраузерність

Сайт повинен нормально працювати як в останніх так і старших версіях популярних браузерів, зокрема IE7 +, FF3 +, Opera9 +, Safari4 +, Chrome.

2. Застосування коментарів

Основні HTML блоки коментарями коментуються в такий спосіб:

<! --- BEGIN FOOTER ->

<! --- END FOOTER ->

CSS блоки в такий:

/* FOOTER */

Якщо використовуються CSS хакі, також потрібні коментарі, що це і для якого браузера. Коментарі допомагають орієнтуватися в коді не лише верстальнику, але і решта учасників проекту: програмісту, контент-менеджеру, оптимізатору.

3. Впорядкування в таблиці стілів

CSS файл повинен бути розбитий за допомогою рядків з коментарями на блоки за  функціональним або структурним призначенням, наприклад:

    / * _____ 1. Скидання CSS____________ * /

    / * _____ 2. Типові елементи__________ * /

    / * _____ 2.1. Заголовки______________ * /

    / * _____ 2.2. Посилання_____________ * /

    / * _____ 2.3. Елементи форм_________ * /

    / * _____3. HEADER (Шапка сайту) ____ * /

    / * _____4. FOOTER (підвал) _________ * /

    / *_____5. SIDEBAR (Праворуч) ______ * /

4. Змістовні назви

Назви класів і 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. Звітність про виправлення

Якщо здача верстки проводиться більш ніж одним етапом (наприклад, верстальник відправляє сторінки по одній, або якщо йому повертаються на доопрацювання вже зверстані сторінки), а система контролю версій для верстки не використовується, тоді виконавець повинен в обов'язковому порядку прикріпити файл з описом змін в макеті приблизно такого змісту:

•Додано нові картинки в папку img,

•Картинки btnHome.jpg і btnFeedback.jpg вже не потрібні, можна видаляти

•Змінено html-код в секції файлу anketa.html

•Додано в кінець файлу main.css нові стилі (починаючи з. Form_row і нижче).