Пріоритетна орієнтація під мобільні пристрої – ретроспектива

30

Від автора: Більшість верстальників погодилися б, що просто мати мобільно-орієнтоване мислення не досить для створення високоякісних чуйних сайтів – також необхідні релевантні мобільно-орієнтовані основні директиви і принципи. Нещодавно ми зіткнулися з проблемами у масштабуванні мобільно-орієнтованих сайтів на планшетах і комп’ютерах. Те, що ми бачили, було не завжди приємно, але уроки виявилися цінні. У цій статті ми виправимо ці помилки і сподіваємося створити повністю кроссплатформенную верстку від мобільних пристроїв до настільного комп’ютера.

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

Бути може, створення чуйних додатків не пріоритетно зараз для вашої команди. Але одного разу – і час конверсії кадрів може бути дуже жорстким, коли ці дні настануть.

В ідеалі, необхідно просто додати медіа запити CSS, і все повинно запрацювати. Але легка адаптація коду до змін розміру екрана – єдине, що може статися.

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

Медіа запити

Всі ми знаємо про медіа запитах. Наскільки складні вони можуть бути? Накидати парочку на кожній сторінці, і чуйний сайт готовий?

Використання медіа запитів на ваших сторінках вкрай важливо; вони дозволяють переписувати значення CSS в залежності від розміру екрана. Можливо, цей підхід звучить просто, але у великих проектах це може швидко вийти з-під контролю. Є кілька основних проблем, які можна отримати, використовуючи медіа запити:

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

Встановлення стилів елементів з JS: Привабливий, але «некрасивий» спосіб для створення чуйних сайтів. Елемент не може належним чином використовувати медіа запити, коли ви спирається на логіку JS для установки власної ширини. Якщо в логіці JS ширина є рядковим властивістю, то неможливо переписати її значення через CSS без !important. На додаток до цього, вам доведеться обслуговувати зростаючий набір JS логіки.

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

Простору імен CSS для інкапсуляції: якщо ви пишіть модуль, то його селектори CSS повинні бути правильно інкапсульовані з допомогою простору імен. Ми радимо додавати префікси до класів з ім’ям модуля, такі як navbar-parent. Дотримуючись цього шаблону, будуть попереджені конфлікти з іншими модулями. А також буде гарантовано, що медіа запити в кінці файлів CSS вашого модуля оброблять необхідні значення.

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

Використання !important для перезапису стилів: Додавання !important в стилі знижує здатність до супроводу. Краще уникати використання !important і замість цього використовувати CSS простір імен для запобігання змішування модулів.

Чуйний або адаптивний?

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

І яку ж слід використовувати? Чуйну або адаптивну методику? Відповідь залежить від того, що ви хочете отримати. Може бути, заманливо застосовувати скрізь адаптивну техніку верстки у вашому проекті, але у багатьох випадках вона може не знадобитися. Гірше того, застосування адаптивної верстки може швидко переусложнить ваш дизайн. Прикладом може послужити використання JavaScript для встановлення значень атрибутів CSS стилів, що ми бачили неодноразово.

Використовуйте JavaScript в крайніх випадках

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

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

Коли використовувати адаптивну верстку

Адаптивна техніка веб дизайну – могутній інструмент, що дозволяє використовувати вибіркове завантаження ресурсів, засновану на user-agent ах і розмірах екрану. Логіка, яка, наприклад, визначає браузер десктопної версії і завантажує зображення високого дозволу на відміну від стислих для мобільних пристроїв копій. Завантаження додаткових ресурсів і функцій для екранів більшого розміру також може бути корисна. Браузер настільного комп’ютера, наприклад, із-за більшого розміру екрану, можливостей або пропускної здатності може відображати більше функціоналу.

В ідеалі, додаткові ресурси будуть подгружаться на вимогу для конкретних платформ. Даний тип завантаження прискорює мобільні версії сайтів, у той же час, дозволяючи використовувати повний функціональний набір у версіях для робочого столу і планшета. Цю методику можна застосувати для перевірки юзер-агента на стороні клієнта або сервера. Якщо все оброблено на сервері, будуть повернуті тільки ресурси підтримувані платформою користувача. Крім того, завантаження на вимогу з боку клієнта може використовувати AJAX запити для завантаження додаткових ресурсів, якщо такі підтримуються. Цей ефект може бути досягнутий при використанні JavaScript на стороні клієнта, заснованого на підтримці браузера і юзер-агента. Зазвичай, визначення на стороні клієнта краще, оскільки дозволяє робити це, виходячи з фактичної функціональності браузера, не вдаючись до складних юзер-агент перевірок.

Простий приклад гнучкої сітки

Чуйна гнучка сітка не повинна бути складною. У нашому демо ми показуємо просту реалізацію, де створена горизонтально-прокручувана секція контейнерів з зображеннями. Центровані зображення і можуть масштабуватися до 100% від батьківського контейнера, зберігаючи вихідне співвідношення сторін. Крім того, висота контейнера встановлено у 100%, дозволяючи нам регулювати висоту виключно в батьківському блоці-обгортці. Цей спосіб підтримує простоту і легкість читання медіа запитів.

HTML та CSS вихідний код за цим посиланням використовує вище описану концепцію. Ми плануємо додати більше стереотипних шаблонів; не соромтеся додавати власний код. Pull-запити вітаються.

Кращі практики

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

Про використання медіа запитів

Найбільш чуйні макети сторінок можуть і мають бути виконані за допомогою медіа запитів. Використання JS для маніпуляції CSS стилів (можливо крім додавання/видалення класів) потрібно уникати. Установка ширини через JS не так проста в обслуговуванні або динамічна, як в CSS.

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

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

Якщо у ваших базових CSS стилях багато селекторів, правила медіа запитів повинні бути пристосовані під правилаСЅЅ. Використовуйте якомога менше селекторів, коли пишіть CSS правила.

Про створення CSS правил

Використовуйте класи, а не ідентифікатори, щоб уникнути специфічних проблем.

Для визначення поточного селектора використовувати найменшу кількість селекторів.

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

Инкапсулируйте ваші селектори CSS, використовуючи правильне простір імен, для запобігання конфліктів. Наприклад, class=»module-name-parent»

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

Про використання LESS

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

Переконайтеся, що у вас немає CSS правил, як це:

#wrapper #body-content #content #left-side #text {
border: 1px solid #000;
}

Працюйте з командою розробників і привласнюйте LESS змінним гарні імена.

Якщо ви використовуєте набір CSS правил повторно, робіть це через LESS домішка.

Про додавання обгорток до елементів

Більшість структур DOM набагато складніше, ніж це необхідно.

Додавайте блоки-обгортки тільки, коли вони необхідні. Не додавайте обгортки, якщо те ж саме можна зробити на CSS.

Якщо видаляєте блок-обгортку, і макет сторінки не змінився, цей блок вам не потрібен. А тепер проведіть глобальний пошук таких блоків (JS, CSS, rhtml, jsp, теги) і видаліть їх.

Про використання завантаження на вимогу

Додавайте плэйсхолдеры до компонентів, де необхідна завантаження на вимогу.

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

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

Про чистку

Якщо ви граєтесь з CSS і намагаєтеся полагодити макет сторінки, не забудьте видалити непотрібні правила CSS. Багато хто з них, можливо, більше не потрібні. Також видаліть зайві блоки-обгортки.