Comments 136
Забавная вещица, пригодится, будем следить за её развитием…
Спасибо что просветили :)
Спасибо что просветили :)
+6
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
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
-6
Позволю себе не согласиться.
Заказчику, к примеру, не столь важно, сколько кода генерирует Sass, Less or Coffee, намного важнее для него, что задача выполнена в срок или даже раньше срока (миф, конечно). Такие инструменты, типа Sass and Coffee, позволяют экономить n-количества времени на «рутинной» работе со стилями и javascript'ами.
Сайты не грузятся дольше и не отрисовуют элементы медленнее, если использовать клиентскую оптимизацию с кешированием и компрессией.
Заказчику, к примеру, не столь важно, сколько кода генерирует Sass, Less or Coffee, намного важнее для него, что задача выполнена в срок или даже раньше срока (миф, конечно). Такие инструменты, типа Sass and Coffee, позволяют экономить n-количества времени на «рутинной» работе со стилями и javascript'ами.
Сайты не грузятся дольше и не отрисовуют элементы медленнее, если использовать клиентскую оптимизацию с кешированием и компрессией.
+4
Простите, а с какой рутинной работой справляется Coffee, с которой не справляются JS-фреймворки?
+1
Количество кода.
-3
Плюс-минус одинаковое. Зато нету такой жести:
Или, например, из-за отказа от «var» теперь нельзя однозначно сказать, в какой области видимости объявленна переменная. Обсуждение растянулось на десятки комментариев, но нормального решения так и не нашли.
Но теперь агрументированно скажите, что может дать CoffeeScript такого, что не может дать «JS с фреймворками». А не отказ от пары ключевых слов за счёт уменьшения понятности и предсказуемости кода.
"http.createServer (request, response) ->
" "http.createServer(request, response) ->
" are two ENTIRELY different things in coffeescript Sigh.
Или, например, из-за отказа от «var» теперь нельзя однозначно сказать, в какой области видимости объявленна переменная. Обсуждение растянулось на десятки комментариев, но нормального решения так и не нашли.
Но теперь агрументированно скажите, что может дать CoffeeScript такого, что не может дать «JS с фреймворками». А не отказ от пары ключевых слов за счёт уменьшения понятности и предсказуемости кода.
+5
Я не сталкивался с проблемами областей видимости, возможно, пока что.
А он ничего не должен давать кроме «отказа от пары ключевых слов» – это сильно экономит время. Плюс синтаксис понятен любому рубисту (насколько я понимаю CoffeeScript ориентирован на Ruby-разработчиков, что бы позволить использовать более-менее схожий синтаксис для frontend и backend).
Насчет понятности и предсказуемости – весьма спорный вопрос и на эту тему можно долго рассуждать.
А он ничего не должен давать кроме «отказа от пары ключевых слов» – это сильно экономит время. Плюс синтаксис понятен любому рубисту (насколько я понимаю CoffeeScript ориентирован на Ruby-разработчиков, что бы позволить использовать более-менее схожий синтаксис для frontend и backend).
Насчет понятности и предсказуемости – весьма спорный вопрос и на эту тему можно долго рассуждать.
+1
т.е. тот факт, что «http.createServer (request, response) ->» и «http.createServer(request, response) ->» — это разные вещи и оно очень непоятно — это спорно. А вы сходу скажете, как правильно написать? А сходу обнаружите ошибку подобного рода в тысячах строках кода?
0
А еще пропущенным пробелом можно /usr удалить.
Для меня CoffeeScript понятен и удобен, мне удобно вместо function(a,b,c) писать (a,b,c) ->, что бы создать класс с наследованием мне нужно написать всего-лишь class MyClass extends MyFirstClass, вместо описания функции с последующим «наследованием» по прототипу и т.д… И самое главное, что я экономлю время на написании кода.
Если Вы находите этот инструмент не удобным – просто не используйте его.
Для меня CoffeeScript понятен и удобен, мне удобно вместо function(a,b,c) писать (a,b,c) ->, что бы создать класс с наследованием мне нужно написать всего-лишь class MyClass extends MyFirstClass, вместо описания функции с последующим «наследованием» по прототипу и т.д… И самое главное, что я экономлю время на написании кода.
Если Вы находите этот инструмент не удобным – просто не используйте его.
+3
что бы создать класс с наследованием мне нужно написать всего-лишь class MyClass extends MyFirstClass, вместо описания функции с последующим «наследованием» по прототипу и т.д…
Coffee справляется с этим лучше, чем MooTools?
Мне просто реально интересно, за что его так любят. Я так и не видел аргументов кроме "->" короче чем «function».
+1
а сильно больше и не надо — сахар, чуть слаще и все
Я знаю, что грех, но иногда использую => для сохранения контекста + возможность перекинуть if & for в конец строки — радует, реально меньше строчек и часто файл умещается в экран
Плюс очень приятные проверки a = obj?.field1?.field2
Код получается простой и понятный и после 2-ух недель на coffeescript.org ты четко понимаешь какую конструкцию в js получишь
PS Меня в нем бесит if a then value1 else value2, вместо прекрасного a? value1: value2, а так все ок
Я знаю, что грех, но иногда использую => для сохранения контекста + возможность перекинуть if & for в конец строки — радует, реально меньше строчек и часто файл умещается в экран
Плюс очень приятные проверки a = obj?.field1?.field2
Код получается простой и понятный и после 2-ух недель на coffeescript.org ты четко понимаешь какую конструкцию в js получишь
PS Меня в нем бесит if a then value1 else value2, вместо прекрасного a? value1: value2, а так все ок
0
/usr не страшно, его можно востановить, а вот если удалить /home…
0
Так ведь очевидно и понятно почему. По крайней мере имея хоть сколько-нибуть опыта написания на CoffeeScript
Ошибку очень легко находить, если контролировать генерируемый JS.
Ошибку очень легко находить, если контролировать генерируемый JS.
0
Если вы пробовали LESS в деле и допустили по ходу дела отпечатку или ошибку в less стиле — весь стиль не будет отработан. Время дебага, как не странно, увеличивается.
0
Вы знакомы с SASS? Кода он генерирует ровно столько, сколько вы напишете. Если поставить задачу минимум — будет столько же сколько и с CSS. Касательно загрузки сайтов — вообще бред, ведь SASS не LESS, пользователь получает готовый CSS-файл. А CSS, на мой взгляд, очень не хватает целого ряда возможностей. Этот язык может быть гораздо гибче, нежели сейчас. Лично я после перехода на SCSS (диалект от SASS) начал верстать раза в 2 быстрее и качественнее.
+6
C LESS тоже может отдаваться готовый CSS-файл
+1
Также на проекте (веб аппликуха) используем SASS — очень удобная штука (без нее наверное бы не справились), интересно, если бы было сравнение LESS'a i SASS'a.
А кода генерирует он немного больше, чем простой CSS, но если грамотно подойти — то все будет хорошо.
А кода генерирует он немного больше, чем простой CSS, но если грамотно подойти — то все будет хорошо.
0
UFO just landed and posted this here
Судя по описанию, LESS по отношению к CSS очень похож на PHP по отношению к HTML когда-то.
Подозреваю, что вскоре «чистый» CSS будет казаться таким же анахронизмом, как статичный html.
Подозреваю, что вскоре «чистый» CSS будет казаться таким же анахронизмом, как статичный html.
+7
Если только сам стандарт не впитает подобную функциональность. Например, где-то, вроде, был черновик для переменных в CSS. И еще много всего интересного предлагалось в разное время.
+4
Нашел кое-что на Хабре даже: habrahabr.ru/blogs/css/112101/
+2
UFO just landed and posted this here
Тому, кто уже слышал о LESS не понаслышке, мой каммент может показаться толстым. Но я пишу не для них, а для тех, кто знакомится с ним через эту статью. Так вот, предупреждаю, если вы не будете предварительно «компилировать» свой LESS-код перед окончательным внедрением в сайт (то есть он будет «компилироваться» клиентским браузером), то при отключении пользователем в бразуере JavaScript-а, отвалится и ваш CSS (в невалидной части).
+11
Для большего понимания, не могли бы вы привести пример ситуации, когда надо процессинг CSS делать на стороне браузера, вместо того, чтобы один раз прогнать через скрипт-сборщик на сервере?
+1
Вообще это не советуется, лучше компилировать файл заранее, но при разработке скриптом пользоваться удобнее.
+1
0
Главная «сборку» забыли:
twitter.github.com/bootstrap/
twitter.github.com/bootstrap/
+4
Я могу ошибаться, но судя по тому, какой код и какие селекторы у вас представлен в примерах, вы не очень заботитесь об оптимизации. Здесь не особо важно уже, как именно вы пишете код — на CSS или на LESS/SASS. Важно то, что очень часто люди, использующие LESS/SASS, пишут тяжелые селекторы, используют каскадность там, где без неё прекрасно можно обойтись, — в угоду лаконичности кода, причем лаконичности только в исходном LESS/SASS файле — а это уже плохо.
+2
Я тоже могу ошибаться, но учитывая опыт последних нескольких проектов (в которых был использован альтернативный, но решающий ту же задачу проект Compass) могу сказать что заметных на глаз проблем с производительностью при отрисовке страниц не было ни в одном браузере.
Думаю что если сравнивать потенциальную дополнительную нагрузку для браузера от «тяжелого» селектора и от скрипта — то последняя будет, как правило, больше.
Зато реализация стилей на LESS (или SASS/SCSS/Compass) позволяет экономить кучу времени на разработке проекта и еще бОльшую кучу сил (и нервов :) ) на его поддержке т.к. позволяет иметь структурированный и разбитый на логические блоки код вместо «спагетти» стилей в которые превращается почти любой изначально хорошо сделанный CSS код после несколько раундов правок и доработок.
Думаю что если сравнивать потенциальную дополнительную нагрузку для браузера от «тяжелого» селектора и от скрипта — то последняя будет, как правило, больше.
Зато реализация стилей на LESS (или SASS/SCSS/Compass) позволяет экономить кучу времени на разработке проекта и еще бОльшую кучу сил (и нервов :) ) на его поддержке т.к. позволяет иметь структурированный и разбитый на логические блоки код вместо «спагетти» стилей в которые превращается почти любой изначально хорошо сделанный CSS код после несколько раундов правок и доработок.
0
В прошлом подобном топике я провёл небольшой эксперимент с компиляцией less файла на лету. В качестве источника был использован страшный жуткий CSS файл в 170 Кб. IE7 грузился порядка 10 секунд, Opera около 20+. Могу скинуть этот файл для сравнения результатов.
0
По-моему подобной функции (компиляции LESS на клиенте) не место на production, а насколько это удобно при разработке — тут видимо решать каждому самостоятельно.
У Compass есть замечательная функция, его можно запустить в режиме отслеживания изменений, при этом на каждое изменение .scss файла в проекте от производит инкрементальную (быструю) компиляцию, так что обычно за время пока я переключаюсь из редактора в браузер и нажимаю там F5 — обновленная версия скомпилированного CSS файла уже лежит в каталоге сайта и, соответственно, подгружается в браузер.
У Compass есть замечательная функция, его можно запустить в режиме отслеживания изменений, при этом на каждое изменение .scss файла в проекте от производит инкрементальную (быструю) компиляцию, так что обычно за время пока я переключаюсь из редактора в браузер и нажимаю там F5 — обновленная версия скомпилированного CSS файла уже лежит в каталоге сайта и, соответственно, подгружается в браузер.
+2
Вы плавно переключились на SCSS, который я люто обожаю, а речь шла о LESS :) Правда у меня машина слабее, поэтому просто альт-табнуться мало, надо подождать полторы секунды. Я не пользовался Compass, но полагаю он использует базовую возможность: sass --watch .scss/.css.
Ещё 1 мелочь. В определённый момент я наткнулся на такое волшебное расширение как CSS Refresh, которое позволяет перегрузить CSS страницы без обновления её самой. Если движок не реактивный, или имеет значение js-окружение, очень помогает. Такое же расширение есть и для chrome.
Ещё 1 мелочь. В определённый момент я наткнулся на такое волшебное расширение как CSS Refresh, которое позволяет перегрузить CSS страницы без обновления её самой. Если движок не реактивный, или имеет значение js-окружение, очень помогает. Такое же расширение есть и для chrome.
+1
Да, LESS я не использовал, синтаксис SCSS показался более логичным, а возможностей побольше. Compass — это в принципе просто framework вокруг SASS предлагающий массу готовых решений типовых задач в виде mixins.
Например:
— готовая и прозрачная кастомизация CSS3 стилей с подстановкой префиксов специфичных для браузера
— работа с CSS Sprites (и их автоматическая генерация)
— и многое другое :)
К примеру SCSS селектор из приведенного вами (в комментарии ниже) примера SCSS кода:
можно было бы оптимизировать в Compass как:
… и обрести независимость от возможных проблем из-за изменений размеров картинки. Или еще лучше:
Например:
— готовая и прозрачная кастомизация 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;
}
+3
В less так же имеется watch mode, работает при использовании компилятора на клиенте (less.js). Для включения, нужно добавить #!watch к URL страницы.
0
Вы не могли бы привести примеры или какие-либо цифры, касательно замедления производительности при не оптимальных css-правилах? Возможно, я ошибаюсь, но мне кажется, что это экономия на спичках на фоне пожара (неоптимизированный js-код, сотни запросов к серверу и т.д.).
0
Согласен, даже если рассматривать только работу подсистемы стилей в браузере то IMHO задача matching'а CSS правил на DOM nodes по затратам никак не может сравниться с задачей отрисовки DOM элементов страницы с наложенными на них CSS стилями. Т.е. например правило:
будет в сумме явно менее затратно чем:
#someElement {
opacity: ...;
background-image: ...;
....
/* а можно и CSS 3D transformations и прочие плюшки ... */
}
будет в сумме явно менее затратно чем:
.one DIV.two SPAN.three ... {
color: green;
}
-1
Чтобы вам было доступнее — давайте вернемся к ассемблеру?
несмотря на то что это оверхед, поддерживаемость и читаемость кода далеко не последние вещи.
несмотря на то что это оверхед, поддерживаемость и читаемость кода далеко не последние вещи.
0
Как увидел заголовок — тут же всплыл в памяти JSS. Попробую как-нибудь в свободное время разобраться с LESS.
P.S. Так же вспомнились мои попытки генерировать CSS с помощью PHP :)
P.S. Так же вспомнились мои попытки генерировать CSS с помощью PHP :)
0
Мне хоть и не очень часто приходится верстать, но когда я писал очередную CSS-простыню (особенно -moz, -ms, -webkit...), я как раз мечтал о таком-вот макро-CSS. Крайне полезная вещь, надо будет опробовать.
А JS-компилятор, на мой взгляд, нужен чисто для отладки: сохранил-посмотрел. В production же такие JS-костыли, разумеется, недопустимы, LESS нужно компилировать в нормальную таблицу стилей, а затем еще и через минимизатор пропускать.
Кстати, наверное немного отстал от жизни, сейчас существуют средства/фреймворки для таблиц стилей, чтобы избавится от рутины (готовый набор layout'ов, мимимизатор)? Пока такие штуки видел только в виде разрозненных web-сервисов.
А JS-компилятор, на мой взгляд, нужен чисто для отладки: сохранил-посмотрел. В production же такие JS-костыли, разумеется, недопустимы, LESS нужно компилировать в нормальную таблицу стилей, а затем еще и через минимизатор пропускать.
Кстати, наверное немного отстал от жизни, сейчас существуют средства/фреймворки для таблиц стилей, чтобы избавится от рутины (готовый набор layout'ов, мимимизатор)? Пока такие штуки видел только в виде разрозненных web-сервисов.
0
Я считаю, что грамотно составленная html-разметка и css в LESS'е не нуждаются.
-5
Как пример:
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 можно просто задать структуру наследования селекторов на этапе разработки.
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 можно просто задать структуру наследования селекторов на этапе разработки.
+2
Т.е. вы считаете этот код прекрасно читабельным? А если там будет вложенность в 4-5 уровней? Да черт голову сломит.
+1
В редакторе, если не скупиться на отступы, это выглядит гораздо лучше. К тому же, никто не заставляет вкладывать все 5 уровней, всякие мелочи можно писать как в обычном CSS.
0
никто не мешает в любой момент выносить вложенность на первый уровень.
Как же читать код завязанный на «табуляции», например python при таком отношении: «А если там будет вложенность в 4-5 уровней? Да черт голову сломит.».
Опять же есть скобки которые заменяют(и подчеркивают уровни вложенности) любое современное ide уже давно подсвечивает начальную и завершающею скобку так что с навигацией по коду проблем нет.
Как же читать код завязанный на «табуляции», например python при таком отношении: «А если там будет вложенность в 4-5 уровней? Да черт голову сломит.».
Опять же есть скобки которые заменяют(и подчеркивают уровни вложенности) любое современное ide уже давно подсвечивает начальную и завершающею скобку так что с навигацией по коду проблем нет.
0
5 уровней вложенности — перебор. Хотя всё что до 7 не вызывает никакой путаницы, в отличии от обычной мешанины CSS (живой пример), с которой мне приходилось сталкиваться (почти всегда это совершенно не рефаторабельный код, только подправить правило или переписать всё с нуля). В случае SASS у меня:
1. полный порядок в коде, живой пример
2. автоматическая сборка, мне проще работать с множеством файлов (особенно если конечный CSS настолько велик, что Netbeans жутко тормозит). о5 же живой пример.
Не стоит боятся применять то, что вы ежедневно используете в программировании (модульность, арифметику, инкапсуляцию и т.д.) в CSS. Многие процессы можно значительно упростить и облегчить и тем самым ускорить разработку. Безусловно, некоторое время понадобится на привыкание, но в данном случае оно сродне наркомании. Я просто не представляю себе как я буду писать какой-нибудь проект без SASS, у меня будет ломка с рвотными порывами (шутка). Это очень и очень удобно.
Не могу не отметить: SASS != CoffeeScript
1. полный порядок в коде, живой пример
2. автоматическая сборка, мне проще работать с множеством файлов (особенно если конечный CSS настолько велик, что Netbeans жутко тормозит). о5 же живой пример.
Не стоит боятся применять то, что вы ежедневно используете в программировании (модульность, арифметику, инкапсуляцию и т.д.) в CSS. Многие процессы можно значительно упростить и облегчить и тем самым ускорить разработку. Безусловно, некоторое время понадобится на привыкание, но в данном случае оно сродне наркомании. Я просто не представляю себе как я буду писать какой-нибудь проект без SASS, у меня будет ломка с рвотными порывами (шутка). Это очень и очень удобно.
Не могу не отметить: SASS != CoffeeScript
0
LESS был бы хорошим плагином для какого-нибудь редактора, не более. Допустим заменять префиксные свойства. А так я не думаю, что он кардинально ускорит верстку. Вот реальным ускорителем можно назвать ZenCodding :)
+1
Думаю бывают ситуации, когда чистый css будет лучше всяких ухищрений типа LESS.
0
Можете продемонстрировать пример подобной ситуации?
+2
Абсолютно. Но LESS ведь не навязывает сам себя, можно в .less писать обычный CSS.
0
Несомненно. Как и ситуации, когда чистый ассемблер будет лучше любых высокоуровневых языков.
0
Некорректное сравнение. Лучше ответьте на вопрос: «Почему дизайнер не программист». И наоборот. Такое конечно встречается, два в одном, но крайне редко.
+1
Ну тут нужно сначала определиться, кто такой дизайнер. Если это человек с сугубо художественными наклонностями, то его инструмент — графический редактор, CSS он не знает. А если под этим подразумевать верстальщика, который может превратить образы в конкретный CSS код, то он от программиста не так уж далёк. Тем более часто люди занимаются фронтендом — как вёрсткой, так и яваскриптом. А это уже программист.
Что до языков — разница не так уж велика. Все люди неспособны держать в голове слишком большие объёмы информации сразу, все выигрывают за счёт использования абстракций, всем проще разобраться в небльшом структурированном объёме информации, чем в километровых листингах. Я считаю, что сравнение может и не точное, но вполне корректное.
Что до языков — разница не так уж велика. Все люди неспособны держать в голове слишком большие объёмы информации сразу, все выигрывают за счёт использования абстракций, всем проще разобраться в небльшом структурированном объёме информации, чем в километровых листингах. Я считаю, что сравнение может и не точное, но вполне корректное.
+1
А чем не вариант использовать классы
А потом, где нужно его подключать. Мне кажется так проще.
.color_blue {color: #019eed;}
.color_blue_no_decor {color: #019eed; text-decoration: none;}
А потом, где нужно его подключать. Мне кажется так проще.
-9
Тем, что .color_blue — само по себе плохое название для класса. Если взять абстрактный header, то в нём могут быть стили из .message, .important-info и т.д. В случае с CSS это значит копипасту, в случае с LESS — повторное использование. То же самое с скруглёнными углами или градиентами в фоне.
LESS не даёт новых возможностей в браузере, так как компилируется в CSS, но позволяет достичь такой лаконичности кода, которая на CSS просто невозможна в силу стандарта.
Возможно, для проекта из 200-300 правил будет достаточно грамотного Code Guide и следования ему всем файлом, плюс нормальное распределение селекторов по блокам, но уверен, что LESS сильно помогает на действительно больших проектах в тысячи селекторов.
LESS не даёт новых возможностей в браузере, так как компилируется в CSS, но позволяет достичь такой лаконичности кода, которая на CSS просто невозможна в силу стандарта.
Возможно, для проекта из 200-300 правил будет достаточно грамотного Code Guide и следования ему всем файлом, плюс нормальное распределение селекторов по блокам, но уверен, что LESS сильно помогает на действительно больших проектах в тысячи селекторов.
+3
.color_blue
— не такое уж и плохое название для класса, как может показаться на первый взгляд.Вот приходит к вам дизайн формы, где есть кнопки 3-ёх размеров и 4-ёх цветов. Как вы назовёте семантически классы для них?
Смотрели исходный код facebook.com? Там семантических названий классов — мм… почти нет. Как думаете, почему?
-2
Да, если это палитра выбора цвета, то color_blue — вполне годное название класса. В примере с формой я бы всё-таки ориентировался на тип кнопок (submit/reset, add/delete и т.п.), а уже в CSS предпочёл бы через перечисление селекторов задать стили сразу для таких-то и таких-то типов кнопок. Кстати, в LESS можно было бы сделать mixin по размерам и цветам и задавать каждому селектору свой набор mixin, без перечисления селекторов и соответственного вычисления пересечения множеств свойств.
Что касается исходников различных проектов вроде fb или google — не всегда организация кода и успешность продукта идут рука об руку, как пример — 1С-Битрикс — продукт вполне успешный и в чём-то даже более удобный, чем конкуренты, но по части качества кода я бы не назвал его таким же успешным. Ещё больший «шок» я испытал, кода пришлось столкнуться с вполне хорошим движком ShopScript — удобный интерфейс держался на глинянных ногах корявого кода.
Что касается исходников различных проектов вроде fb или google — не всегда организация кода и успешность продукта идут рука об руку, как пример — 1С-Битрикс — продукт вполне успешный и в чём-то даже более удобный, чем конкуренты, но по части качества кода я бы не назвал его таким же успешным. Ещё больший «шок» я испытал, кода пришлось столкнуться с вполне хорошим движком ShopScript — удобный интерфейс держался на глинянных ногах корявого кода.
0
И всё же, .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. Всё сразу становится понятным, даже для человека, который первый раз видит ваш код.
Возьмем даже ваш пример — берем основным классом для всех этих кнопок класс .header__button, для трёх различных размеров — добавляем классы .header__button_small, .header__button_normal, .header__button_large, .header__button_blue, .header__button_red, .header__button_green, .header__button_yellow. Всё сразу становится понятным, даже для человека, который первый раз видит ваш код.
0
По личным наблюдениям, чем крупнее проект, тем сложнее соблюсти семантику в классах.
С другой стороны, CSS вовсе не предназначен для описания семантики документа. Его придумали для изменения визуальной составляющей. Поэтому и прокрадываются визуальные словечки в CSS-классы :)
С другой стороны, CSS вовсе не предназначен для описания семантики документа. Его придумали для изменения визуальной составляющей. Поэтому и прокрадываются визуальные словечки в CSS-классы :)
0
с SCSS легко, зачастую очень легко. К примеру у вас есть 20 картинок иконок (не в спрайте), каждая иконка соответствует типу файла, можно сделать так:
А теперь спрайты:
Вообще мелочей, которые легко оптимизировать очень много. Дело вовсе не в семантике, а в том, что работать с .color_blue, li.i_25_19_14 и прочим бредом несколько жутковато.
@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 и прочим бредом несколько жутковато.
0
Так классы/id это сущности не CSS, а HTML, именно оттуда они «прокрадываются» в селекторы (не классы) CSS. Я не знаю как думают дизайнеры и юзабилисты, но лично я при проектировании и структуры, и вида страницы сначала думаю: «нужна кнопка делающая то-то» и потом «лучше если она будет большая и синяя», а не «надо сделать большую синюю кнопку» и потом придумываю ей функциональность (семантику).
Я понимаю, что если вдруг решено часть элементов сделать красными, то присвоить им класс red проще, чем перечислять их полные селекторы в правиле из одного объявления или, тем более, задавать для каждого отдельное правило, да и нагрузка на браузер будет больше. Но это почти ничем не лучше соответствующего style в элементе и на корню рубит главную, имхо, идею использования CSS с HTML- отделение семантики данных от их представления.
Я понимаю, что если вдруг решено часть элементов сделать красными, то присвоить им класс red проще, чем перечислять их полные селекторы в правиле из одного объявления или, тем более, задавать для каждого отдельное правило, да и нагрузка на браузер будет больше. Но это почти ничем не лучше соответствующего style в элементе и на корню рубит главную, имхо, идею использования CSS с HTML- отделение семантики данных от их представления.
0
Вы хотите сказать, что для того чтобы сделать любую синюю кнопку придётся назначать ей класс ".button-save"? :)
Так, как, при создании макета именно на этот класс было назначено нужное оформление.
Так, как, при создании макета именно на этот класс было назначено нужное оформление.
0
Если стоит задача «создать любую синюю кнопку», то что-то пошло не так. Должна стоять создать кнопку «сохранить», к которой есть нюанс — она должна быть синей по дизайну. Чаще всего всё проще:
<button class="tmp_button contact_form_save_button" />
0
Есть такая вещь, как разделение содержания, представления и поведения. Так как в HTML у нас только содержание, то и классы подбираются соответственно содержанию. Благо на уровне представления мы можем практически на каждый элемент в дереве задать свой стиль. Да, в случае использования голого CSS это часто копипаста или куча вспомогательных классов в HTML (возможно они будут иметь семантически верные имена, но если их уже 5-7, это начинает попахивать). И с этой напастью как раз и помогает бороться LESS. Да, в выходящем CSS это всё вновь разворачивается до копипасты, но, во-первых, gzip, а во-вторых, время разработки существенно экономится за счёт понижения сложности.
0
Так есть же такая штука на РНР: 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());
}
+2
Я так понимаю, SASS, LESS и прочие могут быть реализованы браузерами как иной тип таблиц стилей.
Стандарт, по крайней мере позволяет указать иной тип стилей: LinkStyle Interface
Стандарт, по крайней мере позволяет указать иной тип стилей: LinkStyle Interface
+2
Да, господь с вами! 2.1-то еле как начали все поддерживать в полном объеме. Не до жиру…
0
Хотел бы вам возразить, что не в полном, но не удалось вспомнить пример.
Ну по некоторым возможностям браузеры давно дают фору всяким конвенциям w3c, тот же хромовский getCaretRangeFromPoint() чего стоит. Может и нашлась бы группа энтузиастов-апологетов LESS )
Ну по некоторым возможностям браузеры давно дают фору всяким конвенциям w3c, тот же хромовский getCaretRangeFromPoint() чего стоит. Может и нашлась бы группа энтузиастов-апологетов LESS )
0
а как вам
style.css.php
style.css.aspx
style.css.pl
можно же любой файл прогнать через стандартный интерпретатор.
style.css.php
style.css.aspx
style.css.pl
можно же любой файл прогнать через стандартный интерпретатор.
+1
А какой смысл? Неужели:
удобнее чем:
#module_<?php $module ?> {
color: <?php colorable( '#232323', '+', 'red' ); ?>
}
удобнее чем:
#module_#{$module} {
color: #232323 + red;
}
0
у первого варианта есть куча плюсов:
1. всем понятно что там происходит (уж пхп то ...)
2. нет непонятной прослойки с неизвесной поддержкой
3. у клиента всегда будет обычный CSS без фокусов
у второго синтаксический сахар? что бы ктото лишний раз уточнил «что это за такой странный CSS ?»
1. всем понятно что там происходит (уж пхп то ...)
2. нет непонятной прослойки с неизвесной поддержкой
3. у клиента всегда будет обычный CSS без фокусов
у второго синтаксический сахар? что бы ктото лишний раз уточнил «что это за такой странный CSS ?»
0
Если бы я встретил такой CSS-код на php, скорее всего удалил бы не раздумывая. Примерно того же мнения я и о php-шаблонах. Бежать, бежать, выжигая огнём. Есть цивилизованные и удобные решения поставленных задач. Предложенное вами решение годится разве что в качестве заплатки на давно заброшенный проект, в котором, ВНЕЗАПНО, потребовалась какая-нибудь незапланированная ерунда. Представьте в какой ужас превратится ваш php-css файл при попытке достичь хотя бы этого.
По поводу пунктов 2 и 3. Вы имеете представление что такое SCSS или LESS? Или комментируете не глядя?
По поводу пунктов 2 и 3. Вы имеете представление что такое SCSS или LESS? Или комментируете не глядя?
+1
Комментарии всё же закрываются через "*/" ) А не то как скомпилится у пользователя ненароком половина CSS в комментариях…
0
> Я не люблю CSS. Простой и понятный.
facepalm.png
Т.е. тут уже копипаст с гугл-транслэйта одобряется? Не торт.
facepalm.png
Т.е. тут уже копипаст с гугл-транслэйта одобряется? Не торт.
+1
А где лямбда-функции? Подозреваю, что это не настоящий язык.
+1
Вот, набросал давненько вотчер, может кому пригодится
github.com/studentIvan/Perl-LESS-Watcher
github.com/studentIvan/Perl-LESS-Watcher
+1
Кстати, ещё можно через bash отслеживать изменение файла(ов) и компилировать налету в css.
Нужна утилита inotify, забрать можно тут — https://github.com/rvoicilas/inotify-tools/
Вот небольшой примерчик скрипта:
Нужна утилита 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
0
Странно, что не работает, если открывать, например, тестовый .html-файл локально с диска.
А вот если положить его в тот же Dropbox и открыть по публичному адресу — всё работает нормально.
А вот если положить его в тот же Dropbox и открыть по публичному адресу — всё работает нормально.
0
Потребность в подобных инструментах в основном из-за недостаточных знаний CSS, и не достаточного опыта в верстке.
Если правильно группировать селекторы, то переменные не нужны, все и так будет в единственном месте.
Тем не менее, время разработки конечно позволяет экономить — это, часто очень критично.
Если правильно группировать селекторы, то переменные не нужны, все и так будет в единственном месте.
Тем не менее, время разработки конечно позволяет экономить — это, часто очень критично.
+2
По моему мнению SCSS намного мощнее. Как минимум мне не хватает экстендов.
+1
UFO just landed and posted this here
UFO just landed and posted this here
А @if, @for, @each и прочее там планируется, или как?
If'ы в scss бывает, использую.
Циклы не сказать, чтобы часто было нужно, но один раз (один раз где-то за полтора года моего использования sass (теперь уж scss)) мне пригодился @each.
If'ы в scss бывает, использую.
Циклы не сказать, чтобы часто было нужно, но один раз (один раз где-то за полтора года моего использования sass (теперь уж scss)) мне пригодился @each.
0
Хорошая вещь и даже полезная, но меня расстраивает дебаг кода. Допустим, открываем сайт в браузере и смотрим: строка 976, надо для .people .men .kolya добавить/подфиксить какое-то свойство. Открываем less/sass файл, достаем компас и начинаем искать .people, потом внутри него .men (а он ведь может быть и внутри .ussr), и дальше уже .kolya. И все это на какой-то стопиццотой строке. Ну, вы поняли что я хотел сказать. Может, это я что-то не так делаю и все гораздо проще? Пока склоняюсь к чистому CSS, не смотря иногда на жуткую нехватку плюшек less/sass…
0
UFO just landed and posted this here
хотя да, все правильно, можно разбивать на файлы, а потом просто сливать/сжимать все в один на продакшене
0
UFO just landed and posted this here
Не, файлы собираются и сжимаются при билде (.net projects) неплохой штукой YUI Compressor.
@import не хочу
@import не хочу
0
Если файлы будут собираться на клиенте, то может случиться адовый ад. К примеру, у меня их под 70-80. Объективных причин уменьшать их количество нет. Я полагаю что от клиентской загрузки стоит отказаться даже в более простых ситуациях, просто исходя из того, что сие не есть хорошо.
0
В 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 файл.
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 файл.
0
Мне одному Less CSS напоминает чем-то Erlang?
0
очень познавательно — спасибо
0
Решил попробовать, очень понравилось, спасибо за перевод.
0
UFO just landed and posted this here
Ерунда полная. Чтобы изменить моментально во всем коде к примеру цвет есть команда find and replace 1 сек и все изменено. Если у вас код растягивается на 3000 строк дж на крупных проектах, то скорей всего вам не стоит заниматься версткой. Фанатики которым уже просто нечего делать. Пишите весь код в одном CSS файле и будет вам счастье, не занимайтесь ерундой.
0
Автор, параметры в примеси для старичков IE не проблема если воспользоваться обычным стринго-реплейсом:
.gradient(@start, @stop) {
...
filter: e(%(
"progid:DXImageTransform.Microsoft.gradient(startColorstr='%d', endColorstr='%d', GradientType=0)",
@start,
@stop
));
}
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')));
...
});
и подключать в основной проект как обычный файл с расширением .csslink(rel='stylesheet', href='stylesheets/css.css')
Все файлы в папке __dirname + '/public' с расширением .less будут компилироваться в .css 0
а можно некропостинг? хотел уточнить:
>>Пространство имён
>>Также это отличный способ сделать возможным быструю смену и доработку тем.
>>для смены шаблонов на лету, вы можете поместить их все в один LESS файл, используя связки
#fw_1 {… }
#fw_2 {… }
.submit_button {
#fw_2 > .submit;
}
как же мы такое будем менять на лету, если у нас таких submit_button, да любых других селекторов, явно указывающих какая сборка, будет много?
>>Пространство имён
>>Также это отличный способ сделать возможным быструю смену и доработку тем.
>>для смены шаблонов на лету, вы можете поместить их все в один LESS файл, используя связки
#fw_1 {… }
#fw_2 {… }
.submit_button {
#fw_2 > .submit;
}
как же мы такое будем менять на лету, если у нас таких submit_button, да любых других селекторов, явно указывающих какая сборка, будет много?
0
Sign up to leave a comment.
LESS: программируемый язык стилей