Css Github

Исходники скомпилированы в 2 отдельных CSS-файла (чтобы избежать проблемы с максимальным количеством селекторов для IE).

<10).

Эти 2 файла весят в сумме около 90 кб.

Мы не используем никакой специальной «CSS-архитектуры».

Мы выбрали пиксели для определения размера, но у нас еще есть несколько «em».

Мы используем Normalize.css, смешанный с несколькими нашими собственными стилями, для сброса свойств.

Наш SCSS компилируется и подключается с использованием конвейера ресурсов Rails и Sprockets (на данный момент).

Более подробно будет описано ниже.

Как насчет LESS, или Stylus, или.

? Я не думаю, что GitHub когда-нибудь перейдет на LESS. Нам не хотелось бы что-либо менять в этом плане, поскольку явных преимуществ нет. Зачем препроцессор? Наша внутренняя структура включает набор переменных (таких как шрифты и фирменные цвета) и примесей (в основном для префиксов), которые делают написание кода быстрее и проще.

В настоящее время мы не используем Автопрефиксер , но мы должны это сделать.

Таким образом, мы могли бы свести на нет все существующие примеси.

Я надеюсь, что мы это реализуем в ближайшее время.

Мы также не используем исходные карты, но это скоро изменится.

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

Они потрясающие.

) Наше использование инструментов SCSS весьма ограничено.

У нас есть переменные для определения цветов, примесей, цветовых функций, математических функций и уровней вложенности.

Нам не нужно перебирать классы, создавать глобальные настройки или что-то в этом роде.

Мне нравится простота, которую мы получили.

Пишите как можно меньше, чтобы не создавать путаницы.

О предпочитаемой мной архитектуре CSS я напишу в другой статье.

На этом этапе я описываю подход GitHub, который хоть и не идеален, но достаточно хорошо служит своей цели.

У нас были некоторые общие соглашения, но у каждого разработчика был свой стиль, и у каждого из нас было свое уникальное форматирование.

На данный момент каждая сборка проходит процесс анализа кода SCSS и аварийно завершает работу, если: CSS описывает класс, который не используется в шаблонах приложений/представлений/.

Один и тот же селектор используется несколько раз (поскольку их всегда необходимо комбинировать).

Нарушены основные правила форматирования (максимальная вложенность, переносы строк между наборами правил и т.п.

).

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

Они не учитывают различий в стиле комментариев или архитектуре, но это именно то, что нужно каждой команде.

И каждый из нас может что-то предложить и улучшить.

Это ограничение распространяется на версии IE 9 и ниже.

Поскольку для GitHub требуется как минимум IE9, нам необходимо разделить файлы.

На сегодняшний день наши 2 файла состоят примерно из 7000 селекторов.

Легкость, с которой мы можем включать наши таблицы стилей (просто указав require_directory), поразительна.

Но у этого подхода есть свои недостатки.

Порядок применения стилей важен.

Из-за использования звездочек у нас иногда возникают специфические проблемы.

Это связано с тем, что новые файлы можно добавлять в любой пакет в любое время.

В зависимости от имени файла новые стили могут появляться в разных местах скомпилированного CSS. Кроме того, используя Sprocket, вы не получаете немедленного и автоматического доступа к глобальным переменным и миксинам в ваших файлах SCSS. Это означает, что вам придется импортировать их явно в начале каждого файла, который ссылается на переменную или миксин.

Например, размер наших двух CSS-пакетов за последние 3 месяца:



Мы также отслеживаем количество селекторов на странице.

Перед нами по-прежнему стоит задача сократить количество селекторов на тег.

Поскольку мы регулярно обновляем наш CSS и делаем это много раз каждый день, нам приходится постоянно сбрасывать кэширование наших довольно больших файлов.

Мы пока не добились большого прогресса в оптимизации размера этих файлов и ограничении очистки кэша, но начали думать об этом более серьезно.

Было бы неплохо иметь основной пакет, который меняется редко, и второстепенный пакет, который меняется время от времени.

Когда я работал в Twitter, у нас было 2 пакета (не уверен, что это до сих пор): основной и дополнительный.

В основном были описаны все стили, которые требовались для максимально быстрого отображения первого твита.

Все остальное хранилось в доп.

Учитывая любовь GitHub ко всему быстрому, мы планируем заняться этим в ближайшем будущем.

В настоящее время деление файлов является случайным.

Обычно мы не занимаемся производительностью селектора.

Мы знаем о плохих практиках — большой вложенности, использовании селекторов по идентификаторам и элементам и т. д., но мы не пытаемся слишком сильно это оптимизировать.

Единственным исключением является страница различий.

Из-за обширной разметки, необходимой для отображения diff-a, мы избегаем селекторов атрибутов, таких как [class^="octicon"].

При слишком частом использовании эти селекторы атрибутов могут (и уже приводили) к сбою браузера.

Для любопытных Джон Рохан, разработчик GitHub, выступил на GitHub с отличным докладом о производительности CSS, в котором освещаются эти проблемы.

Мы сделали общедоступным наше руководство по CSS и все основные правила написания CSS. Мы также разместили примеры большинства наших компонентов.

Он был скомпилирован с использованием KSS, генератора руководств по стилю.

Наша документация не идеальна, но она помогает людям находить и использовать то, что они хотят. Это также отличный способ показать новичкам, как мы работаем, чтобы ускорить процесс разработки (как я сделал около 2 лет назад).

Твиттер или мой репозиторий для обратной связи.