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

.foo
{
    /* … */
}

и

.foo {
    /* … */
    }

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

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

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

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

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

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

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

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

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

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

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

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

Если попробовать их вспомнить, то это:

1. Возможность выделение текста даже в ссылках — когда кликаешь и ведёшь курсор по горизонтали, текст выделяется, по вертикали — драгается.
2. Свой «юзер-френдли» Ad-Block — возможность через контекстное меню «отключать» те или иные изображения или плагины на странице, с запоминанием, масками и прочим.
3. Возможность включить «плейсхолдеры» для плагинов, чтобы для просмотра видео/баннеров или чего-то ещё нужно было кликать а плейсхолдер.

Ну и ещё много чего наверняка можно будет вспомнить, что завязано на движок, надеюсь, всё получится перенести. Если получится — я всерьёз задумаюсь над тем, чтобы вернуться на Оперу :)

Кстати, а что будет с Dragonfly?

Ну вот сервис, который я выше привёл это и делает :) См. в левой колонке в «export».

Как вы себе это представляете? Всё, что можно, в такой формат сваливается — изображения и прочее. Демки же и встроенные ссылки автоматически не получится подцепить, а каким-либо образом выдирать их для размещения в epub — адовая работа. Кстати, как вы предлагаете в epub сохранять демки, которые должны работать, скажем, только в Chrome Canary?

Самый правильный вариант — создавать epub только из текстовых статей, всё остальное же приводить отдельно в дайджесте. Текст можно будет и в дороге прочитать, а вот демки всё равно почти никто не будет с мобильных девайсов смотреть.

Кстати, да — есть сервисы вроде readlists.com, позволяющие довольно просто делать epub из набора ссылок. Например, для подраздела CSS получается вот такой список: readlists.com/7e40e363/

Результат, кстати, довольно неплохой, правда, всякие демки с сайтов вроде jsfiddle, понятное дело, нормально не подтягиваются.

Попробуйте перезапустить Саблайм — сейчас проверил — почему-то после установке через package control саблайм не подхватывает настройки для отдельных синтаксисов пока его не перезагрузишь :(

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

Должен как для sass — за это отвечает сам ST2 — какой синтаксис он подхватит, тот и будет использоваться.

Идея Хаяку во многом именно в том, что, как таковых, сокращений-то и нет. Есть набор алгоритмов, разбирающих аббревиатуры и подбирщих наиболее подходящую пару свойство-значение из словаря.

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

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

Стандартный автокомплит пока отключаем, да. Я ещё подумаю насчёт того, чтобы его вернуть, но у меня были причины его отключать.

И да — Хаяку не претендует на идеальность, это всего лишь ещё один способ быстро писать CSS. Если кого-то он не устроит — всегда есть как минимум несколько альтернатив. Конкуренция — это хорошо.

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

Спасибо за обзор!

Пара замечаний:

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

2. Хочется уточнить про значения по умолчанию: они не просто вставляются, а вставляются с выделением — оставляя возможность продолжить написание своего значения. Сейчас в посте это не совсем очевидно написано.

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

Ну да, не решил, а обошёл, и не для всех свойств. Но пока есть баги вне ФФ — этим вполне можно пользоваться, если хочется сделать что-то здесь и сейчас.

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

С/С++ — тоже не JS. Кроме того, любые неофициальные порты будут отставать в версиях от оригинала. Какая версия Sass реализована сейчас в livsass? Я с ходу этой информации в репозитории не нашёл.

Именно `&__element`, т.е. когда не псевдокласс или псевдоэлемент присобачиваются к родительскому, а часть имени.

В Less и Stylus `&__element` внутри `.block` даст `.block__element`, а в Sass там появится пробел между ними — и править это разработчики не собираются.