Pull to refresh

Comments 81

Да, ребята из Гугл молодцы, сейчас именно ВебКит требует больше всего префиксов.
UFO just landed and posted this here
Эту проблему немного решил Stylus — у него синтаксис примесей не отличается от обычных свойств, так что префиксы добавляются невидимо. Впрочем, проблема актуальности и значений всё равно остались.
И как же решил проблему актуальности данный велосипед? Чем он лучше Стайлуса? Тем что грузит данные с другого адреса? Ну и что? Почему это лучше?
Автопрефиксер, в отличии от Стайлуса добавляет только те префиксы, что действительно нужны именно этому проекту, а не все подряд. На Can I Use собрана очень хорошая статистика кому нужны префиксы, а кому нет. Автопрефиксер не загружает данные каждый раз — они хранятся в npm-пакете или геме.
Кроме того, в Стайлусе вам надо самому писать все примеси для CSS3-свойств. И даже если вы опишите все нужные примеси, то не сможете добавлять префиксы к значениям свойств, например в calc() или в transition: transform (где transform тоже требует префиксов).

Автопрефиксер всё это имеет и умеет. Но вы можете использовать его вместе со Стайлусом, просто прогоните выход компилятра Стайлуса через Автопрефиксер.
В Stylus можно перегружать такие функции как calc или linear-gradient так же без проблем, как делать простые примиси.
Кстати есть замечательная библиотека к Stylus visionmedia.github.io/nib/.
Про библиотеки к препроцессорам я уже говорил (в разделе про Compass) — список префиков там не поддерживается в актуальном виде. Свойство borde-radius уже год как не нужно писать с префиксом.

Недостаточно перезагрузить calc() и вернуть что-то другое. Нужно именно продублировать:
width: -moz-calc(1% + 1px);
width: -webkit-calc(1% + 1px);
width: calc(1% + 1px);
Именно это умеет делать Stylus, посмотри хотя бы по ссылке (прям сразу показывается как перегружается linear-gradient), что я скинул, ну а если всё равно не веришь, то читай официальную доку:
learnboost.github.io/stylus/docs/bifs.html искать add-property.

Единственно, что нельзя сделать прозрачно (как я понял) в Stylus, так это прозрачные псевдоэлементы/псевдоселекторы, вроде ::-ms-clear, в вашем решении это учтено?
Моя вина, я думал Stylus переопределяет background и дублирует свойства фон через примесь.

Да, селекторы тоже можно переопределять, хотя у поставке по умолчанию нет ни одной штуки с селекторами (я создавал правила только для того, где есть предложение спецификации).
Ну значит профит — это возможность перегружать селекторы, а всё остальное умел делать Stylus. Непонятно зачем автору Stylus захотелось из-за этой фичи создать новый велосипед :)
Тут ещё аргумент, что не надо новый язык учить — всё поверх текущего CSS, который может идти от Sass или чего угодно.
Ну дык тот же Stylus поддерживает CSS синтаксис, т.е. любой CSS является валидным для Stylus и можно не юзать циклы и функции :) Но как я понял rework как раз не имеет этих оч крутых фичей из Stylus и его использовать нужно в паре с другим препроцессором (например, с тем же Stylus).

Сухой остаток: т.е. это просто фреймворк для создания полифилов, что вы и сделали в своей работе. Я правильно понимаю?
Ага, Rework скорее постпроцессор для задач типа префиксов. Я, например, не отказываюсь от Sass, потому что в Rework нет и в ближайшее время не будет хорошей математики.
А зачем городить огород? что плохого в том чтобы были лишние префиксы кое-где? будет поддерживаться больше браузеров, только и всего
Наличие актуальных префиксов — это самое незначительное преимущество. Главная цель написания Автопрефиксера — чтобы писать обычный CSS и чтобы префиксы добавлялись и к значениям (например, чтобы в transition: transform добавлять префиксы и к transition и transform) и к @keyframes.
ну это все встроено в rework: prefix, prefixValue, prefixSelectors, keyframes
Autoprefixer для Rework, как Compass или Bourbon для Sass — это просто библиотека с готовым списком свойств и значений, чтобы не задумываться каждый раз самому.
Спасибо, теперь понятно. Поставил звезду)
Выпустил версию 0.3 — теперь я не использую prefix и prefixValue — свои работают быстрее (на 40 %), создают меньше ненужных свойств и нет некоторых других проблем.
Гораздо лучше компилировать CSS во время выкладки на сервера.
В FAQ про это тоже есть…
Нельзя просто так взять и сказать, что Server-Side solution лучше, всегда есть за и против.
А в чём плюс клиентской библиотеки? Если вы верстаете сразу в Ruby on Rails (то есть у вас работает препроцессоры), то я не вижу ни одного преимущества.

Плюс только если верстальщик верстает сразу в HTML и CSS, но это совсем другой случай.
Облегчаем css на 500 байт и увеличиваем js на 2 500 + увеличиваем время инициализации приложения на 40 мс — странная затея ради нескольких пользователей.
Скоро люди, вообще, разучатся писать на CSS :-(
Ну постоянные повторы префиксов — это не главная вещь в CSS ;). Но вообще многое идёт к тому, что от браузеров прогресса в CSS и JS ждать очень долго (а потом ещё ждать пока старые браузеры исчезнут) — так что фронтенды начинают использовать препроцессоры, чтобы быстрее внедрят инновации, не ожидая браузеров (представляете каким бы отсталым было бы программирование, если бы можно программировать только на тех языках программирования, что поддерживаются процессорами).

Но разработчикам браузеров даже нравится такая затея — Source Map уже внедрили, asm.js уже во всю разрабатывают. Это конечно выглядит странным, но препроцессоры становятся неизбежным духом времени.
Это все равно что сказать, что скоро бухгалтера совсем разучатся заполнять гроссбухи при помощи ручки и калькулятора.
А зачем -ms-transition? В IE10 отказались же от префиксов, они только в превьюшках были.
Так как есть -ms-transform — да, пока это упущение prefixValue() в Rework.
Выпустил новую версию, со своими фильтрами, вместо фильтров Rework´а. Теперь такие лишние свойства не создаются.
Объясните на конкретных примерах, в каких ситуациях Compass не справляется с префиксами.
Я специально выбрал пример в начале статьи, с которым у меня вечно были проблемы в Compass:
transition: transform 1s;
Taк, давайте по порядку.

1) Чем не устраивает решение Compass?

/* +transition(transform, 1s) */
html {
  -webkit-transition: -webkit-transform, 1s;
  -moz-transition: -moz-transform, 1s;
  -o-transition: -o-transform, 1s;
  transition: transform, 1s;
}

Выложите, пожалуйста, некорректно отрабатывающий код на jsbin.com или codepen.io.

2) Если с этим решением действительно проблема, почему вы не отправили pull request в Compass c решением? Исправить эту проблему (если она есть) — тривиально.

3) Есть еще примеры проблем с Compass, или вы создали ваш сияющий реактивный велосипед только из-за этого?
Черт, а Compass добавил префиксирование свойств в transition.

Ладно, тогда другой код: width: calc(1em + 10px)
Как же вы решаете это в autoprefixer?
Autoprefixer говорит Rework отпарсить CSS и получить дерево кода. Потом он находит все элементы CSS, которым нужны префиксы и переделывает их. То есть не нужно писать на отдельном языке и явно указывать примеси.
Плюс проблемы Compass:
  • Нужно писать примеси для CSS 3 свойств, то есть постоянно думать CSS 3 это или нет. В итоге у нас куча код с совершенно не нужным +border-radius или +text-shadow
  • Префиксы в Compass давно устарели, там куча лишних
  • Я коммитил в Compass чистку префиксов, но разработка Compass идёт из рук вон плохо. Они до сих пор не могут выпустить версию 0.13, а поддержки Rails 4 до сих пор нет
а) Не понял, в чем проблема писать +text-shadow.
б) Что значит «префиксы устарели»? Caniuse.com сказал вам, что такой-то браузер теперь поддерживает свойство без префиксов? Посмотрите статистику того же Caniuse, если просуммировать старые версии, наберется несколько процентов. Какой смысл лишать их поддержки? Ради экономии пары сотен байт?
в) Коммиты не приняли? Мейнтейнеры Compass, конечно, консервативны (не будем показывать пальцем), но по части удаления префиксов не могу их упрекнуть.

Вообще, SASS/Compass — это такая базовая вещь для разработки сайтов, как… ну, не знаю… когда я вспоминаю, как верстал без Compass, на ум приходит байка про бухгалтершу, которая перемножала ячейки Excel'я вручную на калькуляторе.

Решить проблему префиксов на SASS и Compass — тривиально. Нет префиксов для calc? Написать mixin — 60 секунд. Отправить pull request в Compass — 300 секунд (спасибо GitHub'у за возможность редактировать код в браузере). Написать и закинуть собственный extension в RubyGems — 600 секунд… ну 1200, если вы делаете это в первый раз.

Вы поймите меня правильно. Я восхищаюсь вашим проектом, просто в голове у меня его цели и средства никак не соизмеряются.
Ну, например, браузеры требующие префиксов border-radius сейчас уже не встретишь: news.ycombinator.com/item?id=5560554

Примесь text-shadow тоже совершенно не нужна, так как ещё пару лет назад все понимали без префиксов.
В том-то и дело, что я думал как улучшить ситуацию в Compass и понял, что, к сожалению, ресурсами Sass — это сделать нельзя. Потому что Sass придумали уже давно, нужно смотреть куда двигаться дальше. Я начал думать над фильтром для Assets Pipeline, но тут автор Stylus зарелизил Rework, который как раз идеально подходил для задачи.

К сожалению, я вообще не верю в будущее Compass — скорость его разработки сильно снижается, они превращаются в такого большого мамонта. Так что я написал Autoprefixer и rails-sass-images и полностью выкинул Compass.

Compass до сих пор не поддерживает нормально Assets Pipeline — у него архитектура со времён Jammit. Нельзя указывать шрифты в vendors/assets, так как Compass не смотрит в Assets Pipeline, а сам имеет только одну папку со шрифтами. Сам репозиторий весит кучу МБ (так как они додумались тестировать спрайты большими картинками и из-за каждого изменения получилось кучу данных в git).
Ну, хороший Compass или плохой, а верстку без него я не представляю. Как можно «выкинуть Compass»? Вы там что, несемантический CSS-фреймворк используете вроде Bootstrap? SASS и Compass дают столько разноплановых преимуществ, что как-то даже странно об этом спорить с человеком, способным написать сабж (я, например, не способен).

С тем же успехом можно сказать, что будущего нет у московского метрополитена: и перегружен он, и рекламой завешан, и плохо освещен… поэтому я сделал портативный прожектор на 30 тысяч люмен! Вот только проблемы метрополитена этот прожектор никак не решает и обойтись без него никак не помогает. Да и не настолько там темно, чтобы с прожектором ходить.
А что есть в Compass, кроме префиксов и вставки размеров картинок и её data-uri (с чем без Assets Pipeline он справляется плохо)?

Ну ещё есть жутко устаревший sticky-footer, который лучше заменить на другую примесь, который не требует #root и #root_footer.
> А что есть в Compass, кроме префиксов и вставки размеров картинок

Вы меня троллите?
Я очень серьёзно. Я же не противник препроцессоров и год назад всем как раз рекламировал Compass, комитил в него и т. п. Так что я точно так же как и вы уважаю, что они сделали.
У Compass есть ещё спрайты, но лучше использовать data-uri в отдельном CSS-файле (особенно, когда поддерживаете ретину), так как спрайты приводят к большой потери памяти (браузер выделяет память с BMP всего суммарного спрайта для каждого случая его использования)
«Зачем нужен Windows? Ну есть нем Сапер и WordPad, это да… Но Сапер быстро надоедает, а в WordPad нет поддержки колонтитулов. В общем, безнадежно устарел ваш Windows.»

Я в данный момент делаю верстку для одного проекта с использованием Singularity и Breakpoint Slicer. При помощи Singularity я задаю модульные сетки (в том числе несимметричные) индивидуально для каждого контейнера. При помощи Breakpoint Slicer — обращаюсь к определенным диапазонам ширины окна. Это не говоря уже о таких важных мелочах, как Sassy Buttons или незаменимом Toolkit.

Ну вот откройте для примера тестовую страницу Breakpoint Slicer, отмотайте в до последнего примера и поиграйте с шириной окна. Пример реализован без JS, только вот этим SASS-кодом:

// Importing Singularity.
@import singularitygs

// Configuring Singularity.
$grids: 1
$gutters: 0.2

// Adding responsive grids.
// Cycling through slices.
@for $i from 2 through total-slices()
  // Setting the number of columns in each slice equal to the number of that slice.
  $grids: add-grid($i at bp($i))

#singularity2 .column
  margin-bottom: 1em

  // Cycling through slices
  @for $slice from 2 through total-slices()

    // Setting a media query for each slice
    +at($slice)

      // Within the media query, cycle through columns
      @for $column from 1 through $slice

        // Span thumbnails in this column
        &:nth-child(#{$slice}n+#{$column})
          +grid-span(1, $column, $output-style: float)


Расскажите, пожалуйста, как еще, без Compass (и, ради бога, без JS), можно решить подобную задачу (модульная сетка с динамическим количеством колонок)?
А при чём тут Compass? Это чистый Sass. Эти плагины точно так же можно подключить к Sass и без Compass.
Гм.

Compass — это в первую очередь инфраструктура. У Compass свой компилятор, делающий использование расширений очень удобным (особенно в сочетании с Bundler).

Вон тут рядом 3D-графику запускают без операционной системы. Зачем нам операционная система? Сапер в ней унылый, да и релиза не было уже черт знает сколько…

Простите за язвительный тон, под конец дня вырывается. :( Не пытаюсь вас обидеть.
У Compass нет своего компилятора — он же использует обычный Sass. Есть конечно расширения Sass, но их там не много и они в основном по спрайтам.

Всё что Compass делает для инфраструктуры — добавляет пути к плагинам в load_path Sass´а. Это можно сделать или вручную, или с помощью кучи других инструментов.

Лично мне, больше нравится Assets Pipeline — система ассетов, на которую перешёл Ruby on Rails (Bundler же тоже из Rails вышел). Он точно так же управляет путями в плагинам (и может брать плагины из гемов Bundler´а), но делает это гораздо лучше (поскольку он создавался уже после Compass, с учётом его опыта) и решает ещё множество полезных задач.

Если бы Compass был бы ещё живым, они бы нормально интегрировались с Assets Pipeline, использовали больше сторонних модулей (например, у них куча самописных велосипедов для полуения размеров файлов, гем dimensions использовать для этого лучше). Но пару лет назад разработка Compass заглохла. Последние месяцы они релизят новые альфы версии 0.13, но там невероятно минорные изменения.
Раз уж вы ради calc() разработали сабж, может и Drupal портируете на Rails, чтобы можно Assets Pipeline использовать вместо Compass?
Sass я очень люблю и использую до сих пор. Но Sass решает далеко не все проблемы (всё таки это был самый первый препроцессор) и уже надо начинать смотреть дальше.
Ну а с calc в том-то и дело, что миксинами эту проблему не решить. Миксины вообще очень ограниченный инструмент. Тут именно нужен полноценный постпроцессор, чтобы менять структуру CSS.
Заспамили. )

Так что делает сабж с calc?
Увидев
width: calc(90% - 10px)

продублирует поля для каждого префикса:
width: -webkit-calc(90% - 10px)
width: -moz-calc(90% - 10px)
width: calc(90% - 10px)
> Ну а с calc в том-то и дело, что миксинами эту проблему не решить.
> продублирует поля


Я вас не понимаю. Задача решается за минуту:

sassmeister.com/gist/lolmaus/5399447
Это костыль, проще написать обычное свойство с обычным calc(), чем делать новый синтаксис.

Да и если вам нужно border: calc(10px + 10%) 20px?
А вы фоллбэки для calc пишете? Если да, то в любом случае вы делаете костыль. Если нет, то какой смысл париться о поддержке 2%, если вы забиваете на 20%?
Для мобильной разработки calc() можно использовать уже сейчас.

Но тут-то вопрос не в единственном свойстве, а в том, что со временем старый инструмент всё меньше и меньше решает проблему, зато создаёт кучу новых. И мы должны пойти дальше. Точно такие же аргументы мне 2 года назад говорили, что Sass — плох. Мол зачем он нам нужен, когда мы всё это и в CSS можем писать. Но вопрос был в том, что в Sass можно это написать проще и чище. Тоже самое и с Автоперфиксером — он решает проблему лучше и чище.
И не только для мобильной. Я активно юзаю calc. Пишу под свежие браузеры.
Я правильно понимаю, что вы сейчас сравнили препроцессор и утилиту, модифицирующую CSS?
UFO just landed and posted this here
Почему? Это унижает ваше достоинство? :)
UFO just landed and posted this here
Пожалуйста, попробуйте посчитать, сколько разных свойств с префиксами вы действительно используете, только честно.
UFO just landed and posted this here
Box sizing включается один раз для всех элементов в секции reset/normalize. Более того, мой инструментарий делает это за меня, не приходится ничего писать самому.

Остается четыре с половиной свойства. Скажите, эти воробьи действительно настолько крупны, что вам приходится стрелять по ним из такой продвинутой гаубицы?
Iskin, вы не думали добавить возможность использовать сабж как расширение SASS?
Автопрефиксер прекрасно работает вместе с Sass. В Assets Pipeline делать ничего не надо. Для других более старых систем просто запустите autoprefixer **/*.css после компиляции.
Ну нет, это не дело.

Compass прекрасен тем, что перекомпилирует только изменившиеся куски кода.

Впрочем, если спарить их и возможно, то вряд ли целесообразно тратить на это время.
Compass тут опять же не при чём — это обычный Сасс, от Компаса только мелкие скрипты, которые есть в любом менеджере ассетов. Кстати, посмотрите в сторону Grunt — он хорошо подходит, если вы просто генерирует сами готовые стили для ПХП.
Уже привык использовать
-webkit-[border-radius|transition|transform]:
-moz-[border-radius|transition|transform]:
border-radius|transition|transform:
Да, пара лишних строк, но ради этого ставить пакет на серверную часть — по мне перебор
Вы не пробовали прикинуть, у скольких пользователей от -prefix-border-radius, набранных вами, сайт стал лучше отображаться, и насколько увеличилось суммарное время загрузки у всех остальных пользователей из-за лишних байтов кода?)

На высоконагруженных сайтах получаются (суммарно) десятки часов в месяц.
Дык, автопрефиксер в любом случаи отдает клиенту css с префиксами, это всего лишь удобство для разработчика
Да и вообще, пары байт для меня не приоритет, на практике, к сожалению, используется в разы больше css говнокода )
Главный минус любой такой штуки один: CSS перестаёт быть самостоятельным и его уже нельзя просто взять и переиспользовать — за ним тянутся препроцессоры.
Согласен, тут надо сразу определить в каком вы лагере — как только внедряете один препроцессор, остальные идут легче, так как вы начинаете использовать пакетные менеджеры и инструменты деплоя.
Этот проект писался с основным прицелом на Руби — а там препроцессоры давно полностью победили
Мне кажется, rework замечательная штука, если использовать его именно для таких целей — добавлять префикс, хаки для различных браузеров и т.д. То есть, с одной стороны в имеете чистый и валидный css, который должен прекрасно работать в сферическом браузере в вакууме, а rework делает грязную работу. А вот если использовать все возможности rework на полную катушку, то получается странно — вроде бы css-файл, но на самом деле это не css, незнакомый с проектом человек открывает, встречает вроде бы знакомые конструкции но с новыми свойствами, или еще хуже — когда переопределены стандартные свойства.
В этом смысле SASS и другие макроязыки лучше — видишь sass файл, если знаешь sass — все в порядке, не знаешь — открываешь референс и разбираешься.
Я пришёл к точно такому же мнению. Да и синтаксис переменных и математики в Реворке ужасный.
Sign up to leave a comment.