Майбутнє CSS

image

Дивне і в той же час дивовижний час для CSS.

Ось уже кілька років ми спостерігаємо зростання популярності парадигм, концепцій, архітектур, бібліотек і фреймворків, що відповідають за модульність, масштабованість і зручність при написанні CSS. З самого зародження інтернету співтовариство розробників стикалося з різними проблемами під front-end розробці, наслідком яких стала поява даних технологій. Серед проблем, що виникли, були відсутність програмних конструкцій (змінних, керуючих структур, областей видимості тощо), зниження когнітивної навантаження (і спрощення організації циклів), викликаної каскадированием і проблемами зі специфічністю, налагодження нормальної працездатності та зручність правил іменування. Але найголовніша проблема полягала в тому, як структурувати код CSS і увібрати в нього найкращі практики, які з'явилися в інших мовах веб-програмування за останні кілька десятиліть.

Судячи зі списку нижче, ці завдання були вирішені з різним ступенем успішності:

  • Препроцессоры і абстракції типу Sass, Less і PostCSS додають в стилі програмні конструкції. З їх допомогою ми можемо представляти CSS, як справжній тьюрінга-complete мову програмування.
  • Шаблони типу Atomic/Functional/Utility роблять селектори більш простими і відкочують нас назад до презентаційної схеми іменування.
  • Архітектури типу ITCSS допомагають організовувати наш код і файли впорядковані зрозумілим і передбачуваним чином логічні частини, що дозволяє легко знаходити потрібну ділянку коду, а також допомагає вибрати відповідне місце для нового коду.
  • Фреймворки типу True і Sassaby проводять модульні тести абстрактного CSS коду.


OOCSS, BEM, SMACSS і т. д. — всі ці технології зараз перебувають на піку популярності. Ці CSS шаблони і архітектури також називають «дорослими».

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

Одним з найбільш полегшують життя подій в сучасній front-end розробці став перехід до компонентній архітектурі – тобто код, в якому розмітка, подання та логіка структурно і/або функціонально об'єднані. Компонентну архітектуру ми бачили в дуже популярному фреймворку React і набирають популярність веб-компонентах (а також в фреймворках на основі веб-компонентів типу Polymer). Інші основні гравці серед JS-фреймворків, такі як Ember і Angular вловили важливість даного переходу і також включили різні варіації даної концепції в бібліотеки.

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

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

Не можна применшувати важливість даних переваг. Якщо ви, раптом, почали сумніватися у важливості вищезгаданої архітектури та її переваг, згадайте ваш кривий проект на Angular 1.x. Згадайте, як ви пробиралися через лабіринт HTML атрибутів, контролерів і директив, назв файлів (часто ці імена зовсім не передавали сенсу контролерів і директив), залежностей модулів… На секунду закрийте очі і уявіть, як може виглядати граф залежностей такого додатка. Я б припустив, що «Найбільший у світі моток шпагату» досить відповідна назва для такого графа.

З розвитком компонентної архітектури, особливо в JS, і диким зростанням популярності компонентних фреймворків ми починаємо помічати, як схожі концепції просочуються в світ CSS. Співтовариство веб-розробників моментально хапається за рішення, здатні спростити структуризацію коду, його написання і відстеження. Крім усього іншого, ми почали виправляти деякі упередження CSS, які існували кілька десятиліть – а саме, споконвічне переконання, що HTML ніколи не повинен містити дані про подання.

Прогресивні фреймворки та бібліотеки «осідлали хвилю», використовуючи вищезгадані шаблони: Atomic/Functional/Utility стали популярні за останній рік або два. Прикладом можуть послужити фреймворки Tachyons, BassCSS, а також мій фреймворк Nuclide.

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

<section class="mw5 mw7-ns center bg-light-gray pa3 ph5-ns">
<!-- контент -->
</section>


Тепер, коли ви звикли до такої великої кількості класів в HTML, давайте розглянемо плюси цього конкретного підходу:

  • Висока декларативність HTML коду дозволяє нам уявити, як виглядає елемент без необхідності заглядати в стилі
  • З плоским списком класів можна забути про проблеми зі специфічністю і перевизначенні стилів
  • Усунення контекстних CSS селекторів дозволяє правильно спланувати і вибудувати нашу архітектуру таким чином, щоб вона дотримувалась кращим сучасним практик: модульність, повторне використання та продуктивність
  • Якщо використовувати даний підхід на більшості елементів веб-сторінки, можна істотно скоротити обсяг стилів для всього сайту – залишаться тільки наші модульні класи від фреймворку Atomic, які можна повторно використовувати (плюс одноразові класи, які часто пишуться для конкретних проектів)


Непогані такі переваги, правда?!

Але не все так гладко. Тепер поглянемо на мінуси:

  • Адаптивний дизайн не так добре працює з даною моделлю. Фреймворк Tachyons використовує класи з додаткового простору імен для індикації класів медіа запитів – а це означає, що нам потрібно продублювати ВСІ класи фреймворку Atomic для кожного дозволу екрану. Крім того, виникає когнітивна перевантаження з-за того, що в нашій базі класи техніки mobile-first перемішуються з класами медіа запитів; уявіть собі, що вам потрібно написати код конкретного компонента для трьох або більше дозволів екрану з великою кількістю змін у стилях
  • Дана модель не охоплює псевдокласи. Як же тоді реалізовувати стану hover або active?
  • Дана модель не охоплює псевдоелементи. Як тоді стилізувати елементи :before або :after?


В принципі, ми майже закінчили. Але можна і краще.

Давайте доведемо цю концепцію до логічного кінця.

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

Наш фреймворк повинен відповідати наступним критеріям:

  • У фреймворку повинен бути повністю компонентний HTML/CSS-код, що створює концептуально-пов'язані контент і подання
  • Фреймворк повинен виробляти високо декларативний HTML-код, щоб ми могли легко уявити, як виглядає компонент без необхідності відкривати файли CSS
  • У фреймворку повинні бути медіа запити, щоб ми могли створювати елементи адаптивного дизайну, переважно без необхідності копіювання CSS класів для кожного дозволу екрану
  • Повинна бути можливість застосування стилів до псевдоклассам


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

Нам знадобиться: JS бібліотека, здатна додати до стандартних HTML атрибутів новий набір атрибутів, які для досягнення поставлених нами завдань будуть працювати в парі з CSS класами Atomic. В основі бібліотеки повинна лежати адаптивна техніка mobile-first. Бібліотека буде застосовувати стандартні можливості HTML на застарілих браузерах.

Приклад HTML коду:

<button
class="d-ib p-sm bgc-cool c-warm"
fxcss-device-tablet-remove="p-sm"
fxcss-device-tablet-add="p-md"
fxcss-device-desktop="d-b p-lg bgc-cloudy c-sunshine"
fxcss-pseudo-class-hover="td-u">
натисни мене
</button>



Пояснимо, що тут відбувається: за замовчуванням атрибут class буде використовуватись для стилів техніки mobile-first. Потім по події повного завантаження сторінки та/або зміни її розміру наша бібліотека (fxCSS або «futureCSS») підтягне атрибути і застосує відповідні зміни до певного пристрою. У цьому прикладі бібліотека fxCSS з допомогою атрибутів -remove і –add замінює клас «p-sm» на «p-md». Піднімаючись до дозволів настільних комп'ютерів, ми замінюємо всі класи списком класів для настільного комп'ютера (для даного функціоналу відсутні директиви -remove/-add). І останнє, у нас є окремий атрибут для стилів псевдокласів зразок hover.

Для роботи всього функціоналу нам потрібно підключити JS, а значить, зараз станеться щось дуже серйозне: якщо зробити HTML код на 100% декларативним і визначити всі 100% CSS класів, які ми будемо використовувати, ми зможемо зробити щось по-справжньому незвичайне:
  1. Можна зменшити CSS бібліотеку під конкретний проект і залишити тільки широко використовуваний фреймворк з набором налаштувань (де задані одиниці вимірювання відстаней (padding/margin/width/height), шрифти, кольори і т. д.), який викидає всі допоміжні класи, які нам могли б знадобитися
  2. Можна реалізувати функцію всередині бібліотеки fxCSS, яка в якості вхідних даних брала б шаблони HTML, становила б повний список використовуваних в шаблонах класів і усувала б непотрібні. Це кардинально б зменшило розмір CSS файлу (файл не було б медіа запитів, так як функціонал щодо застосування стилів залежно від пристрою лежить на JS бібліотеці. Цю функцію можна увімкнути або вимкнути.)
  3. Можна написати тест, який буде перевіряти наявність у заданого елемента потрібного класу. Також за допомогою тесту можна перевіряти, додані або видалені класи до потрібного пристрою. Концепцію тестів можна розвинути ще сильніше – так як наші класи незалежні і підпорядковуються заданій схемі іменування, можна реалізувати перевірки типу: якщо дочірньому елементу присвоєний клас «fl-l» (float: left), можна перевірити, щоб у батьківського був клас «cf» (clearfix)
  4. Можна створити репозиторій HTML-фрагментів компонентів інтерфейсу – так як ядро CSS бібліотеки, її іменування і генеруються класи сталі (теоретично) широко використовуваними стандартами, для створення компонентів нам знадобиться тільки HTML: при необхідності код на 100% декларативний і легкоизменяемый. 20 дизайнерів інтерфейсів можуть створити 20 різних варіантів компонента меню, а так як всі вони використовують одні й ті ж базові CSS класи, для перегляду кожного варіанту необхідно просто скопіювати і вставити правильний HTML код


Не варто забувати про:

  • Продуктивність: Враховуючи, що нові атрибути фактично будуть застосовуватися до всіх елементів на сторінці, може спостерігатися значне падіння продуктивності. Існує потенційний компроміс – наприклад, під час примусових трансформацій за допомогою бібліотеки fxCSS можна перевіряти видиму область веб-сторінки на пристрої і застосовувати стилі тільки до цієї частини, і тільки потім при прокрутці користувачем сторінки вгору або вниз застосувати стилі до іншим частинам
  • Псевдоелементи все ще не працюють – проблему можна вирішити з допомогою додаткового користувача атрибута
  • Є ще які-небудь поступки, на які нам доведеться піти заради старих браузерів? Ми можемо зіткнутися з проблемами з CSS в Internet Explorer?
  • Можна потрапити в оцінку 80/20 для конфігурації CSS за замовчуванням, що дозволить розмістити його на CDN і зробить написання/редагування CSS більш ефективною?


Перш за все, стає ясно, що сам спосіб мислення про CSS різко змінюється. Front-end розробники розуміють, що переписувати одні і ті ж 50 властивостей до посиніння не продуктивно. Крім того, перехід до компонентній архітектурі змушує нас переосмислити процес створення стилів для браузера. HTML і CSS – чудова пара. Так чому б їх не зв'язати разом?

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

Колеги, шановні відвідувачі Хабра! У це останнім абзаці мого перекладу хотів запитати дещо у Вас. Ми зі своєю командою WebForMySelf практичні щодня публікуємо туторіали так чи інакше пов'язані з створенням сайту.

Так ось, хотів дізнатися, чи буде Вам цікаво, якщо ми найсвіжіше і, на наш погляд, цікаве з англомовного інтернету будемо публікувати на хабре. Якщо Ви «За», то дайте знати в коментарях.

Приємного Вам дня!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.