Комментарии 72
Вывод: автору больше нравится SASS, а не LESS.
На самом деле, имхо, самое главное преимущество LESS — CSS-подобный синтаксис.
Во-первых, любой CSS можно рассматривать как LESS
Во-вторых, порог вхождения в LESS меньше за счёт этого.
Проблема в том, что SASS-подход сложнее отлаживать. В LESS ты знаешь, что если ты объявил это где-то здесь, то и в CSS оно будет где-то там же, а SASS будет разбросан по всему коду.
Так что, как всегда в таких сравнениях — это просто набор притянутых за уши фактов, часто не важных, набор ложных посылов и скрытие важных нюансов для того, чтобы оправдать свой выбор инструмента.
На самом деле, имхо, самое главное преимущество LESS — CSS-подобный синтаксис.
Во-первых, любой CSS можно рассматривать как LESS
Во-вторых, порог вхождения в LESS меньше за счёт этого.
Вы это видите? SASS переопределяет селекторы, и это более эффективный путь.
Победитель: SASS
Проблема в том, что SASS-подход сложнее отлаживать. В LESS ты знаешь, что если ты объявил это где-то здесь, то и в CSS оно будет где-то там же, а SASS будет разбросан по всему коду.
Так что, как всегда в таких сравнениях — это просто набор притянутых за уши фактов, часто не важных, набор ложных посылов и скрытие важных нюансов для того, чтобы оправдать свой выбор инструмента.
SCSS ~ SASS. Те же яйца, вид снизу. SCSS обратно-совместим с CSS.
SCSS тоже CSS-подобный синтаксис. Необязательно использовать отступы (sass), можно и скобки (scss). Более того, основным является как раз SCSS.
Ну почему же.
— а чем SCSS не CSS-подобный синтаксис? Можно смело переименовывать css в scss, максимум выкинет ошибку синтаксиса аля «не поставлена ;»
— Используя SCSS я полюбил логику в CSS. Если её убрать, мне будет неудобно, т.к. привык к хорошему
По поводу строки кода — есть FireSass, который показывает строку кода и файл, но с ним много геморроя. Он у меня приводит к страшным тормозам в FireBug, и вообще флаг дебаг-строк добавляет к каждому правилу по 1 строке, и в итоге в старых IE css грузится на половину, если она большая.
С другой стороны, я не совсем понимаю, как организовать использование 50+ less файлов так, чтобы соблюдались номера строк? Это реально? Если нет, то встаёт проблема — или писать всё в одном файле (надеюсь никогда к этому не вернусь), или отдельно организовывать сборку CSS на живом сервере.
— а чем SCSS не CSS-подобный синтаксис? Можно смело переименовывать css в scss, максимум выкинет ошибку синтаксиса аля «не поставлена ;»
— Используя SCSS я полюбил логику в CSS. Если её убрать, мне будет неудобно, т.к. привык к хорошему
По поводу строки кода — есть FireSass, который показывает строку кода и файл, но с ним много геморроя. Он у меня приводит к страшным тормозам в FireBug, и вообще флаг дебаг-строк добавляет к каждому правилу по 1 строке, и в итоге в старых IE css грузится на половину, если она большая.
С другой стороны, я не совсем понимаю, как организовать использование 50+ less файлов так, чтобы соблюдались номера строк? Это реально? Если нет, то встаёт проблема — или писать всё в одном файле (надеюсь никогда к этому не вернусь), или отдельно организовывать сборку CSS на живом сервере.
Под SASS уже давно подразумевается SCSS, который совместим с CSS. Это в статье черным по белому. Автор провел прекрасное исследование, SASS действительно уже давно уделывает LESS. Compass не может быть переписан под LESS не потому, что его автору лень, а потому, что это сделать нельзя.
А генерация спрайтов в компассе — это вообще киллер-фича, избавляет от большой геморной рутины.
А генерация спрайтов в компассе — это вообще киллер-фича, избавляет от большой геморной рутины.
Кажется внекоторых местах над кодом
нужно поставить SASS вместо SCSS?
нужно поставить SASS вместо SCSS?
Для компиляции созданных вами файлов стоит использовать такое приложение как CodeKit. Вы должны знать основы Ruby или командной строки или еще чего-то другого...1. LESS можно вообще не компилировать отдельно.
2. Для LESS есть GUI-компиляторы.
Возможно такое же есть и для SASS (я не в курсе), но этот абзац мне показался странным (если не лишним).
Вы когда-нибудь пробовали этот «не компилировать отдельно» использовать на продакшене в крупном проекте? Для презентаций оно выглядит красиво, но на практике — бесполезная игрушка.
(я про компилировании стилей не на сервере, а в браузере)
Я не предлагаю этим пользоваться, только сказал, что такая возможность есть. Да и web состоит отнюдь не из одних крупных проектов с километровыми стилями.
А для компиляции LESS есть GUI, вся настройка которых сводится к указанию где брать LESS-файлы и куда класть CSS-файлы.
А для компиляции LESS есть GUI, вся настройка которых сводится к указанию где брать LESS-файлы и куда класть CSS-файлы.
Вы когда-нибудь пробовали этот «не компилировать отдельно» использовать на продакшене в крупном проекте?
Я сейчас так делаю. Единственное препятствие использовать такой код на продакшне — cross-origin policy, согласно которой less-файл не может лежать на отдельном домене. Но во время девелопмента у меня он компилируется рантайм, так что фича однозначно полезная
Я тут, не так давно, приводил пример, когда обычный CSS код (правда очень много его, 100+ Кб) в less файле компилировался браузером Opera — 23 секунды, а в IE7 — 10 секунд. Просто пример. Понимаю, что ситуации бывают разные, однако не стоит переоценивать js-движки старых браузеров и оперы (хотя он вроде бы быстрый, странно).
100+ Кб — сильно, что там такого можно было наворочить? это без URI вставок?
Просто «легаси» скопилось много мусора, + довольно непростой сайт. Но css вполне реальная. Вот она. Разжирела уже до 200 Кб :)
А это разве не selling-point LESS'а? То что можно eval'ить CSS-свойства как в старых IE через expressions? :)
Тогда вообще не вижу причин использовать LESS.
Тогда вообще не вижу причин использовать LESS.
Я вот честно скажу не пробовал — но подмывало много раз, ибо у меня .less + лоадер .js в разы меньше получается чем компилированный css(даже с жатием).
Увеличение нагрузки в браузере!? — сомнительно
Отдача 2 статических файлов less + js — мне кажется нименьшим злом по сравнению с «лишним» трафиком и нагрузкой на сервер при компиляции…
Есть у кого опыт нагруженных проектов БЕЗ предварительной компиляции less или sass с обработкой в браузере — чем плохо/хорошо — поделитесь?
Увеличение нагрузки в браузере!? — сомнительно
Отдача 2 статических файлов less + js — мне кажется нименьшим злом по сравнению с «лишним» трафиком и нагрузкой на сервер при компиляции…
Есть у кого опыт нагруженных проектов БЕЗ предварительной компиляции less или sass с обработкой в браузере — чем плохо/хорошо — поделитесь?
Не обязательно компилировать каждый раз less-файл по запросу пользователя открыть страницу. Можно сделать это всего один раз и залить на сервер уже скомпилированный css
Согласен, но я писал что у меня less+js в 2-3 раза меньше компиленного css, а явных препядствий для первого варианта я не вижу — может я чего-то не туда смотрю…
Зато вы два раза дергаете сервер:
1) less.js
2) style.less
В случае прекомпиляции и отдачи готового css из минусов вы получаете только пару килобайт лишнего траффика. Из плюсов — моментальное и корректное отображение стилей, меньшая нагрузка на сервер за счет уменьшения количества запросов к нему.
Ну, если вам так удобно, и время компиляции на клиенте очень маленькое — такой вариант тоже хорош
1) less.js
2) style.less
В случае прекомпиляции и отдачи готового css из минусов вы получаете только пару килобайт лишнего траффика. Из плюсов — моментальное и корректное отображение стилей, меньшая нагрузка на сервер за счет уменьшения количества запросов к нему.
Ну, если вам так удобно, и время компиляции на клиенте очень маленькое — такой вариант тоже хорош
Сейчас бы в 2017 в профессиональной среде разработчиков без гуя не уметь обойтись…
LESS выглядит всё-таки нагляднее.
Автор присудил побуду SASS за счёт Compass, но не стоит забывать, что нужно исходить из задач.
Я бы с удовольствием почитал бы статью, описывающую практическое применение Compass, плюсы и минусы, когда стоит использовать.
Автор присудил побуду SASS за счёт Compass, но не стоит забывать, что нужно исходить из задач.
Я бы с удовольствием почитал бы статью, описывающую практическое применение Compass, плюсы и минусы, когда стоит использовать.
Берёшь и используешь. Ну или и не используешь.
Плюсы? Забыть про набивание префиксов к свойствам, и необходимость запоминать по три варианта синтаксиса для одного свойства (привет градиенты). Ну или просто километровые строки (привет трансформации).
Минусы? Ну надо поставить гем. Возможно что-то настроить, в последний раз вроде изкаропки всё заводилось.
Плюсы? Забыть про набивание префиксов к свойствам, и необходимость запоминать по три варианта синтаксиса для одного свойства (привет градиенты). Ну или просто километровые строки (привет трансформации).
Минусы? Ну надо поставить гем. Возможно что-то настроить, в последний раз вроде изкаропки всё заводилось.
Минусы? Ну надо поставить гем. Возможно что-то настроить, в последний раз вроде изкаропки всё заводилось.
Я купил тулзу за $10, которая следит за моими папками, и сама генерит все на лету. Не надо ничего ставить, все работает из коробки. Никаких гемов, Ruby и т.п.
Compass умеет делать спрайты из моей папки иконок — это просто неимоверно удобно. Добавить новую иконку? Изменить имеющуюся? Один клик!
На минувшем Railsconf 2012 был отдельный доклад про sass, где анонсировали 3 фичи над которыми сейчас ведётся работа, и которые появятся в следующем релизе:
1. libsass — написанный на C компилятор sass в css, работающий быстрее на порядки нынешнего скрипта на руби. Для крупных проектов это очень существенно — большие объёмы стилей при деплое компилируются ну очень долго(полминуты и дольше). Так же это позволит написать биндинги для libsass к другим языкам, что означает более простое встраивание sass во фрейморки питона/ноды/дотнета/пхп.
2. Mixin Content — аналог yield в sass, позволяющий передавать блоки кода в миксины.
3. Placeholder Selectors — наследование свойств от произвольных селекторов (сейчас отнаследовать можно только от конкретного css класса).
А ещё докладчик постебался, что в less много багов, и что их не фиксят :)
1. libsass — написанный на C компилятор sass в css, работающий быстрее на порядки нынешнего скрипта на руби. Для крупных проектов это очень существенно — большие объёмы стилей при деплое компилируются ну очень долго(полминуты и дольше). Так же это позволит написать биндинги для libsass к другим языкам, что означает более простое встраивание sass во фрейморки питона/ноды/дотнета/пхп.
2. Mixin Content — аналог yield в sass, позволяющий передавать блоки кода в миксины.
3. Placeholder Selectors — наследование свойств от произвольных селекторов (сейчас отнаследовать можно только от конкретного css класса).
А ещё докладчик постебался, что в less много багов, и что их не фиксят :)
1. Хочу, хочу, хочу. Скорость текущего парсера, оставляет желать лучшего, на моей, не самой производительной, машине.
2. Можно чуть подробнее?
2. Можно чуть подробнее?
с 12:25 на www.youtube.com/watch?v=MFwId6xSh2o
Python-биндинги для libsass. Эксклюзивно для Хабра habrahabr.ru/post/144419/
а я сделал для .Net: habrahabr.ru/post/147567/
SASS не поддерживает на данный момент такую вот штуку
в LESS это все компилируется в
Полезно для БЭМа.
Хотя в версии 3.2 вроде как обещают запилить.
.some-parent-class {
&__some-modificator {
color: red;
}
}
в LESS это все компилируется в
.some-parent-class__some-modificator {
color: red;
}
Полезно для БЭМа.
Хотя в версии 3.2 вроде как обещают запилить.
Для ховеров и прочего работает.
Как это не поддерживает?
Вполне поддерживает, причём точно также:
Вполне поддерживает, причём точно также:
&:hover
&:first-child
&.another_class
Если я правильно понял smashercosmo, то он имеет ввиду не доп.класс, а склеить одно название класса по кускам, используя вложенность.
&_
&-
в 3.2 так и не запилили, обещают в 3.3
&-
в 3.2 так и не запилили, обещают в 3.3
По мне дак удобнее запустить фоновый преобразователь less в css, писать в less и не парится
Если быть кратким: Stylus.
Выигрывает по всем параметрам, а кроме того, написан на Node.JS, что избавляет от pain in ass с установкой последней беты Ruby через rvm.
Выигрывает по всем параметрам, а кроме того, написан на Node.JS, что избавляет от pain in ass с установкой последней беты Ruby через rvm.
Да, для ноды очень удобная штука, в сочетании с jade вообще радость питониста. Есть врапперы под руби и питон, сам не проверял.
https://github.com/lucasmazza/ruby-stylus
https://github.com/lusentis/django-stylus
https://github.com/lucasmazza/ruby-stylus
https://github.com/lusentis/django-stylus
> Обработка переменных
>…
> SASS имеет странное свойство — если вы переопределите «глобальную» переменную «локальной», глобальная переменная примет ее значение. Немного странно.
Пипец как странно — лезть в глобальный контекст при переопределении локального. Яваскриптеры меня поймут. Тут как раз SASS проиграл.
>…
> SASS имеет странное свойство — если вы переопределите «глобальную» переменную «локальной», глобальная переменная примет ее значение. Немного странно.
Пипец как странно — лезть в глобальный контекст при переопределении локального. Яваскриптеры меня поймут. Тут как раз SASS проиграл.
Насколько я понимаю, CSS-фреймворки используются для того чтобы:
1. Использовать вложенные инструкции
2. Минифицировать результирующий код (пробелы, табуляция, rgb -> hex -> short hex triplet)
3. Генерация CSS правил серверным кодом
4. Дополнить кроссбраузерными CSS3 правилами (как-правило опционально и не везде есть)
Наличие остальных фич уже сомнительно…
Для первых 3-х пунктов у меня есть экстремально небольшая либа (пара десятков строк), которая делает следующее:
Будет транслировано в валидный CSS-код:
Чтобы перевести поток в файл не нужно никаких танцев с бубном:
При этом имеется 3 реализации (CoffeeScript, JavaScript, Python), а это значит что достаточно наличия Node+CoffeeScript или Python.
PS: в JavaScript и Python версии фигурные скобки обязательны, в CoffeeScript опциональны
1. Использовать вложенные инструкции
2. Минифицировать результирующий код (пробелы, табуляция, rgb -> hex -> short hex triplet)
3. Генерация CSS правил серверным кодом
4. Дополнить кроссбраузерными CSS3 правилами (как-правило опционально и не везде есть)
Наличие остальных фич уже сомнительно…
Для первых 3-х пунктов у меня есть экстремально небольшая либа (пара десятков строк), которая делает следующее:
object =
html:
background: 'red'
body:
color: 'rgb(255, 255, 255)'
'div > p':
color: 'green'
border: '#000008'
input :
border : '1px solid #110011'
Будет транслировано в валидный CSS-код:
html {
background: red;
}
html body {
color: #FFF;
}
html body div > p {
color: green;
border: #000008;
}
input {
border: #101;
}
Чтобы перевести поток в файл не нужно никаких танцев с бубном:
file = fs.createWriteStream 'file.css',
flags: 'a'
encoding: 'utf-8'
mode: 0666
file.on 'error', (error) ->
console.error error
file.write to.toCSS object
file.end ->
console.log to.toCSS object
При этом имеется 3 реализации (CoffeeScript, JavaScript, Python), а это значит что достаточно наличия Node+CoffeeScript или Python.
PS: в JavaScript и Python версии фигурные скобки обязательны, в CoffeeScript опциональны
Сомнительные потому, что ваша библиотека, не умеет их?
Постоянно использую:
1. Миксины — блоки стилей, вставляющиеся внутрь любого селектора. Через них же реализованы кроссбраузерные css3 правила. Миксины для DRY — на порядок сокращают повторения в коде.
2. Переменные. Обычно для задания цветов и отступов. DRY.
3. Арифметика — как правило сложение/вычитание для переменных с отступами.
4. Загрузка других scss файлов внутрь текущего, аналог import/include из других языков программирования. Без этого как минимум пукты 1 и 2 не будут работать.
А синтаксис вашей либы — вылитый sass, только с синтаксическим мусором: «object =», кавычки после двоеточия, двоеточие после селектора.
Постоянно использую:
1. Миксины — блоки стилей, вставляющиеся внутрь любого селектора. Через них же реализованы кроссбраузерные css3 правила. Миксины для DRY — на порядок сокращают повторения в коде.
2. Переменные. Обычно для задания цветов и отступов. DRY.
3. Арифметика — как правило сложение/вычитание для переменных с отступами.
4. Загрузка других scss файлов внутрь текущего, аналог import/include из других языков программирования. Без этого как минимум пукты 1 и 2 не будут работать.
А синтаксис вашей либы — вылитый sass, только с синтаксическим мусором: «object =», кавычки после двоеточия, двоеточие после селектора.
В том то и фишка, что в отличии от выше представленных фреймворков мне ничего не приходится парсить, работа происходит с обычным объектом (словарем).
Соответственно я могу использовать переменные, и любые управляющие другие конструкции:
Как я упомянул выше можно использовать фигурные скобки:
только с синтаксическим мусором: «object =
Меня это тоже немного смущает, но зато такой код может работать даже на клиенте и без тормозов, т.к. ничего не парсится!
Иными словами, словами все тоже самое только нет фич для CSS3, а добавить эту возможность очень просто (мне пока это не особо нужно).
Соответственно я могу использовать переменные, и любые управляющие другие конструкции:
html:
background: ['#111', '#222', '#333', '#444', '#555', '#666', '#777'][today]
color:
if 1 > 2
'red'
else
'green'
А синтаксис вашей либы — вылитый sass
Как я упомянул выше можно использовать фигурные скобки:
html: {
background: {
['#111', '#222', '#333', '#444', '#555', '#666', '#777'][today]
},
color: {
if 1 > 2
'red'
else
'green'
}
}
только с синтаксическим мусором: «object =
Если писать стили в отдельном файле, то название объекта писать необязательно!
Кавычки после двоеточия, двоеточие после селектора.
Меня это тоже немного смущает, но зато такой код может работать даже на клиенте и без тормозов, т.к. ничего не парсится!
Иными словами, словами все тоже самое только нет фич для CSS3, а добавить эту возможность очень просто (мне пока это не особо нужно).
здоровенный css-файл с продакшена я могу переименовать в scss, а потом уже постепенно рефакторить его. css-совместимый синтаксис — сильная сторона scss (как и less)
Подскажите, а как заставить NodeJS компилятор LESS-файлов исправлять относительные пути (фоновые картинки, шрифты), так что бы они были правильными относительно расположения скомпилированного файла? JavaScript компилятор правильно переопределяет эти пути, а NodeJS оставляет их без изменения. По моему это достаточно существенный минус у родного компилятора LESS.
Ещё один довод в пользу SASS/SCSS — есть возможность выбора синтаксиса.
Именно SASS мне нравится куда больше SCSS, код становится чище и понятнее :)
Именно SASS мне нравится куда больше SCSS, код становится чище и понятнее :)
ИМХО, инструмент надо выбирать в соответствии с задачей. Не сталкивался еще ни разу с проектом, где вместо LESS потребовался бы SASS с его несколько большими возможностями.
В связи с этим нет инструмента лучше или хуже. Есть тот, который подходит под задачи, и тот, который по каким-то причинам не подходит (слишком просто или слишком избыточен).
В связи с этим нет инструмента лучше или хуже. Есть тот, который подходит под задачи, и тот, который по каким-то причинам не подходит (слишком просто или слишком избыточен).
Вы не рассмотрели тот момент, что у LESS есть компилятор на стороне браузера — LESS.js
Это может стать для кого-то решающим аргументом при выборе LESS, хотя сам я такую практику не понимаю.
Это может стать для кого-то решающим аргументом при выборе LESS, хотя сам я такую практику не понимаю.
Вот сейчас собираюсь попробовать SASS, и всё сомневаюсь: с одной стороны — куча возможностей, генерация спрайтов, примеси и прочее, а с другой — мне он кажется каким-то неизящным. Дело привычки, конечно…
Вот что меня действительно беспокоит, так это как отлаживать и изменять верстку. Может я ошибаюсь, но кажется, что примеси будут сложны в поддержке, потому как сразу не видно, куда эти изменения приминяются. Кто работал, скажите, как вы отлаживаете верстку?
Еще, ребота с вложениями очень смахивает на прекрасный инструмент, чтобы выстрелить себе в ногу :)
Вот что меня действительно беспокоит, так это как отлаживать и изменять верстку. Может я ошибаюсь, но кажется, что примеси будут сложны в поддержке, потому как сразу не видно, куда эти изменения приминяются. Кто работал, скажите, как вы отлаживаете верстку?
Еще, ребота с вложениями очень смахивает на прекрасный инструмент, чтобы выстрелить себе в ногу :)
есть firesass для фаербага. надо только отладочный режим подетальней включить, чтобы в css-файлах писалось из какой строчки scss генерировался данный кусок.
> Кто работал, скажите, как вы отлаживаете верстку?
Многие действия провожу в веб инспекторе хрома, когда надо что-то подтюнить, то сначала правлю в инспекторе, сразу же наблюдая результат, а потом копирую измения в файл стилей.
При таком методе нет никаких отличий между css и scss.
В девелопмент режиме, без склейки стилей в один файл, содержимое каталога с scss файлами соотностится почти 1 к 1 c содержимым каталога со скомпилированными стилями (если не увлеваться инклудом одних файлов стилей в другие).
И в веб-инспекторе вы видите, какие наложены стили, по какому селектору, и из какого файла оно пришло. Соответственно правите нужный селектор в нужном файле.
Если же делать без инспектора, просто вслепую набирая в файле стили и проверяя затем в броузере, то опять же никакой разницы с чистым css — сохранили файл, альт-таб, ф5, видим результат.
И с миксинами всё сильно упрощается: с обычным css для каждого «признака оформления» приходится либо накладывать определённый класс, комбинируя в одном дом элементе по несколько классов ради разных кусочков стилей в них. Либо, используя меньше css классов, приходится дублировать код в css файлах, разным селекторам прописывая одни и те же стили.
Миксины и переменные избавляют от этого дублирования.
Многие действия провожу в веб инспекторе хрома, когда надо что-то подтюнить, то сначала правлю в инспекторе, сразу же наблюдая результат, а потом копирую измения в файл стилей.
При таком методе нет никаких отличий между css и scss.
В девелопмент режиме, без склейки стилей в один файл, содержимое каталога с scss файлами соотностится почти 1 к 1 c содержимым каталога со скомпилированными стилями (если не увлеваться инклудом одних файлов стилей в другие).
И в веб-инспекторе вы видите, какие наложены стили, по какому селектору, и из какого файла оно пришло. Соответственно правите нужный селектор в нужном файле.
Если же делать без инспектора, просто вслепую набирая в файле стили и проверяя затем в броузере, то опять же никакой разницы с чистым css — сохранили файл, альт-таб, ф5, видим результат.
И с миксинами всё сильно упрощается: с обычным css для каждого «признака оформления» приходится либо накладывать определённый класс, комбинируя в одном дом элементе по несколько классов ради разных кусочков стилей в них. Либо, используя меньше css классов, приходится дублировать код в css файлах, разным селекторам прописывая одни и те же стили.
Миксины и переменные избавляют от этого дублирования.
Вот я тоже сначала в испекторе подгоняю.
А как Вы меняете xчто-то в миксинах? Или на миксины разбиваете в самом конце?
Просто я обычно пишу селекторы через запятую. В таком случае когда в общем стиле что-то меняешь, то сразу видишь, где что поменяется, а миксины придется искать. И вот этот момент мне представляется потенциально неудобным.
Соответственно меня интересует, как другие справляются с такими задачами. Может я прсто придумываю себе проблему?..
А как Вы меняете xчто-то в миксинах? Или на миксины разбиваете в самом конце?
Просто я обычно пишу селекторы через запятую. В таком случае когда в общем стиле что-то меняешь, то сразу видишь, где что поменяется, а миксины придется искать. И вот этот момент мне представляется потенциально неудобным.
Соответственно меня интересует, как другие справляются с такими задачами. Может я прсто придумываю себе проблему?..
Если смотреть с самого начала, то, пожалуй, сначала пишу просто scss код без миксинов.
Когда же вижу, что какие-то вещи надо повторять на разных страницах, так, что невозможно в текущем файле стилей просто обойтись перечислением селекторов через запятую, то выношу код в миксин в один глобальный scss файл, который в обязательном порядке инклюдится во всех остальные файлы со стилями.
Вот подобное:
Разные миксины с кодом оформления дефолтных заголовков, ссылок, каких-нибудь блоков, переменные с несколькими осными цветами, на которых дизайн сайта построен и подобное.
Искать ничего не придётся, потому что в коде у вас будет что-то такое:
Вы сразу видите, что там из миксина всё берётся, а мест, где может быть определён нужный миксин, у вас будет всего 1-2.
Когда же вижу, что какие-то вещи надо повторять на разных страницах, так, что невозможно в текущем файле стилей просто обойтись перечислением селекторов через запятую, то выношу код в миксин в один глобальный scss файл, который в обязательном порядке инклюдится во всех остальные файлы со стилями.
Вот подобное:
@ mixin image-selectable-decor {
@ include transition(background-color, 0.2s); <- миксин для кроссброузерного css3 из compass фреймворка
background-color: $default-image-background;
&:hover {
background-color: $default-image-hover-background;
}
&:active {
background-color: $default-image-active-background;
}
}
Разные миксины с кодом оформления дефолтных заголовков, ссылок, каких-нибудь блоков, переменные с несколькими осными цветами, на которых дизайн сайта построен и подобное.
Искать ничего не придётся, потому что в коде у вас будет что-то такое:
.news, .articles {
@ include default-info-block;
/* какое-то свойство из default-info-block тут может быть переопределено */
font-size: 13px;
}
/* а какое-то свойство лишь для одного класса изменено */
.news {
color: red;
}
Вы сразу видите, что там из миксина всё берётся, а мест, где может быть определён нужный миксин, у вас будет всего 1-2.
Объясните пожалуйста на элементарном примере, зачем нужен метаязык? Просто мне стало любопытно, начал вникать, но так особо преимуществ не нашел. Ну где то можно объявить переменную, и поменять цвет, к примеру, во всех элементах где он используется, поправив только одну строчку. Плюс. А что еще?
По поводу extend, — в Less тоже есть extend.
См. доки: lesscss.org/features/#extend-feature
Пост мягко-говоря староват, и несколько не актуален, так что на момент написания статьи наверняка extend-а ещё не было.
См. доки: lesscss.org/features/#extend-feature
Пост мягко-говоря староват, и несколько не актуален, так что на момент написания статьи наверняка extend-а ещё не было.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SASS против LESS