1. Пункт номер 0. Відповідність макету
2. №1. Кросбраузерність, кодування і DOCTYPE
3. №2 Валідність, доступність, мікроформати
4. Деякі помилки в валідації допустимі.
5. CSS
6. №3 Коректна робота при вбивання реального тексту, надійність верстки
7. №4 HTML5 форми, лінковка, валідація
8. №5 семантичного. Відсутність дурниць в html і css, однаковість, акуратність
9. №6 Правильна структура заголовків (H1, H2, ... і т.д. і TITLE)
10. №7 Сайт повинен нормально виглядати у всіх стандартних дозволах від 1024 і вище і не мати горизонтального...
11. №8 Працездатність при вимкненому JavaScript
12. №9 Працездатність при вимкненому Flash
13. №10 Доступність при вимкнених (завантажуються) картинках
14. №11 Відсутність багів при збільшеному шрифті
15. №12 Наявність Win / Mac / Linux-аналогів шрифтів
16. №13 Оптимізація швидкості завантаження
17. Для проектів, де це обумовлено, перевіряється:
18. №15 Важливі дрібниці:

Ви PM. Як дізнатися - чи готова верстка до реального використання?
Ви замовник. Як переконатися, що робота виконана якісно?

Коли я став тим-лідом, а пізніше PM, переді мною постало завдання перевіряти верстку наших проектів. Потрібно було виробити формальні, легкопроверяемие критерії, відповідність коду якою мав би було давати якусь гарантію, що не факапов і ні клієнт, ні програмісти НЕ сказажут потім "WTF?".

Клієнту неважливо наскільки красивий ваш код, але йому важливий результат. Якісний код потрібен фірмі, тому що він надійніше і в майбутньому його буде легше підтримувати.

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

На Хабре була стаття про « Вимоги до html-верстки ». Але це ТЗ для виконавця / угоду про кодування / поради хорошого тону, але не перевірки список: готова-робота і можна-ли її приймати. Він хороший, але на жаль, його дотримання не гарантує що проблем не буде.

0. Відповідність макету

1. Кросбраузерність, кодування і DOCTYPE
2. Валідність, доступність, мікроформати
3. Коректна робота при вбивання реального тексту, надійність верстки
4. HTML5 форми, лінковка, валідація
5. Семантичного. Відсутність дурниць в html і css, однаковість, акуратність
6. Правильна структура заголовків (H1, H2, ... і т.д. і TITLE)
7. Сайт повинен нормально виглядати у всіх стандартних дозволах від 1024 і вище і не мати горизонтального скролла
8. Працездатність при вимкненому JavaScript
9. Працездатність при вимкненому Flash
10. Доступність при вимкнених (завантажуються) картинках
11. Відсутність багів при збільшеному шрифті
12. Наявність Win / Mac / Linux-аналогів шрифтів
13. Оптимізація швидкості завантаження
14. І останній пункт - дрібні перевірки (нижче детальніше)

Пункт номер 0. Відповідність макету

Розташування блоків має бути 1: 1 в порівнянні з макетом. Допускається розбіжність до 5px для тексту. Дозволені і навіть вітаються правки розмірів і розташування криво намальованих блоків (різниця розмірах в 1-2px на різних сторінках).

Ясна річ що при змінах контенту, розміри блоків можуть змінюватися (по висоті наприклад), це нормально. Ми використовуємо Pixel Perfect не для попиксельного Задротство (адекватний ПМ не повинен затягувати здачу проекту, витрачаючи час, а значить і гроші фірми, на вилизування кожного пікселя), а для перевірки що всі базові блоки знаходяться там де треба, їх розміри, відступи - відповідають макету.

Перевіряється в Firefox через плагін Pixel Perfect . Для перевірки в інших браузерах використовуйте ModularGrid .

№1. Кросбраузерність, кодування і DOCTYPE

1. Кодування: UTF-8
   Навіщо потрібно: UTF-8 це універсальність і сумісність. Це сучасний стандарт, за ним майбутнє.
   Як перевіряється: в FF Інструменти → Інформація про сторінку, у вікні повинно бути написано «Кодування: UTF8». Це кодування повинна використовуватися для всіх файлів: html, css, js ...
2. DOCTYPE: HTML5
   Навіщо потрібно: наявність коректного doctype необхідно щоб сторінки відображалися у відповідності зі стандартами. Новий doctype дозволяє нам сміливо використовувати сучасні теги (canvas, header, article, ...) і старі перевірені рішення, які раніше були в опалі (наприклад embed). HTML5 - це сучасний стандарт, XHTML - теж добре, але HTML5 - актуальніше, та й в кінці-кінців це модний тренд зараз. Аргументація для тих, хто сумнівається .
   Перевірка: відкриваємо вихідний код сторінки, перший рядок повинні бути.
3. кросбраузерність:
   • Firefox (останній)
   • Chrome (останній)
   • Safari (останній) і якщо у вас немає Mac щоб перевірити «розмиті Mac'овскіе» шрифти (вони трохи більшого розміру, через це буває вилазять баги) то встановіть в Preferences → Appearance, «Font Smoothing» в Medium (по дефолту там «Windows Standart»).
   • Opera (остання)
   • IE7 + (для IE6 виводиться повідомлення про непідтримку і пропозиції завантажити інший браузер, але з можливістю все-таки переглянути сайт)
   • Opera Mini (перевіряється в Opera Developer Tools → Opera Mini Simulator , Потрібно встановити Java плагін до браузера, або в крайньому випадку: Opera 9.64 → Вид-Маленький екран, але в 9.64 JS буде працювати повноцінно на відміну від справжньої Opera Mini, це потрібно враховувати)
   • iPhone (дивимося в landscape і portrait режимах, тобто вертикально і горизонтально) + Android.

   Перевіряється переглядом сайту в перерахованих вище браузерах.

   • Перевірка в IE7 робиться перемиканням IE8 в режим IE7 (F12 → Режим оглядача → Internet Explorer 7).
   • В IE6 можна подивитися на ipinfo.info/netrenderer/ або на віртуальній машині (зручно використовувати Windows XP Mode в Win7).

№2 Валідність, доступність, мікроформати

1. Не повинно бути js-помилок!
2. Титулки повинна бути правильна в будь-якому випадку. Помилки на внутряк можна вибачити в наступних випадках:
   • Упоротая секретарка копіпаст тексти з Word'а в Візігу;
   • Програмісту ну дуже потрібні якісь кастомниє атрибути (хоча для цього в HTML5 ввели спеціальні атрибути «data- *»).
3. CSS валідіруется за версією 3.0, його валідність не потрібно (та й валідатор ще кривуватий), а ось синтаксичні помилки (типу margin: 10xp) виправляти треба.
4. Мікроформати повинні бути. Як мінімум - hCard. Бажано також hCalendar, XFN, hAtom.

Помилки js перевіряються переглядом сайту в IE - в лівому нижньому кутку не повинно бути значка «є js-помилки».

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

© rossomachin

HTML5 допомагає нам в разі потреби своїх, кастомних, невалидность атрибутів для елементів. Просто вказуємо атрибут «data-чтоугодно» - і можемо використовувати! Це валідність!

Мікроформати не тільки корисні для SEO, але і здорово впорядковують код. Не потрібно півгодини думати як назвати новий блок. Вибирай з існуючих стандартних імен! Бери entry-content, що не помилишся 🙂

Валідність перевіряється онлайн-валідаторами:

В ідеалі верстка повинна відповідати стандарту доступності: WCAG.
Він має три рівні складності, якщо проходить хоча б WCAG1 A (Priority 1) - вже добре. Ідеальний варіант - WCAG2 Priority 3 (AAA). Самий просто спосіб перевірити що скоріше за все WCAG1 Priority A дотриманий - www.cynthiasays.com/ (або Web Developer → Інструменти → Перевірити WAI). Чому «скоріше за все»? Деякі вимоги WCAG неможливо перевірити автоматично. Ось ще кілька скриптів помічників:

І власне сам чекліст WCAG2:

Деякі помилки в валідації допустимі.

• HTML

  1. Стандарт HTML5 знаходиться в активній розробці: вносяться зміни, щось додається, щось виключається. Валідатор HTML5 змінює правила перевірки відповідно до цього.
     Те що було дійсним вчора, сьогодні може видавати помилку, наприклад така ситуація зараз з apple-touch-icon і XFN .
  2. На відміну від HTML4 і XHTML, офіційної кнопки «Valid HTML 5» не існує , Тому валідатор не видасть вам код для її вставки, навіть якщо він вважає документ дійсним.
  3. Люди самі малюють свої варіанти кнопочок , Ви можете використовувати будь-які, але рекомендованим варіантом на сьогоднішній день є додавання на сайт офіційного HTML5 badge зі стрічкою використовуваних технологій , Наприклад так:
     

  4. CSS

     1. За замовчуванням валідатор CSS перевіряє код згідно стандарту 2.1, а не 3.
        Тому допустимі помилки такого роду: Property box-shadow does not exist in CSS level 2.1 Property border-radius does not exist in CSS level 2.1 Property background-size does not exist in CSS level 2.1 Value Error: background Too many values ​​or values ​​are not recognized: linear-gradient (top, # 7baee7, # b5dbff 22%) linear-gradient (top, # 7baee7, # b5dbff 22%) і т.п.
     2. Валідатор вважає помилкою вказівку Вендорний префіксів
        Тому допустимі помилки такого роду: Property -moz-box-shadow does not exist Property -webkit-background-clip does not exist Property -o-border-image does not exist Property -khtml-background-size does not exist Property -ms-filter does not exist Property -pie-background does not exist Unknown pseudo-element or pseudo-class: -moz-any-link Value Error: display -moz-inline-box is not a display value і т .п.
     3. Раніше пропріентарние властивості IE було рекомендовано виносити в окремий CSS. Зараз варто використовувати HTML5 Boilerplate і фільтрувати в style.css за допомогою html.oldie, html.ie7 і т.д.
        Тоді допустимі помилки такого роду: Property behavior does not exist Property progid does not exist Property _display does not exist і т.п.

№3 Коректна робота при вбивання реального тексту, надійність верстки

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

з візіга і т.п.

1. Помилки під час введення і видалення даних.
   Перевіряється: на сторінці з контентом, пробуємо додавати і видаляти вміст - «що буде коли тексту багато?», «А коли мало?».
2. Перевірка коректності роботи стилів.
   Перевіряється: на сторінки з контентом вбиваємо текст з абзацами і без абзаців (важливо! Буває горе-верстальники прописують стилі тільки для абзаців), зі списками і картинками, таблицями і заголовками різних рівнів.

Це потрібно щоб на живому сайті потім не полізли проблеми при заповненні реальними даними.
Правки вмісту сторінки робляться в FF через плагін Firebug : HTML → Edit - міняємо / додаємо / видаляємо текст. Хороший приклад перевірочного тексту знаходиться в m5cssframework в index.html між і.

Добре використовувати html5-теги для розмітки: header, footer, aside, nav, section, article і т.д. Крім того що це семантично, також підвищується надійність, «пуленепробіваемость» верстки. Зайвий відкритий або закритий div легко може поламати верстку. Але коли каркас сайту - атомарні і рідко повторюються html5-теги, то «поломка» локалізується в межах html5-тега.

№4 HTML5 форми, лінковка, валідація

1. Label і input / select повинні бути слінковани.
   Це потрібно для зручності користувачів. Також це дуже полегшує життя користувачам з обмеженими фізичними можливостями.
   Перевіряється кліком по label - потрібно активувати відповідний йому елемент введення.
2. HTML5 валідація заповнення форми.
   Практична цінність поки-що невелика, адже серверна помилки під час введення даних теж може бути реалізована без перезавантаження сторінки (через ajax), але це говорить про проф. рівні виконавця - у рідкісного числа користувачів сучасних браузерів з відключеним javascript, помилки під час введення даних відбудеться засобами браузера, а не сервера.
   Перевіряється в Opera: вимикаємо javascript, що не заповнюємо форму, тиснемо Submit - повинні з'явиться повідомлення про необхідність заповнити поля.
3. JS-валідація форми.
   Це очікуване поведінка. Користувачі звикли що якщо вони неправильно заповнять форму, їм не дадуть її відправити, а вкажуть на помилки.
   Перевіряється в Opera / Safari / Chrome: включаємо javascript, що не заповнюємо форму, тиснемо Submit - повинні з'явиться повідомлення про необхідність заповнити поля.
4. Якщо перевіряємо frontend в цілому - повинна бути серверна валідація форми.
   Перевіряється в Firefox 3.6: вимикаємо javascript, що не заповнюємо форму, тиснемо Submit - повинні з'явиться повідомлення про необхідність заповнити поля.
5. Правильні input type = "email / url / tel".
   Поки-що практична цінність для користувача лише в тому, що на iPhone буде показуватися клавіатура відповідна формату поля введення.
   Перевіряється на iPhone - в залежності від типу поля введення він повинен показувати різну клавіатуру: стандартну / цифрову / для набору web / email-адрес.

Повідомлення про помилки повинні бути не js-alert'ом, а текстом в дизайні сайту!
Все оформлення в формах повинно бути повішено на класи, id - тільки для лінковки з label (a то потім програмісти прикручують, пишуть свої id і ламається зовнішній вигляд).

№5 семантичного. Відсутність дурниць в html і css, однаковість, акуратність

Мабуть єдиний пункт, де можна дати чітких критеріїв. Про те, що таке погано можна почитати в моїй статті « шкідлива верстка ».
Як орієнтир - найбільш часті помилки:

• Найстрашніше, на щастя вже рідкісне - float: left для всіх блоків. Божевільний верстальник емулює звичні осередки таблиць, розставляючи блоки як цеглини один за одним. Геть з профеcсіі! Перевіряється: Web Developer Outline → Float elements, якщо все в червоних блоках, верстку потрібно викидати на смітник.
• Погано - відсутність тайтлів.
• Погано - відсутність тайтлів.
• Погано - відсутність alt у картинок.
• Погано - стилі для IE всередині main.css без фільтрів. Тобто коли просто пишемо {zoom: 1;} - це оч. погано, тому що буде застосовуватися до всіх IE, а не тільки до того, в якому проблема. Потрібно фільтрувати: HTML5 Boilerplate-стилі, використовувати Conditional Comments, ну або на худий кінець (* html, * + html і т.д.).
• Погано - не перевіряти tabindex в формах.
• Погано - писати стилі не думаючи про логіку розміщення елементів. Наприклад, якщо елемент завжди знаходиться зверху, у нього повинен бути великий z-index, не можна сподіватися на те що зараз все нормально виглядає - стилі повинні бути залізобетонними. Якщо елемент завжди повинен знаходиться на якомусь місці, в незалежності від оточуючих його елементів - це position: absolute; а не float і т.д.
• Дуже погано - презентаційні класи (right, red).
• Погано коли немає базових стилів у стандартних елементів. Тобто просто h1, h2, ul, table, etc без класів повинні виглядати красиво і органічно.
• Погано коли немає поступового уточнення стилів, а стиль виписується для кожного елемента окремо, а за його межами - зовнішній вигляд може бути кардинально інший. Мова про ситуацію коли наприклад текст, написаний без абзаців, має взагалі не той стиль що у всіх елементів в блоці. Треба вести стилі від низу до верху, поступово уточнюючи їх.
• Ще гірше - надто деталізовані глобальні стилі. Наприклад a {font: italic 10px Tahoma;} / * Ненависть! Ненависть! НЕНАВИСТЬ !! 11 * / Потім доводиться перевизначати стиль посилань для кожного блоку.
• Розміри і позиціонування елемента повинні вказуватися в одних одиницях виміру. Для текстових блоків це в 90% випадків - em. Line-height - як правило коефіцієнтом (1 / 1.2 / 1.4 ... тобто без вказівки одиниці виміру - це цифра на яку множиться font-size і вийде міжрядковий інтервал). Тобто задали font-size / height в em - значить задаємо і margin / padding теж в em. Класичний приклад: список dl-dt-dd, де dt і dd ставляться один на проти одного за допомогою підтягування dd негативним margin вгору. Або - виділили padding'ом місце під position: absolute якогось текстового блоку. Задаємо padding і height в em (щоб коректно збільшувати розмір шрифту).
• Погано вішати стилі на стандартні теги, без класів. Тобто допустимо пишемо щось типу h2 a span {якась міцна штука, типу картинки з графікою, що закриває текст}, а потім клієнт в Візігу раптово вбиває таке поєднання! І отримуємо неймовірний баг. Всі стилі елементів всередині #content обов'язково повинні навішуватися на елементи з класом.
• Погано - безпосередньо задавати візуальне відображення елементів через js: $ ( "elementid"). Css (styleName, "something")

  . Це повинно робитися через установку / зміну класів.

Приклади хорошого:

• БЕМ ! У чистому вигляді важкуватий, але ідеї - вкрай вірні!
• Добре - структурувати код в блоки описують логіку документа. Тобто створювати div навіть там, де він для презентаційних цілей не потрібен. І навпаки - намагатися не ставити зайвий div там, де структура цього не вимагає, а це потрібно лише для візуальних ефектів.
• HTML5 Boilerplate - чудовий стартовий шаблон від «батьків». Використовуйте і приєднуйтесь до розробки, додавайте свої велосипеди туди!
  Раніше у нас був свій самопісний framework-стартовий html, тепер використовуємо Boilerplate як основу, а в нього вже додаємо старі напрацювання.
• Використовуйте напрацьовані рішення, чужі модулі, jQuery-плагіни, які не винаходьте велосипедів, а якщо винаходите - підтримуйте їх, ведіть бібліотеку коду (після кожного нового проекту додавайте туди код, оновлюйте старий).
• Для текстових блоків, що редагуються в адмінці, повинна забезпечуватися атомарность текстових стилів. Тобто є у нас сторінка з якимось текстовим блоком, приблизно такої структури: body.contacts #content # content-text h1 body.contacts #content # content-text .entry body.contacts #content # content-text .entry .somenamedblock

  div.somenamedblock повинен отримувати текстові стилі безпосередньо -

  div.somenamedblock {font: ...; color: ...;}

  , Тому що інакше в Візігу адмінки ми не зможемо їх застайліть.

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

№6 Правильна структура заголовків (H1, H2, ... і т.д. і TITLE)

Це турбота про семантичності коду, заголовки структурують сайт, роблять його коректним документом. Коректний Document Outline важливий для SEO.

Перевіряється в FF через плагін Web Developer → Information → View Document Outline. Червоних рядків бути не повинно!

№7 Сайт повинен нормально виглядати у всіх стандартних дозволах від 1024 і вище і не мати горизонтального скролла

Перевіряється в FF через плагін Web Developer → Resize
Список класичних дозволів:

• 1024 × 600
• 1024 × 768
• +1152 × 864
• 1280 × 800
• 1280 × 1024
• 1440 × 900
• 1680 × 1050
• 1920 × 1080

№8 Працездатність при вимкненому JavaScript

JS може бути вимкнений згідно корпоративних вимог безпеки. А в Opera Mini він працює тільки методом перезавантаження сторінки.
Але найголовніше - сайт повинен зберігати нормальний вигляд, поки він вантажиться на повільному 3G і js-скрипти ще не виконалися!

Весь критично важливий функціонал сайту повинен бути доступний без JS. Додаткові фішки (наприклад посилання на збільшення шрифту або роздруківку) - при вимкненому JS не повинні відображатися.

Якщо не хочеться / немає можливості реалізовувати функціонал без JS, потрібно хоча-б отримувати сповіщення про необхідність його включити (реалізовується через <noscript>).

Перевіряється в FF через плагін Web Developer → Disable → Disable JavaScript → All JavaScript.

№9 Працездатність при вимкненому Flash

В ідеалі весь критично важливий функціонал сайту був доступний без Flash. У реальному житті потрібно:

• виводити фонову графіку в блок, де повинен відображатися презентаційний flash;
• виводити хоча-б просто тестову інфу в блок де через flash виводиться якась інформація;
• виводити кнопочку "Get Adobe Flash Player" і пропонувати Express Install якщо вже без флеша зовсім ніяк.

Flash не працює на iOS-девайсах. Flash погано індексується пошуковими системами.

Перевіряється в FF відключенням flash-плагіна: Tools → Add-ons → Plugins → Shockwave Flash → disable.

№10 Доступність при вимкнених (завантажуються) картинках

Написи (особливо логотип і головне меню сайту) повинні залишатися читабельними, у всіх інформаційних картинок повинні бути підписи акуратним невеликим сірим шрифтом (так, для img можна задавати font - це зовнішній вигляд alt-тексту, що виводиться замість картинки).
Картинки часто відключають при використанні дорогого інету, що тарифікуються по трафіку (GPRS, роумінг).

Перевіряється в FF через плагін Web Developer → Images → Replace Images With Alt Attributes.

№11 Відсутність багів при збільшеному шрифті

Перевіряється в FF:

• Шрифти - включенням View → Zoom → Zoom Text Only та послідовним натискання клавіш Ctrl + - (або View → Zoom → Zoom In).
• 120 dpi - налаштовується окремим апплетом в Control Panel (Vista / Seven) або у властивостях драйвера відеокарти в XP.

Про приведення зовнішнього вигляду сайту на 120dpi до 96 читайте в моїй статті « 120 dpi і шрифти в em ».

№12 Наявність Win / Mac / Linux-аналогів шрифтів

Перевіряється пошуком по тексту css назв "Helvetica", "Liberation", "DejaVu", "Meera", "Monaco", "Century Schoolbook L", "Nimbus Mono L", "URW". Хоча б два з них повинні бути.
Набори аналогів популярних шрифтів:

№13 Оптимізація швидкості завантаження

Навіщо це нужно:

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

© sunnybear .
В цілому швидкість завантаження перевіряється так:

• по панелі Net в Firebug
  Необхідно перевіряти, як відображається сторінка при завантаженні на малих швидкостях (Хоча б 64 КБ). Дуже часто в такі моменти користувач бачить роз'їхалися верстку.
• Page speed и YSlow аддонам в Firebug (враховуйте що значна частина рекомендацій: включення стиснення, установка певних headers, minifying коду - відноситься до серверних робіт, а не верстці)

Наявність css-спрайтів перевіряється пошуком по коду блоків оголошень виду:

... {background-position: 0 -30px} ... {background-position: 0 -60px} ... {background-position: 0 -90px}

(Цифри можуть бути будь-які)
Наявність base64-encode перевіряється пошуком по коду блоків оголошень виду

url (data: image / png; base64, iVBOR ...)

Border-radius, gradient, box-shadow, text-shadow перевіряються пошуком цих слів в css 🙂
Найпростіший спосіб перевірити оптимізацію png / jpg - запустити готові скрипти оптимізації графіки для картинок вашої верстки і порівняти результат з вихідними файлами - якщо розмір майже не змінитися - значить все ок.
Якщо js не є об'єднані в один файл, то Page Speed ​​скаже вам про це: "Combine external JavaScript".

Необхідно враховувати що спрайтів, base64 encode і css3-стилів може і не бути через непотрібність (макет дуже простий).

Для проектів, де це обумовлено, перевіряється:

• Версія для друку (вона повинна бути реалізована через css)
• Мобільна версія (таки теж повинна бути через css)

№15 Важливі дрібниці:

• Лого на внутряк має вести на титулки. На титулки logo = h1, на внутряк H1 = заголовок контенту, а Logo = div
• У кожної сторінки повинен бути свій унікальний TITLE формату About Us -% CompanyName%
• Всі сторінки повинні бути слінковани і перевірені на наявність битих посилань .
• Всі номери повинні якось реагувати на: hover,: active і: focus - показиванія / прибирання підкреслення, зміною кольору, чим завгодно. У всіх посилань, крім пунктів меню, повинна бути реакція на: visited
• «Контент на початку сторінки» - вміст сторінки має йти на початку коду, до всяких сайдбарі і іншого.
• Розширення сторінок на сайті має бути «.html» а не «.php», а все створені сторінки спочатку повинні бути порізані на шаблони і працювати через mod_rewrite.
• Копірайт повинен бути написаний правильно .
• Повинні бути favicon.ico і apple-touch-icon
• У верстці не повинні залишатися закоментовані «про всяк випадок» шматки коду, зайві невикористовувані файли, старі версії файлів і т.п. Все бекапи можна витягнути з системи контролю версій (наприклад SVN), а на живому проект «сміття» потім заважає розібратися як що працює.
• Розміри для блоків, чиї розміри залежать від міститься в них тексту, потрібно задавати в em, а не px.
• Якщо url посилання невідомий, то він повинен бути дорівнює її анкор, написаному латиницею з заміною прогалин / спецсимволов на тире.
• Skype-плагін не повинен ламати верстку
• Ресайз textarea не повинен ламати верстку
• При перевірці frontend в цілому - 404-сторінка повинна віддаватися з кодом 404 а не 200.
• Потрібно підстрахуватися фіксуючи в css розміри картинок, які виводяться програмно.
• Перевірка орфографії Word'ом або Орфографія , Бажано - оттіпографіть контент.
• Посилання на чужі сайти повинні бути з target = "blank", бажано виділяти їх іконкою «зовнішнє посилання».
• Зрозуміло картинки повинні бути в окремій папці, css - в окремій і js - в окремій.

Де ж 14? Пропущено, правильно, тест на увагу, не спи, чиясь рука в твоєму кишені, йо!
І останнє, але найважливіше проте - на "WTF?" Манагера - май свою думку 🙂

оригінал: https://habrahabr.ru/blogs/webdev/114256/

Читайте також: