Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE

[loat]

Для меня главный плюс Sass в том, что в нём можно использовать @extend.

[kizu]

Да, в Sass экстенд лучше всего сделан. В Стайлусе есть только базовая его поддержка: без селекторов-плейсхолдеров и он работает только на стили, написанные выше вызова @extend, тогда как Sass обработает всё, в том числе и объявленое позже.

[exdeniz]

Роман, спасибо за библиотеку в общем доступе. Использую в следующем проекте.

И я рад, что команда Почты верстает именно на Stylus.

[KeepYourMind]

stylus крут

Написал библиотечку для простой реализации responsive сайтов:

github.com/rithis/stylus-responsive/blob/master/responsive.styl

Пример использования:

.logo
    responsive width 100px same 50px
    responsive height 100px 80px 50px
    phone display block

Получается:

.logo {
    width: 100px;
    height: 100px;
}

@media (max-width: 979px) {
    .logo {
        height: 80px;
    }
}

@media (max-width: 767px) {
    .logo {
        width: 50px;
        height: 50px;
        display: block;
    }
}

[SamDark]

А как используются циклы и массивы, если не секрет? У нас LESS и пока с набором возможностей проблем не было.

[kizu]

Как раз об этом мы и напишем в одной из следующих статей :) Если коротко, то, как описано в статье, «в других [темах] фон может меняться — случайно или в зависимости от времени суток и погоды» — то есть в одной теме может случайно ротироваться порядка двадцати фоновых изображений, сейчас при создании темы достаточно просто сказать сколько есть всего таких изображений, разложить их по папочкам и всё — Стайлус сам сгенерирует все стили со всеми модификаторами.

[SamDark]

Да, так понятней. Рад, что нам такая динамика не нужна :)

[CyberAP]

Для спрайтов, к примеру.

[LegoMushroom]

Сам пользуюсь Stylus и считаю что он не заслуженно обделен вниманием комьюнити разработчиков. Спасибо за Ваш шаг в сторону решения этой проблемы! Странно, что у Вас не получается быстро переводить .css в .styl, у меня с этим проблем почти не возникало. Наверное стоит добавить ссылку, где можно попробовать Stylus онлайн. Еще раз спасибо!

[kizu]

Стайлус не понимает как минимум два более-менее распространённых CSS-кодстайла:

.foo
{
    /* … */
}

и

.foo {
    /* … */
    }

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

Конечно, в Стайлусе есть ещё и встроенный конвертер из .css в .styl, но и он не оптимально работает: скажем, если в CSS где-то использовался graceful degradation как-то так:

.foo {
    background: #808080;
    background: rgba(0,0,0,0.5);
}

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

Потому в любом случае приходится переводить всё в наполовину ручном режиме.

Онлайн-пробник Стайлуса пока что не очень хороший: авторы постоянно забывают его обновлять в соответствие с последними изменениями в репозитории, кроме того он часто может войти в бесконечный цикл, особенно если попробовать поиграться с отступами как в первых примерах в этом комментарии.

[LegoMushroom]

хм… вставил

.foo
{
    /* … */
}

и

.foo {
    /* … */
    }

к себе в .styl файл — скомпилил отлично

ну ладно первый вариант, но 2-ой то почему?

[kizu]

Второй вариант у меня выдаёт ошибку «unexpected «outdent»».

Первый, да, неточно написал — он компилится, но получается вот такое (если добавить какое-нибудь правило внутрь):

.foo,
 {
  width: 10px;
}

[LegoMushroom]

Мы скорее всего используем разные Stylus. Компилю через LiveReload. Я и раньше замечал, что тот, который ставится через npm парсит немножко неадекватно)

[TiGR]

А разве подобная проблема не должна решаться на уровне простейшего препроцессора? Или у Stylus какие-то особые заморочки?

[kizu]

Особые заморочки. Там неверное архитектурное решение, из-за чего парсер размазан тонким слоем по всему коду, в итоге проблем именно из-за парсера встречается довольно много.

[Akuma]

А чем не устраивает ie7-js?

Уже давно использую в верстке по принципу подключил и забыл.

Для нормальных браузеров это пара лишних строк в HTML. А IE будет подтягивать JS скрипты, которые делают его вполне адекватным.

Таким образом верстаю под Chrome/Firefox, и в 99% случаев все прекрасно работает вплоть до ИЕ7

* Да, я знаю разницу между CSS-препроцессором, и JS-библиотекой. Но речь идет исключительно про поддержку IE

[kizu]

IEN-js — адская серия библиотек, в серьёзных проектах ничего кроме головной боли не приносящих. Используемые в этих библиотеках решения далеко не оптимальны. Для больших веб-приложений, когда на странице могут существовать тысячи экземпляров какого-то блока, применение таких библиотек будет вызывать жуткие тормоза вплоть до невозможности использования интерфейса. И это не считая возникающих из-за этих библиотек новых багов.

Путь graceful degradation и ручного контроля над стилями гораздо правильнее: вместо того, чтобы добавлять в IE логики, мы, наоборот, уменьшаем количество отдаваемых ему стилей. Нам не важно, что в IE не будет сгруглённых уголков, градиентов и полупрозрачности, нам важнее, чтобы интерфейс в нём быстрее работал.

[Akuma]

Мне он нравится в основном изза лечения багов с двойными отступами, и прочими прелестями IE.

Но вот о тормозах на крупных страницах не подумал, спасибо. Наверно, потому, что не сталкивался с настолько объемными страницами, чтобы эта библиотека их тормозила

[kizu]

Как я и написал в статье — мы отказались от поддержки IE6 в основной версии Яндекс.Почты, а в IE7, на самом деле, очень много багов поправили, так что специально что-то под него писать стало нужно очень редко.

[Akuma]

Ясно, спасибо. Действительно было интересно почему крупные проекты не используют подобные решения.

[Beautiful-Skyline]

Вы очень правы. И Akuma тоже прав. Бюджеты его проектов просто не предусматривают столь тщательной отладки скорости работы как в Яндексе. Он точно не со зла делает так и точно не от халатности. Не нападайте на него.

[iadramelk]

if-ie.styl замечательная штука, мы её используем уже несколько месяцев и постоянно радуемся. Спасибо за нее отдельное.

Но каждый раз создавать рядом файлик *.ie.styl и вставтять туда импорты неудобно, поэтому мы для себя этот процесс несколько оптимизировали. Мы сделали свой собственный враппер вокруг stylus/less/csso с достаточно гибкими возмонжостями настроек и плагином для grunt.

В настройках можно указывать для less и stylus дефолтные переменные и импорты для всех файлов. Выглядит эта часть конфига примерно так.

Для всех браузеров:

stylus: {
    imports: [
        // other mixins
        'blocks/i-mixins/i-mixins__if-ie.styl'
    ]
}

Для ie:

stylus: {
    variables: { 'ie': true },
    imports: [
        // other mixins
        'blocks/i-mixins/i-mixins__if-ie.styl'
    ]
}

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

github.com/jetstyle/styletto
github.com/jetstyle/grunt-styletto

[sunnybear]

Каждый раз очень приятно читать про hasLayout :)

[Tbird]

Что можно сделать без массивов, циклов и нормальных условных конструкций?

Раз уж вы понимаете необходимость миксинов, циклов, переменных и пр. в css, может повлияете на csswg как один из крупнейших сервисов мира? Результаты последнего face-to-face показали что они слишком далеко ушли от реальной веб-разработки и слабо понимают потребности девелоперов.

[kizu]

А вот это, кстати, очень спорный момент. Я понимаю необходимость подобных конструкций в препроцессоре, но не уверен, что это нужно в самом CSS.

Во-первых, использование возможностей препроцессора на клиенте будет заведомо медленнее чистого CSS. И заведомо более бажное — уже сейчас переменно-подобные сущности вроде `vw` и `vh` не всегда пересчитываются (например, при изменении размеров окна не вызывающего рефлоу), и совсем недавно в вебките комбинаторы `+` и `~` работали статическим образом для всех элементов, кроме первого совпавшего.

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

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

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

[Tbird]

Ну тогда не делали бы их вообще. А так, по css-variables last call, а в текущем виде их с другими спеками совмещать будет ой как тяжело. Таб Аткинс уже анонсировал модули и пр. (судя по спекам тоже уродливые). Короче, в ногу нам себе выстрелить таки дадут, но из очень кривого и страшного оружия :(

[Iskin]

А как вы на Stylus делаете `@keyframes`? Они же должны идти с браузерными префиксами, а Stylus вроде не умеет ловить блок в примесь :D.

[kizu]

Да, не умеет :( Потому, там это есть из коробки.

[Iskin]

То есть просто захардкорен конкретный случай? Есть какой-то API, чтобы делать свои такие штуки, например вида `@for-phones`

[kizu]

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

Теоретически, можно использовать одновременно и Stylus и rework (Головайчук сейчас, по сути, переписывает Стайлус с ноля, разбив всё на блоки и забросив сам Стайлус), сделав что-то на основе того, как там сделан плагин для тех же кейфреймов, но нам пока это не нужно (если нужно будет — что-нибудь придумаем).

Как я в статье и написал — для многих задач Sass подходит лучше, но не для наших :)

[TiGR]

А нельзя ли переменной ie присваивать не булево, а целое с номером версии? Кажется, это может дать дополнительный контроль.

[kizu]

Можно, но у нас такой необходимости нет т.к. используется, по сути, только одна старая версия ие — седьмая (шестой мы не поддерживаем, восьмой переводим в режим седьмого).

А так — да, для нормальных браузеров задаём ie=0, для разных ие — его версию, так будут даже работать проверки вроде if ie > 6 и т.д.

[s2erg]

Скажите, знакомы ли вы с roole и что думаете об этом проекте?

[kizu]

Да, мы смотрели на него. Он пока очень сырой, те же проблемы с parent reference, менее гибкие интерполяции, чем в стайлусе и т.д.

[rassadin]

я вот свой потихоньку свой css препроцессор, со своими печеньками начал писать.

почему вы не решили написать свой препроцессор?
насколько мне известно в Яндекс в многих сферах есть свое и не одно решение,
начиная от NoSQL и заканчивая шаблонизатором?

[kizu]

Пока не решили :) Нам был нужен препроцессор «здесь и сейчас», Стайлус же большинство наших задач решает уже сейчас.