SelenIT

А без мышки никак прокрутить нельзя? А то у меня сейчас реально мышку от ноута отобрали, только стрелки и pgUp/pgDown для скролла и остались Похоже на то, что где-то координаты неадекватно пересчитываются, сдвиг меняется на столько же пикселей, на сколько меняется общая ширина контейнера, а содержимое-то резиновое и должно сдвигаться пропорционально... хотя не исключаю, что это я чего-то наотключал, а теперь без мышки и этого проверить не могу(

Читать же вы его будете не в этом масштабе, а приблизив (напр. двойным "тапом"). Вот тогда он идеально впишется в ширину окна (левая колонка и правое поле спрячутся), и скроллить его надо будет только вертикально. А на обзорном виде (как на скриншоте) он остается узким, чтобы не было скачков при смене масштаба. Это можно отключить (у встроенного браузера в моем андроиде 4.0 - "Настройки/Расширенные/Мобильный вид"), но читать текст без этой фичи - сущее мучение.

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

Из-за vertical-align:baseline инлайн-блоков (по умолчанию). Решение — дать им vertical-align: top.

http://habrahabr.ru/post/175375/

С padding-ом IE9 артачился, к сожалению(

С радиусом чуть сложнее, но при известном паддинге выкрутиться можно

http://jsfiddle.net/q9Vmk/4/ ?

Потому что у шрифта есть верхние выносы и заплечики: http://zaplokee.net/quick-reference-of-typography-terms/#ninth

Может, http://jsfiddle.net/GddQh/3/? Или я чего-то недопонял?

Смущает меня сильно. Если ничего не путаю и кеш моих знаний муськи не протух, при таком раскладе индексы по полю int_val горько плачут, даже если в таблице они есть. Предполагаю, что задействовать индекс и ускорить процесс можно как-то так: SELECT (CASE WHEN int_val BETWEEN 1388952001 AND 1389038400 THEN '2014-06' WHEN int_val BETWEEN 1388865601 AND 1388952000 THEN '2014-05' WHEN int_val BETWEEN 1388779201 AND 1388779200 THEN '2014-04' WHEN int_val BETWEEN 1388692801 AND 1388692800 THEN '2014-03' .... END CASE) as 'y-m', COUNT(int_val) AS cnt FROM.... весь этот жуткий запрос ... GROUP BY CASE.... весь жуткий CASE из начала ... END CASE ORDER BY CASE.... весь жуткий CASE из начала ... END CASE DESCно не проверял, так что не гарантирую.

Судя по этой статье (и эта, кажись, подтверждает), участие GPU в процессе зависит не от способа анимации, а от анимируемого свойства (для трансформаций, как минимум 3D, прозрачности и еще пары подобных украшалок включается, для всяких left/right, width/height и т.п. — нет). Есть небольшая разница за счет того, что JS-анимации идут в основном потоке, а CSS — как бы в отдельном, но именно небольшая, т.к. основную нагрузку дает сама перерисовка, которая никуда не девается. CSS-анимации проще в создании и поддержке, JS-анимации дают немного больше контроля и гибкости, так что, как всегда, нужно выбирать инструмент по задаче

Может, тупо не успевает за полсекунды? Если по $(window).load() вызывать, ситуация не меняется?

Поэтому «тоже». Хромой, так уж и быть, пусть пока пользуется своим костылём, но другим-то (Фоксу, IE10+, Опере12) зачем из-за его хромоты страдать?

И, плз, указывайте всё-таки стандартное свойство без префикса тоже. Пожалейте котят!

Это устаревший синтаксис флексбоксов. Лучше сразу используйте новый, он работает во всех новых браузерах без префиксов. Кстати, разве префикс -chrome- существует?

Насколько я понимаю, медиазапрос к width выдает то, что зашито в meta viewport width. В случае device-width должно возвращать 320.

Не надо ничего исправлять. Это действительно CSS3, абсолютно валидный (насколько это вообще возможно для CSS), полностью совместимый с любой версией HTML, включая эту. Предупреждение — не ошибка. И что за валидатор, кстати?

И backface-visibility для всего надо бы убрать, оставить для нужного. А то бедный браузер может замучиться рисовать *каждый* элементик в отдельном слое рендеринга…

320, как я понимаю. Под «viewport» эмулятора, судя по всему, предполагается screen.width, а ему вообще никогда верить нельзя.

"Апскейл" — увеличение, растягивание . Я поначалу подумал, что эти фоны всё равно слегка размыливаются (и для них это не баг, а фича), и не будет беды, если растянуть их еще сильнее. Возможно, неправ, надо проверять. Да, на hotdot.pro сделано флоатами, но там весь их контейнер как целое сдвигается 3D-трансформацией (по крайней мере, в тех браузерах, которые это умеют). Плюс стоит overflow:hidden на html — возможно, это тоже как-то оптимизируется (надо будет погуглить). Интересно, что у меня это в фоксе работает плавнее, чем в яндекс-браузере (в последнем подлагивает на больших портретах и айпаде с меняющимся содержимым экрана).

Там обычный CSS 3D Transform + Transition, просто с префиксом -webkit-, поэтому в др. браузерах не работает (поубивал бы за такое). По кнопке меняется класс у контейнера, в зависимости от этого класса transform для каждой грани задается по-разному, благодаря transition-у переход происходит плавно. Для контейнера задана анимация вращения.

Скорее, 3000 пикселей много для 300-килобайтной картинки, имхо. При таком качестве можно и сильнее апскейлить, экономя оперативку и кол-во операций по преобразованию пикселей при визуально малозаметной разнице. Не уверен, что это решит проблему (итоговый массив для отрисовки-то останется примерно тем же), но я бы попробовал. Еще float-ы сами по себе напряжноватая вещь для динамики, поскольку они зависят друг от друга, браузеры любят запускать reflow при любом неосторожном движении возле них. Если ширины блоков известны, я бы заюзал absolute. Заодно можно по onsroll делать блокам, заведомо не попадающим в экран, display:none — кто-то умный говорил, что иногда браузерам от этого становится легче...

От лагов при скролле есть еще вот такое лекарство. Если на этих картинках есть какие-нибудь эффекты типа ховера, может помочь. А фоны эти анимируются?

Как скриптик может помочь ускорению перерисовки того же количества тех же пикселей? -*-backface-visibility: hidden (для moz она тоже существует) может помочь, т.к. создает RenderLayer (и его аналоги) — что-то типа современного hasLayout-а. И, в каких-то нигде толком не документированных случаях, перекладывает работу по отрисовке на GPU, что-таки может ее ускорить. Но говорят, что в самом вебките эту лазейку прикрывают (про блинк пока не знаю). В общем, имхо, надо тестить, и если где-то помогает, нигде не мешая — почему нет?