Comments 88
Существует приложение для локальной компиляции файлов SASS в CSS. Кроссплатформенное, но платное.
Прозвучало так, будто приложение для компиляции sass в css платно. Это не так. Платная графическая обёртка над бесплатным компилятором. Зачем она нужна, не совсем ясно.
избавить нас от использования префиксов сможет только официальный выход CSS3
Боюсь что нет, ибо официальный выход css3 не значит немедленное обновление все браузеров юзерами. У нас даже ie6 еще виден на горизонте, козалось бы уже и не поддерживают его верстальщики и юзеры должны были обновится, ан нет, висит, в Росии его конечно меньше но вот если брать статистику мирвого использования то это 1.6% примерно
UFO just landed and posted this here
Я не могу понять, это я уже слишком старый и не воспринимаю новые тенденции и людям действительно проще использовать сторонние сервисы для генерации трех строчек кода с префиксами? Вроде бы они не настолько быстро меняются… Да и нужных свойств этих, с префиксами, раз-два и обчелся. Вон, тот же бордер-радиус, из примера, давно уже без префиксов работает (там где он вообще работает), их разве что для более полной совместимости их оставить можно.
Но статья, тем не менее, интересная и добротная, однозначный плюс.
Но статья, тем не менее, интересная и добротная, однозначный плюс.
Для компиляции LESS на Винде использую замечательную тулзу — winless.org/ (умеет автоматически перекомпилировать файлы, мониторя папку с *.less файлами на наличие изменений
Для генерации css файла иногда используют тот же самый язык, на котором работает сайт. Например, PHP в embedded-стиле:
Для поддерджи префиксов браузеров можно написать отдельные переменные или функции для свойств, или же прогнать результат через регулярное выражение. Сгенерированный css складывается в докрут или кешируется веб-сервером.
Преимущества: просто в реализации, быстро генерируется; гибкость, можно использовать всю мощь языка и даже использовать БД; не нужно знать дополнительные языки разметки; не нужно устанавливать дополнительные интерпретаторы; независим от яваскрипта; можно оставлять невидимые клиенту комментарии.
Недостатки: не подходит для верстальщиков, не знакомых с языком; зависимость безопасности от верстальщика; трудно читается, особенно в редакторе без корректной подсветки синтаксиса; задача осложняется, если проект имеет компонентную структуру.
<?php
// пример с потолка
$clbg = '#FFF';
$clfg = '#000';
$border = 'border: 1px black solid; border-radius: 5px; margin: 0;';
$shadow = 'box-shadow: 0 0 10px rgba(0,0,0,0.5)';
?>
body {background-color: <?=$clbg?>; color: <?=$clfg?>;}
.coment {<?=$border?>; <?=$shadow?>;}
<?for($i=0;$i<10;$i++):?>
.items > .item-<?=$i?> {postition: absolute; top: 0; left: <?=$i*200+100?>px;}
<?endfor;?>
Для поддерджи префиксов браузеров можно написать отдельные переменные или функции для свойств, или же прогнать результат через регулярное выражение. Сгенерированный css складывается в докрут или кешируется веб-сервером.
Преимущества: просто в реализации, быстро генерируется; гибкость, можно использовать всю мощь языка и даже использовать БД; не нужно знать дополнительные языки разметки; не нужно устанавливать дополнительные интерпретаторы; независим от яваскрипта; можно оставлять невидимые клиенту комментарии.
Недостатки: не подходит для верстальщиков, не знакомых с языком; зависимость безопасности от верстальщика; трудно читается, особенно в редакторе без корректной подсветки синтаксиса; задача осложняется, если проект имеет компонентную структуру.
Ужас какой. Если Вам нужно использовать всю мощь языка и тем более использовать БД для генерации СSS — you are doing it wrong. Для компиляции LESS->CSS существует lessphp — написав под него простейшую обертку, можно получить все описанные Вами «преимущества» использования PHP, за исключением «использовать всю мощь языка и даже использовать БД» (но я не представляю, где это может понадобиться)
Вся мощь языка это ведь не только БД и ООП, но и такие замечательные вещи, как функции для работы со строками и массивами, регулярные выражения, и многое другое. Хорошо, БД не нужна. Опустим случаи, когда надо периодически пересобирать CSS в зависимости от каких-то состояний, для этого, вероятно, будет лучше написать что-то более организованное. Но зачем множить сущее без необходимости? Зачем подключать библиотеку, писать для неё обертку, потом интегрировтаь в систему, для решения такой простой задачи, как константы, функции и циклы в css?
Приведите пример, в котором вам нужны будут циклы и регулярные выражения в css?
UFO just landed and posted this here
В примере кода выше есть цикл.
А вообще я не понимаю необходимость введения такой сущности как less (в связке с lessphp), если в проекте нет разделения труда верстальщика и программиста. Просто программист-верстальщик должен выучить ещё один язык, хотя мог бы обойтись связкой css+php, без лишней сущности в виде less и связанного с ним инструментария.
А вообще я не понимаю необходимость введения такой сущности как less (в связке с lessphp), если в проекте нет разделения труда верстальщика и программиста. Просто программист-верстальщик должен выучить ещё один язык, хотя мог бы обойтись связкой css+php, без лишней сущности в виде less и связанного с ним инструментария.
Я «выучил» LESS за пять минут, просто открыв главный сайт проекта.
Пример с циклом — чисто синтетический, я не могу представить задачи, в которой некий список состоял бы из десятка жестко зашитых иконок, например. Как не могу представить, зачем в СSS могут понадобиться операции со строками и регулярными выражениями.
Я могу оправдать такой подход в случае очень простых стилей, иначе — все равно придется писать в каждом файле кучу велосипедных функций, чтобы сымитировать нечто подобное по удобству тем же mixins
Пример с циклом — чисто синтетический, я не могу представить задачи, в которой некий список состоял бы из десятка жестко зашитых иконок, например. Как не могу представить, зачем в СSS могут понадобиться операции со строками и регулярными выражениями.
Я могу оправдать такой подход в случае очень простых стилей, иначе — все равно придется писать в каждом файле кучу велосипедных функций, чтобы сымитировать нечто подобное по удобству тем же mixins
Пример: сделать так, чтобы левое меню выглядело, как сегмент круга, с возможностью настраивать степень выпуклости.
Решение:
Решение:
<html>
<head>
<style>
<?$k=50;?>
.item {border: 1px red solid; border-radius: 5px; height: 20px; line-height: 20px; text-align: right;}
<?for ($i=0; $i<30; $i++):?>
.item-<?=$i?> {width: <?=100+sin($i/30*3.14)*$k?>px;}
<?endfor;?>
</style>
</head>
<body>
<?for($i=0;$i<30;$i++):?>
<div class="item item-<?=$i?>">Menu item <?=$i?></div>
<?endfor;?>
</body>
</html>Округлить width забыл, простите мне этот огрех.
Пример интересный, спасибо. Сделать подобное на less нельзя.
Но мы, кажется, говорим о немного разных вещах. LESS — это не «константы, циклы и функции в CSS», это просто инструмент для удобства. LESS не дает больше возможностей, чем CSS. Пример с сайта
а можно написать даже
Ну да, можно, конечно, написать кучу функций на PHP, которые делали бы тоже самое или похожее. Но зачем изобретать велосипед, еще и жертвуя при этом читабельностью? Неужели не проще написать
?
Но мы, кажется, говорим о немного разных вещах. LESS — это не «константы, циклы и функции в CSS», это просто инструмент для удобства. LESS не дает больше возможностей, чем CSS. Пример с сайта
@nice-blue: #5B83AD;
@light-blue: @nice-blue + #111;
#header { color: @light-blue; }
а можно написать даже
@blue: #5B83AD;
#header { color: lighten(@blue, 10%); }
Ну да, можно, конечно, написать кучу функций на PHP, которые делали бы тоже самое или похожее. Но зачем изобретать велосипед, еще и жертвуя при этом читабельностью? Неужели не проще написать
color: (@blue + #111)*110%;
color: multiply_colors(add_colors($blue, "#11"), "110%");
?
Спасибо за конструктивный ответ. Да, для таких задач придется написать пару функций. Хотя, можно схитрить и использовать грязные хаки, вроде rgb-нотации и implode. Насчет читабельности полностью согласен, это недостаток, PHP режет глаз.
Ну собственно, пришли к тому, о чем я говорил — проще подключить готовую отработанную библиотеку, чем переизобретать на грязных хаках «свой LESS, только с функциями и массивами». Более того, никто же не мешает сделать всё на LESS, а «меню в виде полукруга» вставить маленьким кусочком PHP. Более того, lessphp даже позволяет вытащить в PHP-код переменные и константы из распарсенного .less
Не совсем так. Если верстальщику нужны константы и работа с цветами — тогда да, можно использовать эту библиотеку. Если нужны возможности языка программирования — тогда нет. Две функции для работы с цветами написать проще, чем рассчитывать итерации вручную. Это даже велосипедом трудно назвать, скорее бытовая ситуация, обычный скриптинг. Вот так, к примеру, выглядит работа с цветами в пространстве hsl:
<?
$blue = $blueLight = array(200,50,50);
$blueLight[2]+=30;
function hsl($hsl) {
return "hsl({$hsl[0]},{$hsl[1]}%,{$hsl[2]}%)";
}
function hslLight($hsl, $k) {
$hsl[2]=min(100, max($hsl[2]+$k, 0));
return "hsl({$hsl[0]},{$hsl[1]}%,{$hsl[2]}%)";
}
?>
.item {border: 1px <?=hslLight($blue, -20)?> solid;}
.item-1 {width: 1px; color: <?=hsl($blue)?>; background-color: <?=hsl($blueLight)?>;}
Ну в том же SASS есть основные возможности языка программирования — циклы, массивы, функции, математика итд. При сохранении читабельности кода. Разве что компилироваться дольше будет, чем чистый PHP, но это врядли можно назвать весомым недостатком — можно ведь закешировать результат обработки
Главный недостаток SAAS и т. п. лично для меня — вроде есть основные возможности ЯП, но они в вакууме: нет возможности передать параметры извне и, тем более, нет биндингов к популярным и личным библиотекам. То есть эти почти ЯП являются практически нерасширяемыми DSL. Они хорошо справляются с задачей выполнения принципа DRY и повышения уровня абстракции при написании статических CSS правил, но плохо с их динамической генерацией.
Конечно, можно написать скрипты на sh/bash, php, ruby, python, c++, которые в ответ на htpp запрос GET /style.less будут выдавать динамически генерируемый less-код, интерпретируемый на стороне клиента или выдавать компилированный css, но, имхо, это излишний оверхид ради профита в виде возможности преодолеть недостатки CSS.
Конечно, можно написать скрипты на sh/bash, php, ruby, python, c++, которые в ответ на htpp запрос GET /style.less будут выдавать динамически генерируемый less-код, интерпретируемый на стороне клиента или выдавать компилированный css, но, имхо, это излишний оверхид ради профита в виде возможности преодолеть недостатки CSS.
Возможно. Но все же такие задачи, ИМХО, возникают редко.
В lessphp, кстати, возможность передать параметры извне присутствует:
Да, возможно это оверхед. Но лично я готов слегка пожертвовать скоростью в обмен читабельный, удобный и поддерживаемый код.
В lessphp, кстати, возможность передать параметры извне присутствует:
$less = new lessc("myfile.less");
echo $less->parse(null, array('color' => 'blue'));
Да, возможно это оверхед. Но лично я готов слегка пожертвовать скоростью в обмен читабельный, удобный и поддерживаемый код.
*в обмен на
Не знал, если честно. Но тогда наш спор заключается в том, стоит ли вводить дополнительный уровень абстракции между PHP и CSS? :)
Нуу, да :) Хотя как я уже говорил, лично мне еще не попадались задачи, где нужно передавать параметры из PHP в CSS
Возможно вы просто не знаете, что ваши пользователи применяют к вашим приложениям всякие userjs и custom css ;)
Вот лично я бы хотел, чтобы в настройках хабра была возможность некоторые параметры CSS поправить на свое усмотрение, включая цвета, но не хочется свой браузер отягощать расширениями, применимыми только к одному сайту.
Вот лично я бы хотел, чтобы в настройках хабра была возможность некоторые параметры CSS поправить на свое усмотрение, включая цвета, но не хочется свой браузер отягощать расширениями, применимыми только к одному сайту.
Мне пару раз пригодились в подобных ситуациях:
Регулярные выражения я использую в «баннерорезках». Что-то вроде
@each $name in math, rus, eng, kaz, ... {
.subject_#{$name} { background: url( '/some/' + $name + '.png'; }
}Регулярные выражения я использую в «баннерорезках». Что-то вроде
*[id*=banner] { display:none; }Суть LESS и SASS — предельно понятный, лаконичный и приятный код, имеющий гораздо большую гибкость, нежели обычный CSS. Приведённый вами код беспредельно ужасен, ctrl + a && del. Отдельно хочу отметить что за «использование БД в CSS» надо проводить «серьёзные разговоры» о профпригодности, ибо это не просто нарушение MVC, а терминальная стадия хаоса.
А циклы, условия, математика есть и в SCSS, SASS.
А циклы, условия, математика есть и в SCSS, SASS.
Простите меня за профнепригодность. Даже константы для CSS нельзя хранить? Почему в файле можно хранить, а в MongoDB, к примеру, нельзя?
Model-view-controller. Вы же не пишете так (надеюсь):
<?php
$id = '2C00012f231241'; ?>
<p style="<? implode(';', $style ) ?>">
<a href="<? $db->get( 'article', array( '_id' => $id ), 'href' ) ?>">Перейти</a>
</p>
Сарказм понятен, я тоже от такого плевался. Но какое отношение это имеет к генерации CSS на стороне сервера и хранению цветов в базе?
Кстати, если в классе $article, инстансы которого передаются во вью, я для метода getHref() использую lazy load, то это свидетельствует о необходимости «серьезного разговора»? А если я не использовал, а потом кто-то в результате профилирования увидел, что getHref() используется в одном вью из 100500, куда передаётся article, сделал на getHref() отложенную загрузку, то кто из нас не пригоден?
href не очень удачный пример, конечно, а вот например, $article->getAuthor()->getName(), где User::getName() в 100499 шаблонах не используется.
href не очень удачный пример, конечно, а вот например, $article->getAuthor()->getName(), где User::getName() в 100499 шаблонах не используется.
Тут надо смотреть конкретную ситуацию. Но так или иначе XLST-головного-мозга приучил меня к тому, что все данные для генерации HTML-кода нужно получать заранее. Сколько бы грязи на XSLT не лили, он идеален для организации дисциплины :)
C XSLT, да, без этого не обойтись (кажется, но вроде в xslt для PHP4 была возможность «инжектить» в код XSLT шаблона переменные и вызовы PHP, может и для 5 такая возможность есть). Может в деталях ошибаюсь, давно было как я пытался сделать CMS с использованием XSLT, тогда PHP5 на хостингах был экзотикой.
И (отвечая на коммент ниже) в теории, да, желательно подготовить для view всё необходимые ему данные в готовом виде в отдельном от модели (в терминах MVC) виде, вроде даже паттерн такой есть типа модель домена, контроллер, модель вида и вид. Но на практике шаблонизатор на стороне клиента приводит к большим ограничениям к этому клиенту и профанации идеи тонкого контроллера (куча присваиваний типа
Когда-то (году так в 2005) меня сильно увлекла идея клиентской шаблонизации, но от неё отказался в силу слабой поддержки XSLT браузерами (то есть вроде задекларирована, но нюансов тьма, начиная от того, что часть браузеров не воспринимала content-type xml/* и <?xml version=«1.0» encoding=«UTF-8»?>) и сложности разработки кроссбраузерного JS решения, учитывая возможность отключенного JS, которая актуальна и сейчас.
И (отвечая на коммент ниже) в теории, да, желательно подготовить для view всё необходимые ему данные в готовом виде в отдельном от модели (в терминах MVC) виде, вроде даже паттерн такой есть типа модель домена, контроллер, модель вида и вид. Но на практике шаблонизатор на стороне клиента приводит к большим ограничениям к этому клиенту и профанации идеи тонкого контроллера (куча присваиваний типа
$view_data.article.author.name = $article.getAuthor().getName() тонкости не способствуют).Когда-то (году так в 2005) меня сильно увлекла идея клиентской шаблонизации, но от неё отказался в силу слабой поддержки XSLT браузерами (то есть вроде задекларирована, но нюансов тьма, начиная от того, что часть браузеров не воспринимала content-type xml/* и <?xml version=«1.0» encoding=«UTF-8»?>) и сложности разработки кроссбраузерного JS решения, учитывая возможность отключенного JS, которая актуальна и сейчас.
Кстати, по поводу «все данные для генерации HTML-кода нужно получать заранее». В теории это может вас привести к возможности организации крутого VIEW на стороне браузера, что может сильно разгрузить сервер. Такое может Jade.
Стоит задача: юзер может производить тонкий тюнинг цветовой схемы приложения, то есть определять все «семантические» цвета (как в OS/DE или IDE). По-моему, хранение цветов в базе и генерация индивидуального CSS на её основе в таком случае куда больше отвечает концепции отделения данных от представления, чем встраивание индивидуальных стилей в HTML-страницу, их динамическое получение посредством XHR и переопределение дефолтных стилей «на лету» или предварительное создание кучи классов типа color-0f45ab, назначение их элементам и определение правил для них в громадном css с 16+ миллионов правил.
Можно эту задачу решить посредством less/sass? Без динамической генерации индивидуальных less на стороне сервера посредством php, конечно :)
Можно эту задачу решить посредством less/sass? Без динамической генерации индивидуальных less на стороне сервера посредством php, конечно :)
UFO just landed and posted this here
Задача интересная. При помощи SASS такое можно решить только путём дин.генерации SASS файла с константами. При помощи LESS эту задачу можно решить на стороне клиента без дин.генерации (насколько я знаю там доступен js-код, так что достаточно просто опеределить js-переменные). Об этом вам лучше расскажет Punk UndeaD. На PHP такое реализовать тоже можно, но я бы даже думать не стал, ибо совершенно нечитабельная масса.
На мой взгляд такая задача должна решаться просто по старинке. Единожды генерируется итоговый css при каждой смене константы, которые в дальнейшем и скармливается браузеру. И волки сыты (производительность, читаемость и пр.) и овцы целы (весь функционал доступен).
Многое зависит от задачи. Если речь идёт о замене 3-4 цветов то можно просто пройтись регуляркой. Но в любом случае я бы не стал использовать php-шаблоны. Скажу честно, меня от одного их вида выворачивает на изнанку. И вроде бы таких как я много.
На мой взгляд такая задача должна решаться просто по старинке. Единожды генерируется итоговый css при каждой смене константы, которые в дальнейшем и скармливается браузеру. И волки сыты (производительность, читаемость и пр.) и овцы целы (весь функционал доступен).
Многое зависит от задачи. Если речь идёт о замене 3-4 цветов то можно просто пройтись регуляркой. Но в любом случае я бы не стал использовать php-шаблоны. Скажу честно, меня от одного их вида выворачивает на изнанку. И вроде бы таких как я много.
Префиксы вещь хорошая. Они помогают производителям браузеров в реализации новых возможностей.
Как? Как они им помогают?
UFO just landed and posted this here
Какие именно уникальные воможности, по сравнению с однократной серверной генерацией?
UFO just landed and posted this here
Это можно реализовать и на серверной стороне.
Вот подгонка стилей к размеру окна/экрана — задача, где без JS не обойтись.
Вот подгонка стилей к размеру окна/экрана — задача, где без JS не обойтись.
UFO just landed and posted this here
Потому что это медленно?
UFO just landed and posted this here
Скажите, а давно вы видели старые PIII или PIV? У нас вот на работе у многих. Многие проблемы, которые надо решать по мере поступления, вы не заметите, но заметят другие. Лично у меня был случай когда неплохой js-код выполнялся за 30мс, а у коллегии за 14400мс. Отключив firebug мы получили цифру в 300мс. На IE7 тестить побоялись…
UFO just landed and posted this here
У меня на работе чуть-чуть сильнее (Core 2Duo 1.8). Именно на нём был 30мс :) Так что нет.
Тут ещё нужно сравнивать объём оперативки. Заметил большую разницу при работе только в браузере между AMD Athlon64 3200+ c 1 ГБ и с 4, но практически не заметил при переходе на AMD A4-3400 с теми же (вернее ddr3 1333 vc ddr 400) 4 ГБ со встроенной графикой. Разница заметна только на сайтах с флэшем и дискретной графикой от nVidia.
А как по мне, так прозрачная и логичная разработка в рамках HTTP+HTML это прежде всего минимизация клиентской обработки. JS, XHR, websokets и т. п. — это костыли, призванные сгладить недостатки HTTP+HTML и профанирующие концепцию тонкого клиента. Нужно или отказываться от неё в сторону предоставления серверами лишь совместно используемых клиентами данных (грубо говоря, сервера обеспечивают только доступ к СУБД) и соответствующего изменения клиентов, чтобы не возникало необходимости писать клиентский код на минимум трех (HTML/CSS/JS) языках (а ещё HAML/..., SASS/LESS/..., CofeeScript/Dart/… ), либо подводить технические возможности серверов и сети к тому, что обработка локальных событий на сервере будет незаметна для пользователя. Гибридные решения, имхо, прежде всего сочетают недостатки оригиналов, а лишь потом достоинства и актуальны только в ситуации когда чистые решения по каким-то «искусственным» (читай — уровнем развития массово доступных технологий ) не приемлемы.
Большая часть таких задач (вроде цветовая схема) жутко специфична, нет никакой сложности написать нужный js-код вручную. Какой резон терпеть столь страшные тормоза для такой мелочи? Только не настаивайте на том, что тормозов нет, я вам ещё тогда их показал :)
Может я что-то не понимаю, но что мешает не используя никаких дополнительных инструментов нажимать Ctrl+D и менять одно слово?..
UFO just landed and posted this here
В итоге всё равно будет дублирование. Разница только в том, что без использования JS вы *никак* не нагрузите пользовательский браузер.
UFO just landed and posted this here
Передавать разметку минимально необходимое зло, если мы не хотим ограничиться CLI режимом у клиента или передачей .bmp с сервера. :) Я знаю, что это несколько противоречит моим вышевысказанным идеям о желательности минимизации обработки либо на клиенте, либо на сервере, но я не фанат, для всего есть разумные пределы, сейчас, имхо, они перейдены — минимум три языка для интерпретации клиентом и формирование исходников этих трёх языков на сервере или девелоперской машине с, как правило, привлечением ещё нескольких — явный перебор. По-моему, отрасль веб-разработки застоялась в связи с необходимостью соблюдать BC со стандартами «тысячелетней» (если считать от HTML 4.01, CSS2 и JS 1.5) давности.
UFO just landed and posted this here
Насчёт синтаксиса согласен. По крайней мере часть из него я пытался без задней мысли использовать в CSS в своё время и был удивлён, что он не понимает выражений типа 100px+10px, не говоря о 100px+10% или main_width+10%*side_width. Но огорчает, что для внедрения очевидных расширений синтаксиса нужно пользоваться костылями типа компиляции на для сервера или прикручивания костылей к клиенту.
Отрасль, да, несётся в плане появления новых концепций (или появления технических возможностей для реализации старых концепций), но эти концепции реализуются на базе старых парадигм. В моём понимании создавать сейчас RIA на базе HTTP/HTML/CSS/JS это примерно то же самое, что писать в ОО-стиле на Ассемблере, Си или PHP3 — возможно, но требует усилий не относящихся к конечной задаче, относящихся к формированию среды для решения задачи, но не к самому решению.
В принципе уже сейчас есть общий знаменатель хотя бы для клиентской части — DOM. Но разве это нормально, что одну его часть мы описываем на одном языке, другую на другом, а манипуляции с этими двумя частями на третьем? Плюс вводим новые языки для более удобной (в некоторых случаях) манипуляции. Причём попытки отдельных разработчиков реализовать RIA приложение с максимальным использованием только одного языка вызывают, почти гарантированно, реакцию со стороны некоторых других «говнокод». Причём не важно, состоит ли html-документ, по сути, из одного script, формирующего 100500 DOM, или из 100500 DOM, переключаемых одним скриптом, или из 100500 стилей, применяемых к одному DOM в результате которых 100499/100500 частей одной DOM становятся display:none.
Отрасль, да, несётся в плане появления новых концепций (или появления технических возможностей для реализации старых концепций), но эти концепции реализуются на базе старых парадигм. В моём понимании создавать сейчас RIA на базе HTTP/HTML/CSS/JS это примерно то же самое, что писать в ОО-стиле на Ассемблере, Си или PHP3 — возможно, но требует усилий не относящихся к конечной задаче, относящихся к формированию среды для решения задачи, но не к самому решению.
В принципе уже сейчас есть общий знаменатель хотя бы для клиентской части — DOM. Но разве это нормально, что одну его часть мы описываем на одном языке, другую на другом, а манипуляции с этими двумя частями на третьем? Плюс вводим новые языки для более удобной (в некоторых случаях) манипуляции. Причём попытки отдельных разработчиков реализовать RIA приложение с максимальным использованием только одного языка вызывают, почти гарантированно, реакцию со стороны некоторых других «говнокод». Причём не важно, состоит ли html-документ, по сути, из одного script, формирующего 100500 DOM, или из 100500 DOM, переключаемых одним скриптом, или из 100500 стилей, применяемых к одному DOM в результате которых 100499/100500 частей одной DOM становятся display:none.
Подскажите, пожалуйста, консольную утилиту для компиляции css. Можно ли как-нибудь приспособить simpless?
* компиляции less. Прошу прощения.
Можете за 5 минут склепать такую из php.exe+php.dll+lessphp.
Вроде такой штукой пользовлался. На мой less оно выдавало кучу ошибок… Разбираться не стал, откопал simpless и на скорую руку там получал один нужный файлик со стилями, без всяких проблем.
А вообще, такой вариант вполне бы устроил, но он сыпал ошибками. Попробую еще, конечно…
ps: Less App, кстати, тоже ошибками засыпал. :D
А вообще, такой вариант вполне бы устроил, но он сыпал ошибками. Попробую еще, конечно…
ps: Less App, кстати, тоже ошибками засыпал. :D
Ставишь node.js для винды и npm, потом делаешь npm install less и что-то типа:
"C:/Program Files (x86)/nodejs/lessc.cmd" public/js/bootstrap/bootstrap.less > public/css/style.css
Неплохо бы рассмотреть достоинства и недостатки подготовки (допустим, автоматической) различных css-файлов для различных браузеров, и выбор файла на стороне http-сервера в зависимости от user-agent. Например, тот же php-скрипт, который с site.css делает HTTP 302/301 Redirect на site-${useragent}.css
Из недостатков, кажется, только пользователи, которые сменили себе user-agent и у них сайт будет отображаться неправильно.
Но они сами себе злобные буратино, верно?
Из недостатков, кажется, только пользователи, которые сменили себе user-agent и у них сайт будет отображаться неправильно.
Но они сами себе злобные буратино, верно?
Верно, если пользователи изменили агент на некорректный, то выдавать ему дефолтный css. Если изменили на корректный — значит хотели этого, получите и распишитесь. Причём, управлять выдачей можно не на бекенде, а прямо на сервере, например в Nginx «if ( $http_user_agent ~ MSIE )».
Менять user agent может и прокси-сервер, за которым сидит куча народу с разными браузерами. Ну или просто кэшировать результаты для одного браузера и выдавать их другим.
У prefixr есть плагин и для subline text 2.
www.prefixr.com/api/usage/ ссылку я давал в тексте, там для многих редакторов.
Такое ощущение, что только в виде плагинов prefixr можно получить префиксы в свой редактор. Думал, все разнообразнее будет.
Такое ощущение, что только в виде плагинов prefixr можно получить префиксы в свой редактор. Думал, все разнообразнее будет.
Sign up to leave a comment.
CSS3: жизнь без префиксов