Comments 36
В тексте немного код сбился, не на месте. В разделе про наследование существующего класса блок с результирующим CSS улетел в предыдущий раздел, по-моему. Если это так, поправьте пожалуйста.
Обычно CSS в данном случае выглядел бы так
.buton {
border-radius: 4px;
border: 4px solid black;
}
.search-button {
background-color: blue;
}
.cancel-button {
background-color: red;
}
HTML так
<button class="button cancel-button">Cancel</button>
Чем это хуже того что получилось в SCSS я не понимаю.
В данном конкретном случае
Плюсы
не вижу таких.
Минусы
1. Совершенно новый синтаксис, на изучение (запоминание) которого нужно тратить время.
2. Если сосчитать число символов в коде, то в моем примере их меньше, а значит я потратил меньше времени, набирая код на клавиатуре.
P.S. давно слежу за всеми этими новомодными SASS, LESS… но число объективных достоинств, которые могу назвать, никак не перевесят число недостатков использования этих инструментов.
Ещё плюс:
3. Сравните синтаксис и попробуйте его понять. В моем примере он читается очень быстро. В примере выше вызывает зависание на пару минут. Найти и что-то исправить в обычном CSS проще, чем в коде с mixin.
3. Сравните синтаксис и попробуйте его понять. В моем примере он читается очень быстро. В примере выше вызывает зависание на пару минут. Найти и что-то исправить в обычном CSS проще, чем в коде с mixin.
UFO just landed and posted this here
Частично вы правы. А вот насчёт провосходства минусов над плюсами вынужден не согласиться.
Чего стоит лишь только вкладывание правил? Конечно, злоупотреблять ими не стоит (да и микс-ины дают очень большой CSS-ный выхлоп), но, как по мне, вкладывание давно пора сделать нативно поддерживаемым в CSS.
Если бы LESS/SCSS парсился браузером без необходимости прекомпиляции в CSS — цены бы ему не было.
Чего стоит лишь только вкладывание правил? Конечно, злоупотреблять ими не стоит (да и микс-ины дают очень большой CSS-ный выхлоп), но, как по мне, вкладывание давно пора сделать нативно поддерживаемым в CSS.
Если бы LESS/SCSS парсился браузером без необходимости прекомпиляции в CSS — цены бы ему не было.
>>как по мне, вкладывание давно пора сделать нативно поддерживаемым в CSS.
Честно говоря это единственное, что мне нравится в инструментах подобных SASS. Остальное или очень редко используется, или можно сделать без создания нового языка.
Честно говоря это единственное, что мне нравится в инструментах подобных SASS. Остальное или очень редко используется, или можно сделать без создания нового языка.
Я из препроцессоров вынес только три вещи:
1) нахожу возможность писать media внутри класса более удобным и читаемым, чем классы внутри media.
2) Переменные. Тут без комментариев.
3) Игры с цветами. Хорошо для генерации всяких цветовых схем. Задал базовый цвет, а в других местах, все поменялось в зависимости от него. Но это спецефично.
Что же до миксинов. То пример из статьи ужасен на мой взгляд. Сам делаю как у вас. Миксин позволяю себе, когда надо вынести несколько свойств в одну строчку, а в html он смысловой нагрузки не несет. Напимер, button button-succeed, примелимо. button-rounded — нет. То есть вякие вертикальные выравнивания, обтекания, спрос флоатов, выставления позиционирования – тут миксин полезен.
1) нахожу возможность писать media внутри класса более удобным и читаемым, чем классы внутри media.
2) Переменные. Тут без комментариев.
3) Игры с цветами. Хорошо для генерации всяких цветовых схем. Задал базовый цвет, а в других местах, все поменялось в зависимости от него. Но это спецефично.
Что же до миксинов. То пример из статьи ужасен на мой взгляд. Сам делаю как у вас. Миксин позволяю себе, когда надо вынести несколько свойств в одну строчку, а в html он смысловой нагрузки не несет. Напимер, button button-succeed, примелимо. button-rounded — нет. То есть вякие вертикальные выравнивания, обтекания, спрос флоатов, выставления позиционирования – тут миксин полезен.
Пример здоровский. И он работает. Но когда у вас появятся как минимум 4 похожих кнопки, тогда SASS и LESS будут короче. Вспомните те же бутстраповские кнопки (дефаулт, примари, варн, дангер, линк, инлаин). Кстати, в бутстрапе все классы -варн, -дангер, -инфо и т.д. имеют свой цвет, что так же легче и быстрей сделать миксинами.
По вашим минусам:
1. Не увидел совершенно нового синтаксиса, особенно в SCSS (кто вам мешает писать чистый CSS на SCSS в конце концов?)
2. «Набирая на клавиатуре» — да. «потратил меньше времени» — скорей всего нет. Написать код изящно и кратко занимает гораздо больше времени, чем на скорую руку намазать спагетти.
По вашим минусам:
1. Не увидел совершенно нового синтаксиса, особенно в SCSS (кто вам мешает писать чистый CSS на SCSS в конце концов?)
2. «Набирая на клавиатуре» — да. «потратил меньше времени» — скорей всего нет. Написать код изящно и кратко занимает гораздо больше времени, чем на скорую руку намазать спагетти.
Эм, в бутстрапе как раз используется описанный выше вариант.
<button class="btn btn-danger">Alert!</button>
Про бутстрап хороший пример. Но есть одна особенность: это массовый продукт. Сколько вы используете видов кнопок оттуда на своем проекте? (если все 6, то попрошу пруф). В одном конкретном проекте обычно используется 2 — 3 цветовых стиля кнопок. Поэтому выхлоп с использованием CSS процессоров ощутим только на массовых продуктах. (ИМХО) Я к тому, что инструменты надо использовать с умом, а не просто потому что это модно (часто такое встречал).
Бутстрап обычно использую для административных интерфейсов, поэтому все 6 зачастую задействованы (тогглы — серый, сохранение — синий, удалить — красный, добавить — зелёный, дебаг — оранжевый и т.д.). Но в целом, с вами согласен, т.к. львиная доля компонентов бутстрапа не используется.
Однако нашел для себя отличное решение — gridle. В каждом проекте включаешь именно те фичи, которые будут использоваться, как следствие даёт минимальные размеры для генерируемых css файлов (цветов и разукрашек там нет, только лейаут).
Однако нашел для себя отличное решение — gridle. В каждом проекте включаешь именно те фичи, которые будут использоваться, как следствие даёт минимальные размеры для генерируемых css файлов (цветов и разукрашек там нет, только лейаут).
Мне нравится SASS, я люблю SASS, шикарные возможности, очень круто. Но не всегда понимаю, как с его «выхлопом» работать дальше. Сделал я проект, допустим, CSS написал на SASS, отдал клиенту. Проект развивается, пригласили разработчиков, которые не знают SASS, но знают LESS — как быть в такой ситуации. Выход один — править скомпиленный CSS.
В скорости разработки SASS — лучший помощник. Когда количество строк кода не превышает 2000. Потом ливрелодится компилл долго, Ctrl+S умножается на два с интервалом в 400мс. Может у меня машина слабая, но это немного раздражает.
Даже свои проекты, которые я писал на SASS — поддерживаю и развиваю только на CSS, так как невозможно становится с этим работать, особенно, когда проект находится на удаленном сервере.
На мой взгляд SASS подходит для быстрой разработки какого-нибудь LP, который ты потом отдашь клиенту и благополучно о нем забудешь, но преимущество у разработчика безусловное — в скорости разработки.
В скорости разработки SASS — лучший помощник. Когда количество строк кода не превышает 2000. Потом ливрелодится компилл долго, Ctrl+S умножается на два с интервалом в 400мс. Может у меня машина слабая, но это немного раздражает.
Даже свои проекты, которые я писал на SASS — поддерживаю и развиваю только на CSS, так как невозможно становится с этим работать, особенно, когда проект находится на удаленном сервере.
На мой взгляд SASS подходит для быстрой разработки какого-нибудь LP, который ты потом отдашь клиенту и благополучно о нем забудешь, но преимущество у разработчика безусловное — в скорости разработки.
UFO just landed and posted this here
Вообще в данном конкретном случае целесообразнее использовать плейсхолдеры, тогда не создаётся избыточный класс (если он, конечно, не используется, что довольно редко на практике SASS)
А для всей статьи можно сделать простое и короткое (как по мне, так ещё и очевидное) правило: если шаблон — наследование, если шаблон с переменными — примеси. Соответственно, если в большом шаблоне одна строка с переменными — их можно легко комбинировать.
Код с плейсхолдерами
%button {
border-radius: 4px;
border: 4px solid black;
}
@mixin button($name, $background-color) {
.#{$name}-button {
background-color: $background-color;
@extend %button;
}
}
@include button('search', blue);
@include button('cancel', red);
.search-button, .cancel-button {
border-radius: 4px;
border: 4px solid black;
}
.search-button {
background-color: blue;
}
.cancel-button {
background-color: red;
}
А для всей статьи можно сделать простое и короткое (как по мне, так ещё и очевидное) правило: если шаблон — наследование, если шаблон с переменными — примеси. Соответственно, если в большом шаблоне одна строка с переменными — их можно легко комбинировать.
На мой взгляд подобные возможности препроцессорных языков для css (less тоже это умеет), скорее костыль, которого стоит избегать. Это примерно как important. Понятно, что gzip обожмет такие повторения, но все же лучше избегать .extend там, где без этого можно обойтись. На пример в примере с button. Просто используйте 2 класса.
Всю статью не читал, потому что как обычно, очередная каша про то, как правильно писать SASS, но вот насчет первого примера в «Скромных примесях» выскажусь. Я считаю, что это чистейшей воды антипаттерн и правильно было бы сделать все на чистом CSS и не вы**ываться:
Не знаю, как с SASS, но LESS позволяет просто сделать так (и я считаю, что это элегантно):
Почему нужно делать именно так? Это банально интуитивнее. Потом, в HTML коде вы будете писать все естественным языком, не городить забор. Взгляните на пример:
Cогласитесь, первый вариант будет лучше второго, потому что это естественный язык, естественная подача информации. По большому счету, никакого существенного отличия вроде и нет, но разметку писать стало проще понятней и мы не стали плодить сущности с этими вашими миксинами. Миксины — это хороший пример того, как народ неверно интерпритирует концепцию. Изначально они создавались, чтобы выносить какие-то квирки (хаки/костыли/whatever) в отдельные функциональные единицы кода.
.button {
border-radius: 4px;
border: 4px solid black;
}
.search.button {
background-color: blue;
}
.cancel.button {
background-color: red;
}
Не знаю, как с SASS, но LESS позволяет просто сделать так (и я считаю, что это элегантно):
.button {
border-radius: 4px;
border: 4px solid black;
&.search {
background-color: blue;
}
&.cancel {
background-color: red;
}
}
Почему нужно делать именно так? Это банально интуитивнее. Потом, в HTML коде вы будете писать все естественным языком, не городить забор. Взгляните на пример:
<span class="search icon"></span>
<span class="icon-search"></span>
Cогласитесь, первый вариант будет лучше второго, потому что это естественный язык, естественная подача информации. По большому счету, никакого существенного отличия вроде и нет, но разметку писать стало проще понятней и мы не стали плодить сущности с этими вашими миксинами. Миксины — это хороший пример того, как народ неверно интерпритирует концепцию. Изначально они создавались, чтобы выносить какие-то квирки (хаки/костыли/whatever) в отдельные функциональные единицы кода.
stylus:
Раньше тоже пользовался и SASS и LESS но в последнее время Stylus применяю
.button
border-radius 4px
border 4px solid black
.search&
background-color blue
.cancel&
background-color red
Раньше тоже пользовался и SASS и LESS но в последнее время Stylus применяю
Мне как питонисту очень удобен Stylus отсутсвием скобочек и привычные отступы))
Я тоже питонист, но искринне убежден, что определение семантики кода отступами — это самый худший антипаттерн, который когда либо был представлен в пайтоне. Но, опять-таки, все зависит от команды и инструментария. Ящитаю, что LESS лучше читается, чем стилус, хотя первый однозначно не без недостатков.
Ну я в Stylus нашел много хорошего, и выбрал его уже после того как несколько лет пользовался LESS/Sass.
Насчет отступов — я и шаблоны пишу на slm/jade в последнее время))
Python/Django,Flask или Golang, Erlang только для бэкенда с API, а фронт пишу отдельно, используя средства фронт-енд разработки и MVC-фреймворки(это я к тому, что могут возникнуть вопросы почему я пишу шаблоны на slm а не на jinja2 например)
Насчет отступов — я и шаблоны пишу на slm/jade в последнее время))
Python/Django,Flask или Golang, Erlang только для бэкенда с API, а фронт пишу отдельно, используя средства фронт-енд разработки и MVC-фреймворки(это я к тому, что могут возникнуть вопросы почему я пишу шаблоны на slm а не на jinja2 например)
В вашем же примере LESS не получится того, что выше написано на СSS
У вас получится .button.search и .button.cancel а не как выше в CSS .search.button .cancel.button
У вас получится .button.search и .button.cancel а не как выше в CSS .search.button .cancel.button
Но ведь .button.search это тоже самое, что и .search.button. Мой способ же интуитивнее и проще пишется, без горождения заборов с @extend и прочими миксинами.
А, я кажется понял, о чем ты. Да, конечный код будет не 1:1 c указанным листингом на CSS, но суть, я так понимаю, сохраняется. Согласись, это в любом случае лучше того, что автор проталкивает в статье.
По поводу всего этого безобразия у меня есть единственный комментарий: «сами создаём себе проблемы, а потом благополучно их решаем».
Чрезмерное увлечение @extend ведёт к космическому росту количества селекторов и, возможно, проблеме 4096 селектора в IE.
Честно говоря, не понимаю проблемы размера css-файла при использовании примесей. Ведь gzip все это великолепно сожмет же? А большое количество @extend, как верно заметил vdv73rus, может привести к багам в итоге.
Верно, то что имеется куча примесей в less/stylus/sass это не значит что в результате css cкомпилится с кучей этих миксинов.
Миксины имеет смысл создавать когда что-то очень часто повторяется.
Как один из наиболее наглядных примеров плюсов использования миксинов в less/stylus/sass перед использованием чистого сss это конечно использование префиксов браузеров. Например можно сделать миксин типа:
а не расписывать все в кучу строк для каждого браузера.
В СSS это было бы:
Тут же вся фишка не в том какой в результате CSS будет по размеру, а как быстро ты его напишешь.
Миксины имеет смысл создавать когда что-то очень часто повторяется.
Как один из наиболее наглядных примеров плюсов использования миксинов в less/stylus/sass перед использованием чистого сss это конечно использование префиксов браузеров. Например можно сделать миксин типа:
.blur(@blur) {
-webkit-filter: blur(@blur);
-moz-filter: blur(@blur);
-o-filter: blur(@blur);
-ms-filter: blur(@blur);
filter: blur(@blur);
}
// и потом везде писать просто:
.some-class {
.blur(значение);
}
.another-class {
.blur(значение);
}
.one-more-class {
.blur(значение);
}
а не расписывать все в кучу строк для каждого браузера.
В СSS это было бы:
.some-class {
-webkit-filter: blur(значение);
-moz-filter: blur(значение);
-o-filter: blur(значение);
-ms-filter: blur(значение);
filter: blur(значение);
}
.another-class {
-webkit-filter: blur(значение);
-moz-filter: blur(значение);
-o-filter: blur(значение);
-ms-filter: blur(значение);
filter: blur(значение);
}
.one-more-class {
-webkit-filter: blur(значение);
-moz-filter: blur(значение);
-o-filter: blur(значение);
-ms-filter: blur(значение);
filter: blur(значение);
}
Тут же вся фишка не в том какой в результате CSS будет по размеру, а как быстро ты его напишешь.
В 2015 году не надо так. Читайте про autoprefixer.
Это было лишь примером))
вообще у меня в gulpfile автопрефиксер для стилуса стоит:
вообще у меня в gulpfile автопрефиксер для стилуса стоит:
prefixer = require 'autoprefixer-stylus'Есть куда больше разнообразных квирков, которые автопрефиксеры не решают. В данном случае, это просто пример. Суть в том, что миксины не нужны для того, что показал в статье автор.
Sign up to leave a comment.
Как писать более чистый CSS и рациональный SASS