Что такое 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 популярных фрэймворка:
Вот видео о данном взаимодействии sass и compass.
UPD: Поправил текст про @import
комментарии (74)
А вообще интересно, как в CSS реализовать какую-нибудь абстракцию… А то уже запарило одни и те же фиксы/layout'ы писать по многу раз.
я себе сделал так: по умолчанию все цсс-ки собираются в один файл, жмутся, все дела, но в режиме отладки — все цсс-ки подключаются по отдельности, в результате чего в отладчике на против каждого правила пишется имя файла и номер строки соответствующие действительности в исходниках.
Наверное так же как и любой другой продукт препроцессора/компилятора/интерпретатора.
HTML сейчас в чистом виде можно только в исходниках страницы увидеть — все пропускается через шаблонизаторы да еще и в несколько проходов.
вообще говоря, проблему бэктрейса хтмл можно было бы решить средстами шаблонизатора, который бы добавлял спец-аттрибут, но… нормальных шаблонизаторов вообще кот наплакал, а что б ещё и такое счастье…
Ну а как без шаблонизаторов? Никак. 2009 год все-таки. Чистую статику сейчас не встретить.
Хотя для CSS никакого геморроя не вижу. Применение подобных средств только повышает читаемость кода и сокращает его объем. Соответственно и ошибок должно быть меньше. При условии что препроцессор не начнет вносить свои ошибки.
Переменные в CSS напрашивались сами собой. Но их и в CSS3 нет. Хотя WebKit их давно ввел в оборот disruptive-innovations.com/zoo/cssvariables/
Каскадирование в стиле HSS/SASS- тоже существенно облегчает читабельность кода, но хрен дождешься от идиотов из w3c.
от каскадирования больше проблем чем пользы: гигантские отступы, жёсткая привязка к селектору родителя, «разбрасывание» частей селектора по разным концам файла.
За последний год сообщения о cssvariables/HSS/SASS слишком часто стали появляться. Через некоторое время количество явно перерастет в качество.
Хотя может получится как с шаблонизаторами — вырастет зоопарк самоделок + каждый броузер обзаведется своим собственным прибабахом.
Опера — маздай!
CSS:
.main_border {
border: 10px solid #ff0000;
}
.main_color {
color: #00ff00;
}
HTML:
<div class="main_border main_color">bla bla</div>
соответственно этим мы решаем первые 2 пункта…
поправьте если я не прав
по поводу «Абстрактных классов» вопрос открыт
можно в CSS это вынести в отдельнй файл (только для «абстрактных» классов)…
в принципе велосипед тот-же только понавороченей :)
на самом деле я только за, а то CSS всетаки убогий и полного наследования ой как не хватает да и много чего не хватает.
и как я уже сказал в итоговой css абстрактные классы будут заменены на присвоенные им параметры и значения.
пс: может велосипед, но велосипеды тоже не все одинаковые.
Это пища для размышлений для вас и для меня.
Класс по-хорошему должен отражать, чем является элемент, а не как его показывать.
классы для того и были введены, чтобы можно было указывать _как_ отображать элемент независимо от его семантики.
Во-вторых, да, имя тега показывает что это за элемент, а класс его классифицирует. Но не по отображению, а по назначению. Вот эта ссылка внешняя, вон тот пункт меню активный, вон тот комментарий непрочитанный (а не «синенький»), вон тот div.item — контейнер для карточки чего-либо. Так как он в списке товаров, допустим, #tovars, то его показать так-то, а h4 в нём так-то, а ссылочку в нём вправо прибить, а p.short-description показать меленьким, а img прибить влево и бордюром обвести. А если совершенно такой же div.item положить в другой #контейнер, допустим, боковую панель спецпредложений, то правила могут быть другие. А серверу тем временем один и тот же шаблон в совершенно разных задачах.
2. нет, классы не для этого. для этого предназначены аттрибуты. checked=«checked», а не class=«checked» другое дело, что ие6 вынуждает использовать для этого классы…
3. одна вёрстка для любых случаев — это либо утопия, либо жестокое самоограничение.
2. Вот именно, что ие6, я это и пишу. Плюс свои аттрибуты нам опять же придумывать так просто не дают.
3. Совсем нет. Очень удобно порой скопипастить HTML из одного места в другое и лишь переписать css.
2. кто не даёт? скажи мне — я с ним разберусь B-)
3. ещё удобней — не копипастить ничего ;-)
Там можно так?
а если серьёзно — я очень не люблю, когда правила для одного класса раскиданны по десяти файлам…
Есть цсс-хаки, прекрасно проходящие валидацию, и позволяющие довольно точно таргетнуть браузер.
я предложил альтернативу, которая пашет в и опере…
при этом они не так удобны, как например _height: 1%
к тому же оперу нужно точнее хачить, ибо 9.0, 9.1, 9.2 и 9.5 имеют свои, уникальные баги…
:_height: 1%
:-)
PS в гугле не просто найти ncannasse.fr/projects/hss
пока еще это просто утилита-транслятор из HSS в CSS, т.е. на входе задаем hss файл, а на выходе получаем css.
В отличии от CSS в HSS есть:
— переменные;
— блоки переменных;
— вложенные блоки;
В процессе трансляции проверяет синтаксис.
Для работы требуется neko (http://nekovm.org) и как следствие кросс-платформенная штуковина.
#headerbackground: #ccc
border= !width "solid" #777
Мне одного взгляда на такой синтаксис хватило, чтоб понять, что автор sass не сильно парился об интуитивности языка.
Использовать не хочется…
#headerbackground: #ccc
border: !width solid #777
так все будет гуд.
просто переносить желательно ":" за параметр и если используем константу арифметику то ставим "="
.page-title
+large-text
:padding 4px
:margin
:top 10px
Не понимаю, честно говоря, зачем было придумывать синтаксис с нуля. Ведь есть привычка ставить двоеточие после аттрибута, а не до, и будут постоянно возникать противоречия. По моему неудобно. А у кого то не только привычка, но и сниппеты, система подстветки синтаксиса — и все это конфликтует с новым синтаксисом.
По хорошему — надо было расширять css а не заменять. Ну и синтаксис типа !a = value мне тоже не нравится, так как лишние значки вносят доп. сложность (вспомните Перл с его зуболомными сокращениями к примеру). Нигде так присваивание не делается (ну еслитолько в каком нибудь малоизвестном языке) и это плохо. Например, в php для переменных используют $ — почему бы не использвоть привычный символ?
Просто развращенный удобными средами разработки, облегчающими написание кода, уже не хочу возвращаться к блокнот-стайл.
А к хамлу я давно присматриваюсь, мне он кажется весьма удобным.