Comments 44
Stylus я пока не пробовал, как-нибудь потом.
А зря — Stylus очень вкусный, у него, например, есть опциональный упрощенный формат, когда без дополнительных настроек можно использовать двоеточия и точки с запятой, а можете не использовать — движок сам поймет что надо делать.
Хотя в конечном счете в битве Sass/Stylus — просто фломастеры у всех разные, а так все похоже)
Думаю, они бы пользовались большей популярностью, если бы синтаксис был частью CSS, что повлекло бы:
— отсутствие необходимости в дополнительных инструментах (прежде всего компиляторов и сборщиков проектов, что для верстальщиков не самый привычный инструмент, плюс поддержки в девтулсах браузеров нет, афаик)
— единый синтаксис (сколько сейчас, три синтаксиса популярны вроде основных, но они не единственные)
— необходимость знания этого синтаксиса любым, кто претендует на должность верстальщика.
А сейчас, вот решил верстальщик потрогать хотя бы. Ему нужно устанавливать кучу софта, изучать инструменты и методологии типа CI, выбирать какой из препроцессоров использовать, и не факт, что єти знания ему пригодятся на новіх работах или проектах.
— отсутствие необходимости в дополнительных инструментах (прежде всего компиляторов и сборщиков проектов, что для верстальщиков не самый привычный инструмент, плюс поддержки в девтулсах браузеров нет, афаик)
— единый синтаксис (сколько сейчас, три синтаксиса популярны вроде основных, но они не единственные)
— необходимость знания этого синтаксиса любым, кто претендует на должность верстальщика.
А сейчас, вот решил верстальщик потрогать хотя бы. Ему нужно устанавливать кучу софта, изучать инструменты и методологии типа CI, выбирать какой из препроцессоров использовать, и не факт, что єти знания ему пригодятся на новіх работах или проектах.
Да, если бы CSS развивался, не было препроцессоров.
— Дополнительные инструменты для верстальщиков только в плюс: всякие Grunt облегчают работу с чем угодно — спрайты, минификация и т.п. Разобраться с ними дело нескольких часов, а достоинств — море.
— Синтаксис довольно-таки одинаков, в пределах фантазий авторов — где-то $variable, где-то @variable.
— Синтаксис слишком легкий, чтобы считать, что его знание отягощает и не нужно. На данный момент я не вижу проектов, где не использовался бы хоть какой-нибудь препроцессор.
Куча софта — в общем-то, нет. Базовый проект создается через yeoman и доступны все прелести веб-разработки, существующей 2014 году.
— Дополнительные инструменты для верстальщиков только в плюс: всякие Grunt облегчают работу с чем угодно — спрайты, минификация и т.п. Разобраться с ними дело нескольких часов, а достоинств — море.
— Синтаксис довольно-таки одинаков, в пределах фантазий авторов — где-то $variable, где-то @variable.
— Синтаксис слишком легкий, чтобы считать, что его знание отягощает и не нужно. На данный момент я не вижу проектов, где не использовался бы хоть какой-нибудь препроцессор.
Куча софта — в общем-то, нет. Базовый проект создается через yeoman и доступны все прелести веб-разработки, существующей 2014 году.
Разобраться с ними дело нескольких часов, а достоинств — море.
Вот как-то не попадалось нормальной инфы для начинающих о достоинствах подобных инструментов именно для верстальщиков. Чтобы верстальщик захотел поднять их локально, даже если в проекте ничего подоного не используется.
На данный момент я не вижу проектов, где не использовался бы хоть какой-нибудь препроцессор.
Очень субъективно.
Базовый проект создается через yeoman
Сколько верстальщиков поймут что такое
npm install -g yo
В общем, имхо, если хотите популяризировать препроцессоры и т. п., то очень помогут статьи о настройке всего этого хозяйства «для чайников», причем не с базовых проектов, а как начать использовать современные технологии в существующем проекте, даже если остальная команда против изменения своих процессов и появления «лишних» файлов в репозитории. В общем типичная ситуация, когда верстальщик имеет право коммитить в svn (это важно) только в <project_root>/www ну, может ещ’ в шаблоны и никто ради него не будет что-то внедрять на серверах.
А можно попопдробнее про @media-queries: @inсlude responsive(sm), я так понял это для группировки?
Нет.
У меня есть миксин responsive, который является оберткой над media-queries.
Вот пример:
Изначально класс .promo будет с паддингом в 2em, но начиная с sm (ширина окна 768px) — 5em.
У меня есть миксин responsive, который является оберткой над media-queries.
Вот пример:
.promo {
padding: 2em;
@include responsive(sm) {
padding: 5em;
}
}
Изначально класс .promo будет с паддингом в 2em, но начиная с sm (ширина окна 768px) — 5em.
а, я '@media-queries:' воспринял как некую сущность sass, позволяющую потом сгруппировать все медиа правила в одном месте
Возможно, это есть в Compass. А так — есть ли смысл?
только для уменьшения веса файла.
Мечтаю о том чтоб
превращалось в
Мечтаю о том чтоб
.profile-pic {
@include responsive(sm) {
width: 100px;
float: none;
}
}
.biography {
@include responsive(sm) {
font-size: 1.5em;
}
}
превращалось в
@media (min-width: 768px) {
.profile-pic {
width: 100px;
float: none;
}
.biography {
font-size: 1.5em;
}
}
Не нужно ничего оборачивать, Sass умеет вытаскивать медиа наружу:
.main__articles {
column-count:3;
@media (max-width:1023px) {
column-count:2;
}
}
У меня на Less подобная плюшка реализована проще:
@sm: ~"(min-width: 768px)";
@md: ~"(min-width: 992px)";
@lg: ~"(min-width: 1200px)";
@xlg: ~"(min-width: 1700px)";
.promo {
padding: 2em;
@media @sm {
padding: 5em;
}
@media @md {
padding: 6em;
}
@media @lg {
padding: 7em;
}
@media @xlg {
padding: 8em;
}
}
UFO just landed and posted this here
Медлительность — отличный довод против.
libsass
А теперь вспоминаем сколько раз реально приходится что-то менять? Правильно при редизайне один раз за один-два года! Да find/sed работают куда быстрее чем пересборка на каждый чих. На внедрение препроцессора куда больше времени уйдёт.
Это лишь пример использования. Мощь переменных в разы больше, нежели простой список цветов (например, в том же BrandButtons я использую переменную для массива)
Функция, которую почти никто не использует. Всё равно цвет задаёт дизайнер, а что копировать из макета абсолютно всё равно — на работе это никак не сказывается.
Функций больше.
Плохая практика, которая только мешает читать, так как глаза скачут по отступам. Особенно весело, когда пойдут изменения (а они будут): элементы начнут переезжать с места на место и т. д. Только БЭМ может с этим работать.
Не знаю, что у вас за метод разработки, что элементы едут с места на место. Глаза скачут по отступам? Вы их вообще не ставите?
В редакторах давно есть те же сниппеты, превращающие две буквы во что надо. И удобочитаемость кода выше.
bourbon.io/docs/ и многое другое
И в IE8? И на девайсах? Отладка — значимая часть работы верстальщика, и тут производительность как раз упадёт.
На девайсах — да. IE8 не нужен. К тому же, никто не мешает с помощью Dev Tools редактировать и сгенерированный CSS, разницы никакой.
UFO just landed and posted this here
Какой-то вы агрессивный.
К счастью, ко мне никогда не приходили менеджеры, да и не переверстывал я настолько, что нужно все менять.
medium. Это не так сложно, если открыть всего один файл mixins.scss
IE — да, что поделать, вы же сами выбрали этот путь.
Лол, а если был бы CSS, изменения в Dev Tools из коробки (а вы за это ратуете) сразу бы в файл писались?
К вам никогда не приходили менеджеры, говорящие, что этот блок теперь будет тут и т.п.? Вы точно разработчик?
К счастью, ко мне никогда не приходили менеджеры, да и не переверстывал я настолько, что нужно все менять.
И как это поможет понять человеку, что означают буквы 'md'? Вы каждый раз, когда они встречаются, пишете комментарий? Если так, то это первый признак дурнопахнущего кода.
medium. Это не так сложно, если открыть всего один файл mixins.scss
IE — да, что поделать, вы же сами выбрали этот путь.
А потом надо будет искать исходник и делать всё по новой.
Лол, а если был бы CSS, изменения в Dev Tools из коробки (а вы за это ратуете) сразу бы в файл писались?
Копипастом можно вносить изменения.
UFO just landed and posted this here
Значит, вы не участвовали в серьёзной разработке.
Я разрабатывал сервис Подарки в Бумстартере (не текущую версию, к сожалению), мое резюме доступно на hh. Может, не будете за меня решать, в чем я участвовал, а в чем нет?
Вот смотрит разработчик, незнакомый с кодом. Как он должен догадаться какой файл открыть? Это нечитаемый код.
Если человек не понимает, что
@include responsive() — миксин, то вряд ли он полезет в mixins.scss, согласен. Также могу отметить, если человек не может зайти на sass-lang.com и потратить 5 минут (не фигура речи), чтобы прочитать туториал — он не особо способен вообще к разработке. Ведь зачем изучать новое, лучше сидеть в 2008 и не развиваться.В IE10? Не пишутся, увы.
В остальных браузерах по дефолту тоже. Без плагинов. Так в чем смысл, если в обоих случаях все равно придется в файле еще раз править после Dev Tools?
Можно ли использовать SASS для обработки CSS-подобных языков? И если да — то как?
Например, я экспериментирую с стилями для карт, записанными в виде MapCSS, хочу заменить цвета: вместо значений использовать $переменные и попутно добавить вычисления оттенков — это было удобно. Пробую запустить sass и скормить ему mapcss-файл — получаю сообщение об ошибке синтаксиса (что вполне логичко — синтаксисы CSS и MapCSS отличаются). Можно ли сделать так, чтоб SASS молча пропускал незнакомые ему слова в результирующий файл? Смотрел документацию — пока не нашёл, как это сделать.
Например, я экспериментирую с стилями для карт, записанными в виде MapCSS, хочу заменить цвета: вместо значений использовать $переменные и попутно добавить вычисления оттенков — это было удобно. Пробую запустить sass и скормить ему mapcss-файл — получаю сообщение об ошибке синтаксиса (что вполне логичко — синтаксисы CSS и MapCSS отличаются). Можно ли сделать так, чтоб SASS молча пропускал незнакомые ему слова в результирующий файл? Смотрел документацию — пока не нашёл, как это сделать.
На счет source map. Как-то внезапно на крупном проекте (2500 строчек правил, а не свойст, т.е. все свойства пишутся в одну строку) в IE перестали применяться некоторые стили. Выяснилось, что причина в том, что в сгенерированном css файле было более 4095 правил.
Пришлось убрать source map, который и добавлял правила — ведь он через media работает. Для отладки пользуемся комментариями теперь:
В итоге удалось правил стало около 1800. Т.е. их количество уменьшилось примерно на 60%
Пришлось убрать source map, который и добавлял правила — ведь он через media работает. Для отладки пользуемся комментариями теперь:
/* line 24, ../../../../app/_app.scss */
.blockParent {
position: relative; }
В итоге удалось правил стало около 1800. Т.е. их количество уменьшилось примерно на 60%
Поделитесь, пожалуйста, методологией разработки.
Кода Вы говорите «сразу номально писать» — это означает, что ни разу не посмотреть в браузер? Если это не так, то, наверное и Вы смотрите в браузер, да и средствами разработчика (Wed Developers Toolkit) не брезгуете?
Может, я какой-то не такой, но для меня самый эффективный способ верстки следующий: создав структуру и набросав в классы, ей предназначенные, основные стили, я перехожу в Дев Кит Хрома и вживую играюсь параметрами до тех пор, пока результат меня не удовлетворит. Полученные стили копирую в их классы. Повторяю.
Очевидно, такой подход совсем не работает с Сассом. Как поступаете Вы?
Кода Вы говорите «сразу номально писать» — это означает, что ни разу не посмотреть в браузер? Если это не так, то, наверное и Вы смотрите в браузер, да и средствами разработчика (Wed Developers Toolkit) не брезгуете?
Может, я какой-то не такой, но для меня самый эффективный способ верстки следующий: создав структуру и набросав в классы, ей предназначенные, основные стили, я перехожу в Дев Кит Хрома и вживую играюсь параметрами до тех пор, пока результат меня не удовлетворит. Полученные стили копирую в их классы. Повторяю.
Очевидно, такой подход совсем не работает с Сассом. Как поступаете Вы?
Нет, «нормально писать» относилось к оптимизации. Хороший разработчик не будет писать плохой код, если и нужно будет что-то подчистить, то это мелочи.
Я так и делаю, только у меня есть поддержка Source Maps, проблем не возникает. Ну, и live reload как дополнение ко всему прочему.
Я так и делаю, только у меня есть поддержка Source Maps, проблем не возникает. Ну, и live reload как дополнение ко всему прочему.
Смотрю я на эти препроцесоры и не могу найти довода их использовать лично для себя вообще, сколько ими не интересуюсь. Я могу себе позволить своевольствие в разработке и не делаю проект в гигантской команде.
Смысл переменных только в изменении фона цветов? Я не нашел других оправданий переменным. В теории это удобно, а на практике?
Как часто просят переделать ТОЛЬКО цвет без изменений html? Если просят, почему нельзя сделать find and replace по файлам, не так удобно, а оно так часто чтобы быть удобным? Это же вообще не проблема, ее для меня лично не существует. переделки если есть то они вообще переделки, там не до переменных. НУ приперло так, можно же через класс оформить переменную цвета.
Ну окей у нас фирменные цвета которые нужно использовать. Но ведь сколько раз я сталкивался что шрифт, и фон под ним могут вообще визуально менять восприятие фирменного цвета шрифта вообще в другую сторону. И менеджеру или клиенту доказывать пипеткой что цвет по ГОСТу глупо, оба же видят он не тот что нужен. Приходится цвет менять чисто по восприятию.
У меня складывается мнение, что технологии уходят в абстракцию и тем самым порождают кучу еще больших зависимостей. У нас толком то CSS чтобы сказать знает большинство довольно хорошо трудно, что касается и меня.
Читай зависимость. Более глубокая зависимость от html структуры чревато при переделке оной и переделкой css. То есть от работы не избавляет.
Я не говорю что ими пользоваться не нужно. Если они кому то облегчают очень жизнь, то это хорошо. Но я вообще не вижу никаких преимуществ, на данный момент для себя(.
т.к. у меня бэкграунды используются во многих местах, мне проще отредактировать свойство переменной в одном месте, а не делать поиск по файлам или даже по одному файлу — все равно дольше, чем отредактировать в одном месте.
Смысл переменных только в изменении фона цветов? Я не нашел других оправданий переменным. В теории это удобно, а на практике?
Как часто просят переделать ТОЛЬКО цвет без изменений html? Если просят, почему нельзя сделать find and replace по файлам, не так удобно, а оно так часто чтобы быть удобным? Это же вообще не проблема, ее для меня лично не существует. переделки если есть то они вообще переделки, там не до переменных. НУ приперло так, можно же через класс оформить переменную цвета.
Ну окей у нас фирменные цвета которые нужно использовать. Но ведь сколько раз я сталкивался что шрифт, и фон под ним могут вообще визуально менять восприятие фирменного цвета шрифта вообще в другую сторону. И менеджеру или клиенту доказывать пипеткой что цвет по ГОСТу глупо, оба же видят он не тот что нужен. Приходится цвет менять чисто по восприятию.
У меня складывается мнение, что технологии уходят в абстракцию и тем самым порождают кучу еще больших зависимостей. У нас толком то CSS чтобы сказать знает большинство довольно хорошо трудно, что касается и меня.
Вложенность
Читай зависимость. Более глубокая зависимость от html структуры чревато при переделке оной и переделкой css. То есть от работы не избавляет.
Я не говорю что ими пользоваться не нужно. Если они кому то облегчают очень жизнь, то это хорошо. Но я вообще не вижу никаких преимуществ, на данный момент для себя(.
Если просят, почему нельзя сделать find and replace по файлам
Могут быть проблемы, если во время одной из итераций два семантически разных цвета (например, цвет текста и цвет заголовков) стали физически одинаковыми, а потом их нужно сделать разными.
Вообще довольно многие проблемы препроцессоры решают, но их можно решать и другими способами — например отдавать CSS через шаблонизаторы.
Да тут все совсем охерели, sass им не нравится!
Еще скажите вы slim-ом не пользуетесь и вообще в блокноте «верстаете»?
И где-то до сих пор платят деньги только за HTML+CSS?
«Верстальщики не могут в командную строку», «Find/Replace проще» — ну что за бред?
WUT?!
Я негодую.
Еще скажите вы slim-ом не пользуетесь и вообще в блокноте «верстаете»?
И где-то до сих пор платят деньги только за HTML+CSS?
«Верстальщики не могут в командную строку», «Find/Replace проще» — ну что за бред?
WUT?!
Я негодую.
Может быть, мне очень везет с дизайнером, может быть, мне просто везет по жизни, но на написание CSS у меня уходит ну крайне мало времени и сил. Цвета хранить в переменных нет никакого смысла — и вот почему: дизайнер наш понимает, что цвет ради цвета — это моветон, и поэтому цветом выделяет только те места, которые реально несут какую-то дополнительную нагрузку. Серый цвет? Дополнительные, необязательные данные. Красный цвет? Ошибка. Это совершенно справедливо можно положить в классы типа «nonimportantdata» и «error». Я, конечно, крайне негативно отношусь к классам типа «hidden» или «left», или, упаси Боже, «gray»/«blue». Но, на мой взгляд, если дизайнер использует цвет просто потому что цвет здесь выглядит круче — это далеко не самый хороший дизайнер.
Конечно, так устроен трудовой процесс во многих конторах: есть менеджер, который «я-начальник-ты-дурак», который даже может взять и написать дизайнеру: «сделай-ка тут шрифт покрупнее, а тут синий цвет». Мне кажется, уже в этом месте подход абсолютно неверный. Работа дизайнера не подлежит микроменеджменту, если он, конечно, не джуниор (или как там у дизайнеров джуниоры называются). А на выходе получаются интерфейсы, где цвет содержимого никак не связан с самим содержимым, используется пяток разных цветов, десяток размеров шрифта и прочая, прочая. И тут, конечно, без переменных никуда.
TLDR-версия. Вот я лично считаю препроцессоры этаким управленческим костылем, попыткой верстальщиков совладать с плохим дизайнером и самодуром-менеджером.
Конечно, так устроен трудовой процесс во многих конторах: есть менеджер, который «я-начальник-ты-дурак», который даже может взять и написать дизайнеру: «сделай-ка тут шрифт покрупнее, а тут синий цвет». Мне кажется, уже в этом месте подход абсолютно неверный. Работа дизайнера не подлежит микроменеджменту, если он, конечно, не джуниор (или как там у дизайнеров джуниоры называются). А на выходе получаются интерфейсы, где цвет содержимого никак не связан с самим содержимым, используется пяток разных цветов, десяток размеров шрифта и прочая, прочая. И тут, конечно, без переменных никуда.
TLDR-версия. Вот я лично считаю препроцессоры этаким управленческим костылем, попыткой верстальщиков совладать с плохим дизайнером и самодуром-менеджером.
Sign up to leave a comment.
Почему стоит использовать препроцессоры