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

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

    Проблема очевидна. Нужен способ облегчить работу с префиксами.

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


    1. Препроцессоры


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

    Самые известные препроцессоры CSS это LESS и SASS.

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

    LESS


    Этот препроцессор обладает синтаксисом, который проще, чем у конкурента. Существует возможность обрабатывать файлы стилей на стороне сервера, но нас интересует сейчас вариант работы на стороне клиента через файл javascript.

    Подключение
    <!doctype html>
    <hеad>
      <link rеl="stylesheet/less" type="text/css" href="style.less">
      <sсript src="less-1.1.3.min.js" type="text/javascript"></sсript>
    </hеad>


    Миксин
    .border-radius( @radius: 3px ) {
      -webkit-border-radius: @radius;
      -moz-border-radius: @radius;
      border-radius: @radius;
    }


    Использование
    #shape1{
      .border-radius(10px);
    }


    Для того, чтобы работать с префиксами, нужно использовать миксины (тот самый код, который знает что и где заменять). Существуют готовые наборы миксинов и библиотеки для CSS3
    lesselements.com
    github.com/jdmiller82/-lessins-
    snipplr.com/view/47181/less-classes
    roel.vanhintum.eu/more-less

    Не обязательно компилировать файлы .less на сервере или в браузере, можно локально получить готовый файл CSS и уже его использовать на сайте
    SimpLESS — приложение, которое автоматически компилирует .less в стандартный CSS. Бесплатно для всех платформ.
    Less App — аналогичное приложение, но только для Мака.

    Есть даже расширение для Дримвивера, компилирующее файлы .less в CSS.


    Компьютер-клиент получает файлы .less и .js, после обработки в браузере имеем файл .css со всеми возможными префиксами

    SASS


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

    Одним из плюсов является наличие фреймворка Compass, который содержит готовые библиотеки и миксины, в том числе и для работы с CSS3. Существует приложение для локальной компиляции файлов SASS в CSS. Кроссплатформенное, но платное (платной является графическая оболочка, сам компилятор опенсорсный).

    Есть и библиотеки миксинов CSS3 для SASS:
    github.com/thoughtbot/bourbon


    На сервер происходит обработка файлов SASS, компьютер-клиент получает уже готовый файл .css

    Достоинства препроцессоров:
    + Кроме префиксов, можно делать куда больше вещей
    + Возможность автоматически обрабатывать файл CSS (например, сжимать, удаляя лишнее)
    + Нормальное кэширование (правда, LESS кэшируется с помощью localStorage)

    Недостатки препроцессоров:
    – Для варианта с javascript — зависимость от включенных скриптов в браузере
    – Генерируется код со всеми возможными префиксами, не только теми, которые нужны конкретному браузеру

    Еще конкуренты


    2. -Prefix-free



    -Prefix-free — это скрипт, который нужно подключать к своим страницам. В отличие от препроцессоров, обрабатывает обычный файл CSS, то есть в коде нет переменных или миксинов, а самый обычный CSS-код, только без вендорных префиксов.

    Обработка страниц стилей происходит с помощью Javascript.

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


    Компьютер-клиент получает файл .css без префиксов. После обработки в браузере с помощью javascript, только нужные префиксы добавляются в этот файл

    Достоинства:
    + Автор файла стилей использует только один вариант свойств, без префиксов
    + Браузер пользователя не получает стили с «чужими» префиксами или префиксами, которые уже устарели
    + Валидный код
    + Можно удалить безболезненно, когда исчезнет в нем необходимость

    Недостатки:
    – Не обрабатываются стили, подключенные через import
    – После загрузки сайта и перед полной обработкой CSS3-стилей возникает едва заметная пауза
    – При отключенном Javascript пользователь не увидит некоторые CSS3-стили
    – Дополнительный файл для загрузки (правда, всего 2KB в сжатом виде)
    – Обработанный файл стилей не кэшируется

    Конкуренты


    3. Генераторы


    Этот способ уже используется многими. Просто открываем один из онлайн-генераторов и копируем оттуда готовый код с префиксами.

    Недавно я попробовал поискать генератор, который бы автоматически добавлял свойства с префиксами к написанному мной стандартному свойству. Оказалось, что есть несколько вариантов.



    • prefixr.com Можно выбрать браузеры, для которых используются префиксы, можно сжимать код, использовать переменные, имеет плагины для редакторов кода
    • prefixmycss.com
    • cssprefixer.appspot.com Тут генератор работает как демонстрация возможностей серверного скрипта, доступного для бесплатного использования
    • imsky.github.com/cssFx Этот генератор демонстрирует возможности скрипта на javascript, доступного для бесплатного использования


    Загружаем на сервер файл с подготовленным вручную файловм .css со всеми префиксами

    Достоинства:
    + Ничего не нужно устанавливать и настраивать
    + Часто генератор дает возможность удобной настройки значений для свойств CSS3

    Недостатки:
    – Нет автоматизации при создании и последующем изменении значений свойств CSS3

    4. Редакторы кода


    Ну и наверняка существует возможность автоматизации подстановки префиксов для редакторов кода и сред программирования. Иметь под рукой Zen Coding для префиксов было бы очень удобно.

    На данный момент удалось найти плагины, использующие Prefixr:

    На этой странице перечислены плагины для Notepad++, TextMate, Espresso, Coda и некоторых других.
    Prefixr для NetBeans

    UPD For those of you who don't speak Russian this article in English.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 88

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

      Прозвучало так, будто приложение для компиляции sass в css платно. Это не так. Платная графическая обёртка над бесплатным компилятором. Зачем она нужна, не совсем ясно.
        +2
        избавить нас от использования префиксов сможет только официальный выход CSS3
          +1
          Боюсь что нет, ибо официальный выход css3 не значит немедленное обновление все браузеров юзерами. У нас даже ie6 еще виден на горизонте, козалось бы уже и не поддерживают его верстальщики и юзеры должны были обновится, ан нет, висит, в Росии его конечно меньше но вот если брать статистику мирвого использования то это 1.6% примерно
          • UFO just landed and posted this here
            0
            Я не могу понять, это я уже слишком старый и не воспринимаю новые тенденции и людям действительно проще использовать сторонние сервисы для генерации трех строчек кода с префиксами? Вроде бы они не настолько быстро меняются… Да и нужных свойств этих, с префиксами, раз-два и обчелся. Вон, тот же бордер-радиус, из примера, давно уже без префиксов работает (там где он вообще работает), их разве что для более полной совместимости их оставить можно.

            Но статья, тем не менее, интересная и добротная, однозначный плюс.
              0
              Для компиляции LESS на Винде использую замечательную тулзу — winless.org/ (умеет автоматически перекомпилировать файлы, мониторя папку с *.less файлами на наличие изменений
                –3
                Для генерации 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 складывается в докрут или кешируется веб-сервером.

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

                Недостатки: не подходит для верстальщиков, не знакомых с языком; зависимость безопасности от верстальщика; трудно читается, особенно в редакторе без корректной подсветки синтаксиса; задача осложняется, если проект имеет компонентную структуру.
                  +3
                  Ужас какой. Если Вам нужно использовать всю мощь языка и тем более использовать БД для генерации СSS — you are doing it wrong. Для компиляции LESS->CSS существует lessphp — написав под него простейшую обертку, можно получить все описанные Вами «преимущества» использования PHP, за исключением «использовать всю мощь языка и даже использовать БД» (но я не представляю, где это может понадобиться)
                    0
                    Вся мощь языка это ведь не только БД и ООП, но и такие замечательные вещи, как функции для работы со строками и массивами, регулярные выражения, и многое другое. Хорошо, БД не нужна. Опустим случаи, когда надо периодически пересобирать CSS в зависимости от каких-то состояний, для этого, вероятно, будет лучше написать что-то более организованное. Но зачем множить сущее без необходимости? Зачем подключать библиотеку, писать для неё обертку, потом интегрировтаь в систему, для решения такой простой задачи, как константы, функции и циклы в css?
                      0
                      Приведите пример, в котором вам нужны будут циклы и регулярные выражения в css?
                      • UFO just landed and posted this here
                          0
                          В примере кода выше есть цикл.

                          А вообще я не понимаю необходимость введения такой сущности как less (в связке с lessphp), если в проекте нет разделения труда верстальщика и программиста. Просто программист-верстальщик должен выучить ещё один язык, хотя мог бы обойтись связкой css+php, без лишней сущности в виде less и связанного с ним инструментария.
                            0
                            Я «выучил» LESS за пять минут, просто открыв главный сайт проекта.
                            Пример с циклом — чисто синтетический, я не могу представить задачи, в которой некий список состоял бы из десятка жестко зашитых иконок, например. Как не могу представить, зачем в СSS могут понадобиться операции со строками и регулярными выражениями.
                            Я могу оправдать такой подход в случае очень простых стилей, иначе — все равно придется писать в каждом файле кучу велосипедных функций, чтобы сымитировать нечто подобное по удобству тем же mixins
                              +1
                              Пример: сделать так, чтобы левое меню выглядело, как сегмент круга, с возможностью настраивать степень выпуклости.
                              Решение:
                              <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?
                                0
                                Округлить width забыл, простите мне этот огрех.
                                  0
                                  Пример интересный, спасибо. Сделать подобное на 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%");
                                  

                                  ?
                                    0
                                    Спасибо за конструктивный ответ. Да, для таких задач придется написать пару функций. Хотя, можно схитрить и использовать грязные хаки, вроде rgb-нотации и implode. Насчет читабельности полностью согласен, это недостаток, PHP режет глаз.
                                      0
                                      Ну собственно, пришли к тому, о чем я говорил — проще подключить готовую отработанную библиотеку, чем переизобретать на грязных хаках «свой LESS, только с функциями и массивами». Более того, никто же не мешает сделать всё на LESS, а «меню в виде полукруга» вставить маленьким кусочком PHP. Более того, lessphp даже позволяет вытащить в PHP-код переменные и константы из распарсенного .less
                                        +1
                                        Не совсем так. Если верстальщику нужны константы и работа с цветами — тогда да, можно использовать эту библиотеку. Если нужны возможности языка программирования — тогда нет. Две функции для работы с цветами написать проще, чем рассчитывать итерации вручную. Это даже велосипедом трудно назвать, скорее бытовая ситуация, обычный скриптинг. Вот так, к примеру, выглядит работа с цветами в пространстве 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)?>;}
                                        
                                        Таким образом, самый существенный недостаток такого подхода — это внешний вид кода.
                                          0
                                          Ну в том же SASS есть основные возможности языка программирования — циклы, массивы, функции, математика итд. При сохранении читабельности кода. Разве что компилироваться дольше будет, чем чистый PHP, но это врядли можно назвать весомым недостатком — можно ведь закешировать результат обработки
                                            0
                                            Главный недостаток SAAS и т. п. лично для меня — вроде есть основные возможности ЯП, но они в вакууме: нет возможности передать параметры извне и, тем более, нет биндингов к популярным и личным библиотекам. То есть эти почти ЯП являются практически нерасширяемыми DSL. Они хорошо справляются с задачей выполнения принципа DRY и повышения уровня абстракции при написании статических CSS правил, но плохо с их динамической генерацией.

                                            Конечно, можно написать скрипты на sh/bash, php, ruby, python, c++, которые в ответ на htpp запрос GET /style.less будут выдавать динамически генерируемый less-код, интерпретируемый на стороне клиента или выдавать компилированный css, но, имхо, это излишний оверхид ради профита в виде возможности преодолеть недостатки CSS.
                                              0
                                              Возможно. Но все же такие задачи, ИМХО, возникают редко.
                                              В lessphp, кстати, возможность передать параметры извне присутствует:
                                              $less = new lessc("myfile.less");
                                              echo $less->parse(null, array('color' => 'blue'));
                                              


                                              Да, возможно это оверхед. Но лично я готов слегка пожертвовать скоростью в обмен читабельный, удобный и поддерживаемый код.
                                                0
                                                *в обмен на
                                                  0
                                                  Не знал, если честно. Но тогда наш спор заключается в том, стоит ли вводить дополнительный уровень абстракции между PHP и CSS? :)
                                                    0
                                                    Нуу, да :) Хотя как я уже говорил, лично мне еще не попадались задачи, где нужно передавать параметры из PHP в CSS
                                                      0
                                                      Возможно вы просто не знаете, что ваши пользователи применяют к вашим приложениям всякие userjs и custom css ;)

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

                                                          Это уже обфускация получится. Вроде как одно из правил то ли веб-вёрстки, то ли веб-дизайна (скорее вёрстки), гласит, что страница должна выглядить нормально и быть хоть как-то юзабельна, даже если браузер не понимает CSS в принципе.
                                +1
                                Мне пару раз пригодились в подобных ситуациях:
                                @each $name in math, rus, eng, kaz, ... {
                                  .subject_#{$name} { background: url( '/some/' + $name + '.png'; }
                                }

                                Регулярные выражения я использую в «баннерорезках». Что-то вроде
                                *[id*=banner] { display:none; }
                            +1
                            Суть LESS и SASS — предельно понятный, лаконичный и приятный код, имеющий гораздо большую гибкость, нежели обычный CSS. Приведённый вами код беспредельно ужасен, ctrl + a && del. Отдельно хочу отметить что за «использование БД в CSS» надо проводить «серьёзные разговоры» о профпригодности, ибо это не просто нарушение MVC, а терминальная стадия хаоса.

                            А циклы, условия, математика есть и в SCSS, SASS.
                              0
                              Простите меня за профнепригодность. Даже константы для CSS нельзя хранить? Почему в файле можно хранить, а в MongoDB, к примеру, нельзя?
                                0
                                Model-view-controller. Вы же не пишете так (надеюсь):
                                <?php 
                                  $id = '2C00012f231241'; ?>
                                  <p style="<? implode(';', $style ) ?>">
                                    <a href="<? $db->get( 'article', array( '_id' => $id ), 'href' )  ?>">Перейти</a>
                                  </p>
                                


                                  0
                                  Сарказм понятен, я тоже от такого плевался. Но какое отношение это имеет к генерации CSS на стороне сервера и хранению цветов в базе?
                                    0
                                    Я имел ввиду не хранение цветов в базе (всё ок), а запросы к базе из css файла, который на самом деле php файл.
                                    0
                                    Кстати, если в классе $article, инстансы которого передаются во вью, я для метода getHref() использую lazy load, то это свидетельствует о необходимости «серьезного разговора»? А если я не использовал, а потом кто-то в результате профилирования увидел, что getHref() используется в одном вью из 100500, куда передаётся article, сделал на getHref() отложенную загрузку, то кто из нас не пригоден?

                                    href не очень удачный пример, конечно, а вот например, $article->getAuthor()->getName(), где User::getName() в 100499 шаблонах не используется.
                                      0
                                      Тут надо смотреть конкретную ситуацию. Но так или иначе XLST-головного-мозга приучил меня к тому, что все данные для генерации HTML-кода нужно получать заранее. Сколько бы грязи на XSLT не лили, он идеален для организации дисциплины :)
                                        0
                                        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, которая актуальна и сейчас.
                                          0
                                          Клиентская шаблонизация — Jade, а не XLST. Последний можно использовать на клиентской стороне, но я полагаю, что это дичайший геморрой из-за зоопарка браузеров :)
                                        0
                                        Кстати, по поводу «все данные для генерации HTML-кода нужно получать заранее». В теории это может вас привести к возможности организации крутого VIEW на стороне браузера, что может сильно разгрузить сервер. Такое может Jade.
                                    0
                                    Стоит задача: юзер может производить тонкий тюнинг цветовой схемы приложения, то есть определять все «семантические» цвета (как в OS/DE или IDE). По-моему, хранение цветов в базе и генерация индивидуального CSS на её основе в таком случае куда больше отвечает концепции отделения данных от представления, чем встраивание индивидуальных стилей в HTML-страницу, их динамическое получение посредством XHR и переопределение дефолтных стилей «на лету» или предварительное создание кучи классов типа color-0f45ab, назначение их элементам и определение правил для них в громадном css с 16+ миллионов правил.

                                    Можно эту задачу решить посредством less/sass? Без динамической генерации индивидуальных less на стороне сервера посредством php, конечно :)
                                    • UFO just landed and posted this here
                                        0
                                        Задача интересная. При помощи SASS такое можно решить только путём дин.генерации SASS файла с константами. При помощи LESS эту задачу можно решить на стороне клиента без дин.генерации (насколько я знаю там доступен js-код, так что достаточно просто опеределить js-переменные). Об этом вам лучше расскажет Punk UndeaD. На PHP такое реализовать тоже можно, но я бы даже думать не стал, ибо совершенно нечитабельная масса.

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

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

                                    Как? Как они им помогают?
                                      +1
                                      ответ же очевиден — создатель браузера ставит префикс и спокойно ждёт, пока рекомендации устаканятся. Всё — убирает префикс.
                                        0
                                        в чём разница с «не ставит префикс»?
                                          +1
                                          в том что если синтаксис изменится — смерть.
                                            +2
                                            Может измениться, например, формат параметров, и тогда один браузер будет использовать свойство, а другой даже не поймет, что это было
                                              0
                                              Спасибо, понял.
                                              • UFO just landed and posted this here
                                              0
                                              В различных браузерах до момента устаканивания реализация разная.
                                        • UFO just landed and posted this here
                                            0
                                            Какие именно уникальные воможности, по сравнению с однократной серверной генерацией?
                                            • UFO just landed and posted this here
                                                0
                                                Это можно реализовать и на серверной стороне.

                                                Вот подгонка стилей к размеру окна/экрана — задача, где без JS не обойтись.
                                                • UFO just landed and posted this here
                                                    0
                                                    Потому что это медленно?
                                                    • UFO just landed and posted this here
                                                        0
                                                        Скажите, а давно вы видели старые PIII или PIV? У нас вот на работе у многих. Многие проблемы, которые надо решать по мере поступления, вы не заметите, но заметят другие. Лично у меня был случай когда неплохой js-код выполнялся за 30мс, а у коллегии за 14400мс. Отключив firebug мы получили цифру в 300мс. На IE7 тестить побоялись…
                                                        • UFO just landed and posted this here
                                                            0
                                                            У меня на работе чуть-чуть сильнее (Core 2Duo 1.8). Именно на нём был 30мс :) Так что нет.
                                                              0
                                                              Тут ещё нужно сравнивать объём оперативки. Заметил большую разницу при работе только в браузере между AMD Athlon64 3200+ c 1 ГБ и с 4, но практически не заметил при переходе на AMD A4-3400 с теми же (вернее ddr3 1333 vc ddr 400) 4 ГБ со встроенной графикой. Разница заметна только на сайтах с флэшем и дискретной графикой от nVidia.
                                                          0
                                                          А как по мне, так прозрачная и логичная разработка в рамках HTTP+HTML это прежде всего минимизация клиентской обработки. JS, XHR, websokets и т. п. — это костыли, призванные сгладить недостатки HTTP+HTML и профанирующие концепцию тонкого клиента. Нужно или отказываться от неё в сторону предоставления серверами лишь совместно используемых клиентами данных (грубо говоря, сервера обеспечивают только доступ к СУБД) и соответствующего изменения клиентов, чтобы не возникало необходимости писать клиентский код на минимум трех (HTML/CSS/JS) языках (а ещё HAML/..., SASS/LESS/..., CofeeScript/Dart/… ), либо подводить технические возможности серверов и сети к тому, что обработка локальных событий на сервере будет незаметна для пользователя. Гибридные решения, имхо, прежде всего сочетают недостатки оригиналов, а лишь потом достоинства и актуальны только в ситуации когда чистые решения по каким-то «искусственным» (читай — уровнем развития массово доступных технологий ) не приемлемы.
                                                    0
                                                    Большая часть таких задач (вроде цветовая схема) жутко специфична, нет никакой сложности написать нужный js-код вручную. Какой резон терпеть столь страшные тормоза для такой мелочи? Только не настаивайте на том, что тормозов нет, я вам ещё тогда их показал :)
                                                    • UFO just landed and posted this here
                                                        0
                                                        Вплане неоптимально? Тот файл, на 23 секунды компиляции, был просто CSS-файлом, в конец которого я добавил нечто вроде:
                                                        .some { margin-left: 24 + 32px; }

                                                        Или банальный CSS код не оптимален? :D
                                                        • UFO just landed and posted this here
                                                0
                                                Может я что-то не понимаю, но что мешает не используя никаких дополнительных инструментов нажимать Ctrl+D и менять одно слово?..
                                                • UFO just landed and posted this here
                                                    0
                                                    В итоге всё равно будет дублирование. Разница только в том, что без использования JS вы *никак* не нагрузите пользовательский браузер.
                                                    • UFO just landed and posted this here
                                                        0
                                                        Передавать разметку минимально необходимое зло, если мы не хотим ограничиться CLI режимом у клиента или передачей .bmp с сервера. :) Я знаю, что это несколько противоречит моим вышевысказанным идеям о желательности минимизации обработки либо на клиенте, либо на сервере, но я не фанат, для всего есть разумные пределы, сейчас, имхо, они перейдены — минимум три языка для интерпретации клиентом и формирование исходников этих трёх языков на сервере или девелоперской машине с, как правило, привлечением ещё нескольких — явный перебор. По-моему, отрасль веб-разработки застоялась в связи с необходимостью соблюдать BC со стандартами «тысячелетней» (если считать от HTML 4.01, CSS2 и JS 1.5) давности.
                                                        • UFO just landed and posted this here
                                                            0
                                                            Насчёт синтаксиса согласен. По крайней мере часть из него я пытался без задней мысли использовать в 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.
                                                  0
                                                  Подскажите, пожалуйста, консольную утилиту для компиляции css. Можно ли как-нибудь приспособить simpless?
                                                    0
                                                    * компиляции less. Прошу прощения.
                                                      0
                                                      а чем вам node.js не угодил?
                                                        0
                                                        А чем может угодить?
                                                      0
                                                      Можете за 5 минут склепать такую из php.exe+php.dll+lessphp.
                                                        0
                                                        Вроде такой штукой пользовлался. На мой less оно выдавало кучу ошибок… Разбираться не стал, откопал simpless и на скорую руку там получал один нужный файлик со стилями, без всяких проблем.

                                                        А вообще, такой вариант вполне бы устроил, но он сыпал ошибками. Попробую еще, конечно…
                                                        ps: Less App, кстати, тоже ошибками засыпал. :D
                                                          0
                                                          Ну, lessphp быстро развивается. Полгода назад, например, в нем не было поддержки функций типа darken() для цветов. А сейчас он компилирует все мои .less-файлы так же, как и less.js
                                                        0
                                                        Ставишь node.js для винды и npm, потом делаешь npm install less и что-то типа:
                                                        "C:/Program Files (x86)/nodejs/lessc.cmd" public/js/bootstrap/bootstrap.less > public/css/style.css
                                                        +1
                                                        Неплохо бы рассмотреть достоинства и недостатки подготовки (допустим, автоматической) различных css-файлов для различных браузеров, и выбор файла на стороне http-сервера в зависимости от user-agent. Например, тот же php-скрипт, который с site.css делает HTTP 302/301 Redirect на site-${useragent}.css

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

                                                              Прокси-серверы имеют привычку кешировать редиреректы?
                                                                0
                                                                Смотря как этот сервер настроен. Но вроде есть такая возможность.
                                                            +1
                                                            У prefixr есть плагин и для subline text 2.
                                                              0
                                                              www.prefixr.com/api/usage/ ссылку я давал в тексте, там для многих редакторов.

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

                                                            Only users with full accounts can post comments. Log in, please.