Розробка CSS в GitHub

Від перекладача:
Стаття написана від імені Mark Otto, одного з провідних мейнтейнерів популярного front-end фреймворку Twitter Bootstrap, нині розробника CSS в GitHub
.

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

Коротка характеристика
Огляд поточного стану CSS коду показує:

  • Використання SCSS як препроцесора;
  • У нас понад 100 окремих вихідних таблиць стилів, які ми компілюємо перед випуском у продакшен;
  • Скомпільований CSS розділений на 2 файлу, щоб уникнути ліміту на кількість селекторів у версіях IE<10;
  • Два цих файлу мають загальний вага в 90KB;
  • Ми не дотримуємося певного підходу в архітектурі CSS;
  • Ми використовуємо пікселі в якості одиниці виміру, хоча іноді ми також користуємося em;
  • Ми використовуємо Normalize.css і змішання наших власних скидають стилів.

Препроцесор
Як сказано вище, ми використовуємо SCSS. Цей вибір зроблено задовго до мого приходу і я не маю нічого проти (незважаючи на те, що Bootstrap зараз розробляється на LESS). Наші SCSS файли створюються Ruby on Rails з деякою допомогою Sprockets для включення файлів. Детальніше про це трохи пізніше.

щодо LESS, Stylus, або ...? Я не думаю, що GitHub колись планував перейти на LESS, але не можу стверджувати це. Зараз ми також, швидше за все, не будемо переходити на розробку, використовуючи LESS, тому що не бачимо явних переваг.

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

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

Також на даний момент ми не використовуємо source maps, але це скоро зміниться. (Якщо ви не знали, source maps дозволяють вам бачити в Inspector'e браузера, з якого вихідного SCSS файлу був скомпільований даний набір стилів, замість скомпільованого і стисненого CSS. Вони круті.)

В добавок до цього, ми використовуємо дуже мало можливостей SCSS. У нашому випадку функціонал SCSS зводиться до використання змінних, миксинов, функцій кольору (darken, lighten, etc), математичних функцій і успадкування.

Архітектура
На даний момент два популярних підходу до CSS архітектурі — це BEM та OOCSS. Ми схиляємося в бік OOCSS, але у нас немає цілісного і глобального підходу. Ми намагаємося розробляти нові елементи з розпливчастим підходом, комбінує властивості цих двох підходів, але який має такі базові риси:

  • Перевагу класам, ніж чого-небудь ще (ID, теги), в селекторах;
  • Ухилення від зайвого спадкування;
  • Використання (одиничних) дефісів в назвах класів;
  • Намагаємося давати як можна більш короткі імена класів, але без створення плутанини.


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

Перевірка синтаксису (linting)
Ми почали користуватися перевіркою синтаксису нашого SCSS кілька тижнів тому. У нас були свої умовні угоди стосовно код-стайл, але стиль і форматування кожного розробника були в якійсь мірі унікальні. Зараз же кожен CI білд включає в себе базовий SCSS linting і файл не випускався в білд, якщо:

  • Ваш клас є в CSS, але його немає ніде в папці шаблони app/views;
  • Ви використовуєте один і той же селектор кілька разів (оскільки вони майже завжди мають бути суміщені);
  • Загальні правила форматування (ліміти спадкування, відступи між правилами, відсутність пробілів після : і т.д.) порушені.


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

Два CSS файлу
GitHub має набір з двох CSS файлів, github github2. Файл був розділений кілька років тому, щоб вирішити проблему ліміту 4095 селекторів на один файл. Цей ліміт розповсюджується на версії IE 9 і молодше, тому GitHub вимагає підтримки IE9, наш підхід до поділу CSS залишиться в силі ще довго. Тому що на сьогоднішній день GitHub має близько 7000 селекторів в цих двох файлах. Порівняємо ці цифри з даними з інших сайтів:

  • Bootstrap v3.2.0 має трохи менше 1900 селекторів;
  • Twitter має трохи менше 8900 селекторів;
  • NY Times — близько 2100 селекторів;
  • SoundCloud (нова версія) — близько 1100.


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

Включення через Sprockets
CSS і JavaScript GitHub'a включаються через Sprockets і require. Ми розробляємо наш CSS код за допомогою розділених підкаталогів всередині папки app/assets/shylesheets. Ось як це виглядає:

/*
= require primer/basecoat/normalize
= require primer/basecoat/base
= require primer/basecoat/forms
= require primer/basecoat/type
= require primer/basecoat/utility
= require_directory ./shared
= require_directory ./_plugins
= require_directory ./graphs
= require primer-user-content/components/markdown
= require primer-user-content/components/syntax-pygments
= require primer/components/buttons
= require primer/components/navigation
= require primer/components/behavior
= require primer/components/alerts
= require primer/components/tooltips
= require primer/components/counter
= require primer-select-menu
= require octicons

= require_directory .
*/


Ми включаємо наші залежності (Primer це наш внутрішній фреймворк) і після цього включаємо всі SCSS файли папки у тому порядку, в якому Sprockets вирішує включити їх (мені здається, за алфавітом). Легкість, з якої ми можемо пов'язувати наші стилі (просто за допомогою команди require_directory .) вражає, але в цьому також є недоліки.

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

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

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



Також, от графік кількості селекторів в CSS файли за останні 3 місяці на наших blob сторінках. Очевидно, що у нас ще залишилося багато роботи по зменшенню кількості tag-селекторів.



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

Розкриваючи цю тему в Twitter, у нас було (не впевнений, чи є у них це зараз) 2 файлу, core more. Core-file містив в собі стилі, необхідні для того, щоб час, що минув до першого твіта, було як можна більш маленьким. Все інше було в файлі more. Знаючи про любов GitHub до швидких змін (тут нічого не портируется, якщо це не було портировано швидко), ми звернемо свою увагу на такий підхід. Зараз же наші два файлу розділені довільно.

загалом, оптимізація продуктивності селекторів не особливо нас турбує. Ми в курсі поганих підходів: надмірні вкладення, ID, елементи і т.д., але ми не намагаємося переоптимизировать. Єдиним винятком були diff сторінки. З-за занадто великої кількості розмітки, яке було потрібно для візуалізації diff сторінки, ми уникали аттрибутивных селекторів, як [class^=«octicon»]. При занадто частому використанні, ці аттрибутивные селектори можуть крашить (і крашили) браузери.

Документація


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

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

Primer


Я натякав на це раніше, але для тих, хто не в курсі, Primer p це наш внутрішній фреймворк для обшіх стилів і компонентів всередині наших публічних і внутрішніх додатків. Він включає:

  • Normalize;
  • Глобальні стилі для box-sizing, друкарню, посилання тощо;
  • Навігацію;
  • Форми;
  • Сітку;
  • Стилі розмітки;
  • Спеціальне меню select.


Ми використовуємо його на GitHub.com, Gist і декількох внутрішніх додатках.

Більшість компонентів Primer'a документовані в нашому стайлгайде (навігація, tooltips, і т.д.) Незважаючи на це, ми нещодавно взялися за оновлення і поліпшення Primer'a, тому багато компонентів зараз змінюється.

Для тих, хто хотів запитати, я б дуже хотів викласти у відкритий доступ частини Primer'a, але в цьому напрямку мало що зміниться найближчим часом. Все-таки, надія у мене є.

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

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


Загальний процес рефакторінгу, ймовірно, не унікальний для GitHub'a. Ми знаходимо речі, які варто було б видалити, видаляємо їх, публічно обговорюємо, повідомляємо про це команді по розробці CSS і портуємо їх так швидко, наскільки це можливо. Будь-який член команди може видаляти код. У нас є багато розробників, які безпосередньо додають щось нове в GitHub, але у нас також є чимало нердов, аналізують те, що ми можемо видалити.

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

0 коментарів

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