понедельник, 9 ноября 2015 г.

KSS styleguide

Что такое KSS?

KSS (Knyle Style Sheets) - это документация к CSS, достаточно понятная для разработчиков и хорошо структурированная для программной обаботки. Для лучшего понимания рекомендую почитать ну очень хорошую статью о концепции KSS.

Как это выглядит в коде? Пример файла buttons.css:

/*
A button suitable for giving stars to someone.

:hover             - Subtle hover highlight.
.stars-given       - A highlight indicating you've already given a star.
.stars-given:hover - Subtle hover highlight on top of stars-given styling.
.disabled          - Dims the button to indicate it cannot be used.

Styleguide 2.1.3.
*/
a.button.star{
  ...
}
a.button.star.stars-given{
  ...
}
a.button.star.disabled{
  ...
}

Как видно из примера, документация css осуществляется через комментарии следующим образом: первая строка - это описание данной секции. Затем идет список классов, модификаторов и псевдоклассов, которые будут документированы и их порядок.  При этом не обязательно создавать документацию на каждый элемент css. Достаточно указать поведение основных и самых используемых.

Последней строкой комментария задается расположение описания: 2.1.3 - в данном случае 2 глава с указанием пунктов и подпунктов. Вложенность можно делать любую в зависимости от нужд разработчика. Например:

1. Text styling
2. Buttons
   2.1 Form Buttons
       2.1.1
   2.2 Other buttons
       2.2.1
3. Forms
   3.1 Text fields
   3.2 Radio and checkboxes


По этой документации создается специальная страница styleguide, где можно увидеть задокументированный css c описанием. Пример:



Работая с препроцессорами (sass, less) достаточно удобно описывать миксцины и их параметры:

// Creates a linear gradient background, from top to bottom.
//
// $start - The color hex at the top.
// $end - The color hex at the bottom.
//
// Compatible in IE6+, Firefox 2+, Safari 4+.
@mixin gradient($start, $end){
  ...
}

Зачем это вообще надо?

Стоит ли так заморачиваться если проект маленький и я сижу в нем один? Как показывает практика, даже маленький проект нуждается в минимальной поддержке и доработке: там банер добавить, а тут текст увеличить. Иногда таких мелких правок бывает очень много, что легко испортить самый кристально чистый css.

Преимущества документированного css:

  • Такой css легко поддерживать, он остается чистым и понятным, а это сокращает время на написание нового
  • Структурирование css по файлам, что позволяет быстро находить существующие стили и использовать их, избегая дублирования
  • Написание такого css позволяет выработать хорошую привычку
  • Легко поддерживать консистентность в проекте

На каком этапе стоит использовать в своем проекте?

Я бы рекомендовала на самом раннем этапе, пока проект еще не испорчен простынями стилей, в которых нужно очень долго копаться в поисках нужного.

В идеале практическая сторона верстки должна строиться так:

  1. Построение html-структуры
  2. Описание основных css-стилей, кнопок, блоков и проч. элементов в соответствии с kss-документацией
  3. Создание прочих, уникальных css-стилей

То есть это должно быть первым этапом верстки: описание и документирование основных элементов страниц (формы, кнопки, заголовки, текст, ui элементы и проч.), а уже после "доработать напильником". Таким образом идя от общего к частному.

Какой "фреймворк" выбрать?


Принцип "фреймворков" достаточно простой: в стилях идет описательная часть в комментариях в начале файла. А по заголовкам они автоматически добавляются к списку гайдов.

Создание описаний-документации - это своего рода тесты для css. Их можно и нужно определять до написания самих стилей, чтобы знать что именно должно содержаться в данном блоке.

Хороший пример стайлгайда представлен у гитхаба. Естественно, хорошо бы иметь документацию и на html и на js.

Альтернативы


Наряду с KSS существуют и другие инструменты с очень похожим приниципом:


Комментариев нет:

Команды Emacs

При работе в консоли мы используем команды Emacs, но редко когда что-то сложнее [CTRL-R] для поиска по истории. Хотя зачастую возникает неп...