CSS3: жизнь без префиксов

[EvilShadow]

Существует приложение для локальной компиляции файлов SASS в CSS. Кроссплатформенное, но платное.

Прозвучало так, будто приложение для компиляции sass в css платно. Это не так. Платная графическая обёртка над бесплатным компилятором. Зачем она нужна, не совсем ясно.

[makzimko]

избавить нас от использования префиксов сможет только официальный выход CSS3

[Seldon]

Боюсь что нет, ибо официальный выход css3 не значит немедленное обновление все браузеров юзерами. У нас даже ie6 еще виден на горизонте, козалось бы уже и не поддерживают его верстальщики и юзеры должны были обновится, ан нет, висит, в Росии его конечно меньше но вот если брать статистику мирвого использования то это 1.6% примерно

[kyrie]

Я не могу понять, это я уже слишком старый и не воспринимаю новые тенденции и людям действительно проще использовать сторонние сервисы для генерации трех строчек кода с префиксами? Вроде бы они не настолько быстро меняются… Да и нужных свойств этих, с префиксами, раз-два и обчелся. Вон, тот же бордер-радиус, из примера, давно уже без префиксов работает (там где он вообще работает), их разве что для более полной совместимости их оставить можно.

Но статья, тем не менее, интересная и добротная, однозначный плюс.

[b3atb0x]

Для компиляции LESS на Винде использую замечательную тулзу — winless.org/ (умеет автоматически перекомпилировать файлы, мониторя папку с *.less файлами на наличие изменений

[Stdit]

Для генерации css файла иногда используют тот же самый язык, на котором работает сайт. Например, PHP в embedded-стиле:

<?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 складывается в докрут или кешируется веб-сервером.

Преимущества: просто в реализации, быстро генерируется; гибкость, можно использовать всю мощь языка и даже использовать БД; не нужно знать дополнительные языки разметки; не нужно устанавливать дополнительные интерпретаторы; независим от яваскрипта; можно оставлять невидимые клиенту комментарии.

Недостатки: не подходит для верстальщиков, не знакомых с языком; зависимость безопасности от верстальщика; трудно читается, особенно в редакторе без корректной подсветки синтаксиса; задача осложняется, если проект имеет компонентную структуру.

[ZimM]

Ужас какой. Если Вам нужно использовать всю мощь языка и тем более использовать БД для генерации СSS — you are doing it wrong. Для компиляции LESS->CSS существует lessphp — написав под него простейшую обертку, можно получить все описанные Вами «преимущества» использования PHP, за исключением «использовать всю мощь языка и даже использовать БД» (но я не представляю, где это может понадобиться)

[Stdit]

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

[ZimM]

Приведите пример, в котором вам нужны будут циклы и регулярные выражения в css?

[VolCh]

В примере кода выше есть цикл.

А вообще я не понимаю необходимость введения такой сущности как less (в связке с lessphp), если в проекте нет разделения труда верстальщика и программиста. Просто программист-верстальщик должен выучить ещё один язык, хотя мог бы обойтись связкой css+php, без лишней сущности в виде less и связанного с ним инструментария.

[ZimM]

Я «выучил» LESS за пять минут, просто открыв главный сайт проекта.
Пример с циклом — чисто синтетический, я не могу представить задачи, в которой некий список состоял бы из десятка жестко зашитых иконок, например. Как не могу представить, зачем в СSS могут понадобиться операции со строками и регулярными выражениями.
Я могу оправдать такой подход в случае очень простых стилей, иначе — все равно придется писать в каждом файле кучу велосипедных функций, чтобы сымитировать нечто подобное по удобству тем же mixins

[Stdit]

Пример: сделать так, чтобы левое меню выглядело, как сегмент круга, с возможностью настраивать степень выпуклости.
Решение:

<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>

Каково будет ваше решение на lessphp?

[Stdit]

Округлить width забыл, простите мне этот огрех.

[ZimM]

Пример интересный, спасибо. Сделать подобное на less нельзя.
Но мы, кажется, говорим о немного разных вещах. 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%");

?

[Stdit]

Спасибо за конструктивный ответ. Да, для таких задач придется написать пару функций. Хотя, можно схитрить и использовать грязные хаки, вроде rgb-нотации и implode. Насчет читабельности полностью согласен, это недостаток, PHP режет глаз.

[ZimM]

Ну собственно, пришли к тому, о чем я говорил — проще подключить готовую отработанную библиотеку, чем переизобретать на грязных хаках «свой LESS, только с функциями и массивами». Более того, никто же не мешает сделать всё на LESS, а «меню в виде полукруга» вставить маленьким кусочком PHP. Более того, lessphp даже позволяет вытащить в PHP-код переменные и константы из распарсенного .less

[Stdit]

Не совсем так. Если верстальщику нужны константы и работа с цветами — тогда да, можно использовать эту библиотеку. Если нужны возможности языка программирования — тогда нет. Две функции для работы с цветами написать проще, чем рассчитывать итерации вручную. Это даже велосипедом трудно назвать, скорее бытовая ситуация, обычный скриптинг. Вот так, к примеру, выглядит работа с цветами в пространстве 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)?>;}

Таким образом, самый существенный недостаток такого подхода — это внешний вид кода.

[ZimM]

Ну в том же SASS есть основные возможности языка программирования — циклы, массивы, функции, математика итд. При сохранении читабельности кода. Разве что компилироваться дольше будет, чем чистый PHP, но это врядли можно назвать весомым недостатком — можно ведь закешировать результат обработки

[VolCh]

Главный недостаток SAAS и т. п. лично для меня — вроде есть основные возможности ЯП, но они в вакууме: нет возможности передать параметры извне и, тем более, нет биндингов к популярным и личным библиотекам. То есть эти почти ЯП являются практически нерасширяемыми DSL. Они хорошо справляются с задачей выполнения принципа DRY и повышения уровня абстракции при написании статических CSS правил, но плохо с их динамической генерацией.

Конечно, можно написать скрипты на sh/bash, php, ruby, python, c++, которые в ответ на htpp запрос GET /style.less будут выдавать динамически генерируемый less-код, интерпретируемый на стороне клиента или выдавать компилированный css, но, имхо, это излишний оверхид ради профита в виде возможности преодолеть недостатки CSS.

[ZimM]

Возможно. Но все же такие задачи, ИМХО, возникают редко.
В lessphp, кстати, возможность передать параметры извне присутствует:

$less = new lessc("myfile.less");
echo $less->parse(null, array('color' => 'blue'));

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

[ZimM]

*в обмен на

[VolCh]

Не знал, если честно. Но тогда наш спор заключается в том, стоит ли вводить дополнительный уровень абстракции между PHP и CSS? :)

[ZimM]

Нуу, да :) Хотя как я уже говорил, лично мне еще не попадались задачи, где нужно передавать параметры из PHP в CSS

[VolCh]

Возможно вы просто не знаете, что ваши пользователи применяют к вашим приложениям всякие userjs и custom css ;)

Вот лично я бы хотел, чтобы в настройках хабра была возможность некоторые параметры CSS поправить на свое усмотрение, включая цвета, но не хочется свой браузер отягощать расширениями, применимыми только к одному сайту.

[ZimM]

ТруЪ :) Надо тогда еще сделать, чтобы по умолчанию хабр был без CSS вообще, и чтобы нормально им пользоваться, каждый должен будет написать свой CSS. Это круче любой каптчи :D

[VolCh]

:)
>чтобы нормально им пользоваться

Это уже обфускация получится. Вроде как одно из правил то ли веб-вёрстки, то ли веб-дизайна (скорее вёрстки), гласит, что страница должна выглядить нормально и быть хоть как-то юзабельна, даже если браузер не понимает CSS в принципе.

[faiwer]

Мне пару раз пригодились в подобных ситуациях:

@each $name in math, rus, eng, kaz, ... {
  .subject_#{$name} { background: url( '/some/' + $name + '.png'; }
}

Регулярные выражения я использую в «баннерорезках». Что-то вроде

*[id*=banner] { display:none; }

[faiwer]

Суть LESS и SASS — предельно понятный, лаконичный и приятный код, имеющий гораздо большую гибкость, нежели обычный CSS. Приведённый вами код беспредельно ужасен, ctrl + a && del. Отдельно хочу отметить что за «использование БД в CSS» надо проводить «серьёзные разговоры» о профпригодности, ибо это не просто нарушение MVC, а терминальная стадия хаоса.

А циклы, условия, математика есть и в SCSS, SASS.

[Stdit]

Простите меня за профнепригодность. Даже константы для CSS нельзя хранить? Почему в файле можно хранить, а в MongoDB, к примеру, нельзя?

[faiwer]

Model-view-controller. Вы же не пишете так (надеюсь):

<?php 
  $id = '2C00012f231241'; ?>
  <p style="<? implode(';', $style ) ?>">
    <a href="<? $db->get( 'article', array( '_id' => $id ), 'href' )  ?>">Перейти</a>
  </p>

[Stdit]

Сарказм понятен, я тоже от такого плевался. Но какое отношение это имеет к генерации CSS на стороне сервера и хранению цветов в базе?

[faiwer]

Я имел ввиду не хранение цветов в базе (всё ок), а запросы к базе из css файла, который на самом деле php файл.

[VolCh]

Кстати, если в классе $article, инстансы которого передаются во вью, я для метода getHref() использую lazy load, то это свидетельствует о необходимости «серьезного разговора»? А если я не использовал, а потом кто-то в результате профилирования увидел, что getHref() используется в одном вью из 100500, куда передаётся article, сделал на getHref() отложенную загрузку, то кто из нас не пригоден?

href не очень удачный пример, конечно, а вот например, $article->getAuthor()->getName(), где User::getName() в 100499 шаблонах не используется.

[faiwer]

Тут надо смотреть конкретную ситуацию. Но так или иначе XLST-головного-мозга приучил меня к тому, что все данные для генерации HTML-кода нужно получать заранее. Сколько бы грязи на XSLT не лили, он идеален для организации дисциплины :)

[VolCh]

C XSLT, да, без этого не обойтись (кажется, но вроде в xslt для PHP4 была возможность «инжектить» в код XSLT шаблона переменные и вызовы PHP, может и для 5 такая возможность есть). Может в деталях ошибаюсь, давно было как я пытался сделать CMS с использованием XSLT, тогда PHP5 на хостингах был экзотикой.

И (отвечая на коммент ниже) в теории, да, желательно подготовить для view всё необходимые ему данные в готовом виде в отдельном от модели (в терминах MVC) виде, вроде даже паттерн такой есть типа модель домена, контроллер, модель вида и вид. Но на практике шаблонизатор на стороне клиента приводит к большим ограничениям к этому клиенту и профанации идеи тонкого контроллера (куча присваиваний типа $view_data.article.author.name = $article.getAuthor().getName() тонкости не способствуют).

Когда-то (году так в 2005) меня сильно увлекла идея клиентской шаблонизации, но от неё отказался в силу слабой поддержки XSLT браузерами (то есть вроде задекларирована, но нюансов тьма, начиная от того, что часть браузеров не воспринимала content-type xml/* и <?xml version=«1.0» encoding=«UTF-8»?>) и сложности разработки кроссбраузерного JS решения, учитывая возможность отключенного JS, которая актуальна и сейчас.

[faiwer]

Клиентская шаблонизация — Jade, а не XLST. Последний можно использовать на клиентской стороне, но я полагаю, что это дичайший геморрой из-за зоопарка браузеров :)

[faiwer]

Кстати, по поводу «все данные для генерации HTML-кода нужно получать заранее». В теории это может вас привести к возможности организации крутого VIEW на стороне браузера, что может сильно разгрузить сервер. Такое может Jade.

[VolCh]

Стоит задача: юзер может производить тонкий тюнинг цветовой схемы приложения, то есть определять все «семантические» цвета (как в OS/DE или IDE). По-моему, хранение цветов в базе и генерация индивидуального CSS на её основе в таком случае куда больше отвечает концепции отделения данных от представления, чем встраивание индивидуальных стилей в HTML-страницу, их динамическое получение посредством XHR и переопределение дефолтных стилей «на лету» или предварительное создание кучи классов типа color-0f45ab, назначение их элементам и определение правил для них в громадном css с 16+ миллионов правил.

Можно эту задачу решить посредством less/sass? Без динамической генерации индивидуальных less на стороне сервера посредством php, конечно :)

[faiwer]

Задача интересная. При помощи SASS такое можно решить только путём дин.генерации SASS файла с константами. При помощи LESS эту задачу можно решить на стороне клиента без дин.генерации (насколько я знаю там доступен js-код, так что достаточно просто опеределить js-переменные). Об этом вам лучше расскажет Punk UndeaD. На PHP такое реализовать тоже можно, но я бы даже думать не стал, ибо совершенно нечитабельная масса.

На мой взгляд такая задача должна решаться просто по старинке. Единожды генерируется итоговый css при каждой смене константы, которые в дальнейшем и скармливается браузеру. И волки сыты (производительность, читаемость и пр.) и овцы целы (весь функционал доступен).

Многое зависит от задачи. Если речь идёт о замене 3-4 цветов то можно просто пройтись регуляркой. Но в любом случае я бы не стал использовать php-шаблоны. Скажу честно, меня от одного их вида выворачивает на изнанку. И вроде бы таких как я много.

[VampiRUS]

Префиксы вещь хорошая. Они помогают производителям браузеров в реализации новых возможностей.

Как? Как они им помогают?

[Alinaki]

ответ же очевиден — создатель браузера ставит префикс и спокойно ждёт, пока рекомендации устаканятся. Всё — убирает префикс.

[VampiRUS]

в чём разница с «не ставит префикс»?

[ngreduce]

в том что если синтаксис изменится — смерть.

[ZimM]

Может измениться, например, формат параметров, и тогда один браузер будет использовать свойство, а другой даже не поймет, что это было

[VampiRUS]

Спасибо, понял.

[undead_ekb]

В различных браузерах до момента устаканивания реализация разная.

[Stdit]

Какие именно уникальные воможности, по сравнению с однократной серверной генерацией?

[VolCh]

Это можно реализовать и на серверной стороне.

Вот подгонка стилей к размеру окна/экрана — задача, где без JS не обойтись.

[ZimM]

Потому что это медленно?

[faiwer]

Скажите, а давно вы видели старые PIII или PIV? У нас вот на работе у многих. Многие проблемы, которые надо решать по мере поступления, вы не заметите, но заметят другие. Лично у меня был случай когда неплохой js-код выполнялся за 30мс, а у коллегии за 14400мс. Отключив firebug мы получили цифру в 300мс. На IE7 тестить побоялись…

[faiwer]

У меня на работе чуть-чуть сильнее (Core 2Duo 1.8). Именно на нём был 30мс :) Так что нет.

[VolCh]

Тут ещё нужно сравнивать объём оперативки. Заметил большую разницу при работе только в браузере между AMD Athlon64 3200+ c 1 ГБ и с 4, но практически не заметил при переходе на AMD A4-3400 с теми же (вернее ddr3 1333 vc ddr 400) 4 ГБ со встроенной графикой. Разница заметна только на сайтах с флэшем и дискретной графикой от nVidia.

[VolCh]

А как по мне, так прозрачная и логичная разработка в рамках HTTP+HTML это прежде всего минимизация клиентской обработки. JS, XHR, websokets и т. п. — это костыли, призванные сгладить недостатки HTTP+HTML и профанирующие концепцию тонкого клиента. Нужно или отказываться от неё в сторону предоставления серверами лишь совместно используемых клиентами данных (грубо говоря, сервера обеспечивают только доступ к СУБД) и соответствующего изменения клиентов, чтобы не возникало необходимости писать клиентский код на минимум трех (HTML/CSS/JS) языках (а ещё HAML/..., SASS/LESS/..., CofeeScript/Dart/… ), либо подводить технические возможности серверов и сети к тому, что обработка локальных событий на сервере будет незаметна для пользователя. Гибридные решения, имхо, прежде всего сочетают недостатки оригиналов, а лишь потом достоинства и актуальны только в ситуации когда чистые решения по каким-то «искусственным» (читай — уровнем развития массово доступных технологий ) не приемлемы.

[faiwer]

Большая часть таких задач (вроде цветовая схема) жутко специфична, нет никакой сложности написать нужный js-код вручную. Какой резон терпеть столь страшные тормоза для такой мелочи? Только не настаивайте на том, что тормозов нет, я вам ещё тогда их показал :)

[faiwer]

Вплане неоптимально? Тот файл, на 23 секунды компиляции, был просто CSS-файлом, в конец которого я добавил нечто вроде:

.some { margin-left: 24 + 32px; }

Или банальный CSS код не оптимален? :D

[EvgeniyLazarev]

Может я что-то не понимаю, но что мешает не используя никаких дополнительных инструментов нажимать Ctrl+D и менять одно слово?..

[EvgeniyLazarev]

В итоге всё равно будет дублирование. Разница только в том, что без использования JS вы *никак* не нагрузите пользовательский браузер.

[VolCh]

Передавать разметку минимально необходимое зло, если мы не хотим ограничиться CLI режимом у клиента или передачей .bmp с сервера. :) Я знаю, что это несколько противоречит моим вышевысказанным идеям о желательности минимизации обработки либо на клиенте, либо на сервере, но я не фанат, для всего есть разумные пределы, сейчас, имхо, они перейдены — минимум три языка для интерпретации клиентом и формирование исходников этих трёх языков на сервере или девелоперской машине с, как правило, привлечением ещё нескольких — явный перебор. По-моему, отрасль веб-разработки застоялась в связи с необходимостью соблюдать BC со стандартами «тысячелетней» (если считать от HTML 4.01, CSS2 и JS 1.5) давности.

[VolCh]

Насчёт синтаксиса согласен. По крайней мере часть из него я пытался без задней мысли использовать в 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.

[Hig]

Подскажите, пожалуйста, консольную утилиту для компиляции css. Можно ли как-нибудь приспособить simpless?

[Hig]

* компиляции less. Прошу прощения.

[Hig]

А чем может угодить?

[ZimM]

Можете за 5 минут склепать такую из php.exe+php.dll+lessphp.

[Hig]

Вроде такой штукой пользовлался. На мой less оно выдавало кучу ошибок… Разбираться не стал, откопал simpless и на скорую руку там получал один нужный файлик со стилями, без всяких проблем.

А вообще, такой вариант вполне бы устроил, но он сыпал ошибками. Попробую еще, конечно…
ps: Less App, кстати, тоже ошибками засыпал. :D

[ZimM]

Ну, lessphp быстро развивается. Полгода назад, например, в нем не было поддержки функций типа darken() для цветов. А сейчас он компилирует все мои .less-файлы так же, как и less.js

[Yeah]

Ставишь node.js для винды и npm, потом делаешь npm install less и что-то типа:

"C:/Program Files (x86)/nodejs/lessc.cmd" public/js/bootstrap/bootstrap.less > public/css/style.css

[archim]

Неплохо бы рассмотреть достоинства и недостатки подготовки (допустим, автоматической) различных css-файлов для различных браузеров, и выбор файла на стороне http-сервера в зависимости от user-agent. Например, тот же php-скрипт, который с site.css делает HTTP 302/301 Redirect на site-${useragent}.css

Из недостатков, кажется, только пользователи, которые сменили себе user-agent и у них сайт будет отображаться неправильно.
Но они сами себе злобные буратино, верно?

[Stdit]

Верно, если пользователи изменили агент на некорректный, то выдавать ему дефолтный css. Если изменили на корректный — значит хотели этого, получите и распишитесь. Причём, управлять выдачей можно не на бекенде, а прямо на сервере, например в Nginx «if ( $http_user_agent ~ MSIE )».

[chikuyonok]

Менять user agent может и прокси-сервер, за которым сидит куча народу с разными браузерами. Ну или просто кэшировать результаты для одного браузера и выдавать их другим.

[archim]

Вот вечно прокси-серсеверы мешают прогрессивным идеям.

Прокси-серверы имеют привычку кешировать редиреректы?

[chikuyonok]

Смотря как этот сервер настроен. Но вроде есть такая возможность.

[kuzvac]

У prefixr есть плагин и для subline text 2.

[crenative]

www.prefixr.com/api/usage/ ссылку я давал в тексте, там для многих редакторов.

Такое ощущение, что только в виде плагинов prefixr можно получить префиксы в свой редактор. Думал, все разнообразнее будет.