Pull to refresh

Comments 136

Забавная вещица, пригодится, будем следить за её развитием…
Спасибо что просветили :)
Less и Sass это извращения на мой взгляд. Код которые они генерируют очень большой, сайты грузятся дольше и отрисовуют элементы медленней.

CSS — очень мощная штука и единственное чего ему не хватает, это наследования.

Кому интересная данная тема, рекомендую ознакомится с докладами Nicole Sullivan
developer.yahoo.com/blogs/ydn/posts/2009/03/website_and_webapp_performance/
www.webstock.org.nz/talks/speakers/nicole-sullivan/css-tools-massive-websites/
www.youtube.com/watch?v=j6sAm7CLoCQ
Позволю себе не согласиться.
Заказчику, к примеру, не столь важно, сколько кода генерирует Sass, Less or Coffee, намного важнее для него, что задача выполнена в срок или даже раньше срока (миф, конечно). Такие инструменты, типа Sass and Coffee, позволяют экономить n-количества времени на «рутинной» работе со стилями и javascript'ами.
Сайты не грузятся дольше и не отрисовуют элементы медленнее, если использовать клиентскую оптимизацию с кешированием и компрессией.
Простите, а с какой рутинной работой справляется Coffee, с которой не справляются JS-фреймворки?
Плюс-минус одинаковое. Зато нету такой жести:
"http.createServer (request, response) ->" "http.createServer(request, response) ->" are two ENTIRELY different things in coffeescript Sigh.


Или, например, из-за отказа от «var» теперь нельзя однозначно сказать, в какой области видимости объявленна переменная. Обсуждение растянулось на десятки комментариев, но нормального решения так и не нашли.

Но теперь агрументированно скажите, что может дать CoffeeScript такого, что не может дать «JS с фреймворками». А не отказ от пары ключевых слов за счёт уменьшения понятности и предсказуемости кода.
Я не сталкивался с проблемами областей видимости, возможно, пока что.

А он ничего не должен давать кроме «отказа от пары ключевых слов» – это сильно экономит время. Плюс синтаксис понятен любому рубисту (насколько я понимаю CoffeeScript ориентирован на Ruby-разработчиков, что бы позволить использовать более-менее схожий синтаксис для frontend и backend).

Насчет понятности и предсказуемости – весьма спорный вопрос и на эту тему можно долго рассуждать.
т.е. тот факт, что «http.createServer (request, response) ->» и «http.createServer(request, response) ->» — это разные вещи и оно очень непоятно — это спорно. А вы сходу скажете, как правильно написать? А сходу обнаружите ошибку подобного рода в тысячах строках кода?
А еще пропущенным пробелом можно /usr удалить.

Для меня CoffeeScript понятен и удобен, мне удобно вместо function(a,b,c) писать (a,b,c) ->, что бы создать класс с наследованием мне нужно написать всего-лишь class MyClass extends MyFirstClass, вместо описания функции с последующим «наследованием» по прототипу и т.д… И самое главное, что я экономлю время на написании кода.

Если Вы находите этот инструмент не удобным – просто не используйте его.
что бы создать класс с наследованием мне нужно написать всего-лишь class MyClass extends MyFirstClass, вместо описания функции с последующим «наследованием» по прототипу и т.д…

Coffee справляется с этим лучше, чем MooTools?
Мне просто реально интересно, за что его так любят. Я так и не видел аргументов кроме "->" короче чем «function».
а сильно больше и не надо — сахар, чуть слаще и все
Я знаю, что грех, но иногда использую => для сохранения контекста + возможность перекинуть if & for в конец строки — радует, реально меньше строчек и часто файл умещается в экран
Плюс очень приятные проверки a = obj?.field1?.field2
Код получается простой и понятный и после 2-ух недель на coffeescript.org ты четко понимаешь какую конструкцию в js получишь

PS Меня в нем бесит if a then value1 else value2, вместо прекрасного a? value1: value2, а так все ок
/usr не страшно, его можно востановить, а вот если удалить /home…
Так ведь очевидно и понятно почему. По крайней мере имея хоть сколько-нибуть опыта написания на CoffeeScript
Ошибку очень легко находить, если контролировать генерируемый JS.
То есть нужно хорошо знать два языка, чтобы писать на одном?
Если вы пробовали LESS в деле и допустили по ходу дела отпечатку или ошибку в less стиле — весь стиль не будет отработан. Время дебага, как не странно, увеличивается.
Вы знакомы с SASS? Кода он генерирует ровно столько, сколько вы напишете. Если поставить задачу минимум — будет столько же сколько и с CSS. Касательно загрузки сайтов — вообще бред, ведь SASS не LESS, пользователь получает готовый CSS-файл. А CSS, на мой взгляд, очень не хватает целого ряда возможностей. Этот язык может быть гораздо гибче, нежели сейчас. Лично я после перехода на SCSS (диалект от SASS) начал верстать раза в 2 быстрее и качественнее.
C LESS тоже может отдаваться готовый CSS-файл
Я в курсе. Но в этом случае, ИМХО, он слабый конкурент SASS(SCSS). Возможно, ему просто нужно время. Туда уже запилили аналог & в SCSS?
Не знаю. Мне понравился LESS тем, что он ближе по синтаксису на SASS, но холиварить не хочу, т.к. второй даже не пробовал
Также на проекте (веб аппликуха) используем SASS — очень удобная штука (без нее наверное бы не справились), интересно, если бы было сравнение LESS'a i SASS'a.

А кода генерирует он немного больше, чем простой CSS, но если грамотно подойти — то все будет хорошо.
UFO just landed and posted this here
Видимо, имелось в виду нечто подобное функционалу LESS, описанному в пункте «Вложенность» )
UFO just landed and posted this here
Судя по описанию, LESS по отношению к CSS очень похож на PHP по отношению к HTML когда-то.

Подозреваю, что вскоре «чистый» CSS будет казаться таким же анахронизмом, как статичный html.
Если только сам стандарт не впитает подобную функциональность. Например, где-то, вроде, был черновик для переменных в CSS. И еще много всего интересного предлагалось в разное время.
UFO just landed and posted this here
Тому, кто уже слышал о LESS не понаслышке, мой каммент может показаться толстым. Но я пишу не для них, а для тех, кто знакомится с ним через эту статью. Так вот, предупреждаю, если вы не будете предварительно «компилировать» свой LESS-код перед окончательным внедрением в сайт (то есть он будет «компилироваться» клиентским браузером), то при отключении пользователем в бразуере JavaScript-а, отвалится и ваш CSS (в невалидной части).
Вообще, использовать клиентский интерпретатор удобно для девелопмента — не надо на каждый чих лезть в косоль. На продакшене же нужно иметь скомпилированную статику.
зачем в консоль, по крайней мере для винды есть WinLESS, эта тулза детектит изменения less файлов и автоматом ребилдит css. Удобно.
Ну его нафиг, чтоб какой-то «беспобедный» демон сидел в памяти :)
У вас хорошо получилось. Первый раз слышу! Буду начинать использовать! Спасибо!
Для большего понимания, не могли бы вы привести пример ситуации, когда надо процессинг CSS делать на стороне браузера, вместо того, чтобы один раз прогнать через скрипт-сборщик на сервере?
Вообще это не советуется, лучше компилировать файл заранее, но при разработке скриптом пользоваться удобнее.
Мне кажется, это единственная конкурентная черта less перед sass. Я не прав? Прошлый раз когда я разбирался с его синтаксисом, мне он показался намного менее продуманным и функциональным, нежели scss.
Я могу ошибаться, но судя по тому, какой код и какие селекторы у вас представлен в примерах, вы не очень заботитесь об оптимизации. Здесь не особо важно уже, как именно вы пишете код — на CSS или на LESS/SASS. Важно то, что очень часто люди, использующие LESS/SASS, пишут тяжелые селекторы, используют каскадность там, где без неё прекрасно можно обойтись, — в угоду лаконичности кода, причем лаконичности только в исходном LESS/SASS файле — а это уже плохо.
Я тоже могу ошибаться, но учитывая опыт последних нескольких проектов (в которых был использован альтернативный, но решающий ту же задачу проект Compass) могу сказать что заметных на глаз проблем с производительностью при отрисовке страниц не было ни в одном браузере.

Думаю что если сравнивать потенциальную дополнительную нагрузку для браузера от «тяжелого» селектора и от скрипта — то последняя будет, как правило, больше.

Зато реализация стилей на LESS (или SASS/SCSS/Compass) позволяет экономить кучу времени на разработке проекта и еще бОльшую кучу сил (и нервов :) ) на его поддержке т.к. позволяет иметь структурированный и разбитый на логические блоки код вместо «спагетти» стилей в которые превращается почти любой изначально хорошо сделанный CSS код после несколько раундов правок и доработок.
В прошлом подобном топике я провёл небольшой эксперимент с компиляцией less файла на лету. В качестве источника был использован страшный жуткий CSS файл в 170 Кб. IE7 грузился порядка 10 секунд, Opera около 20+. Могу скинуть этот файл для сравнения результатов.
По-моему подобной функции (компиляции LESS на клиенте) не место на production, а насколько это удобно при разработке — тут видимо решать каждому самостоятельно.

У Compass есть замечательная функция, его можно запустить в режиме отслеживания изменений, при этом на каждое изменение .scss файла в проекте от производит инкрементальную (быструю) компиляцию, так что обычно за время пока я переключаюсь из редактора в браузер и нажимаю там F5 — обновленная версия скомпилированного CSS файла уже лежит в каталоге сайта и, соответственно, подгружается в браузер.
Вы плавно переключились на SCSS, который я люто обожаю, а речь шла о LESS :) Правда у меня машина слабее, поэтому просто альт-табнуться мало, надо подождать полторы секунды. Я не пользовался Compass, но полагаю он использует базовую возможность: sass --watch .scss/.css.

Ещё 1 мелочь. В определённый момент я наткнулся на такое волшебное расширение как CSS Refresh, которое позволяет перегрузить CSS страницы без обновления её самой. Если движок не реактивный, или имеет значение js-окружение, очень помогает. Такое же расширение есть и для chrome.
Да, LESS я не использовал, синтаксис SCSS показался более логичным, а возможностей побольше. Compass — это в принципе просто framework вокруг SASS предлагающий массу готовых решений типовых задач в виде mixins.

Например:
— готовая и прозрачная кастомизация CSS3 стилей с подстановкой префиксов специфичных для браузера
— работа с CSS Sprites (и их автоматическая генерация)
— и многое другое :)

К примеру SCSS селектор из приведенного вами (в комментарии ниже) примера SCSS кода:

.login_key {
			background: url($image_dir + 'login_key.png') no-repeat;
			float: left;
			width: 17px;
			height: 11px;
			margin: 3px 10px 0 0;
		}


можно было бы оптимизировать в Compass как:

.login_key {
  $image: 'login_key.png';
  background: image-url($image) no-repeat;
  width: image-width($image);
  height: image-height($image);
  float: left;
  margin: 3px 10px 0 0;
}


… и обрести независимость от возможных проблем из-за изменений размеров картинки. Или еще лучше:

@mixin image($image) {
    width: image-width($image);
    height: image-height($image);
    background: image-url($image) no-repeat;
    display: block;
    overflow: hidden;
    text-align: left;
    text-indent: -10000px;
}

.login_key {
  @include image('login_key.png');
  float: left;
  margin: 3px 10px 0 0;
}
Ух ты. А вот это уже интересно, я думал. что Compass просто обёртка с mixin-ами. Надо будет попробовать.
В less так же имеется watch mode, работает при использовании компилятора на клиенте (less.js). Для включения, нужно добавить #!watch к URL страницы.
Вы не могли бы привести примеры или какие-либо цифры, касательно замедления производительности при не оптимальных css-правилах? Возможно, я ошибаюсь, но мне кажется, что это экономия на спичках на фоне пожара (неоптимизированный js-код, сотни запросов к серверу и т.д.).
Согласен, даже если рассматривать только работу подсистемы стилей в браузере то IMHO задача matching'а CSS правил на DOM nodes по затратам никак не может сравниться с задачей отрисовки DOM элементов страницы с наложенными на них CSS стилями. Т.е. например правило:

#someElement {
  opacity: ...;
  background-image: ...;
  ....
  /* а можно и CSS 3D transformations и прочие плюшки ... */
}


будет в сумме явно менее затратно чем:

.one DIV.two SPAN.three ...  {
  color: green;
}

Чтобы вам было доступнее — давайте вернемся к ассемблеру?
несмотря на то что это оверхед, поддерживаемость и читаемость кода далеко не последние вещи.
Как увидел заголовок — тут же всплыл в памяти JSS. Попробую как-нибудь в свободное время разобраться с LESS.
P.S. Так же вспомнились мои попытки генерировать CSS с помощью PHP :)
Мне хоть и не очень часто приходится верстать, но когда я писал очередную CSS-простыню (особенно -moz, -ms, -webkit...), я как раз мечтал о таком-вот макро-CSS. Крайне полезная вещь, надо будет опробовать.

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

Кстати, наверное немного отстал от жизни, сейчас существуют средства/фреймворки для таблиц стилей, чтобы избавится от рутины (готовый набор layout'ов, мимимизатор)? Пока такие штуки видел только в виде разрозненных web-сервисов.
…(готовый набор layout'ов, мимимизатор)…

Опечатка или так задумано? :)
Я считаю, что грамотно составленная html-разметка и css в LESS'е не нуждаются.
Как пример:
css

#page{
margin:0;
}
#page h1{
font-size:160%;
}
#page h1 a{
color:#fff;
text-decoration:none;
}

less

#page{
margin:0;
  h1{
   font-size:160%;
   a{
    color:#fff;
    text-decoration:none;
   }
 }
}

Без каких либо особых плюшек less можно просто задать структуру наследования селекторов на этапе разработки.
Т.е. вы считаете этот код прекрасно читабельным? А если там будет вложенность в 4-5 уровней? Да черт голову сломит.
В редакторе, если не скупиться на отступы, это выглядит гораздо лучше. К тому же, никто не заставляет вкладывать все 5 уровней, всякие мелочи можно писать как в обычном CSS.
никто не мешает в любой момент выносить вложенность на первый уровень.
Как же читать код завязанный на «табуляции», например python при таком отношении: «А если там будет вложенность в 4-5 уровней? Да черт голову сломит.».
Опять же есть скобки которые заменяют(и подчеркивают уровни вложенности) любое современное ide уже давно подсвечивает начальную и завершающею скобку так что с навигацией по коду проблем нет.
5 уровней вложенности — перебор. Хотя всё что до 7 не вызывает никакой путаницы, в отличии от обычной мешанины CSS (живой пример), с которой мне приходилось сталкиваться (почти всегда это совершенно не рефаторабельный код, только подправить правило или переписать всё с нуля). В случае SASS у меня:
1. полный порядок в коде, живой пример
2. автоматическая сборка, мне проще работать с множеством файлов (особенно если конечный CSS настолько велик, что Netbeans жутко тормозит). о5 же живой пример.

Не стоит боятся применять то, что вы ежедневно используете в программировании (модульность, арифметику, инкапсуляцию и т.д.) в CSS. Многие процессы можно значительно упростить и облегчить и тем самым ускорить разработку. Безусловно, некоторое время понадобится на привыкание, но в данном случае оно сродне наркомании. Я просто не представляю себе как я буду писать какой-нибудь проект без SASS, у меня будет ломка с рвотными порывами (шутка). Это очень и очень удобно.

Не могу не отметить: SASS != CoffeeScript
Мы немного про другую вложенность говорим, ну да ладно. Я не против ..SS-подобных и уже присматривался к ним, но пока все не решусь. Подумаем еще.
LESS был бы хорошим плагином для какого-нибудь редактора, не более. Допустим заменять префиксные свойства. А так я не думаю, что он кардинально ускорит верстку. Вот реальным ускорителем можно назвать ZenCodding :)
Zen Coding. Действительно ускоряет работу и привносит удобства написания маркапа.

less заинтересовал, как и sass.
Думаю бывают ситуации, когда чистый css будет лучше всяких ухищрений типа LESS.
Можете продемонстрировать пример подобной ситуации?
Абсолютно. Но LESS ведь не навязывает сам себя, можно в .less писать обычный CSS.
Несомненно. Как и ситуации, когда чистый ассемблер будет лучше любых высокоуровневых языков.
Некорректное сравнение. Лучше ответьте на вопрос: «Почему дизайнер не программист». И наоборот. Такое конечно встречается, два в одном, но крайне редко.
Ну тут нужно сначала определиться, кто такой дизайнер. Если это человек с сугубо художественными наклонностями, то его инструмент — графический редактор, CSS он не знает. А если под этим подразумевать верстальщика, который может превратить образы в конкретный CSS код, то он от программиста не так уж далёк. Тем более часто люди занимаются фронтендом — как вёрсткой, так и яваскриптом. А это уже программист.
Что до языков — разница не так уж велика. Все люди неспособны держать в голове слишком большие объёмы информации сразу, все выигрывают за счёт использования абстракций, всем проще разобраться в небльшом структурированном объёме информации, чем в километровых листингах. Я считаю, что сравнение может и не точное, но вполне корректное.
А чем не вариант использовать классы

.color_blue {color: #019eed;}
.color_blue_no_decor {color: #019eed; text-decoration: none;}


А потом, где нужно его подключать. Мне кажется так проще.

Тем, что .color_blue — само по себе плохое название для класса. Если взять абстрактный header, то в нём могут быть стили из .message, .important-info и т.д. В случае с CSS это значит копипасту, в случае с LESS — повторное использование. То же самое с скруглёнными углами или градиентами в фоне.

LESS не даёт новых возможностей в браузере, так как компилируется в CSS, но позволяет достичь такой лаконичности кода, которая на CSS просто невозможна в силу стандарта.

Возможно, для проекта из 200-300 правил будет достаточно грамотного Code Guide и следования ему всем файлом, плюс нормальное распределение селекторов по блокам, но уверен, что LESS сильно помогает на действительно больших проектах в тысячи селекторов.
.color_blue — не такое уж и плохое название для класса, как может показаться на первый взгляд.

Вот приходит к вам дизайн формы, где есть кнопки 3-ёх размеров и 4-ёх цветов. Как вы назовёте семантически классы для них?

Смотрели исходный код facebook.com? Там семантических названий классов — мм… почти нет. Как думаете, почему?
Да, если это палитра выбора цвета, то color_blue — вполне годное название класса. В примере с формой я бы всё-таки ориентировался на тип кнопок (submit/reset, add/delete и т.п.), а уже в CSS предпочёл бы через перечисление селекторов задать стили сразу для таких-то и таких-то типов кнопок. Кстати, в LESS можно было бы сделать mixin по размерам и цветам и задавать каждому селектору свой набор mixin, без перечисления селекторов и соответственного вычисления пересечения множеств свойств.

Что касается исходников различных проектов вроде fb или google — не всегда организация кода и успешность продукта идут рука об руку, как пример — 1С-Битрикс — продукт вполне успешный и в чём-то даже более удобный, чем конкуренты, но по части качества кода я бы не назвал его таким же успешным. Ещё больший «шок» я испытал, кода пришлось столкнуться с вполне хорошим движком ShopScript — удобный интерфейс держался на глинянных ногах корявого кода.
И всё же, .color_blue — плохое название. Название класса для элемента в первую очередь должно служить пояснением, для чего этот элемент вообще нужен на странице и что он из себя представляет.

Возьмем даже ваш пример — берем основным классом для всех этих кнопок класс .header__button, для трёх различных размеров — добавляем классы .header__button_small, .header__button_normal, .header__button_large, .header__button_blue, .header__button_red, .header__button_green, .header__button_yellow. Всё сразу становится понятным, даже для человека, который первый раз видит ваш код.
По личным наблюдениям, чем крупнее проект, тем сложнее соблюсти семантику в классах.

С другой стороны, CSS вовсе не предназначен для описания семантики документа. Его придумали для изменения визуальной составляющей. Поэтому и прокрадываются визуальные словечки в CSS-классы :)
с SCSS легко, зачастую очень легко. К примеру у вас есть 20 картинок иконок (не в спрайте), каждая иконка соответствует типу файла, можно сделать так:
@each $name in png, gif, jpeg, ..., txt
{
  .icon_#{$name} { background-image: url(#{name}.png); }
}

А теперь спрайты:

$i: 0;
@each $name in png, gif, jpeg, ..., txt
{
  .icon_#{$name} { background-position: left $i; }
  $i: $i - 16px;
}

Вообще мелочей, которые легко оптимизировать очень много. Дело вовсе не в семантике, а в том, что работать с .color_blue, li.i_25_19_14 и прочим бредом несколько жутковато.
Так классы/id это сущности не CSS, а HTML, именно оттуда они «прокрадываются» в селекторы (не классы) CSS. Я не знаю как думают дизайнеры и юзабилисты, но лично я при проектировании и структуры, и вида страницы сначала думаю: «нужна кнопка делающая то-то» и потом «лучше если она будет большая и синяя», а не «надо сделать большую синюю кнопку» и потом придумываю ей функциональность (семантику).

Я понимаю, что если вдруг решено часть элементов сделать красными, то присвоить им класс red проще, чем перечислять их полные селекторы в правиле из одного объявления или, тем более, задавать для каждого отдельное правило, да и нагрузка на браузер будет больше. Но это почти ничем не лучше соответствующего style в элементе и на корню рубит главную, имхо, идею использования CSS с HTML- отделение семантики данных от их представления.
Вы хотите сказать, что для того чтобы сделать любую синюю кнопку придётся назначать ей класс ".button-save"? :)

Так, как, при создании макета именно на этот класс было назначено нужное оформление.
Если стоит задача «создать любую синюю кнопку», то что-то пошло не так. Должна стоять создать кнопку «сохранить», к которой есть нюанс — она должна быть синей по дизайну. Чаще всего всё проще:
&ltbutton class="tmp_button contact_form_save_button" />
Есть такая вещь, как разделение содержания, представления и поведения. Так как в HTML у нас только содержание, то и классы подбираются соответственно содержанию. Благо на уровне представления мы можем практически на каждый элемент в дереве задать свой стиль. Да, в случае использования голого CSS это часто копипаста или куча вспомогательных классов в HTML (возможно они будут иметь семантически верные имена, но если их уже 5-7, это начинает попахивать). И с этой напастью как раз и помогает бороться LESS. Да, в выходящем CSS это всё вновь разворачивается до копипасты, но, во-первых, gzip, а во-вторых, время разработки существенно экономится за счёт понижения сложности.
Так есть же такая штука на РНР: lessphp. Её прелесть в том, что не надо ставить никаких программ и т.д. — просто в IDE жамкнуть run less.php и всё. Содержимое less.php (для тех кому лень копаться с документации):
chdir(dirname(__FILE__));
include 'lessphp/lessc.inc.php';

try {
    lessc::ccompile('basic.less.css', 'basic.css');
    print "<p>success: <a href='basic.css'>basic.css</a></p>\n";

    lessc::ccompile('global.less.css', 'global.css');
    print "<p>success: <a href='global.css'>global.css</a></p>\n";
}
catch (exception $ex) {
    exit($ex->getMessage());
}

А он уже в полном объёме поддерживает LESS? Просто когда я его щупал, поддержка LESS была очень ограниченной, в итоге пришлось пользоваться less-компилятором на node.js.
Я так понимаю, SASS, LESS и прочие могут быть реализованы браузерами как иной тип таблиц стилей.
Стандарт, по крайней мере позволяет указать иной тип стилей: LinkStyle Interface
Да, господь с вами! 2.1-то еле как начали все поддерживать в полном объеме. Не до жиру…
Хотел бы вам возразить, что не в полном, но не удалось вспомнить пример.
Ну по некоторым возможностям браузеры давно дают фору всяким конвенциям w3c, тот же хромовский getCaretRangeFromPoint() чего стоит. Может и нашлась бы группа энтузиастов-апологетов LESS )
а как вам
style.css.php
style.css.aspx
style.css.pl

можно же любой файл прогнать через стандартный интерпретатор.
А какой смысл? Неужели:
#module_<?php $module ?> {
  color: <?php colorable( '#232323', '+', 'red' ); ?>
}

удобнее чем:
#module_#{$module} {
  color: #232323 + red;
}
у первого варианта есть куча плюсов:
1. всем понятно что там происходит (уж пхп то ...)
2. нет непонятной прослойки с неизвесной поддержкой
3. у клиента всегда будет обычный CSS без фокусов

у второго синтаксический сахар? что бы ктото лишний раз уточнил «что это за такой странный CSS ?»
Если бы я встретил такой CSS-код на php, скорее всего удалил бы не раздумывая. Примерно того же мнения я и о php-шаблонах. Бежать, бежать, выжигая огнём. Есть цивилизованные и удобные решения поставленных задач. Предложенное вами решение годится разве что в качестве заплатки на давно заброшенный проект, в котором, ВНЕЗАПНО, потребовалась какая-нибудь незапланированная ерунда. Представьте в какой ужас превратится ваш php-css файл при попытке достичь хотя бы этого.

По поводу пунктов 2 и 3. Вы имеете представление что такое SCSS или LESS? Или комментируете не глядя?
если вам потребовалась какая то логика в CSS наверно что то не так с проэктом :) что такое LESS я посмотрел. любопытно интересно но не более.
CSS это описание представления, а логика представления вполне имеет право на существование и, желательно, должна быть отделена от другой логики.
Комментарии всё же закрываются через "*/" ) А не то как скомпилится у пользователя ненароком половина CSS в комментариях…
> Я не люблю CSS. Простой и понятный.
facepalm.png

Т.е. тут уже копипаст с гугл-транслэйта одобряется? Не торт.
Я не люблю гугл-транслейт. Хотя это я что-то не очень по русски написал. Кстати вышеупомянутый инструмент сделал бы это так: Мне не нравится, CSS. Просто и понятно. Это заставляет мир вращаться в Интернете, но язык носит ограничительный характер и трудно управлять.
А где лямбда-функции? Подозреваю, что это не настоящий язык.
Кстати, ещё можно через bash отслеживать изменение файла(ов) и компилировать налету в css.
Нужна утилита inotify, забрать можно тут — https://github.com/rvoicilas/inotify-tools/
Вот небольшой примерчик скрипта:
#!/bin/sh
# перехватываем событие изменения файлов less и компилируем наш основной less файл в css
while inotifywait -e modify ./*.less; do
    lessc -x ./style.less > ./../css/style.css
done
Странно, что не работает, если открывать, например, тестовый .html-файл локально с диска.
А вот если положить его в тот же Dropbox и открыть по публичному адресу — всё работает нормально.
Потребность в подобных инструментах в основном из-за недостаточных знаний CSS, и не достаточного опыта в верстке.
Если правильно группировать селекторы, то переменные не нужны, все и так будет в единственном месте.

Тем не менее, время разработки конечно позволяет экономить — это, часто очень критично.
UFO just landed and posted this here
Часто группирую такие места, и пока рекорд 34-ре элемента.
А вообще редко бывает необходимость больше 15-20 — вполне приемлемо и читаемо.

А вот когда такой избыток элементов, что аж 150500 — это явно не тривиальный случай.
По моему мнению SCSS намного мощнее. Как минимум мне не хватает экстендов.
UFO just landed and posted this here
мне не нужен mixin, мне нужен @extend как в SCSS. Что тут не понятного?
UFO just landed and posted this here
Если для меня есть разница, то наверное у меня была ситуация для которой не подходили @mixin. Если на ваш взгляд это одно и тоже, то удачи вам, пользуйтесь тем что есть.
UFO just landed and posted this here
Спасибо за то, что ты обьяснил мне это, но я и так это знал.
Вопрос, в less добавили аналог & в SCSS?
UFO just landed and posted this here
UFO just landed and posted this here
О, спасибо за наводку, искал что-нибудь подобное для убунту.
UFO just landed and posted this here
А @if, @for, @each и прочее там планируется, или как?
If'ы в scss бывает, использую.
Циклы не сказать, чтобы часто было нужно, но один раз (один раз где-то за полтора года моего использования sass (теперь уж scss)) мне пригодился @each.
UFO just landed and posted this here
UFO just landed and posted this here
Кстати @if очень хорошая штука для реализации mixin-ов с утиной типизацией (или как там она называется, ака jQuery).
Хорошая вещь и даже полезная, но меня расстраивает дебаг кода. Допустим, открываем сайт в браузере и смотрим: строка 976, надо для .people .men .kolya добавить/подфиксить какое-то свойство. Открываем less/sass файл, достаем компас и начинаем искать .people, потом внутри него .men (а он ведь может быть и внутри .ussr), и дальше уже .kolya. И все это на какой-то стопиццотой строке. Ну, вы поняли что я хотел сказать. Может, это я что-то не так делаю и все гораздо проще? Пока склоняюсь к чистому CSS, не смотря иногда на жуткую нехватку плюшек less/sass…
UFO just landed and posted this here
хотя да, все правильно, можно разбивать на файлы, а потом просто сливать/сжимать все в один на продакшене
UFO just landed and posted this here
Не, файлы собираются и сжимаются при билде (.net projects) неплохой штукой YUI Compressor.

@import не хочу
UFO just landed and posted this here
Если вы пришли к сжатию css файлов (и скорее всего js), то использование less или sass легко впишется в вашу автоматизацию. В частности сборка единого css файла будет проведена именно ими.
Если файлы будут собираться на клиенте, то может случиться адовый ад. К примеру, у меня их под 70-80. Объективных причин уменьшать их количество нет. Я полагаю что от клиентской загрузки стоит отказаться даже в более простых ситуациях, просто исходя из того, что сие не есть хорошо.
В SCSS есть плагин для Firebug, зовётся firesass. Позволяет указывать в CSS поле в файрбаге scss-файл и номер строки, отвечающей за сие правило. К сожалению в файрбаге выше 1.9.2 (или даже чуть ниже) пока не работает. Раньше пользовался, потом «проапгрыжился» и пришёл к 1-му простому выводу — такой функционал (необходимость знать номер строк и файл) нужен именно для CSS файлов в виду ряда причин. В SCSS файлах этот функционал весьма вторичен. Пара причин:

1. К примеру, правило #feedback .js_link {} однозначно располагается в файла modules/feedback.scss, в то время как в CSS-случае оно было бы в общем файле style.css (не делать же 999 css файлов издеваясь над браузером пользователя).
2. В 99% случаев мне нужно что-то изменить в CSS правиле именно тогда, когда я только что работал с нужным мне SCSS кодом. Проще говоря мне достаточно нажать Alt-tab. Ничего искать не нужно.
3. В редких запущенных случаях я просто прохожусь поиском по файлам в папке где размещены scss файлы. В Netbeans это занимает от силы 2-3 секунды.

В общем — номер строки и имя файла полезный функционал, но имея под рукой такой огромный и удобный арсенал, необходимость в этой функции сильно уменьшается. Про less файлы я такого увы сказать не могу, хотя бы исходя из того, что вижу им единственное применение — компиляция в браузере пользователя, а это подразумевает под собой ряд неудобств, главное из которых — 1 здоровенный less файл.
Мне одному Less CSS напоминает чем-то Erlang?
Решил попробовать, очень понравилось, спасибо за перевод.
UFO just landed and posted this here
Ерунда полная. Чтобы изменить моментально во всем коде к примеру цвет есть команда find and replace 1 сек и все изменено. Если у вас код растягивается на 3000 строк дж на крупных проектах, то скорей всего вам не стоит заниматься версткой. Фанатики которым уже просто нечего делать. Пишите весь код в одном CSS файле и будет вам счастье, не занимайтесь ерундой.
то есть бутстрап создан фанатиками которым уже нечего делать? Попробуйте прежде, а потом говорите. А если попробовали — еще раз попробуйте, видимо не распробовали.
Автор, параметры в примеси для старичков IE не проблема если воспользоваться обычным стринго-реплейсом:

.gradient(@start, @stop) {
  ...
  filter: e(%(
        "progid:DXImageTransform.Microsoft.gradient(startColorstr='%d', endColorstr='%d', GradientType=0)",
        @start,
        @stop 
  ));
}
To один способ только что нашел на StackOverflow:
.gradient(@start, @stop) {
  ...
  filter: ~"progid:DXImageTransform.Microsoft.gradient(
                startColorstr='@{start}', 
                endColorstr='@{stop}', 
                GradientType=0)";
}

В дополнение я советую не использовать LESS файл. В этом нет ничего плохого, но нет причины загружать LESS файл и обрабатывать его. Несомненно, скрипт очень быстрый, но я уверен что без него будет быстрее. Я обычно разрабатываю все мои сайты с LESS, беру выходной файл, сжимаю его и использую обычный CSS файл.

Я использую LESS файлы в Node.js используя lessMiddleware. Достаточно подключить
var express = require('express')
  , ...
  , lessMiddleware = require('less-middleware')
var app = express();
app.configure(function () {
  ...
  app.use(lessMiddleware(__dirname + '/public'));
  app.use(express.static(path.join(__dirname, 'public')));
  ...
});
и подключать в основной проект как обычный файл с расширением .css
link(rel='stylesheet', href='stylesheets/css.css')
Все файлы в папке __dirname + '/public' с расширением .less будут компилироваться в .css
а можно некропостинг? хотел уточнить:
>>Пространство имён
>>Также это отличный способ сделать возможным быструю смену и доработку тем.
>>для смены шаблонов на лету, вы можете поместить их все в один LESS файл, используя связки
#fw_1 {… }
#fw_2 {… }

.submit_button {
#fw_2 > .submit;
}

как же мы такое будем менять на лету, если у нас таких submit_button, да любых других селекторов, явно указывающих какая сборка, будет много?
Sign up to leave a comment.

Articles