• Сравнение эффективности минимизаторов CSS- и JavaScript-кода
    +3
    А будь добр, приведи примеры того, что SASS сжимает лучше, чем CSSO? Для того же бутстрапа CSSO выдаёт лучший результат.
  • Повторяющийся зубчатый фон на CSS
    0
    Да с нормальной картинкой можно и на луну улететь, тут же вопрос именно в «чистом CSS». Хотя, например, с инлайновым SVG в бордер-имадже было бы отлично, но — FF…
  • Повторяющийся зубчатый фон на CSS
    +1
    Можно сделать и с полупрозрачными зубчиками/фоном — dabblet.com/gist/5387364 — так ещё и background-size/-position гораздо проще задаются :)
  • Повторяющийся зубчатый фон на CSS
    0
    Не, не получится. Для градиента внутри border-image нельзя задать background-size, т.е. то, от чего можно было бы отталкиваться для определения border-image. Кроме того, кажется, в ФФ это вообще не сработает. В вебкитах/опере можно, в итоге, лишь примерно подогнать это дело под известную ширину блока, но вот если размеры блока будут неизвестны — всё будет разъезжаться.

    Но если же вы уже делали такое — было бы интересно посмотреть на пример. У меня сходу ничего толкового не вышло :)
  • Прощай, Zen Coding. Привет, Emmet!
    0
    О, точно. Спасибо.
  • Прощай, Zen Coding. Привет, Emmet!
    0
    Надо, на странице про CSS-сниппеты.

    Жаль, что live templates не были вынесены в Open Source. Мне долгое время казалось, что где-то в ярушке был пост про них, но не смог найти. Я хотел на него сослаться когда буду делать нормальный сайт для Хаяку, т.к. далеко в основе лежат live templates с Zen CSS наравне. Никаких внешний артефактов точно не сохранилось? Куда ссылку ставить? :)
  • Прощай, Zen Coding. Привет, Emmet!
    +1
    «Присвоить» — нельзя. «Не упомянуть» — можно (но не нужно).

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

    А если чья-то идея легла в основу твоего проекта, это тем более важно. Да, иногда про это можно забыть, это может потеряться и часто не узнаешь откуда та или иная идея пошла. Но сейчас не такой случай, конечно.
  • Прощай, Zen Coding. Привет, Emmet!
    +10
    Реализация без идеи тоже ничего не стоит. Так как её не будет.

    Идея CSS-selector-like HTML-сниппетов — то, из-за чего вообще Zen Coding обрёл популярность. Вадим не просто предложил идею, а довольно подробно её описал. И, прямо в описании, предложил кому-нибудь стать соавтором.

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

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

    Это то, что лежит в основе — взаимоуважение и послание людям: «сообщество уважает вас и ваши идеи, не бойтесь их выражать, их подхватят другие и разовьют». Сохранение авторства — та штука, которая может мотивировать людей придумывать новое, не класть идеи в стол.
  • Верстка писем. Снова баги
    0
    Это свойство просто «выключает» cellspacing, если прописать таблице инлановый стиль border-collapse:separate, то мы его не вырежем и после этого cellspacing будет нормально работать.
  • Верстка писем. Снова баги
    0
  • Верстка писем. Снова баги
    0
    3. Хмм, вот сейчас сам себе отослал письма с таблицей, ни border-collapse:separate ни cellspacing не вырезались. Как раз во встречающихся у простых пользователей письмах чаще нужно коллапсирование, чем его отсутствие.

    4. Мы подумаем об этом, конечно, но ничего обещать не могу.
  • Верстка писем. Снова баги
    +2
    Привет. Спасибо за конкретные примеры :)

    1. У меня не получилось это воспроизвести — быстро переслал себе через визивиг копипастом такую таблицу и получил то, что нужно — только пунктирную границу слева. Не могли бы вы мне переслать на kizu@yandex-team.ru конкретный пример, который у нас не работает? Посмотрим, разберёмся.

    2. Ну, тут довольно спорный момент. Если не менять дефолтный лайн-хейт, то текст будет гораздо менее удобно читать. 1.2em — далеко не самая оптимальная высота строки для чтения. Тут уж или всем улучшать, или, в редких случаях, кому-то что-то по мелочи ломать. Так уж можно и ожидать, что пользователи везде будут ожидать дефолтного серифного 16px шрифта. Но в любом случае буду рад посмотреть на примеры писем, которые ломаются из-за большого лайн-хейта.

    3. Разработчики писем, почему-то, чаще верстают так, что отсутствие коллапсирования всё ломает. После его добавления я не помню жалоб на то, что он у нас есть — так что, пожалуйста, пришлите конкретные примеры писем (+ скриншоты из десктопного аутлука с проблемой), чтобы можно было посмотреть что да как.

    4. Нам самим хочется добавить возможность использовать хедерные стили, но там кроется очень много подводных граблей, на обхождение которых всё никак не может найти время :( Надо очень жёстко санитайзить такие стили, убирая или экранируя опасные стили, что не совсем банально и может сказаться на производительности. Альтернатива — использовать айфрейм для сендбоксинга — также имеет очень много проблем. В общем, мы думаем над этим, но пока времени нет на то, чтобы добраться до решения этой задачи — она довольно большая. Делать полумеру вроде поддержки только стилей для ховера также опасно — для этого всё равно надо парсить стили, санитайзить содержимое соответствующих блоков деклараций и т.д.

    И да, ещё раз — можно мне пересылать на почту kizu@yandex-team.ru конкретные письма, которые ломаются в нашем веб-интерфейсе. Будем разбираться :)
  • Frontender Magazine: давайте поговорим о фронтенде
    0
    Насколько я понимаю «Update your public repositories (Commits, Issues, etc).» нужно для того, чтобы дать возможность оставлять комментарии к issues. У Гитхаба сейчас вроде нет возможности ограничить права только на issues, увы.

    Альтернативой, не требующей таких обширных прав, сейчас может быть только gists — там тоже есть возможность комментирования, но в этом случае пропадёт привязка к репозиторию со статьёй.
  • Frontender Magazine: давайте поговорим о фронтенде
    0
    Чтобы читать в любой читалке в мобильном девайсе. Некоторые предпочитают и такой формат. Раз в месяц, кажется, было бы оптимально. Если всё автоматизировать, то времени это нисколько не будет отнимать, но кому-то может пригодиться :)
  • Frontender Magazine: давайте поговорим о фронтенде
    0
    Как вариант можно попробовать собирать переодически (месяц? раз в пару недель?) epub со статьями, например, с помощью readlists — readlists.com/777a586f — там для любого такого «списка» есть ссылка «Download e-book». Возможно, там где-то есть API (он точно есть у родительского проекта — Readability).
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    0
    Пока не решили :) Нам был нужен препроцессор «здесь и сейчас», Стайлус же большинство наших задач решает уже сейчас.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    0
    Да, мы смотрели на него. Он пока очень сырой, те же проблемы с parent reference, менее гибкие интерполяции, чем в стайлусе и т.д.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    +1
    Можно, но у нас такой необходимости нет т.к. используется, по сути, только одна старая версия ие — седьмая (шестой мы не поддерживаем, восьмой переводим в режим седьмого).

    А так — да, для нормальных браузеров задаём ie=0, для разных ие — его версию, так будут даже работать проверки вроде if ie > 6 и т.д.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    0
    Особые заморочки. Там неверное архитектурное решение, из-за чего парсер размазан тонким слоем по всему коду, в итоге проблем именно из-за парсера встречается довольно много.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    0
    Неа. Люди просят, но авторы как-то подзабросили это дело. Для всяких респонсив штук Sass сейчас гораздо лучше подходит.

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

    Как я в статье и написал — для многих задач Sass подходит лучше, но не для наших :)
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    0
    Да, не умеет :( Потому, там это есть из коробки.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    +1
    А вот это, кстати, очень спорный момент. Я понимаю необходимость подобных конструкций в препроцессоре, но не уверен, что это нужно в самом CSS.

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

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

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

    В CSS есть множество других вещей, которые нужно бы сделать до того, как нужно будет приступать к возможностям препроцессоров.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    0
    Второй вариант у меня выдаёт ошибку «unexpected «outdent»».

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

    .foo,
     {
      width: 10px;
    }
    
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    +1
    Стайлус не понимает как минимум два более-менее распространённых CSS-кодстайла:

    .foo
    {
        /* … */
    }
    


    и

    .foo {
        /* … */
        }
    


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

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

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


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

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

    Онлайн-пробник Стайлуса пока что не очень хороший: авторы постоянно забывают его обновлять в соответствие с последними изменениями в репозитории, кроме того он часто может войти в бесконечный цикл, особенно если попробовать поиграться с отступами как в первых примерах в этом комментарии.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    0
    Как я и написал в статье — мы отказались от поддержки IE6 в основной версии Яндекс.Почты, а в IE7, на самом деле, очень много багов поправили, так что специально что-то под него писать стало нужно очень редко.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    +4
    IEN-js — адская серия библиотек, в серьёзных проектах ничего кроме головной боли не приносящих. Используемые в этих библиотеках решения далеко не оптимальны. Для больших веб-приложений, когда на странице могут существовать тысячи экземпляров какого-то блока, применение таких библиотек будет вызывать жуткие тормоза вплоть до невозможности использования интерфейса. И это не считая возникающих из-за этих библиотек новых багов.

    Путь graceful degradation и ручного контроля над стилями гораздо правильнее: вместо того, чтобы добавлять в IE логики, мы, наоборот, уменьшаем количество отдаваемых ему стилей. Нам не важно, что в IE не будет сгруглённых уголков, градиентов и полупрозрачности, нам важнее, чтобы интерфейс в нём быстрее работал.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    0
    Как раз об этом мы и напишем в одной из следующих статей :) Если коротко, то, как описано в статье, «в других [темах] фон может меняться — случайно или в зависимости от времени суток и погоды» — то есть в одной теме может случайно ротироваться порядка двадцати фоновых изображений, сейчас при создании темы достаточно просто сказать сколько есть всего таких изображений, разложить их по папочкам и всё — Стайлус сам сгенерирует все стили со всеми модификаторами.
  • Почему мы стали использовать препроцессор Stylus в Яндекс.Почте, а также о библиотеке, помогающей жить с IE
    0
    Да, в Sass экстенд лучше всего сделан. В Стайлусе есть только базовая его поддержка: без селекторов-плейсхолдеров и он работает только на стили, написанные выше вызова @extend, тогда как Sass обработает всё, в том числе и объявленое позже.
  • 300 миллионов пользователей и переход на WebKit
    +24
    Надеюсь, что получится нормально перенести бóльшую часть интерфейсных решений, которые завязаны на движок, я многим из этого пользовался когда сидел на Опере.

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

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

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

    Кстати, а что будет с Dragonfly?
  • Дайджест интересных новостей и материалов из мира айти за последнюю неделю №41 (19 — 25 января 2013)
    0
    Ну вот сервис, который я выше привёл это и делает :) См. в левой колонке в «export».
  • Дайджест интересных новостей и материалов из мира айти за последнюю неделю №41 (19 — 25 января 2013)
    0
    Как вы себе это представляете? Всё, что можно, в такой формат сваливается — изображения и прочее. Демки же и встроенные ссылки автоматически не получится подцепить, а каким-либо образом выдирать их для размещения в epub — адовая работа. Кстати, как вы предлагаете в epub сохранять демки, которые должны работать, скажем, только в Chrome Canary?

    Самый правильный вариант — создавать epub только из текстовых статей, всё остальное же приводить отдельно в дайджесте. Текст можно будет и в дороге прочитать, а вот демки всё равно почти никто не будет с мобильных девайсов смотреть.
  • Дайджест интересных новостей и материалов из мира айти за последнюю неделю №41 (19 — 25 января 2013)
    +1
    Кстати, да — есть сервисы вроде readlists.com, позволяющие довольно просто делать epub из набора ссылок. Например, для подраздела CSS получается вот такой список: readlists.com/7e40e363/

    Результат, кстати, довольно неплохой, правда, всякие демки с сайтов вроде jsfiddle, понятное дело, нормально не подтягиваются.
  • Hayaku — пишем CSS быстрее
    0
    Попробуйте перезапустить Саблайм — сейчас проверил — почему-то после установке через package control саблайм не подхватывает настройки для отдельных синтаксисов пока его не перезагрузишь :(

    В дальнейшем попробую перенести настрйоки прямо в код, чтобы не зависеть от подобного поведения саблайма/пакетов.
  • Hayaku — пишем CSS быстрее
    0
    Должен как для sass — за это отвечает сам ST2 — какой синтаксис он подхватит, тот и будет использоваться.
  • Hayaku — пишем CSS быстрее
    +1
    Идея Хаяку во многом именно в том, что, как таковых, сокращений-то и нет. Есть набор алгоритмов, разбирающих аббревиатуры и подбирщих наиболее подходящую пару свойство-значение из словаря.

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

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

    И да — Хаяку не претендует на идеальность, это всего лишь ещё один способ быстро писать CSS. Если кого-то он не устроит — всегда есть как минимум несколько альтернатив. Конкуренция — это хорошо.
  • Hayaku — пишем CSS быстрее
    +1
    Пока почти никак — но в будущем появится возможность определять в настройках свои сниппеты и статические аббревиатуры, если такая необходимость возникнет. К сожалению, в саблайме нельзя нормально управлять приоритетами сниппетов и команд, так что можно либо использовать только статичные сниппеты, либо что-то более умное, но переопределяющее нажатие на таб.
  • Hayaku — пишем CSS быстрее
    +4
    Спасибо за обзор!

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

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

    2. Хочется уточнить про значения по умолчанию: они не просто вставляются, а вставляются с выделением — оставляя возможность продолжить написание своего значения. Сейчас в посте это не совсем очевидно написано.
  • Новый аккуратный трёхпанельный интерфейс Яндекс.Почты для деловой переписки
    +1
    Пока нет, но мы думаем об этом. Размер окна специально не зафиксировали так как глобальные скроллбары вместе с локальными совсем не дружат. Но да — пока из-за этого есть проблемы с шапкой, их мы и планируем решить используя медиаквери.
  • Популярно о псевдоэлементах :Before и :After
    +2
    Ну да, не решил, а обошёл, и не для всех свойств. Но пока есть баги вне ФФ — этим вполне можно пользоваться, если хочется сделать что-то здесь и сейчас.