По этой теме много чего можно рассказать, но если кратко:
— Sass отличный, но он а) на руби, б) имеет местами излишне громоздкий синтаксис (для `.scss`), в) не поддерживает конкатенацию с parent reference (типа `&__element`).
— Less — очень-очень слабый, как-то спасает возможность внутри использовать js, но в целом он очень простой. Его сильная сторона — низкий порог входа, но когда нужно сделать что-то не банальное, его возможностей не хватает.
— Stylus — как и Less работает на js — у нас и так всё на нём, для нас это преимущество. Он очень гибкий и позволяет делать много сложных штук. Если сравнивать по функциональности с Sass, то он в чём-то и проиграет, но большинство минусов для нас не имеют значения. Зато у Стайлуса прозрачный синтаксис миксинов — не нужно учить новый синтаксис для префиксных свойств, просто подключаешь библиотеку с миксинами и всё будет работать.
А вообще, самый простой способ понять какой препроцессор использовать — взять какой-то свой проект и по очереди переписать весь CSS на разных препроцессорах — максимально используя их возможности. Сразу станет ясно что подходит, а что — нет :)
Да, в Почте уже перешли на Stylus. Не целиком, конечно, — перевести код с таким наследием за один раз практически невозможно.
Сейчас больше половины старых блоков подключается импортами в css, но все новые блоки уже сразу пишутся на стайлусе, ну и как только какой-то блок надо подправить — он также переводится на стайлус. Плюс, новые темы для Почты также делаются, используя стайлус. Процесс идёт :)
Подробнее про переход на стайлус я когда-нибудь (как смогу найти на это время) напишу статью в наш блог по разработке интерфейсов.
Это не сложно сделать, просмотрев на список Most Funded и их апдейты.
Ну разве что в игровом разделе пока тихо — но там и проекты все пока свежие. А в дизайне и технологиях куча выстреливших и уже доставленных пользователям аксессуаров для всяких айфонов-айпадов-велосипедов и т.д.
Скажем, один мой знакомый сейчас вполне успешно использует olloclip (там, правда, не стопятьсот, а всего лишь $68201 собрали). Ну или можно посмотреть на ютубовские ролики счастливых пользователей Printbotr — он уже $830827 собрал. И т.д.
Да, отсутствие бордер-радиуса для бордер-имаджа — огромный недостаток, обидно, что нельзя хотя бы обрезать получающийся блок, не то, что пускать границу по радиусу.
Ха, сам думал у себя написать про этот метод, но поленился. Отлично, мне меньше работы :)
По поводу минусов:
1. Для очень маленьких бордер-радиусов (2-3 пикселя максимум) можно сделать и полупрозрачные градиентные бордеры, и полупрозрачный градиентный фон. Советую подумать над тем, как это сделать, не хочу сразу давать подсказку :)
2. Для больших бордер-радиусов есть один хак, которым можно добиться и больших скруглений при непрозрачном фоне. Один из вариантов можно посмотреть на этой картинке — там виден недостаток: края скруглённого бордера получаются чуть светлее, чем нужно. Другой метод, почти без недостатков, можно элементарно сделать с псевдоэлементом, но в этом случае для элемента нужно прописывать z-index, что не всегда может быть применимо.
Код обоих вариантов не буду приводить, оставлю на откуп экспериментам. Но если надо — могу и про них написать.
Недавно обнаружил, что многие крутые штуки, которые я использую, сделал он — препроцессор Stylus, шаблонизатор Jade + огромное число проектов для Node.js можно найти у него в гитхабе.
Кстати, у Лии забыли упомянуть одну из её важнейших вещей — dabblet.com — аналог jsfiddle, только для html&css, но с отображением результата в реальном времени.
Кстати, советую посмотреть на мой вариант попапов только на CSS: kizu.ru/fun/popups/#SomePopup2 — правда, я там акцентировал внимание на том, чтобы показывать/скрывать попап используя только CSS, и на анимации появления/скрытия через транзишны, т.е. над центрированием по вертикали не заморачивался.
Но, может, заморочусь как-нибудь — иногда это бывает надо, да.
Ну там даже в таблице видно, что id не везде быстрее, а где быстрее — то разница минимальна. При этом проблемы с использованием id того не стоят совершенно: классы гораздо, гораздо гибче. Потому id для вёрстки, на самом деле, бессмысленно использовать: только в качестве якоря и/или для использования :target, во всех остальных случаях оправданнее использовать классы.
Нет :) В данном случае на перерисовку тратится некоторое время, но на поиск элементов времени таки тратится больше: это можно заметить если открыть оба примера и, выбрав какой-то радиобатон (кликнув и нажав таб для активации фокуса), попереключать их с клавиатуры быстро нажимая влево-вправо-влево-вправо. В Вебкитах исправленный вариант работает моментально, не исправленный — тормозит. В ФФ (у меня 9.0) исправленный вариант не моментален, но заметно (более чем в 2 раза) быстрее, чем не исправленный.
Это, кстати, достаточно хороший тест-кейс, демонстрирующий влияние одного только поиска элементов по селектору в CSS на время рефлоу. И видно, что правильно использоанные селекторы в больших проектах могут дать ощутимый рост производительности, особенно если используется какая-то анимация, которая может триггерить рефлоу. Вполне можно использовать как пример для пропаганды БЭМ :)
Тут смысл в том, что селектр «~» — не самый быстрый, потому для длинного списка для последних пунктов движку браузера приходится долго-долго идти по всему дому в самое начало. Но если добавить враппер и матчиться уже на него, то это очень сильно облегчает жизнь движку: ему в таком случае надо смотреть на минимальное количество элементов.
Привет. Да, я согласен, мне нужно ещё учиться и учиться выступать, спасибо за критику!
Другое дело, что запись доклада и живое выступление сильно различаются: не всё, что хорошо идёт в зале будет нормально восприниматься в записи и наоборот. Выше вот критиковали Славу, советовали в следующий раз использовать лазерную указку, но на деле никаких проблем с артикуляцией жестами не было, а вот кружок лазерной указки с последних рядах не было бы видно.
Замечательно! Есть к чему придраться, но работа проделана отличная.
Было бы интересно почитать побольше подробностей про реализацию: наверняка же встретились разные особенности в применении трансформов и градиентов? Подобные примеры позволяют очень хорошо изучить всяческие грабли и подводные камни, об этом вполне можно написать серию статей :)
А, да: из придирок одну-таки упомяну: на js тут надо было сделать только тянущийся слайдер, а вот все остальные состояния было бы круто сделать тоже чисто на CSS, на :target или на :checked.
Использование тени вместо градиента для сохранения кликабельности — хороший момент.
А так — чаще нужно использовать затухание только тогда когда это действительно нужно, т.е. когда длина текста превышает высоту соответствующего блока. На этот счёт на хабре была хорошая статья: habrahabr.ru/blogs/css/116646/ — возможно, можно тот метод проапгрейдить тенью, это будет более кроссбраузерный «проклик», чем pointer-events: none;
Слайдер работает на других тач-устройствах, просто не так хорошо как хотелось бы (читай — другие устройства пока работают не так хорошо как хотелось бы), но, хочется верить, или устройства постепенно начнут поддерживать тач-жесты без тормозов, или скрипт будет доработан, если найдём способ сделать это хорошо и для старых тач-устройств.
— Sass отличный, но он а) на руби, б) имеет местами излишне громоздкий синтаксис (для `.scss`), в) не поддерживает конкатенацию с parent reference (типа `&__element`).
— Less — очень-очень слабый, как-то спасает возможность внутри использовать js, но в целом он очень простой. Его сильная сторона — низкий порог входа, но когда нужно сделать что-то не банальное, его возможностей не хватает.
— Stylus — как и Less работает на js — у нас и так всё на нём, для нас это преимущество. Он очень гибкий и позволяет делать много сложных штук. Если сравнивать по функциональности с Sass, то он в чём-то и проиграет, но большинство минусов для нас не имеют значения. Зато у Стайлуса прозрачный синтаксис миксинов — не нужно учить новый синтаксис для префиксных свойств, просто подключаешь библиотеку с миксинами и всё будет работать.
А вообще, самый простой способ понять какой препроцессор использовать — взять какой-то свой проект и по очереди переписать весь CSS на разных препроцессорах — максимально используя их возможности. Сразу станет ясно что подходит, а что — нет :)
Сейчас больше половины старых блоков подключается импортами в css, но все новые блоки уже сразу пишутся на стайлусе, ну и как только какой-то блок надо подправить — он также переводится на стайлус. Плюс, новые темы для Почты также делаются, используя стайлус. Процесс идёт :)
Подробнее про переход на стайлус я когда-нибудь (как смогу найти на это время) напишу статью в наш блог по разработке интерфейсов.
Ну разве что в игровом разделе пока тихо — но там и проекты все пока свежие. А в дизайне и технологиях куча выстреливших и уже доставленных пользователям аксессуаров для всяких айфонов-айпадов-велосипедов и т.д.
Скажем, один мой знакомый сейчас вполне успешно использует olloclip (там, правда, не стопятьсот, а всего лишь $68201 собрали). Ну или можно посмотреть на ютубовские ролики счастливых пользователей Printbotr — он уже $830827 собрал. И т.д.
Без поддержки маркдауна (или иного облегчённого языка разметки) Хабр нельзя называть серьёзным IT-сайтом.
По поводу минусов:
1. Для очень маленьких бордер-радиусов (2-3 пикселя максимум) можно сделать и полупрозрачные градиентные бордеры, и полупрозрачный градиентный фон. Советую подумать над тем, как это сделать, не хочу сразу давать подсказку :)
2. Для больших бордер-радиусов есть один хак, которым можно добиться и больших скруглений при непрозрачном фоне. Один из вариантов можно посмотреть на этой картинке — там виден недостаток: края скруглённого бордера получаются чуть светлее, чем нужно. Другой метод, почти без недостатков, можно элементарно сделать с псевдоэлементом, но в этом случае для элемента нужно прописывать z-index, что не всегда может быть применимо.
Код обоих вариантов не буду приводить, оставлю на откуп экспериментам. Но если надо — могу и про них написать.
Недавно обнаружил, что многие крутые штуки, которые я использую, сделал он — препроцессор Stylus, шаблонизатор Jade + огромное число проектов для Node.js можно найти у него в гитхабе.
Кстати, у Лии забыли упомянуть одну из её важнейших вещей — dabblet.com — аналог jsfiddle, только для html&css, но с отображением результата в реальном времени.
Но, может, заморочусь как-нибудь — иногда это бывает надо, да.
Это, кстати, достаточно хороший тест-кейс, демонстрирующий влияние одного только поиска элементов по селектору в CSS на время рефлоу. И видно, что правильно использоанные селекторы в больших проектах могут дать ощутимый рост производительности, особенно если используется какая-то анимация, которая может триггерить рефлоу. Вполне можно использовать как пример для пропаганды БЭМ :)
Вот, можно сравнить, разница должна быть заметна:
— старый вариант: dabblet.com/gist/1528271
— исправленный вариант: dabblet.com/gist/1528281
Тут смысл в том, что селектр «~» — не самый быстрый, потому для длинного списка для последних пунктов движку браузера приходится долго-долго идти по всему дому в самое начало. Но если добавить враппер и матчиться уже на него, то это очень сильно облегчает жизнь движку: ему в таком случае надо смотреть на минимальное количество элементов.
Другое дело, что запись доклада и живое выступление сильно различаются: не всё, что хорошо идёт в зале будет нормально восприниматься в записи и наоборот. Выше вот критиковали Славу, советовали в следующий раз использовать лазерную указку, но на деле никаких проблем с артикуляцией жестами не было, а вот кружок лазерной указки с последних рядах не было бы видно.
Я быстренько, на основе вашего варианта сделал аналог на ховере: dabblet.com/gist/1522751 — особо его не прорабатывал, но идея должна быть понятна :)
(фф/вебкиты ок)
Было бы интересно почитать побольше подробностей про реализацию: наверняка же встретились разные особенности в применении трансформов и градиентов? Подобные примеры позволяют очень хорошо изучить всяческие грабли и подводные камни, об этом вполне можно написать серию статей :)
А, да: из придирок одну-таки упомяну: на js тут надо было сделать только тянущийся слайдер, а вот все остальные состояния было бы круто сделать тоже чисто на CSS, на :target или на :checked.
Что касается меню, то вот соответствующий раздел: cssplay.co.uk/menus/
А так — чаще нужно использовать затухание только тогда когда это действительно нужно, т.е. когда длина текста превышает высоту соответствующего блока. На этот счёт на хабре была хорошая статья: habrahabr.ru/blogs/css/116646/ — возможно, можно тот метод проапгрейдить тенью, это будет более кроссбраузерный «проклик», чем pointer-events: none;