войти зарегистрироваться

Вкусный CSS: Sass + Compass

Что такое Haml/Sass?


Haml (xHTML Abstraction Markup Language) это язык разметки для упрощённой генерации xHTML. В свою очередь эквивалент Haml для css — это Sass (Syntactically Awesome StyleSheets).

В данной статье я расскажу чем примечателен Sass. И с помощью чего sass-файл можно скомпилировать в css.

И так начнем.

Вкустности SASS.


Sass имеет ряд преимуществ перед css. Начну с @import. Сам по себе @import не является преимуществом sass перед css, но его использование становится еще более оправданным потому, что возможно подключать по мимо sass-файла c ресетами и sass-файла c типографикой, sass-файл с «константами» (об этом ниже подробнее), четвертый sass-файл с «абстрактными классами» (об этом так же ниже). Потом это все пакуется в одну готовую css-ку. Что избавляет от работы с огромным кодом.

И так константы (constants). Допустим по всему HTML документу к некоторым классам применим некий css параметр, и вдруг нам понадобилось его изменить. Скажем выделение разных элементов четырех пиксельным border голубого цвета. И нужно это заменить на двухпиксельный. Красного. Даже если он был всего лишь применим к трем классам (на деле же это ) это уже заставляет тратить дополнительное время. В таких случаях целесообразно использовать константы применимые сразу к нескольким элементам.

Пример:

!main_color = #00ff00

#main
  :color = !main_color
  :p
    :background-color = !main_color
    :color #000000


«Абстрактные классы» (Mixins). Это набор параметров изначально ни к какому элементу не принадлежащий. Но его в любой момент можно «приплюсовать» к тому или иному набору параметров элемента или класса. Что порой так же бывает удобно.

Пример:

=large-text
  :font
    :family Arial
    :size 20px
    :weight bold
  :color #ff0000

.page-title
  +large-text
  :padding 4px
  :margin
    :top 10px


Арифметика. Так же один из плюсов sass является арифметика. Это и вычитание цветов друг из друга, и деление длин объектов, в общем всего-всего. Таким образом цветовую схему можно вообще задать одним цветом, а остальные задать арифметикой. В итоге меняем один цвет и оп ля-ля и у нас новая цветовая схема.

Пример:
!main_width = 10px
!unit1 = 5px
!bg_color = #a5f39e

#main
  :background-color = !bg_color
  p
    :background-color = !bg_color + #202020
    :width = !main_width + !unit1


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

Compass css framework.


Теперь вопрос как это все скомпилировать в css если мы не собираемся разрабатывать под Ruby,
Не так давно вышел очень удобный css framework compass, как раз таки работающий под sass и позволяющий компилировать sass в css.

Мы создаем compass-проект на основе одного из этих css фрэймворков и начинаем работу, а compass автоматически следит за изменениями sass-файлов и компилирует их в css.

Так же compass поддерживает 3 популярных фрэймворка:
  • BluePrint
  • YUI
  • 960gs

Вот видео о данном взаимодействии sass и compass.

UPD: Поправил текст про @import

комментарии (74)

  • Mixins != абстрактные классы.

    А вообще интересно, как в CSS реализовать какую-нибудь абстракцию… А то уже запарило одни и те же фиксы/layout'ы писать по многу раз.
    • на некотрый своих проектах использую php в css для чего просто обратчику php подсовываю расширение css
      • еще можно так header('Content-type: text/css'); и расширение оставит php
      • а кеширование Вы в PHP поддерживаете или заставляете пользователей каждый раз скачивать Ваш css-файл?
        • пока этот проект в альфе глубокой… в паблике нет
    • Сделайте простой интрумент на основе любого шаблонизатора. Я сделал когда-то себе банальный «молоток» на базе TT и perl и постоянно пользуюсь. Потом добавил строчку кода, что бы всё моё добро компилировалось перед запуском (либо при сохранении).
  • хитро)
  • Мягко поправлю: и в языке CSS также есть @import "имяФайла.css" так что импорт не такая уж и новинка.
    • Плюсодин, как говорится обычно, однако saas удобнее с импортом тем, что при грамотном использовании, он будет выплевывать клиенту 1 цсс файл, который клиентский браузер закеширует.
      • Автор это и имел ввиду. Sass тем и хорош. А если еще в тандеме с Compass…
        • Согласно вашего замечания… Я откорректировал абзац про @import. И на этот раз выразил свои мысли более правильно и конкретно.
    • Кстати, и подобие Mixins в CSS тоже есть, только в другом ключе: <element class=«class1 class2 ...» >
      • Вы имеете ввиду присвоение одному элементу нескольких классов?
      • Это на уровне HTML а не CSS. Тут как раз говориться о другом.
        • Вот вот, я тож думаю что тут html попахивает)
          • тут просто несколько все иначе, и на мой взгляд удобнее.
  • всякие препроцессоры — эт, конечно, хорошо, но как отлаживать продукт их жизнедеятельности?
    я себе сделал так: по умолчанию все цсс-ки собираются в один файл, жмутся, все дела, но в режиме отладки — все цсс-ки подключаются по отдельности, в результате чего в отладчике на против каждого правила пишется имя файла и номер строки соответствующие действительности в исходниках.
    • >но как отлаживать продукт их жизнедеятельности?
      Наверное так же как и любой другой продукт препроцессора/компилятора/интерпретатора.
      HTML сейчас в чистом виде можно только в исходниках страницы увидеть — все пропускается через шаблонизаторы да еще и в несколько проходов.
      • ага, мало гемора с хтмл, так давайте ещё и цсс с яваскриптом сделаем также >_<

        вообще говоря, проблему бэктрейса хтмл можно было бы решить средстами шаблонизатора, который бы добавлял спец-аттрибут, но… нормальных шаблонизаторов вообще кот наплакал, а что б ещё и такое счастье…
        • > мало гемора с хтмл
          Ну а как без шаблонизаторов? Никак. 2009 год все-таки. Чистую статику сейчас не встретить.

          Хотя для CSS никакого геморроя не вижу. Применение подобных средств только повышает читаемость кода и сокращает его объем. Соответственно и ошибок должно быть меньше. При условии что препроцессор не начнет вносить свои ошибки.

          Переменные в CSS напрашивались сами собой. Но их и в CSS3 нет. Хотя WebKit их давно ввел в оборот disruptive-innovations.com/zoo/cssvariables/
          Каскадирование в стиле HSS/SASS- тоже существенно облегчает читабельность кода, но хрен дождешься от идиотов из w3c.

          • необходимость шаблонизации хтмл обоснована необходимостью вставки динамических данных. для цсс такой необходимости нет.

            от каскадирования больше проблем чем пользы: гигантские отступы, жёсткая привязка к селектору родителя, «разбрасывание» частей селектора по разным концам файла.
            • необходимость того или иного инструментария вытекает из сложности задачи.
              За последний год сообщения о cssvariables/HSS/SASS слишком часто стали появляться. Через некоторое время количество явно перерастет в качество.
              Хотя может получится как с шаблонизаторами — вырастет зоопарк самоделок + каждый броузер обзаведется своим собственным прибабахом.
              • не может, а так и будет =(
                • С другой стороны бардак имеет свои плюсы. Чем больше разножопица — тем больше зарплата специалистов и есть повод для холивара на досуге.

                  Опера — маздай!
  • Познавательно!
  • НЛО прилетело и опубликовало эту надпись здесь.
  • про арифметику интересно, а вот «константы» и «Абстрактные классы» — так это можно решить средствами CSS подсовывая в HTML в один параметр class несколько разных из CSS. Мне кажеться разницы от этого никакой, что в самом файле стилей приплюсовать, что в HTML написать 2 класса подряд… К примеру:
    CSS:
    .main_border {
    border: 10px solid #ff0000;
    }
    .main_color {
    color: #00ff00;
    }
    HTML:
    <div class="main_border main_color">bla bla</div>
    соответственно этим мы решаем первые 2 пункта…
    поправьте если я не прав
    • ой, ё, по поводу констант погорячился, не досмотрел :)
      по поводу «Абстрактных классов» вопрос открыт
    • выше уже говорили об этом… я соглашусь что можно, но стоит ли? это образует огромное количество классов как в HTML так и в CSS, что в принципе имхо не есть хорошо, дык от них потом еще и в глазаx рябит))) а тут на выходе получится одна css в которой минимум классов и все «абстрактные классы» и «константы» заменены на параметры с определенными значениями.
      • вот вот хотел сказать что вы привели лишь подобие mixins, а констант что то не увидел. ну да ладно в прочем. обсуждаем.
      • почему это огромное кол-во? ровно столько же.
        можно в CSS это вынести в отдельнй файл (только для «абстрактных» классов)…
        в принципе велосипед тот-же только понавороченей :)
        на самом деле я только за, а то CSS всетаки убогий и полного наследования ой как не хватает да и много чего не хватает.
        • во первых лишние классы в html.

          и как я уже сказал в итоговой css абстрактные классы будут заменены на присвоенные им параметры и значения.

          пс: может велосипед, но велосипеды тоже не все одинаковые.
          • любой подобный велосипед требует серверного времени и внимания = потеря в производительности. для небольших проектов, которые никогда не вырастут — может и интересно, для интересных проектов — не стоит овчинка выделенки
            • безусловно в использовании есть свои нюансы. Но никто ведь не говорит что этим нужно пользоваться а про css забыть… ни в коем разе.
              Это пища для размышлений для вас и для меня.
    • Прописывая классы, описывающие отображение в HTML, мы нарушаем семантичность и отделение содержание от представления.
      Класс по-хорошему должен отражать, чем является элемент, а не как его показывать.
      • гм… а разве не *имя тэга* должно отражать /чем/ является элемент? ;-)
        классы для того и были введены, чтобы можно было указывать _как_ отображать элемент независимо от его семантики.
        • Это уже идеальный случай. В XML-то пожалуйста, а вот в том html, на котором приходится писать, возможностей, кроссбраузерности и набора стандартных тегов не всегда хватает. Да и продвинутые селекторы типа «прямой потомок» или выборка по значению свойства не работают в IE6, а их можно заменить только классами. Это раз.

          Во-вторых, да, имя тега показывает что это за элемент, а класс его классифицирует. Но не по отображению, а по назначению. Вот эта ссылка внешняя, вон тот пункт меню активный, вон тот комментарий непрочитанный (а не «синенький»), вон тот div.item — контейнер для карточки чего-либо. Так как он в списке товаров, допустим, #tovars, то его показать так-то, а h4 в нём так-то, а ссылочку в нём вправо прибить, а p.short-description показать меленьким, а img прибить влево и бордюром обвести. А если совершенно такой же div.item положить в другой #контейнер, допустим, боковую панель спецпредложений, то правила могут быть другие. А серверу тем временем один и тот же шаблон в совершенно разных задачах.
          • 1. xhtml как бэ не вчера появился…

            2. нет, классы не для этого. для этого предназначены аттрибуты. checked=«checked», а не class=«checked» другое дело, что ие6 вынуждает использовать для этого классы…

            3. одна вёрстка для любых случаев — это либо утопия, либо жестокое самоограничение.
            • 1. И часто ли вы видели вёрстку с изменённым DTD?
              2. Вот именно, что ие6, я это и пишу. Плюс свои аттрибуты нам опять же придумывать так просто не дают.
              3. Совсем нет. Очень удобно порой скопипастить HTML из одного места в другое и лишь переписать css.
              • 1. каждый день её делаю ;-)
                2. кто не даёт? скажи мне — я с ним разберусь B-)
                3. ещё удобней — не копипастить ничего ;-)
                • Ок, ушёл учить матчасть.
  • все конечно классно, а как писать там фиксы для браузеров? например только для ие, чонить в стиле _height: 1%
    Там можно так?
    • а чем вас не устраивает?
      • блин, хабр скушал:( Я имел ввиду такую конструкцию: !--[if IE]> ![endif]-->
        • когда это заработает для оперы — я тя расцелую XD
          а если серьёзно — я очень не люблю, когда правила для одного класса раскиданны по десяти файлам…
          • Ну в основном у всех проблем с ИЕ :) ну на счет раскиданности соглашусь:)
            • у меня с ие проблем нет, ибо экспрешшены творят чудеса ;-) а вот с этой кривущей оперой…
              • +1 И не только expression. Глюки ie стократно окупаются большим числом вариантов обхода и хорошей изученностью. В отличие от долбанной Оперы.
          • www.webdevout.net/css-hacks#in_css-selectors

            Есть цсс-хаки, прекрасно проходящие валидацию, и позволяющие довольно точно таргетнуть браузер.
            • речь шла об условных комментах…
              • Верхний каммент в треде вроде про цсс-хаки…
                я предложил альтернативу, которая пашет в и опере…
                • ты предложил валидные цсс-хаки…
                  при этом они не так удобны, как например _height: 1%
                  к тому же оперу нужно точнее хачить, ибо 9.0, 9.1, 9.2 и 9.5 имеют свои, уникальные баги…
    • можно сделать отдельный css для ie и импортировать в нее основную css, как делает blueprint например… ну или дописать хак в готовую css…
      • ну цсс как бы формируется на лету и поэтому он, по идее, будет перезатираться, а использовать условные коментарие я не очень привык, ибо хак удобней писать в контексте селектора, а не где то там на странице сайта, или в отдельной цсске.
    • ой ) кстати _height: 1% легко делаееца
      :_height: 1%

      :-)
  • HSS в первой версии мне кажется значительно вкуснее.

    PS в гугле не просто найти ncannasse.fr/projects/hss
    • посмотрим))
    • расскажете об его ингредиентах и рецепте приготовления?
      • в принципе по ссылке все написано.

        пока еще это просто утилита-транслятор из HSS в CSS, т.е. на входе задаем hss файл, а на выходе получаем css.

        В отличии от CSS в HSS есть:
        — переменные;
        — блоки переменных;
        — вложенные блоки;

        В процессе трансляции проверяет синтаксис.

        Для работы требуется neko (http://nekovm.org) и как следствие кросс-платформенная штуковина.
        • а в отличие от sass что есть? то есть чем он все таки «вкуснее»?
  • #header
      background: #ccc
      border= !width "solid" #777


    Мне одного взгляда на такой синтаксис хватило, чтоб понять, что автор sass не сильно парился об интуитивности языка.
    Использовать не хочется…
    • Никому здесь не кажется, что можно было бы и поднапрячься и сделать унифицированный синтаксис. Вот такой:

      #header
        background: #ccc
        border: !width solid #777

      • А ещё лучше оставить основу от CSS, имхо скобки никому не мешали.
      • #header
        :background-color #ccc
        :border = !width solid #777


        так все будет гуд.
        просто переносить желательно ":" за параметр и если используем константу арифметику то ставим "="
        • забыл отступ вставить перед 2 и 3 строками((
  • Синтаксис уродливый.
    • у sass?)))))
    • как правило такие резкие высказывания надо хотя бы прокомментировать.
      • Код:

        .page-title
        +large-text
        :padding 4px
        :margin
        :top 10px

        Не понимаю, честно говоря, зачем было придумывать синтаксис с нуля. Ведь есть привычка ставить двоеточие после аттрибута, а не до, и будут постоянно возникать противоречия. По моему неудобно. А у кого то не только привычка, но и сниппеты, система подстветки синтаксиса — и все это конфликтует с новым синтаксисом.

        По хорошему — надо было расширять css а не заменять. Ну и синтаксис типа !a = value мне тоже не нравится, так как лишние значки вносят доп. сложность (вспомните Перл с его зуболомными сокращениями к примеру). Нигде так присваивание не делается (ну еслитолько в каком нибудь малоизвестном языке) и это плохо. Например, в php для переменных используют $ — почему бы не использвоть привычный символ?
        • спасибо за комментарии)) но почему там не $ и почему двоеточие перед этого уж я не знаю…
        • Вы правы, даже по этой единственной причине мало кто решится использовать это решение.
  • А редакторы под это дело есть? С подсветкой синтаксиса, автокомплитом и прочими радостями…

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

    А к хамлу я давно присматриваюсь, мне он кажется весьма удобным.
    • TextMate, NetBeans. Для них есть хорошая подсветка.
    • ну видишь кому как)) меня вот хамл не особо порадовал… а вот в sass увидел кое-что интересное.
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.