18 сентября 2013 в 19:47

Compass — инструмент для эффективной работы с CSS из песочницы

CSS*
С выходом CSS3 появилось множество новшеств: с новыми свойствами стили стали сложнее, но не появилось никаких улучшений для поддержки новых и старых сложностей, в том числе дупликации кода. В чистом CSS отсутствует модульность, так как разбиение стилей на файлы и их подключение через @import пагубно влияет на производительность.
Решение этих проблем нашлось в CSS препроцессорах, с их помощью стало возможным использование переменных, выполнение математических подсчетов в коде, появилась возможность повторно использовать код с помощью миксинов и наследования. Идеология препроцессоров базируется на логическом разделении файлов стилей по контексту — решена проблема модульности. Безусловно, плюсом является уменьшение риска конфликтов кода в команде, навигация по коду становится намного удобнее. Так же в препроцессорах появилась возможность генерации кода с помощью циклов, в SASS это выглядит так:

/* SCSS */ 
$animals: puma, sea-slug, salamander;
@each $animal in $animals {
  .#{$animal}-icon {
    background-image: url('/images/#{$animal}.png');
  }
}

/* скомпилированный CSS */
.puma-icon {
  background-image: url("/images/puma.png");
}

.sea-slug-icon {
  background-image: url("/images/sea-slug.png");
}

.salamander-icon {
  background-image: url("/images/salamander.png");
}

или:

/* SCSS */
@for $i from 1 through 3 {
  .item-#{$i} { width: 2em * $i; }
}

/* скомпилированный CSS */
.item-1 {
  width: 2em;
}

.item-2 {
  width: 4em;
}

.item-3 {
  width: 6em;
}

Немного о Compass


Compass нечто большее чем CSS препроцессор, разработчики Compass позиционируют его как дизайнерский фреймворк. Compass использует SASS синтаксис (.sass или .scss), так что любой SASS код будет скомпилирован и в Compass.
Одной из главных концепций Compass является модульность и упрощение поддержки стилей, что позволяет сконцентрироваться на стилизации, тратить минимальные усилия на поддержку старых браузеров, поэтому Compass имеет широкий функционал и работает с большинством CSS framework-ов:
— огромное количество встроенных mixins для работы с изображениями, CSS3, шрифтами, лэйаутами;
— утилиты для работы с цветом, спрайтами и стилизации базовых элементов таких как списки, таблицы, линки;
— встроенный CSS reset;
— normalize.css;
— HTML5 Boilerplate, Blueprint, Twitter Bootstrap;
— Grid systems(Fluid 960, Singularity, 960.gs, Susy, Zen grids, и др.)
— Widgets (Fancy Buttons, Sassy Buttons);
— CSS3 PIE;

Cписок Compass mixins по категориям здесь, более полный список Compass модулей здесь.

Как начать с Compass


Compass написан на Ruby и устанавливатся из gem пакет-менеджера (требуется установленный Ruby):

$ gem update --system
$ gem install compass
$ compass create <myproject> /* создаем compass проект */
$ compass watch [path/to/compass-project] /* запускаем Compass просматривать на изменения папку [path/to/compass-project]*/

Scout, Compass.app — для тех кто не любит возиться с комадной строкой.

Установить расширение Compass также довольно просто:

1. Устанавливаем расширение:
$ gem install {extension}

2. Добавить в начало файла config.rb в Compass проекте:
require '{extension}'

3. Подключить расширение:
@import '{extension}';

Давайте рассмотрим преимущества использования Compass в деле.

Автоматически генерируемые спрайты

На этапе разработки довольно часто приходится обновлять спрайты, и в большинстве случаев это рутинное действие производится вручную. Compass предлагает иной подход для генерации спрайтов — маппинг изображений к переменной-спрайту (http://compass-style.org/reference/compass/helpers/sprites/):

/* SCSS */
$arrows: sprite-map("arrows/*.png"); // содержит все изображения в папке arrows

или можно объявить спрайт с нестандартными настройками:

/* SCSS */
/* Возможно несколько способов расположения элементов в спрайте: vertical(по умолчанию), horizontal, diagonal, smart */
$<arrows-dirname>-layout: smart;
$arrows: sprite-map("<arrows-dirname>/*.png",
   $position: 100%,
   $spacing: 25px, /* отступы между изображениями */
   $arrows-arrow-down-spacing: 10px /* отступ в спрайте для <arrows-dirname>/arrow-down.png */
);

Переменную спрайта $icons теперь можно использовать в свойстве background используя миксин sprite:

/* SCSS */
background: sprite($arrows, arrow-down) no-repeat;

/* скомпилированный CSS */
background: url('/<arrows-dirname>/arrow-down.png?12345678') 0 -24px no-repeat;

При добавления нового изображения в папку <arrows-dirname> Compass перегенерирует спрайт, не надо беспокоиться о background-position — Compass подставляет нужные значения для отображения соответсвующих изображений.

Удобно работать со шрифтами и размерами

Compass является удобным инструментом для работы со шрифтами.
В CSS добавление нестандартного шрифта выглядит следующим образом:

/* CSS */
@font-face {
  font-family: "PacificoRegular";
  src: url('[project-root]/fonts/pacifico/Pacifico-webfont.eot');
  src: url('[project-root]/fonts/pacifico/Pacifico-webfont.eot?#iefix') format('eot'),
       url('[project-root]/fonts/pacifico/Pacifico-webfont.woff') format('woff'),
       url('[project-root]/fonts/pacifico/Pacifico-webfont.ttf') format('truetype'),
       url('[project-root]/fonts/pacifico/Pacifico-webfont.svg') format('svg');
}

Пример с использованием встроенного в Compass миксина font-face:

/* SCSS */
@include font-face("PacificoRegular", font-files(
    "pacifico/Pacifico-webfont.woff", 
    "pacifico/Pacifico-webfont.ttf", 
    "pacifico/Pacifico-webfont.svg"
  ), 
  "pacifico/Pacifico-webfont.eot" /* относительный путь к .eot файлу для IE */
);

Работа с em-ами в качестве размера шрифтов не всегда самая приятная в CSS из-за дополнительных математических расчетов, но Compass упрощает работу с ними:

/* SCSS */
$base-font-size: 14px; /* задаем базовый размер */
div{
  @include adjust-font-size-to(28px); /* @adjust-font-size-to() - подсчитывает размер шрифта относительно базового */
  h1 {
    @include adjust-font-size-to(32px, $from-size: 28px); /* параметр $from-size используется при наследовании размеров для корректного подсчета em */
  }
}

/* скомпилированный CSS */
body {
  font-size: 0.875em; // 0.875 * 16px = 14px 
}
div {
  font-size: 2em;   // 2 * 14px = 28px
}
div h1 {
  font-size: 1.143em;// 1.143 * 28px = 32px
}

При работе с em лучше избегать наследования шрифтов, но пример выше показывает, как можно справиться с подобными ситуациями в Compass.
Compass также работает с Vertical Rhythms(подробнее про Vertical Rhythms).

Вендорские префиксы

Встроенные миксины Compass поддерживают генерацию вендорских префиксов. Пример:

/* SCSS */
.round {
    @include border-radius(4px);
}

/* скомпилированный CSS */
.round {
    -moz-border-radius: 4px;
    -webkit-border-radius: 4px;
    -o-border-radius: 4px;
    -ms-border-radius: 4px;
    -khtml-border-radius: 4px;
    border-radius: 4px;
}

Возможно конфигурирование префиксов:

/* SCSS */
$experimental-support-for-mozilla : true; // !default;
$experimental-support-for-webkit : true; // !default;
$support-for-original-webkit-gradients : true; // !default;
$experimental-support-for-microsoft : true; // !default;
$experimental-support-for-opera : false;
$experimental-support-for-khtml : false;

.round {
    @include border-radius(4px);
}

/* скомпилированный CSS */
.round {
    -moz-border-radius: 4px;
    -webkit-border-radius: 4px;
    -ms-border-radius: 4px;
    border-radius: 4px;
}

Градиенты

Для работы с градиентами в Compass есть 2 встроенных миксина linear-gradient и radial-gradient, которые изпользуются в связке с мисксинами background-image или background:

/* SCSS */
@import "compass/css3/images";
@import "compass/utilities/general/hacks";  /* необходимо для @filter-gradient */

.item {
  /* для IE, лучше помещать этот блок перед @linear-gradient или в отдельный файл для IE стилей */
  @include filter-gradient(#aaaaaa, #eeeeee);
  /* Fallback: */
  background: #cccccc;
  /* CSS3 c префиксами вендоров */
  @include background(linear-gradient(top, #aaaaaa, #eeeeee));
}

/* скомпилированный CSS */
.item {
  *zoom: 1;
  -ms-filter: "progid:DXImageTransform.Microsoft.gradient(gradientType=0, startColorstr='#FFAAAAAA', endColorstr='#FFEEEEEE')";
  filter: progid:DXImageTransform.Microsoft.gradient(gradientType=0, startColorstr='#FFAAAAAA', endColorstr='#FFEEEEEE');
  background: #cccccc;
  /* генерация вендорских префиксов */
  background: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, #aaaaaa), color-stop(100%, #eeeeee));
  background: -moz-linear-gradient(top, #aaaaaa, #eeeeee);
  background: -o-linear-gradient(top, #aaaaaa, #eeeeee);
  background: linear-gradient(top, #aaaaaa, #eeeeee);
}

Еще один пример использования градиентов.

Media queries

Для работы с медиа запросами в Compass есть очень полезный модуль Breakpoint. Breakpoint позволяет собрать медиа запросы в одном блоке стилей, что является структурированным и повышает читабельность кода:

/* SCSS */
$small: 543px;
$medium: 794px;
$fence-sm: $small $medium;

#foo {
  content: 'No Media Queries';

  @include breakpoint($small) {
    content: 'Small Media Query';
  }

  @include breakpoint($fence-sm) {
    content: 'Fenced Media Query';
  }
}

/* скомпилированный CSS */
#foo {
  content: 'No Media Queries';
}

@media (min-width: 543px) {
	#foo {
		content: 'Small Media Query';
	}
}

@media (min-width: 543px) and (max-width: 794px) {
	#foo {
		content: 'Fenced Media Query';
	}
}

Примеры более сложных запросов с «И», «ИЛИ» логикой:

/* SCSS */
$print-land: print monochrome (orientation landscape);
$fenced-landscape: screen 321px 543px, handheld (orientation portrait); /* сгенерируется в screen and (min-width: 321px) and (max-width: 543px), handheld and (orientation: portrait) */

#foo {
  @include breakpoint($print-land) {
    content: 'Monochrome Print in Landscape';
  }

  @include breakpoint($fence-landscape) {
    content: 'Screen media type between 300px and 500px or Handheld media type in Portrait';
  }
}

/* скомпилированный CSS */
@media print and (monochrome) and (orientation: landscape) {
	#foo {
		content: 'Monochrome Print in Landscape';
	}
}

@media screen and (min-width: 321px) and (max-width: 543px), handheld and (orientation: portrait) {
	#foo {
		content: 'Screen media type between 321px and 543px or Handheld media type in Portrait';
	}
}


Итоги


image

Compass является мощным инструментом для разработчика, помогает быстро писать эффективный и кросбраузерный CSS код. Также следует отметить, что Compass является полезным инструментом для быстрого прототипирования в браузере и работает в связке с LiveReload.
Не стоит забывать, что Compass это всего лишь инструмент, но его умное использование дает впечатляющие результаты и избавляют от множества рутинной работы.
Сергей Семашко @semashko_sergey
карма
13,0
рейтинг 0,0
Fullstack Javascript программист
Похожие публикации
Самое читаемое Разработка

Комментарии (43)

  • +1
    генерацию несуществующих префиксов так и не исправили, браузеров с border-radius -khtml и -ms не существует.
    • +2
      Для border-radius префиксы вообще не нужны. Для градиентов разве что префикс -webkit-, если не жаль напрячь ими мобильные устройства.
      Вообще префиксы уже отмирают и прошлый век. Браузеры включают экспериментальные свойства за флагом в экспериментальных билдах.
    • +1
      Кто вам сказал, что khtml не существовал?
    • 0
      Компасс вообще очень плохо подходит для добавления префиксов, лучше использовать Автопрефиксер
  • 0
    Наиболее понравившиеся мне вещи в Compass:
    .some { background: image-url('point.jpg'); }
    /* => */
    .some { background: url('public/images/point.jpg?23525345'); }
    

    и возможность встраивания base64 вариаций шрифтов и изображений прямо в CSS-файл, просто указав путь к ним.

    А встроенных в Compass CSS3 миксинов мне не хватало и почти всегда приходилось всю эту лапшу писать вручную. Ещё Compass не обрадовал весьма запоздалой поддержкой source.map, её до сих пор не добавили в основную ветку. К тому же она у меня основательно глючит (правда, возможно, в этом виноват сам SCSS).
    • –1
      Вообще то эти вещи даёт не Compass а сам SASS из коробки.
      • +1
        Гхм, может я чего недопонимаю, поправьте меня, если я не прав, но SASS reference упорно молчит про image-url, в то время как Compass наоборот. Или же вот.
    • 0
      Эту возможность добавляет gem sass-rails, не требуя подключения compass.
      • 0
        Справедливо и обратное. К примеру, у меня нет gem sass-rails, потому, что я не пишу на ruby и, соответственно, не использую рельсы.
    • +1
      Генерация урла и эмбеддинг, это больше к ассетик-генераторам, а вот такие вот штуки compass-style.org/reference/compass/helpers/image-dimensions/ крутые и полезные.
      • 0
        Да да да, совсем забыл про них. Активно этим пользуюсь в связке с image-url. Написав трёхстрочный mixin, подключаю изображение на фон в одну строку, учитывая его (изображения) размеры. Очень удобно. Также удобно при разного рода вычислениях сопутсвующих размеру величин.
  • +2
    Есть ощущение, что Compass за годы своего существования превратился в громоздкую библиотеку, которая никогда не выйдет в версию 1.0.
    Bourbon выглядет на таком фоне крайне привлекательно. В нём выкидывают всё что становится неактуально.
    • 0
      Абсолютно согласен. Пересел на него с Compass. Документация по Bourbon кажется более понятной.
    • +2
      Bourbon, хорошо, но я там с разбегу в документации работы с картинками вообще не заметил: получение ширины/высоты, base64, спрайты.

      Собственно для меня Compass отличается от любого другого набора миксинов-хелперов-стилей, именно расширениями, которые выходят за рамки css. Иначе все это висящие в воздухе синтаксические конструкции, которые в принципе можно написать на чем угодно, да и особых библиотек не надо, некоторые пишут свои миксины да и радуются.
      • 0
        Ещё раз, по картинкам (широта/высота, base64, спрайты) работает sass сам по себе, если у них этого нет в документации, то погуглите, в инете есть информация на данную тему.
        • 0
          Вам бы следовало все-таки привести ссылку, потому что пока мое мнение не изменилось. Сам по себе sass ничего с картинками делать не может и не умеет. Это возможно через sass-расширения* на руби, что собственно и сделано в компасе. Все что нужно можно и самому собрать, выдрав из компаса или найдя в сети, что лучше вопрос спорный и давайте не лезть в эти дебри. Все-таки мой комментарий был про то, что в компасе эти расширения есть, а во многих других библиотеках нет, что делает их лишь синтаксической надстройкой без какого-либо расширения функционала самого sass.

          *Sass предоставляет возможность расширить свою функциональность с использованием руби, это стандартная возможность, именно это я и имею ввиду. В том плане, что это есть в sass и это не хак или хитрость и не заслуга compass.
  • +8
    Мы недавно в довольно крупном проекте перешли на него. Думаю стоит отказаться.

    О наболевшем:
    1. Тормоз. Ребилд после изменения — 5 секунд. Очень выбешивает.
    2. Автобилд глючит. Например при изменении картинки не пересобирает спрайт — нужно изменить какую-нибудь scss.
    3. Нет зависимостей, есть только инклуды. А включает Б и В, Б включает Г, В тоже включает Г, в итоге Г подключен 2 раза. То есть всё-равно нужно иметь некий индекс в котором перечислены все файлы в нужном порядке, а в них никаких подключений.
    4. Метод сериализации compressed — портит стили (вся вёрстка едет, хрен знает где косяк ибо в этой лапше не разберешься), compact — оставляет комменты, пробелы и лишние переводы строк. То есть после него ещё нужно какой-нибудь вменяемый css минификатор использовать.
    5. Не умеет резать на несколько файлов, чтобы не превышать ограничение ие в 4095 правил на файл. Пришлось писать костыли через одно место (там можно повесить хэндлер на запись результирующего файла в котором прочитать его, нарезать и записать)
    6. Руби — тот ещё трансцендентный язык. Если очень хочется именно scss (не compass), то лучше уж заюзать нодовый биндинг к сишной либе. Хотябы работать будет быстро.
    7. При наследовании пытается оптимизировать делая кучу селекторов через запятую с одним правилом внутри. Но плохо получается и в итоге размер не меняется (селекторы-то склонны к располнению, а он их ещё и копипастит), так ещё и из-за нарушения исходного порядка правил предок начинает перегружать свойства потомка, что приводит к ахтунгу и необходимости в потомке повышать вес селекторов или отказываться от наследования. Дебажить такой код тоже не ахти какое удовольствие: из 100500 селекторов применяется только один, а места портянка занимает на пол консоли.
    8. Непрозрачный синтаксис. Нельзя просто написать «display:flex» — нужно помнить все миксины, а если каких нет — пиши их на птичьем языке. Добавить хэши к ссылкам в url тоже нельзя — иди и меняй все url на image-url при каждом обновлении стилей из сторонней либы.
    9. Жесткая архитектура. Чтобы настроить под своё расположение и именование файлов — приходится много плясать с бубном, но многие финты без глубокого погружения в недра вообще не возможны.
    10. При формировании спрайтов гадит в консоль каждый раз когда встречает код генерации ссылки на него. Не редко пропускал из за этого «варнинг» о несуществующей картинке или родителе, с последующим расколбасом на странице.
    11. Умеет вставлять пробелы между картинками в спрайте, но блин нафига первую прижимать к верху, а нижнюю к низу? Из-за этого везде приходится прописывать дополнительно no-repeat.
    12. Есть 1000 и 1 способ как вставить ссылку на картинку из спрайта. И все одинаково неудобные. Ну казалось бы, что сложного в том, чтобы встретив конструкцию «background: url(img.png') 0 0» заменить её на «background: url(sprite.png) 0 -100px»?

    Попробовал тут заюзать упоминаемый недавно rework для процессинга css. Не смог распарсить обычный комментарий. В баг трекере есть лишь ответ 4 месячной давности, что дескать либа css-parser валится на коментах и они ничего сделать не могут.
    • +1
      Это все, конечно, может и имеет место быть, но непонятно, что вы в итоге предлагаете. Во-первых, 6, 7, 8 не является недостатками Compass на самом деле, а 9, 11 и 12 как минимум требуют пояснения, иначе тоже как-то странно.

      Кроме этого может вы можете посоветовать инструмент, который бы мог делать то что делает Compass, но не обладал бы указанными недостатками? Например, если про 2, то в плагин для less, просит вообще вручную, запускать каждый раз команду для сбора спрайта, после изменения картинок.

      Если же рассматривать указанные вами проблемы, то на этот счет могу сказать следующее
      1. Sass c недавней версии начал как-то странно тормозить, на форумах люди просто, откатились до одной из предыдущих версий. Может у вас долгий ребилд связан именно с этим, так как там разница была на порядок.
      4. Было такое, когда в название картинок, элементов списков совпадали с цветами. То ли он из названия в hex формат переводил их то ли наоборот.
      7. Используете миксины, если не хотите чтобы он собирал их в один селектор. Это фича, а не баг.
      8. Вам похоже стоит посмотреть в сторону stylus, там так можно. Про хеши, если можно подробней? Может сейчас поздно, но идею уловить не могу, к сожалению.
      11. Можете пример привести? Потому что пробелы нужны, чтобы картинки не было видно другой, сверху и снизу то вам зачем?
      13. Не понял проблемы, чем вас «background: sprite( $sprite_variable, image_name )» не устраивает?
      Ваш пример «background: url(img.png') 0 0» тоже не идеален, нет способа отличить когда вы хотите поставить картинку из спрайта, а когда просто так
    • 0
      А насколько много у вас стилей? У меня даже 100 KiB файл собирался <= 1 сек. 5 секунд это и в правду слишком много.
      • 0
        А потом перейдёте на Grunt, подключите CSSLint, JSHint и т.д, будет ещё дольше.
        Теперь мощные процы и для верстки нужны :)
        • 0
          Использую вместо Grunt свой собственный велосипед, локально — раздельные файлы, на продакшне — собранные. Проблем со временем не испытываю :) В CSSLint-е не вижу ровным счётом никакого смысла, а JSHint-ом пользуюсь давно, он почти не влияет на производительность, мгновенно срабатывает при сохранении любых изменений :)

          Так что мощные процы для вёрстки нужны вовсе не из-за препроцессоров, а из-за того, что современные сайты — это уйма CSS3 и сложной графики :) Хотя… мой мобильник справляется с ней на ура без тормозов (наверное, потому что android из коробки не умеет флеш :D ).
          • 0
            Grunt, CSSLint и т.д. — незаменимые вещи, когда у вас отдел и нужно чтоб ребята писали код согласно вашим гайдлайнам, чтоб были тесты и т.д.
    • 0
      Спасибо за коммент. Соглашусь, пожалуй, лишь с пункстами 2, 6.

      1. Работаю с Compass тоже на крупном проекте, не сталкивался с проблемой производительности. Основная нагрузка приходиться на генерацию спрайтов, но файлы спрайтов обновляются только при добавлении нового изображения. Обработка scss происходит быстро, хватает времени перезагрузить страницу, а при использовании LiveReload вообще не волнует. Какой объем стилей?
      3. Лучше все-таки все инклуды держать в _base.scss или в одном общем файле, это проблема организации кода.
      4. Интересно, еще не сталкиывался с такой проблемой, но возможно это поможет её решить.
      5. Что мешает создать еще один styles_2nd_part.scss, что сгенерирует дополнительный css файл, и подключить его? В нем соответсвенно подключить общие файлы с инклудами.
      7. Следуйте правилу вложенности селекторов не больше 3-го уровня, @extеnd — не всегда лучший способ наследования, можно использовать сайлент селекторы или миксины. Они предоставляют меньше зависимостей и переопределений.
      8. Не хочется запоминать миксины — пишите как привыкли. Как раз запомнить необходимые миксины и использовать их — лучшее вложение времени, чем писать одни и те же правила много раз.
      9. Формируйте свою архитекуру файлов и подключайте их как Вам удобно.

      Compass — не панацея и не для каждого проекта, в нем есть свои минусы, по мне так они незначительные. Но плюсов его использования я вижу несомненно больше.
      • 0
        Отвечу сразу всем.

        Кода у нас порядка пол мегабайта минифицированного кода. Есть и много каскада и что-то типа бэма. Проект действительно большой (а не «довлльно крупный») и древний — мечта археолога) И не надо мне рассказывать, что единовременно из всего этого нужно от силы пара десятков килобайт — я это всё прекрасно знаю, но приложение одностраничное, а жонглирование динамическими стайлшитами и их генерация с учетом всех зависимостей — тот ещё секс.

        3. Лучше всё-таки не держать никаких _base.scss, index.js и тп, а иметь разделение кода на модули и автоматический учет зависимостей между ними. Ручная пересортировка списка на 100+ файлов — совсем не то, чем хочется заниматься.

        5. Я же программист, мне лень делать руками то, что может сделать программа. Один раз потрахался и теперь файлы нарезаются сами.

        7. Да-да, и не используйте псевдоселекторы и псевдоэлементы) Я бы предпочёл, чтобы @extend функционировал точно также как @mixin — изменял одно конкретное правило, а не разбрасывал свойства одного класса по десятку правил. И это как раз такая «фича», которая скорее баг.

        8. Не для того мы внедрили использование препроцессора, чтобы его не использовать х) АФАЙК, «миксины для стандартных свойств» — это не удобно по сравнению с «пишем по стандарту, а для отстающих генерируется фоллбэк, а для кеширования добавляется хэш к урлу».

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

        11. Если нет no-repeat, то нижняя картинка оказывается сверху верхней. И наоборот.

        13. Копипастой не устраивает. Я всегда хочу картинки засовывать в спрайт. Иначе бы и не использовал компасс, ограничившись scss с примесями. И вообще я не хочу ничего решать в каждом цсс-правиле, я хочу единожды для проекта настроить правило «все картинки до 20кб спрайтуем» и всё.

        6, 7 и 8 — вполне себе недостатки компаса, просто он их унаследовал от scss)

        Резюме: поменяли шило на мыло. Был один геморрой, теперь другой геморрой. Плюс ещё и архитектурная сложность возросла. Нахрен такое надо. Лучше уж заюзать либу типа rework и полностью контролировать процесс, чем использовать такой вот кривой фреймворк.

        • 0
          Вы сами придумали себе кучу геморроя, а вините в этом фреймворк :) Я вот не испытываю ни одной из этих проблем. Во многом, наверное, из-за использования datauri вместо спрайтов, и отсутствия @extend (так и не придумал этой возможности применения). А framework нормальный, просто каждой задаче свой инструмент.
    • 0
      а с чего перешли на Компас?
      • 0
        С нативного CSS

        Мне очень смешно с тех, кто не испытывает проблем с компасом. Вы либо им толком не пользуетесь, либо фанатично игнорируете проблемы. Компас — это очень топорный инструмент (не топор, замечу!). Всё в нём сделано как-то через одно место, но это не видно, пока не попытаешься им воспользоваться.

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

        datauri? С его «шикарной» поддержкой в ие? С разрастанием объёмов в два раза? С лишним временем на декодирование? И пляски с бубном, чтобы одна и та же картинка не дублировалась? Нафиг надо.
        • 0
          я использовал SCSS под Компас на достаточно крупном руби-проекте, из того что вы упоминали сталкивался с 2, 10, 12 + мне сильно мешал компасовский резет стилей. спрайты предпочитал делать вручную. зависимости разрешались вручную, но это вообще не было проблемой и возлагать это на Компас не приходило в голову.
          я не большой любитель процессоров (и даже Stylus on Mac у меня поломался, не собирает эти пресловутые datauri), но у меня не было ощущения что Компас из них самый кривой.
        • 0
          datauri? С его «шикарной» поддержкой в ие?

          Проблем в IE не испытываю. Ибо MHTML + пара финтов для Windows Vista. Давно авсё автоматизировал

          С разрастанием объёмов в два раза?

          gzip? там от силы 5-10%. А число запросов уменьшается практически до 1-го (кроме особо крупных файлов и файлов нарочно исключённых из data-uri

          И пляски с бубном, чтобы одна и та же картинка не дублировалась

          Увы, тут да. Не так чтобы уж создавало кучу проблем, но учитывать это нужно при написании CSS-кода. Куда большие проблемы я вижу когда представляю как организовать быстро-загружаемый сайт со спрайтами. Когда то давным давно от них отказался и с тех пор счастлив :)

          Нафиг надо.

          Сменив шаблонизатор на HAML-подобный и отказавшись от IE7 — вёрстка стала простой, разумной и местами даже приятной. Спасибо SCSS, Compass, DataURI, CSS3, HTML5, Jade. Так что вынужден с вами не согласится.

          А проблемы которые ВЫ испытываете с Compass-ом весьма специфичны. О них уже отписал выше.
  • +1
    image

    Есть мнение, что когда программисты берутся за CSS, появляется LESS, SASS и COMPASS
    • –1
      А кто по-Вашему еще с CSS работает кроме программистов?
      • +1
        Менеджеры проекта, уборщицы, генеральные директора и, иногда, верстальщики.
    • +3
      По вашей картинке выходит, что программисты берут хорошую вешь и портят: делают рукоять с выступами, чтобы натирать руку и тонкая, чтобы ломалась о первый же череп, или ствол; добавляют «фичи», чтобы было хуже транспортировать; делают хрупким, чтобы все знали, что это «тонкая вещь; усложняют лезвие, чтобы потом хрен кто смог сделать аналогичное.

      Это шутка :) Почти.
      • +1
        Я ни разу не сказал, что одно хуже другого. Топор справа явно магический, укреплённый волшебством. Зачем такому топору массивность? Он разит врага одним касанием :)

        Смысл картинки в том, что для достижения цели люди, пришедшие в CSS из программирования, улучшают свой инструмент, а не свои навыки. И то и другое приводит к одной цели, а значит равнозначно.

        Скажу честно, я не пользуюсь ничем подобным хотя много раз пытался. Основные изменения в CSS происходят в момент его создания или рефакторинга. Далее — мелкие правки. Кроме того, IDE + emmet прекрасно справляется с дополнениями, префиксами, конвертациями в base64 и проч.
  • 0
  • 0
    Кто там выше искал альтернативу? Их сейчас как грибов, может кому будет интересно сделать сводное сравнение:

    и ещё пачка

    Да, ещё эпический More CSS >:-]
    • 0
      Забыли ещё Autoprefixer
    • 0
      More CSS потрясающая вещь :)
    • +1
      Bourbon — набор mixin'ов для sass. Для меня самым подходящим на сегодня выглядит — sass + bourbon; а на завтра — stylus.
  • 0
    инструмент для эффективной работы с CSS
    помогает быстро писать эффективный <...> CSS код

    А как вы оцениваете эффективность?

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

    P.S.
    Опыт небольшой — 2 проекта, несколько человеко-месяцев на LESS, теперь приглядываемся к SCSS, но я как ПМ пока не очень понимаю смысл этих движений.
    • +1
      А как вы оцениваете эффективность?


      Для меня показатель эффективности, это когда можно с инструментом написать более качественный код и быстрее, чем без него. SASS + Compass автоматизируют рутинные задачи и имеют много полезных хелперов. Зачем изобретать что-то заново, если оно уже есть и протестированно сообществом? Можно, конечно, и c помощью чистого CSS умудриться написать приличный проект, но Вы, скорее всего, будете каким-нибудь образом пытаться синтезировать то, что уже есть в SASS + Compass. И огромный минус чистого CSS — дубликация кода со всеми вытекающими последствиями. На более менее приличном проекте всегда есть смысл использовать CSS препроцессор.

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


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

      «Задокументированные стандарты по производительности и архитектуре в ваших стилях» — нужно учитывать размеры/сложность проекта, целевые браузеры/устройства. Хороший пример для респонсив сайтов: github.com/Snugug/north. Если уже есть стандарты на уровне проекта/компании — хорошо, если нету — хороший шанс начать и по-тихоньку выстроить сообщество внутри компании.

      «Настроенное окружение» — зависит от проекта/размера команды. чем больше команда, тем больше Вам нужно обезопасить себя от головняка, автоматизировать рутинные процессы, настроить grunt + JS/CSS lint (пускай код стайл проверяется автоматически), minifier и concat. Очень приятно ощущать разницу до автоматизации и после.

      «грамотный фронтенд лид» — который в состоянии поднять и настроить окружение и процесс и будет следить за соблюдением стандартов.
      К сожалению, без этих моментов проект ждет довольно хаотичное состояние.

      • 0
        Для меня показатель эффективности, это когда можно с инструментом написать более качественный код и быстрее, чем без него.

        Не подумайте, что я придираюсь, но на хабре полно статей «качество кода vs. скорость» (в других хабах). Как программист, знаю, что ситуация «win-win» возникает только при определённых условиях (в долгосрочной перспективе, при отсутствии кардинальных изменений в ТЗ и т.д.).

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

        Это всё круто. Но в жизни так выходит, что на проекте, который уже много лет в топ-500 alexa.com, до сих пор атмосфера бутстрэппинга. Правки в дизайн вносятся в таком режиме, когда некогда думать о высоких материях стандартах. Но ок, попробую поднять этот вопрос. Пойду поищу грамотного фронтенд лида. :)
        • 0
          Не подумайте, что я придираюсь, но на хабре полно статей «качество кода vs. скорость» (в других хабах). Как программист, знаю, что ситуация «win-win» возникает только при определённых условиях (в долгосрочной перспективе, при отсутствии кардинальных изменений в ТЗ и т.д.).

          Скорость можно потерять только при переходе на SASS + Compass и настройке окружения, CSS файл при переименовании в .scss будет компилироваться без проблем. По сути, этот еще тот же CSS, только теперь появляется много возможностей как: выстроить необходимую структуру папок, манипуляции с изображениями, Grids где хотите и как хотите, снижение дубликации кода и тд. А за качеством кода нужно чтобы кто-то следил и знал, что это такое и как добиться.

          Это всё круто. Но в жизни так выходит, что на проекте, который уже много лет в топ-500 alexa.com, до сих пор атмосфера бутстрэппинга. Правки в дизайн вносятся в таком режиме, когда некогда думать о высоких материях стандартах. Но ок, попробую поднять этот вопрос. Пойду поищу грамотного фронтенд лида. :)

          вспомнил поговорку в тему — «Точить некогда, мне пилить надо». А в вообще, понимаю :) Когда сроки горят — не до этого. Лучший эффект, конечно, когда все настроено в начале проекта. Удачи в поисках!

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