У цій статті я спробую коротко і доступно дати рекомендації, як верстати під Бітрікс, щоб "верстальник не став ворогом програміста" і не робив тисячі "дурних" правок. Почну з основних моментів, їх небагато. Закінчу ж тим, що я винесла для себе з досвіду верстки.
Чи не встановлювати повний reset
Скидаючи всі стилі за замовчуванням, необхідно їх перевизначити, адже не дарма розробники їх встановили. А у випадку з Бітрікс робити це взагалі не можна, оскільки зламається вся админка frontend'а.
Мінімізувати використання абсолютних елементів за винятком необхідності
Абсолютний елемент - сам по собі і поза контекстом. Зазвичай таких елементів дуже небагато. І їх явно видно в макеті. Використання за призначенням і немає часто призводить до непередбачуваного поведінки верстки, коли якийсь блок / елемент потрібно прибрати. Тоді виходять дірки. Чим більше діра, тим кругліше очі у програміста (про думки промовчу).
У дизайні все ідеально, але не в реальності. Це потрібно враховувати.
Також варто бути обережним з використанням високих значень z-index. Не варто встановлювати значення в 1000, якщо в верстці немає жодного блоку, що має значення близьке. Можна починати з малого, 1-10, підвищуючись короткими кроками (5-10) в міру необхідності.
Не застосовувати препарат "банальні" назви стилів
Я пам'ятаю одну назву ".title", використання якого благополучно зламало админку frontend'а. Тому проявляємо політ фантазії і називаємо оригінально, але осмислено.
Шаблонизировать контейнери контенту
Якщо шапка, футер, контейнер контенту та інші блоки однакові, значить і код і розмітка у них повинні бути однаковими.
Відмінності тематичних складових необхідно оточувати в додаткові обгортки з ідентифікацією класом або ВД, якщо необхідно.
Наприклад, неправильно:
page1
Якщо поведінка колонок однакове, замість виділення для них двох окремих класних .main_wrap1 і .main_wrap2, варто вказати один .main_wrap і класифікувати внутрішній вміст.
Тут відкрию маленьку таємницю: з приводу деяких дрібниць з дизайнерами завжди можна домовитися. Тобто наприклад, якщо на двох макетах одні і ті ж відступи / поля відрізняються в кілька пікселів, це не завжди критично і може бути приведено до однакового значення.
Не застосовувати препарат ">"
Якось спочатку до подібної записи селектор душа не лягла, чи то тому, що лінь було розбиратися, чи то тому, що Місяць була не в потрібній фазі. Але так склалося історично. На практиці ж виходить так, що на стадії програмування відбуваються всякі метаморфічні зміни в розмітці і верстка може зламатися. Якщо взяти до уваги Бітрікс, то админка frontend'а додає додаткові обгортки та інші смаколики, що дуже вдало ламає все успадкування.
Роздавати кожному елементу класи
Двозначне заяву, яке кожен трактує по-своєму і золоту середину знаходить кожен свою. Основним є той аргумент, що рендеринг відбувається швидше, тому що читання стилів ведеться справа наліво, а ієрархія значно знижується (до 2-3 рівнів). Ще скажу, що це зручніше - усвідомлення цього приходить з досвідом.
Зазначу, що на цьому принципі побудований БЕМ від Яндекс.
Від себе ж додам, що якось безглуздо обнуляти стилізовані теги (, ...). якщо можна використовувати порожні ( Чи не обрамляти елементи списку публікацій посиланням Моя особиста думка: розмітка виглядає м'яко кажучи незвично, про семантику і говорити нема чого. Але мене просвітив фахівець з іншої галузі - виявляється, SEO страждає по перше число і робот такі записи просто пропускає. Чи не прописувати стилі і скрипти в розмітці Такий розподіл порядку дозволить централізовано вносити зміни як в стилі, так і в розмітку, і в скрипти і не шукати причини, за якими дані зміни чомусь не хочуть застосовуватися. Нагадувати про ролловеров і випадають елементи Використовувати окремі класи для скриптів
Давним давно жив-був чудовий doctype Strict, який регламентував розділяти "Мухи окремо, котлети окремо". Погодьтеся, набагато зручніше шайби шукати в банку на середній полиці, а болти - в шафці, в дальньому кутку кімнати, а не перемешанность в середньому ящику стола.
Всі ми без винятку хочемо, щоб сайти реагували на наші дії, відгукувалися, візуально пояснювали задумку творця, були чуйними. Основну роль в реалізації такої "цукерки" грає ролловер. І якщо раптом дизайнер забув промальовувати на щось відгук, потрібно йому про це нагадати. Тоді все без винятку будуть пишатися таким витвором.
Коли верстка максимально приводиться до одного "знаменника", однакові стилі можуть бути застосовані до різних за змістом блокам. Не кожному потрібен буде виклик скрипта. Розділивши за допомогою класів уявлення і контролер, отримуємо можливість безболісно вносити зміни в код.
І наостанок, не забувайте Конфуція. Верстаючи вміст контенту, замислюйтесь: як людина, що не має ні найменшого поняття про HTML і насилу розбирається в WYSIWYG, буде створювати наповнення сайту в такому ж вигляді.Схожі статті