Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
генерацию несуществующих префиксов так и не исправили, браузеров с border-radius -khtml и -ms не существует.
Кто вам сказал, что khtml не существовал?
Компасс вообще очень плохо подходит для добавления префиксов, лучше использовать Автопрефиксер
Наиболее понравившиеся мне вещи в Compass:
и возможность встраивания base64 вариаций шрифтов и изображений прямо в CSS-файл, просто указав путь к ним.
А встроенных в Compass CSS3 миксинов мне не хватало и почти всегда приходилось всю эту лапшу писать вручную. Ещё Compass не обрадовал весьма запоздалой поддержкой source.map, её до сих пор не добавили в основную ветку. К тому же она у меня основательно глючит (правда, возможно, в этом виноват сам SCSS).
.some { background: image-url('point.jpg'); }
/* => */
.some { background: url('public/images/point.jpg?23525345'); }
и возможность встраивания base64 вариаций шрифтов и изображений прямо в CSS-файл, просто указав путь к ним.
А встроенных в Compass CSS3 миксинов мне не хватало и почти всегда приходилось всю эту лапшу писать вручную. Ещё Compass не обрадовал весьма запоздалой поддержкой source.map, её до сих пор не добавили в основную ветку. К тому же она у меня основательно глючит (правда, возможно, в этом виноват сам SCSS).
Вообще то эти вещи даёт не Compass а сам SASS из коробки.
Гхм, может я чего недопонимаю, поправьте меня, если я не прав, но SASS reference упорно молчит про image-url, в то время как Compass наоборот. Или же вот.
Эту возможность добавляет gem sass-rails, не требуя подключения compass.
Генерация урла и эмбеддинг, это больше к ассетик-генераторам, а вот такие вот штуки compass-style.org/reference/compass/helpers/image-dimensions/ крутые и полезные.
Есть ощущение, что Compass за годы своего существования превратился в громоздкую библиотеку, которая никогда не выйдет в версию 1.0.
Bourbon выглядет на таком фоне крайне привлекательно. В нём выкидывают всё что становится неактуально.
Bourbon выглядет на таком фоне крайне привлекательно. В нём выкидывают всё что становится неактуально.
Абсолютно согласен. Пересел на него с Compass. Документация по Bourbon кажется более понятной.
Bourbon, хорошо, но я там с разбегу в документации работы с картинками вообще не заметил: получение ширины/высоты, base64, спрайты.
Собственно для меня Compass отличается от любого другого набора миксинов-хелперов-стилей, именно расширениями, которые выходят за рамки css. Иначе все это висящие в воздухе синтаксические конструкции, которые в принципе можно написать на чем угодно, да и особых библиотек не надо, некоторые пишут свои миксины да и радуются.
Собственно для меня Compass отличается от любого другого набора миксинов-хелперов-стилей, именно расширениями, которые выходят за рамки css. Иначе все это висящие в воздухе синтаксические конструкции, которые в принципе можно написать на чем угодно, да и особых библиотек не надо, некоторые пишут свои миксины да и радуются.
Ещё раз, по картинкам (широта/высота, base64, спрайты) работает sass сам по себе, если у них этого нет в документации, то погуглите, в инете есть информация на данную тему.
Вам бы следовало все-таки привести ссылку, потому что пока мое мнение не изменилось. Сам по себе sass ничего с картинками делать не может и не умеет. Это возможно через sass-расширения* на руби, что собственно и сделано в компасе. Все что нужно можно и самому собрать, выдрав из компаса или найдя в сети, что лучше вопрос спорный и давайте не лезть в эти дебри. Все-таки мой комментарий был про то, что в компасе эти расширения есть, а во многих других библиотеках нет, что делает их лишь синтаксической надстройкой без какого-либо расширения функционала самого sass.
*Sass предоставляет возможность расширить свою функциональность с использованием руби, это стандартная возможность, именно это я и имею ввиду. В том плане, что это есть в sass и это не хак или хитрость и не заслуга compass.
*Sass предоставляет возможность расширить свою функциональность с использованием руби, это стандартная возможность, именно это я и имею ввиду. В том плане, что это есть в sass и это не хак или хитрость и не заслуга compass.
Мы недавно в довольно крупном проекте перешли на него. Думаю стоит отказаться.
О наболевшем:
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. Тормоз. Ребилд после изменения — 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 валится на коментах и они ничего сделать не могут.
Это все, конечно, может и имеет место быть, но непонятно, что вы в итоге предлагаете. Во-первых, 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» тоже не идеален, нет способа отличить когда вы хотите поставить картинку из спрайта, а когда просто так
Кроме этого может вы можете посоветовать инструмент, который бы мог делать то что делает 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» тоже не идеален, нет способа отличить когда вы хотите поставить картинку из спрайта, а когда просто так
А насколько много у вас стилей? У меня даже 100 KiB файл собирался <= 1 сек. 5 секунд это и в правду слишком много.
А потом перейдёте на Grunt, подключите CSSLint, JSHint и т.д, будет ещё дольше.
Теперь мощные процы и для верстки нужны :)
Теперь мощные процы и для верстки нужны :)
Использую вместо Grunt свой собственный велосипед, локально — раздельные файлы, на продакшне — собранные. Проблем со временем не испытываю :) В CSSLint-е не вижу ровным счётом никакого смысла, а JSHint-ом пользуюсь давно, он почти не влияет на производительность, мгновенно срабатывает при сохранении любых изменений :)
Так что мощные процы для вёрстки нужны вовсе не из-за препроцессоров, а из-за того, что современные сайты — это уйма CSS3 и сложной графики :) Хотя… мой мобильник справляется с ней на ура без тормозов (наверное, потому что android из коробки не умеет флеш :D ).
Так что мощные процы для вёрстки нужны вовсе не из-за препроцессоров, а из-за того, что современные сайты — это уйма CSS3 и сложной графики :) Хотя… мой мобильник справляется с ней на ура без тормозов (наверное, потому что android из коробки не умеет флеш :D ).
Спасибо за коммент. Соглашусь, пожалуй, лишь с пункстами 2, 6.
1. Работаю с Compass тоже на крупном проекте, не сталкивался с проблемой производительности. Основная нагрузка приходиться на генерацию спрайтов, но файлы спрайтов обновляются только при добавлении нового изображения. Обработка scss происходит быстро, хватает времени перезагрузить страницу, а при использовании LiveReload вообще не волнует. Какой объем стилей?
3. Лучше все-таки все инклуды держать в _base.scss или в одном общем файле, это проблема организации кода.
4. Интересно, еще не сталкиывался с такой проблемой, но возможно это поможет её решить.
5. Что мешает создать еще один styles_2nd_part.scss, что сгенерирует дополнительный css файл, и подключить его? В нем соответсвенно подключить общие файлы с инклудами.
7. Следуйте правилу вложенности селекторов не больше 3-го уровня,
8. Не хочется запоминать миксины — пишите как привыкли. Как раз запомнить необходимые миксины и использовать их — лучшее вложение времени, чем писать одни и те же правила много раз.
9. Формируйте свою архитекуру файлов и подключайте их как Вам удобно.
Compass — не панацея и не для каждого проекта, в нем есть свои минусы, по мне так они незначительные. Но плюсов его использования я вижу несомненно больше.
1. Работаю с Compass тоже на крупном проекте, не сталкивался с проблемой производительности. Основная нагрузка приходиться на генерацию спрайтов, но файлы спрайтов обновляются только при добавлении нового изображения. Обработка scss происходит быстро, хватает времени перезагрузить страницу, а при использовании LiveReload вообще не волнует. Какой объем стилей?
3. Лучше все-таки все инклуды держать в _base.scss или в одном общем файле, это проблема организации кода.
4. Интересно, еще не сталкиывался с такой проблемой, но возможно это поможет её решить.
5. Что мешает создать еще один styles_2nd_part.scss, что сгенерирует дополнительный css файл, и подключить его? В нем соответсвенно подключить общие файлы с инклудами.
7. Следуйте правилу вложенности селекторов не больше 3-го уровня,
@extеnd — не всегда лучший способ наследования, можно использовать сайлент селекторы или миксины. Они предоставляют меньше зависимостей и переопределений.8. Не хочется запоминать миксины — пишите как привыкли. Как раз запомнить необходимые миксины и использовать их — лучшее вложение времени, чем писать одни и те же правила много раз.
9. Формируйте свою архитекуру файлов и подключайте их как Вам удобно.
Compass — не панацея и не для каждого проекта, в нем есть свои минусы, по мне так они незначительные. Но плюсов его использования я вижу несомненно больше.
Отвечу сразу всем.
Кода у нас порядка пол мегабайта минифицированного кода. Есть и много каскада и что-то типа бэма. Проект действительно большой (а не «довлльно крупный») и древний — мечта археолога) И не надо мне рассказывать, что единовременно из всего этого нужно от силы пара десятков килобайт — я это всё прекрасно знаю, но приложение одностраничное, а жонглирование динамическими стайлшитами и их генерация с учетом всех зависимостей — тот ещё секс.
3. Лучше всё-таки не держать никаких _base.scss, index.js и тп, а иметь разделение кода на модули и автоматический учет зависимостей между ними. Ручная пересортировка списка на 100+ файлов — совсем не то, чем хочется заниматься.
5. Я же программист, мне лень делать руками то, что может сделать программа. Один раз потрахался и теперь файлы нарезаются сами.
7. Да-да, и не используйте псевдоселекторы и псевдоэлементы) Я бы предпочёл, чтобы @extend функционировал точно также как @mixin — изменял одно конкретное правило, а не разбрасывал свойства одного класса по десятку правил. И это как раз такая «фича», которая скорее баг.
8. Не для того мы внедрили использование препроцессора, чтобы его не использовать х) АФАЙК, «миксины для стандартных свойств» — это не удобно по сравнению с «пишем по стандарту, а для отстающих генерируется фоллбэк, а для кеширования добавляется хэш к урлу».
9. Мне удобно, чтобы сгенерированный файл клался не рядышком, а в заданную подпапку, чтобы файлы были сгруппированы по модулям, а не по типам, чтобы спрайты собирались не из всех подряд файлов в заданной директории, а из тех файлов, что были подключены в css и тд и тп
11. Если нет no-repeat, то нижняя картинка оказывается сверху верхней. И наоборот.
13. Копипастой не устраивает. Я всегда хочу картинки засовывать в спрайт. Иначе бы и не использовал компасс, ограничившись scss с примесями. И вообще я не хочу ничего решать в каждом цсс-правиле, я хочу единожды для проекта настроить правило «все картинки до 20кб спрайтуем» и всё.
6, 7 и 8 — вполне себе недостатки компаса, просто он их унаследовал от scss)
Резюме: поменяли шило на мыло. Был один геморрой, теперь другой геморрой. Плюс ещё и архитектурная сложность возросла. Нахрен такое надо. Лучше уж заюзать либу типа rework и полностью контролировать процесс, чем использовать такой вот кривой фреймворк.
Кода у нас порядка пол мегабайта минифицированного кода. Есть и много каскада и что-то типа бэма. Проект действительно большой (а не «довлльно крупный») и древний — мечта археолога) И не надо мне рассказывать, что единовременно из всего этого нужно от силы пара десятков килобайт — я это всё прекрасно знаю, но приложение одностраничное, а жонглирование динамическими стайлшитами и их генерация с учетом всех зависимостей — тот ещё секс.
3. Лучше всё-таки не держать никаких _base.scss, index.js и тп, а иметь разделение кода на модули и автоматический учет зависимостей между ними. Ручная пересортировка списка на 100+ файлов — совсем не то, чем хочется заниматься.
5. Я же программист, мне лень делать руками то, что может сделать программа. Один раз потрахался и теперь файлы нарезаются сами.
7. Да-да, и не используйте псевдоселекторы и псевдоэлементы) Я бы предпочёл, чтобы @extend функционировал точно также как @mixin — изменял одно конкретное правило, а не разбрасывал свойства одного класса по десятку правил. И это как раз такая «фича», которая скорее баг.
8. Не для того мы внедрили использование препроцессора, чтобы его не использовать х) АФАЙК, «миксины для стандартных свойств» — это не удобно по сравнению с «пишем по стандарту, а для отстающих генерируется фоллбэк, а для кеширования добавляется хэш к урлу».
9. Мне удобно, чтобы сгенерированный файл клался не рядышком, а в заданную подпапку, чтобы файлы были сгруппированы по модулям, а не по типам, чтобы спрайты собирались не из всех подряд файлов в заданной директории, а из тех файлов, что были подключены в css и тд и тп
11. Если нет no-repeat, то нижняя картинка оказывается сверху верхней. И наоборот.
13. Копипастой не устраивает. Я всегда хочу картинки засовывать в спрайт. Иначе бы и не использовал компасс, ограничившись scss с примесями. И вообще я не хочу ничего решать в каждом цсс-правиле, я хочу единожды для проекта настроить правило «все картинки до 20кб спрайтуем» и всё.
6, 7 и 8 — вполне себе недостатки компаса, просто он их унаследовал от scss)
Резюме: поменяли шило на мыло. Был один геморрой, теперь другой геморрой. Плюс ещё и архитектурная сложность возросла. Нахрен такое надо. Лучше уж заюзать либу типа rework и полностью контролировать процесс, чем использовать такой вот кривой фреймворк.
Вы сами придумали себе кучу геморроя, а вините в этом фреймворк :) Я вот не испытываю ни одной из этих проблем. Во многом, наверное, из-за использования datauri вместо спрайтов, и отсутствия @extend (так и не придумал этой возможности применения). А framework нормальный, просто каждой задаче свой инструмент.
а с чего перешли на Компас?
С нативного CSS
Мне очень смешно с тех, кто не испытывает проблем с компасом. Вы либо им толком не пользуетесь, либо фанатично игнорируете проблемы. Компас — это очень топорный инструмент (не топор, замечу!). Всё в нём сделано как-то через одно место, но это не видно, пока не попытаешься им воспользоваться.
Ручное построение списков файлов с учётом зависимостей — это проблема, но все к этому привыкли и не видят её. Я даже не буду на эту тему спорить — поюзайте хоть одну систему автоматического управления зависимостями и поймёте, что ранее занимались ерундой.
datauri? С его «шикарной» поддержкой в ие? С разрастанием объёмов в два раза? С лишним временем на декодирование? И пляски с бубном, чтобы одна и та же картинка не дублировалась? Нафиг надо.
Мне очень смешно с тех, кто не испытывает проблем с компасом. Вы либо им толком не пользуетесь, либо фанатично игнорируете проблемы. Компас — это очень топорный инструмент (не топор, замечу!). Всё в нём сделано как-то через одно место, но это не видно, пока не попытаешься им воспользоваться.
Ручное построение списков файлов с учётом зависимостей — это проблема, но все к этому привыкли и не видят её. Я даже не буду на эту тему спорить — поюзайте хоть одну систему автоматического управления зависимостями и поймёте, что ранее занимались ерундой.
datauri? С его «шикарной» поддержкой в ие? С разрастанием объёмов в два раза? С лишним временем на декодирование? И пляски с бубном, чтобы одна и та же картинка не дублировалась? Нафиг надо.
я использовал SCSS под Компас на достаточно крупном руби-проекте, из того что вы упоминали сталкивался с 2, 10, 12 + мне сильно мешал компасовский резет стилей. спрайты предпочитал делать вручную. зависимости разрешались вручную, но это вообще не было проблемой и возлагать это на Компас не приходило в голову.
я не большой любитель процессоров (и даже Stylus on Mac у меня поломался, не собирает эти пресловутые datauri), но у меня не было ощущения что Компас из них самый кривой.
я не большой любитель процессоров (и даже Stylus on Mac у меня поломался, не собирает эти пресловутые datauri), но у меня не было ощущения что Компас из них самый кривой.
datauri? С его «шикарной» поддержкой в ие?
Проблем в IE не испытываю. Ибо MHTML + пара финтов для Windows Vista. Давно авсё автоматизировал
С разрастанием объёмов в два раза?
gzip? там от силы 5-10%. А число запросов уменьшается практически до 1-го (кроме особо крупных файлов и файлов нарочно исключённых из data-uri
И пляски с бубном, чтобы одна и та же картинка не дублировалась
Увы, тут да. Не так чтобы уж создавало кучу проблем, но учитывать это нужно при написании CSS-кода. Куда большие проблемы я вижу когда представляю как организовать быстро-загружаемый сайт со спрайтами. Когда то давным давно от них отказался и с тех пор счастлив :)
Нафиг надо.
Сменив шаблонизатор на HAML-подобный и отказавшись от IE7 — вёрстка стала простой, разумной и местами даже приятной. Спасибо SCSS, Compass, DataURI, CSS3, HTML5, Jade. Так что вынужден с вами не согласится.
А проблемы которые ВЫ испытываете с Compass-ом весьма специфичны. О них уже отписал выше.
Есть мнение, что когда программисты берутся за CSS, появляется LESS, SASS и COMPASS
А кто по-Вашему еще с CSS работает кроме программистов?
По вашей картинке выходит, что программисты берут хорошую вешь и портят: делают рукоять с выступами, чтобы натирать руку и тонкая, чтобы ломалась о первый же череп, или ствол; добавляют «фичи», чтобы было хуже транспортировать; делают хрупким, чтобы все знали, что это «тонкая вещь; усложняют лезвие, чтобы потом хрен кто смог сделать аналогичное.
Это шутка :) Почти.
Это шутка :) Почти.
Я ни разу не сказал, что одно хуже другого. Топор справа явно магический, укреплённый волшебством. Зачем такому топору массивность? Он разит врага одним касанием :)
Смысл картинки в том, что для достижения цели люди, пришедшие в CSS из программирования, улучшают свой инструмент, а не свои навыки. И то и другое приводит к одной цели, а значит равнозначно.
Скажу честно, я не пользуюсь ничем подобным хотя много раз пытался. Основные изменения в CSS происходят в момент его создания или рефакторинга. Далее — мелкие правки. Кроме того, IDE + emmet прекрасно справляется с дополнениями, префиксами, конвертациями в base64 и проч.
Смысл картинки в том, что для достижения цели люди, пришедшие в CSS из программирования, улучшают свой инструмент, а не свои навыки. И то и другое приводит к одной цели, а значит равнозначно.
Скажу честно, я не пользуюсь ничем подобным хотя много раз пытался. Основные изменения в CSS происходят в момент его создания или рефакторинга. Далее — мелкие правки. Кроме того, IDE + emmet прекрасно справляется с дополнениями, префиксами, конвертациями в base64 и проч.
Забыли ещё Autoprefixer
More CSS потрясающая вещь :)
Bourbon — набор mixin'ов для sass. Для меня самым подходящим на сегодня выглядит — sass + bourbon; а на завтра — stylus.
инструмент для эффективной работы с CSS
помогает быстро писать эффективный <...> CSS код
А как вы оцениваете эффективность?
То, что код чище — понятно. Но времени на создание и особенно поддержку этой чистоты — такое ощущение, что не меньше, чем писали бы на простом CSS.
P.S.
Опыт небольшой — 2 проекта, несколько человеко-месяцев на LESS, теперь приглядываемся к SCSS, но я как ПМ пока не очень понимаю смысл этих движений.
А как вы оцениваете эффективность?
Для меня показатель эффективности, это когда можно с инструментом написать более качественный код и быстрее, чем без него. SASS + Compass автоматизируют рутинные задачи и имеют много полезных хелперов. Зачем изобретать что-то заново, если оно уже есть и протестированно сообществом? Можно, конечно, и c помощью чистого CSS умудриться написать приличный проект, но Вы, скорее всего, будете каким-нибудь образом пытаться синтезировать то, что уже есть в SASS + Compass. И огромный минус чистого CSS — дубликация кода со всеми вытекающими последствиями. На более менее приличном проекте всегда есть смысл использовать CSS препроцессор.
То, что код чище — понятно. Но времени на создание и особенно поддержку этой чистоты — такое ощущение, что не меньше, чем писали бы на простом CSS.
Задокументированные стандарты по производительности и архитектуре ваших стилей + настроенное окружение + грамотный фронтенд лид — это что обычно нужно для поддержки чистоты и целостности кода.
«Задокументированные стандарты по производительности и архитектуре в ваших стилях» — нужно учитывать размеры/сложность проекта, целевые браузеры/устройства. Хороший пример для респонсив сайтов: github.com/Snugug/north. Если уже есть стандарты на уровне проекта/компании — хорошо, если нету — хороший шанс начать и по-тихоньку выстроить сообщество внутри компании.
«Настроенное окружение» — зависит от проекта/размера команды. чем больше команда, тем больше Вам нужно обезопасить себя от головняка, автоматизировать рутинные процессы, настроить grunt + JS/CSS lint (пускай код стайл проверяется автоматически), minifier и concat. Очень приятно ощущать разницу до автоматизации и после.
«грамотный фронтенд лид» — который в состоянии поднять и настроить окружение и процесс и будет следить за соблюдением стандартов.
К сожалению, без этих моментов проект ждет довольно хаотичное состояние.
Для меня показатель эффективности, это когда можно с инструментом написать более качественный код и быстрее, чем без него.
Не подумайте, что я придираюсь, но на хабре полно статей «качество кода vs. скорость» (в других хабах). Как программист, знаю, что ситуация «win-win» возникает только при определённых условиях (в долгосрочной перспективе, при отсутствии кардинальных изменений в ТЗ и т.д.).
Задокументированные стандарты по производительности и архитектуре ваших стилей + настроенное окружение + грамотный фронтенд лид — это что обычно нужно для поддержки чистоты и целостности кода.
Это всё круто. Но в жизни так выходит, что на проекте, который уже много лет в топ-500 alexa.com, до сих пор атмосфера бутстрэппинга. Правки в дизайн вносятся в таком режиме, когда некогда думать о высоких
Не подумайте, что я придираюсь, но на хабре полно статей «качество кода vs. скорость» (в других хабах). Как программист, знаю, что ситуация «win-win» возникает только при определённых условиях (в долгосрочной перспективе, при отсутствии кардинальных изменений в ТЗ и т.д.).
Скорость можно потерять только при переходе на SASS + Compass и настройке окружения, CSS файл при переименовании в .scss будет компилироваться без проблем. По сути, этот еще тот же CSS, только теперь появляется много возможностей как: выстроить необходимую структуру папок, манипуляции с изображениями, Grids где хотите и как хотите, снижение дубликации кода и тд. А за качеством кода нужно чтобы кто-то следил и знал, что это такое и как добиться.
Это всё круто. Но в жизни так выходит, что на проекте, который уже много лет в топ-500 alexa.com, до сих пор атмосфера бутстрэппинга. Правки в дизайн вносятся в таком режиме, когда некогда думать о высоких материях стандартах. Но ок, попробую поднять этот вопрос. Пойду поищу грамотного фронтенд лида. :)
вспомнил поговорку в тему — «Точить некогда, мне пилить надо». А в вообще, понимаю :) Когда сроки горят — не до этого. Лучший эффект, конечно, когда все настроено в начале проекта. Удачи в поисках!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Compass — инструмент для эффективной работы с CSS