Пользователь
0,0
рейтинг
28 февраля 2014 в 00:13

Разработка → Почему стоит использовать препроцессоры

У меня достаточно неплохой опыт в верстке — несколько лет.
За это время было многое — и табличная верстка, и собственные фреймворки, и IE6, и адаптивный дизайн, да что угодно — я всегда старался быть рядом с bleeding edge, как говорится.
Больше CSS-фреймворков (привет, бутстрап) и Emmet-а мне нравятся препроцессоры и я расскажу, почему. Возможно, покажется, что моя статья несколько устарела и сейчас все используют препроцессоры как само собой разумеющееся, но, увы, это не так. Недавно я встретил человека, который говорил о том, что ему быстрее писать CSS-код, нежели использовать препроцессоры. Мы долго спорили, на самом деле, ну очень долго, в итоге я решил выложить свои мысли здесь, в одном месте.

Less или Sass?


Ну, на самом деле, это дело каждого. Мне не нравился Sass из-за его медлительности — Less побыстрее выполнялся всегда, в итоге в один момент я решил перейти на Less, но через некоторое время оказалось, что мне не хватает его мощности! Увы, я так и не нашел, как реализовать банальный миксин уровня вот этого.
Но и медлительность Sass не устраивала, но именно в тот момент, когда я хотел обратно вернуться на Sass, но терзался сомнениями, мне посоветовали libsass, а т.к. я использую Grunt — мне было достаточно подключить только grunt-sass (и ничего больше, например, установка Ruby и гемов). Для меня выбор был ясен и с тех пор — только libsass. Мощность самого Sass и с скорость C — что еще нужно?
Stylus я пока не пробовал, как-нибудь потом.

Почему все-таки препроцессоры?


Я не скажу ничего нового, скорее всего, но я хочу показать, почему стоит использовать препроцессоры.

Переменные

Переменные — это нечто великолепное. Мне стали в упрек «препроцессоры были придуманы программистом, не верстальщиком», но как можно отказываться от переменных? Простой пример, который сильно облегчает жизнь — так как я в том числе еще и дизайнер, все цвета, настройки шрифтов и т.п. по проекту мне достаточно хранить в файле _variables.scss
_variables.scss
$white: rgb(255, 255, 255);
$lightgray: rgb(238, 238, 238);
$gray: rgb(153, 153, 153);
$asphalt: rgb(85, 85, 85);
$black: rgb(17, 17, 17);

$blue: rgb(85, 164, 242);
$lightblue: rgb(91, 192, 222);
$green: rgb(46, 204, 113);
$orange: rgb(230, 126, 34);
$magenta: rgb(228, 183, 240);
$red: rgb(231, 76, 60);

$bgBrand: linear-gradient(to left, rgba(26,214,253,1) 0%, rgba(85,164,242,0.72) 100%) no-repeat center center fixed;
$bgBlueLight: linear-gradient(rgb(26, 214, 253) 0%, rgb(29, 98, 240) 100%) no-repeat center center fixed;
$bgPinkViolet: linear-gradient(#EF4DB6 0%, #C643FC 100%) no-repeat center center fixed;
$bgWhiteGray: linear-gradient(#F7F7F7 0%, #D7D7D7 100%) no-repeat center center fixed;


Затем, когда мне это необходимо, я лишь указываю переменную, а не полное свойство. background: $bgBrand, а т.к. у меня бэкграунды используются во многих местах, мне проще отредактировать свойство переменной в одном месте, а не делать поиск по файлам или даже по одному файлу — все равно дольше, чем отредактировать в одном месте.

Вложенность

Что может быть лучше вложенности :hover, :after, :before, :nth-child в родительский элемент?
Простой, очень простой пример:
a {
  color: $blue;

  &:hover {
    color: darken($blue, 10%);
  }
}

В нем я использую переменные, внутреннюю функцию darken() и ту самую вложенность. Казалось бы, мелочь, но из таких мелочей и состоит верстка. В разы удобнее смотреть, что относится к конкретному блоку, следя за тем, что находится внутри него, а не за тем, что идет ниже. Да и писать каждый раз .my-super-class:hover все-таки бессмысленно. Сторонники БЭМ-подхода оценили бы такую возможность, но у них там свои инструменты.
Мне нужно было сделать таблицу, где отсутствовали заголовки (я использовал Bootstrap).
Пример
.table-information {
  tr {
    th {
      height: 0;
      padding: 0;
      border: 0;
    }

    td {
      border-top: 0;
      border-bottom: 1px solid $lightgray;
    }

    &:last-child {
      td {
        border-bottom: 0;
      }
    }
  }
}



Миксины, импорты и т.п.

Самый главный плюс препроцессоров — это в миксинах, экстендах и т.п. Это как функции в нормальном языке — можно использовать бесконечное количество раз, подключая когда необходимо. Лично я не так часто использую миксины, но т.к. я верстаю с подходом mobile first, мне очень сильно помогает один маленький миксин, о котором я уже упомянул:
@mixin responsive($media) {
  @if $media == sm {
    @media (min-width: 768px) { @content; }
  }
  @else if $media == md {
    @media (min-width: 992px) { @content; }
  }
  @else if $media == lg {
    @media (min-width: 1200px) { @content; }
  }
  @else if $media == xlg {
    @media (min-width: 1700px) { @content; }
  }
}

Используется достаточно просто, как @media-queries: @include responsive(sm) { background-color: red } и это вместе с вложенностью элементов.

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

«Я не могу разобраться в сгенерированном коде»

Когда я услышал этот аргумент, я не совсем понял, о чем шла речь. Затем мне разъяснили (человек работает на фрилансе) — к нему поступает проект с Sass или Less, но сгенерированный код ужасен, в нем нельзя разобраться. И это неправильный подход, потому что препроцессоры — для людей, для того, чтобы было удобно разрабатывать, держать архитектуру проекта в нормальном состоянии. Если человек пишет нормально, CSS на выходе получается оптимизированным, с этой стороны нет никакой разницы, на чем было написано — на CSS или Sass, Sass лишь помогает разработчику, а не браузеру. Для поддержки браузером есть Source maps, поддержка которых в нормальных инструментах типа Grunt есть из коробки.

Пример


Не так давно я разрабатывал один проект, в котором мне понадобились кнопки социальных сетей — не так много, штук 5, но именно тогда я задумался над тем, чтобы сделать библиотеку с использованием Sass, где хранилось бы огромное количество кнопок. Разумеется, делать это на CSS было бы неудобно, именно поэтому я решил использовать Sass. Тот человек, с которым мы спорили, в итоге отметил изящность решения.
Для того, чтобы сделать Brand Buttons, мне понадобилось совсем немного:

В итоге 3 файла, в которых я использовал небольшую, но мощную часть возможностей Sass: переменные, импорты, миксины, внутренние функции типа each/@for. Конечный CSS вышел на 687 строк.
Для того, чтобы добавить новую кнопку в этот проект, мне достаточно в _variables.scss вставить одну строчку brand: color и запустить grunt build, а не создавать новые классы вручную.

Препроцессоры — это история о том, как мелочи типа переменных способны сильно увеличить производительность. Препроцессоры, может быть, и написаны программистами, но при этом они не привносят ничего сложного, лишь улучшают жизнь: код остается читабельным, даже более того — его становится меньше, он становится более стройным. В этой статье я не рассказал о многих возможностях, но у меня было желание показать, почему я использую препроцессоры и какие плюсы они дают тем, кто все-таки решится.
Eugene Rodionov @justusebrain
карма
13,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • +1
    Stylus я пока не пробовал, как-нибудь потом.


    А зря — Stylus очень вкусный, у него, например, есть опциональный упрощенный формат, когда без дополнительных настроек можно использовать двоеточия и точки с запятой, а можете не использовать — движок сам поймет что надо делать.

    Хотя в конечном счете в битве Sass/Stylus — просто фломастеры у всех разные, а так все похоже)
    • 0
      Обещаю попробовать. Выглядит также мощно, как Sass, но еще чище.
  • 0
    Думаю, они бы пользовались большей популярностью, если бы синтаксис был частью CSS, что повлекло бы:
    — отсутствие необходимости в дополнительных инструментах (прежде всего компиляторов и сборщиков проектов, что для верстальщиков не самый привычный инструмент, плюс поддержки в девтулсах браузеров нет, афаик)
    — единый синтаксис (сколько сейчас, три синтаксиса популярны вроде основных, но они не единственные)
    — необходимость знания этого синтаксиса любым, кто претендует на должность верстальщика.

    А сейчас, вот решил верстальщик потрогать хотя бы. Ему нужно устанавливать кучу софта, изучать инструменты и методологии типа CI, выбирать какой из препроцессоров использовать, и не факт, что єти знания ему пригодятся на новіх работах или проектах.
    • +1
      Да, если бы CSS развивался, не было препроцессоров.
      — Дополнительные инструменты для верстальщиков только в плюс: всякие Grunt облегчают работу с чем угодно — спрайты, минификация и т.п. Разобраться с ними дело нескольких часов, а достоинств — море.
      — Синтаксис довольно-таки одинаков, в пределах фантазий авторов — где-то $variable, где-то @variable.
      — Синтаксис слишком легкий, чтобы считать, что его знание отягощает и не нужно. На данный момент я не вижу проектов, где не использовался бы хоть какой-нибудь препроцессор.

      Куча софта — в общем-то, нет. Базовый проект создается через yeoman и доступны все прелести веб-разработки, существующей 2014 году.
      • +1
        Разобраться с ними дело нескольких часов, а достоинств — море.

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

        Очень субъективно.
        Базовый проект создается через yeoman

        Сколько верстальщиков поймут что такое
        npm install -g yo
        
        ?

        В общем, имхо, если хотите популяризировать препроцессоры и т. п., то очень помогут статьи о настройке всего этого хозяйства «для чайников», причем не с базовых проектов, а как начать использовать современные технологии в существующем проекте, даже если остальная команда против изменения своих процессов и появления «лишних» файлов в репозитории. В общем типичная ситуация, когда верстальщик имеет право коммитить в svn (это важно) только в <project_root>/www ну, может ещ’ в шаблоны и никто ради него не будет что-то внедрять на серверах.
        • +1
          У меня есть мысли сделать гайд, обширный, масштабный, но, похоже, не совсем то, чего ожидаете — увы, SVN, PHP и прочее слишком далекая от меня тема. Но я внедрял yeoman на существующем проекте Ruby on Rails и получилось, в общем-то. Как-нибудь расскажу.
  • 0
    А можно попопдробнее про @media-queries: @inсlude responsive(sm), я так понял это для группировки?
    • 0
      Нет.
      У меня есть миксин responsive, который является оберткой над media-queries.
      Вот пример:
      .promo {
        padding: 2em;
      
        @include responsive(sm) {
          padding: 5em;
        }
      }
      


      Изначально класс .promo будет с паддингом в 2em, но начиная с sm (ширина окна 768px) — 5em.
      • 0
        а, я '@media-queries:' воспринял как некую сущность sass, позволяющую потом сгруппировать все медиа правила в одном месте
        • 0
          Возможно, это есть в Compass. А так — есть ли смысл?
          • 0
            только для уменьшения веса файла.
            Мечтаю о том чтоб
            .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;
              }
            }
            
      • 0
        Не нужно ничего оборачивать, Sass умеет вытаскивать медиа наружу:

        .main__articles {
            column-count:3;
            @media (max-width:1023px) {
                column-count:2;
                }
            }
        • 0
          Я знаю, но мне удобнее запомнить sm/md/lg (с учетом того, что я использую бутстрап), чем конкретные значения.
          • 0
            Как-то так:

            $md: "(max-width:1023px)";
            
            .main__articles {
                column-count:3;
                @media #{$md} {
                    column-count:2;
                }
            }
            
            • 0
              Да, я заметил ваше решение. Изящно, мне нравится.
              • 0
                Ещё комбинировать правила можно через and.
                Пример из документации Sass:

                $media: screen;
                $feature: -webkit-min-device-pixel-ratio;
                $value: 1.5;
                
                @media #{$media} and ($feature: $value) {
                  .sidebar {
                    width: 500px;
                  }
                }
                
      • 0
        У меня на 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;
          }
        }
        
  • +1
    Не увидел ни одного реального довода.

    > Мне не нравился Sass из-за его медлительности — Less побыстрее выполнялся всегда, в итоге в один момент я решил перейти на Less, но через некоторое время оказалось, что мне не хватает его мощности!

    Медлительность — отличный довод против.

    > …мне проще отредактировать свойство переменной в одном месте, а не делать поиск по файлам или даже по одному файлу — все равно дольше, чем отредактировать в одном месте.

    А теперь вспоминаем сколько раз реально приходится что-то менять? Правильно при редизайне один раз за один-два года! Да find/sed работают куда быстрее чем пересборка на каждый чих. На внедрение препроцессора куда больше времени уйдёт.

    > darken()

    Функция, которую почти никто не использует. Всё равно цвет задаёт дизайнер, а что копировать из макета абсолютно всё равно — на работе это никак не сказывается.

    > Вложенность

    Плохая практика, которая только мешает читать, так как глаза скачут по отступам. Особенно весело, когда пойдут изменения (а они будут): элементы начнут переезжать с места на место и т. д. Только БЭМ может с этим работать.

    > Миксины, импорты и т.п.

    В редакторах давно есть те же сниппеты, превращающие две буквы во что надо. И удобочитаемость кода выше.

    > Для поддержки браузером есть Source maps…

    И в IE8? И на девайсах? Отладка — значимая часть работы верстальщика, и тут производительность как раз упадёт.
    • +1
      Медлительность — отличный довод против.

      libsass

      А теперь вспоминаем сколько раз реально приходится что-то менять? Правильно при редизайне один раз за один-два года! Да find/sed работают куда быстрее чем пересборка на каждый чих. На внедрение препроцессора куда больше времени уйдёт.

      Это лишь пример использования. Мощь переменных в разы больше, нежели простой список цветов (например, в том же BrandButtons я использую переменную для массива)

      Функция, которую почти никто не использует. Всё равно цвет задаёт дизайнер, а что копировать из макета абсолютно всё равно — на работе это никак не сказывается.

      Функций больше.

      Плохая практика, которая только мешает читать, так как глаза скачут по отступам. Особенно весело, когда пойдут изменения (а они будут): элементы начнут переезжать с места на место и т. д. Только БЭМ может с этим работать.

      Не знаю, что у вас за метод разработки, что элементы едут с места на место. Глаза скачут по отступам? Вы их вообще не ставите?

      В редакторах давно есть те же сниппеты, превращающие две буквы во что надо. И удобочитаемость кода выше.

      bourbon.io/docs/ и многое другое

      И в IE8? И на девайсах? Отладка — значимая часть работы верстальщика, и тут производительность как раз упадёт.

      На девайсах — да. IE8 не нужен. К тому же, никто не мешает с помощью Dev Tools редактировать и сгенерированный CSS, разницы никакой.
      • –2
        > Не знаю, что у вас за метод разработки, что элементы едут с места на место. Глаза скачут по отступам? Вы их вообще не ставите?

        К вам никогда не приходили менеджеры, говорящие, что этот блок теперь будет тут и т.п.? Вы точно разработчик?

        > bourbon.io/docs/ и многое другое

        И как это поможет понять человеку, что означают буквы 'md'? Вы каждый раз, когда они встречаются, пишете комментарий? Если так, то это первый признак дурнопахнущего кода.

        > IE8 не нужен.

        Ну, допустим, а IE10?

        > К тому же, никто не мешает с помощью Dev Tools редактировать и сгенерированный CSS, разницы никакой.

        А потом надо будет искать исходник и делать всё по новой.
        • 0
          Какой-то вы агрессивный.

          К вам никогда не приходили менеджеры, говорящие, что этот блок теперь будет тут и т.п.? Вы точно разработчик?

          К счастью, ко мне никогда не приходили менеджеры, да и не переверстывал я настолько, что нужно все менять.

          И как это поможет понять человеку, что означают буквы 'md'? Вы каждый раз, когда они встречаются, пишете комментарий? Если так, то это первый признак дурнопахнущего кода.

          medium. Это не так сложно, если открыть всего один файл mixins.scss

          IE — да, что поделать, вы же сами выбрали этот путь.

          А потом надо будет искать исходник и делать всё по новой.

          Лол, а если был бы CSS, изменения в Dev Tools из коробки (а вы за это ратуете) сразу бы в файл писались?
          • 0
            Копипастом можно вносить изменения.
            • 0
              Именно. А что мешает делать то же самое, но с Sass?
              • 0
                Отсутствие нативной поддержки Sass в браузерах?
                • 0
                  Так она есть — Source maps поддерживаются браузерами.
                  • 0
                    Всеми? И, насколько я понимаю, компиляция на лету не поддерживается нигде.
          • 0
            > К счастью, ко мне никогда не приходили менеджеры, да и не переверстывал я настолько, что нужно все менять.

            Значит, вы не участвовали в серьёзной разработке.

            > medium. Это не так сложно, если открыть всего один файл mixins.scss

            Вот смотрит разработчик, незнакомый с кодом. Как он должен догадаться какой файл открыть? Это нечитаемый код.

            > Лол, а если был бы CSS, изменения в Dev Tools из коробки (а вы за это ратуете) сразу бы в файл писались?

            В IE10? Не пишутся, увы.
            • 0
              Значит, вы не участвовали в серьёзной разработке.

              Я разрабатывал сервис Подарки в Бумстартере (не текущую версию, к сожалению), мое резюме доступно на hh. Может, не будете за меня решать, в чем я участвовал, а в чем нет?

              Вот смотрит разработчик, незнакомый с кодом. Как он должен догадаться какой файл открыть? Это нечитаемый код.

              Если человек не понимает, что @include responsive() — миксин, то вряд ли он полезет в mixins.scss, согласен. Также могу отметить, если человек не может зайти на sass-lang.com и потратить 5 минут (не фигура речи), чтобы прочитать туториал — он не особо способен вообще к разработке. Ведь зачем изучать новое, лучше сидеть в 2008 и не развиваться.

              В IE10? Не пишутся, увы.

              В остальных браузерах по дефолту тоже. Без плагинов. Так в чем смысл, если в обоих случаях все равно придется в файле еще раз править после Dev Tools?
              • –1
                > Я разрабатывал сервис Подарки в Бумстартере (не текущую версию, к сожалению)

                Тривиальный сайт для верстальщика на вид (и то ошибки на айпаде). Резюме ничем не впечатляет. Наоборот, большое перечисление невыдающихся пунктов наводит на мысль, что особых заслуг нет.

                > Ведь зачем изучать новое

                Изучать новое не самоцель, вы до сих пор этого не понимаете? В сети столько всего дофига нового, что если всё изучать, времени на работу не хватит.

                > Так в чем смысл, если в обоих случаях все равно придется в файле еще раз править после Dev Tools?

                Вот вы и начали задавать правильные вопросы.
                • +1
                  До чего же толсто. Успехов.
                  • +1
                    Вы так ко всякому фидбеку относитесь? Обратная связь — это то, чем ещё ценен хабр. Вон, Alexufo практически повторяет мои слова ниже.
                    • 0
                      Конструктивную критику я всегда выслушиваю, вашу тоже. Под конец вы стали выглядеть как очень толстый тролль, а мне это неинтересно. Спасибо за общение.
                      • –1
                        Понятно, как за личное задело, так сразу ярлыки вместо того, чтобы подумать. Типичная ошибка. Это ведь как раз то, что стоит проанализировать.
  • 0
    Можно ли использовать SASS для обработки CSS-подобных языков? И если да — то как?

    Например, я экспериментирую с стилями для карт, записанными в виде MapCSS, хочу заменить цвета: вместо значений использовать $переменные и попутно добавить вычисления оттенков — это было удобно. Пробую запустить sass и скормить ему mapcss-файл — получаю сообщение об ошибке синтаксиса (что вполне логичко — синтаксисы CSS и MapCSS отличаются). Можно ли сделать так, чтоб SASS молча пропускал незнакомые ему слова в результирующий файл? Смотрел документацию — пока не нашёл, как это сделать.
    • 0
      Увы, но, похоже, что нельзя.
  • 0
    На счет source map. Как-то внезапно на крупном проекте (2500 строчек правил, а не свойст, т.е. все свойства пишутся в одну строку) в IE перестали применяться некоторые стили. Выяснилось, что причина в том, что в сгенерированном css файле было более 4095 правил.

    Пришлось убрать source map, который и добавлял правила — ведь он через media работает. Для отладки пользуемся комментариями теперь:
    /* line 24, ../../../../app/_app.scss */
    .blockParent {
      position: relative; }
    


    В итоге удалось правил стало около 1800. Т.е. их количество уменьшилось примерно на 60%
    • 0
      Ого.
      Source map (и разделение по файлам) я обычно использую в development-режиме, в продакшене все минифицируется и т.п. Но 4095+ правил — это, конечно, многовато.
  • +1
    Поделитесь, пожалуйста, методологией разработки.
    Кода Вы говорите «сразу номально писать» — это означает, что ни разу не посмотреть в браузер? Если это не так, то, наверное и Вы смотрите в браузер, да и средствами разработчика (Wed Developers Toolkit) не брезгуете?

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

    Очевидно, такой подход совсем не работает с Сассом. Как поступаете Вы?
    • 0
      Нет, «нормально писать» относилось к оптимизации. Хороший разработчик не будет писать плохой код, если и нужно будет что-то подчистить, то это мелочи.
      Я так и делаю, только у меня есть поддержка Source Maps, проблем не возникает. Ну, и live reload как дополнение ко всему прочему.
  • 0
    Смотрю я на эти препроцесоры и не могу найти довода их использовать лично для себя вообще, сколько ими не интересуюсь. Я могу себе позволить своевольствие в разработке и не делаю проект в гигантской команде.
    т.к. у меня бэкграунды используются во многих местах, мне проще отредактировать свойство переменной в одном месте, а не делать поиск по файлам или даже по одному файлу — все равно дольше, чем отредактировать в одном месте.

    Смысл переменных только в изменении фона цветов? Я не нашел других оправданий переменным. В теории это удобно, а на практике?
    Как часто просят переделать ТОЛЬКО цвет без изменений html? Если просят, почему нельзя сделать find and replace по файлам, не так удобно, а оно так часто чтобы быть удобным? Это же вообще не проблема, ее для меня лично не существует. переделки если есть то они вообще переделки, там не до переменных. НУ приперло так, можно же через класс оформить переменную цвета.

    Ну окей у нас фирменные цвета которые нужно использовать. Но ведь сколько раз я сталкивался что шрифт, и фон под ним могут вообще визуально менять восприятие фирменного цвета шрифта вообще в другую сторону. И менеджеру или клиенту доказывать пипеткой что цвет по ГОСТу глупо, оба же видят он не тот что нужен. Приходится цвет менять чисто по восприятию.

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

    Вложенность

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

    Я не говорю что ими пользоваться не нужно. Если они кому то облегчают очень жизнь, то это хорошо. Но я вообще не вижу никаких преимуществ, на данный момент для себя(.
    • 0
      Если просят, почему нельзя сделать find and replace по файлам

      Могут быть проблемы, если во время одной из итераций два семантически разных цвета (например, цвет текста и цвет заголовков) стали физически одинаковыми, а потом их нужно сделать разными.

      Вообще довольно многие проблемы препроцессоры решают, но их можно решать и другими способами — например отдавать CSS через шаблонизаторы.
  • 0
    Да тут все совсем охерели, sass им не нравится!
    Еще скажите вы slim-ом не пользуетесь и вообще в блокноте «верстаете»?
    И где-то до сих пор платят деньги только за HTML+CSS?
    «Верстальщики не могут в командную строку», «Find/Replace проще» — ну что за бред?

    WUT?!

    Я негодую.
    • 0
      Платят. используют не блокнот, а *Storm или Netbeans (из того, что сам встречал за последний год).
  • 0
    Может быть, мне очень везет с дизайнером, может быть, мне просто везет по жизни, но на написание CSS у меня уходит ну крайне мало времени и сил. Цвета хранить в переменных нет никакого смысла — и вот почему: дизайнер наш понимает, что цвет ради цвета — это моветон, и поэтому цветом выделяет только те места, которые реально несут какую-то дополнительную нагрузку. Серый цвет? Дополнительные, необязательные данные. Красный цвет? Ошибка. Это совершенно справедливо можно положить в классы типа «nonimportantdata» и «error». Я, конечно, крайне негативно отношусь к классам типа «hidden» или «left», или, упаси Боже, «gray»/«blue». Но, на мой взгляд, если дизайнер использует цвет просто потому что цвет здесь выглядит круче — это далеко не самый хороший дизайнер.

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

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

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