Обнаружение Ретины
Поскольку у меня теперь «Макбук» с Ретиной, я изучаю вопрос как сделать сайты пригодными к отображению на таких экранах. Возможно читатели с Ретинами уже заметили кое-какие изменения на сайте.
Наиболее животрепещущий вопрос — подготовка изображений для Ретины.
Напомню, что Ретина — технология Эпл, ставшая уже нарицательной, заключающаяся в примерении экранов высокого разрешения (например, на моём ноуте это 2560×1600) с отображением на нём обычной графики так, как бы это выглядело на экранах вдвое низкого разрешения. При этом шрифт смотрится просто великолепно, как на бумаге, а вот с картинками беда.
В вебе бо́льшая часть графики выглядит не очень (хотя масса сайтов уже подготовилась). Для того, чтобы стало хорошо, все изображения надо готовить вдвое большего размера, при этом указывая для них в коде вдвое меньший размер, тогда проявляется вся мощь Ретины — будет видно самые мелкие детали изображения и пропадёт размытие.
Пока ещё не у всех Ретины, хочется, чтобы клиенты, у которых её нет, не грузили лишнего. К сожалению, загвоздка в том, что браузеры пока не научились сообщать серверу, что мы имеем дело с таким (пока) необычным экраном и есть только клиенские способы выяснить это.
Появилось уже несколько библиотек, которые на стороне клиента делают замены картинок на подходящие под тип экрана. Это всё равно вызывает лиший трафик, так как некоторые картинки успевают загрузиться, а если изображений много, замена, бывает, подтормаживает.
Насколько я вижу, даже в Эпл не придумали достойной альтернативы этой техники и у них сайт «улучшается» по мере загрузки — сначала грузятся обычные изображения, потом «ретиновые», если это необходимо.
Вообще, у Джипега, например, есть прогрессивная загрузка — по мере загрузки «прогрессивное» изображение не грузится сверху вниз, а становится всё чётче и чётче (хорошая иллюстрация этого есть в одном из параграфов «Ководства»). Надо будет поэксперементировать в эту сторону — нельзя ли прервать передачу на нужной детализации, если экран не «ретиновый».
А пока, у меня такое решение. Используем старые-добрые «печеньки» и mod_rewrite.
На стороне клиента первой строкой каждой нашей страницы ставим проверку по «ретиновые» экраны с установкой «печенья»:
<script>if(window.devicePixelRatio>=2)document.cookie='retina=1'</script>
Этот скрипт выполнится первым и все дальнейшие запросы на сервер будут содержать строку «retina=1», если мы имеем дело с Ретиной. Все изображения, для которых у нас есть две копии — обычная и «ретиновая» (в два раза большая) называем одинаково, но с постфиксом «@2x» для большей, при этом в коде указываем данные разрешения для более мелкой картинки:
<img src="/images/owl@2x.jpg" width="400" height="560" alt="Совушка">
Сейчас, конечно, Апач теряет популярность, но я воспользуюсь синтаксисом mod_rewrite, желающие могут переделать в Энжин Икс или какой-то другой синтакис:
RewriteEngine On
RewriteCond %{HTTP_COOKIE} !retina=1
RewriteRule (.*)@2x\.(gif|jpe?g|png|webp) $1.$2 [L,NC]
Этот код означает, что если не установлено «печенье» «retina=1», то нужно убрать постфикс «@2x» из имени картинки.
В итоге, если у нас Ретина, «печенька» ставится в самом начале, все дальнейшие запросы к серверу идут с ней и картинки грузятся как указано в коде — например, если указано «owl@2x.jpg», то эта картинка и грузится.
Если у нас обычный экран, «печеньки» нет, запросы к серверу идут без неё и из картинок вырезается постфикс «@2x», т. е. картинка «cat.jpg» грузится по своему имени, а вместо «owl@2x.jpg» загрузится «owl.jpg».
Voilà!
Если @2 заменить на @2x, то будет вообще отлично. Почему так? Без особой причины, просто при разработке приложений для iOS используется похожий принцип, когда кладется две картинки рядом и, если у нас ретина, iOS выбирает ту, в которой приписан суффикс @2x. Ну, типа, унифицированно.
А так — классная идея, действительно классная.
Со всей этой магией с определением ретины, есть очень интересный нюанс.
Большинство экранов, где нет «ретины» — имеют хорошее подключение к Интернету. Низкая скорость обычно у телефонов, который как раз имеют ретину. В итоге, те, кому действительно надо трафик экономить нуждаются в ретине.
Есть ещё более сложный вопрос. Как минимум картинки оформления сайта лучше заинлайнить в ЦСС. Но тут уже надо делать магию с загрузкой разных ЦСС в зависимости от кук.
В итоге, мне кажется, что проще не определять тип экрана и всегда отдавать картинки для ретины.
на экранах с разрешение вдвое меньше?
А как по дефолту отображаются на ретине сайты, где размеры сетки, шрифтов и картинок указаны в пикселях? Наверное, все равно какое-то масштабирование имеет место?
А почему отрицание «НЕ»? Ну, как-то человечнее всё же размышлять «если есть ретина, то делаем то-то и то-то»
RewriteCond %{HTTP_COOKIE} retina=1
, не? Или вот сюда — $1.$2 [L,NC] — проблематично вставить символ «@»?
Комментарий для petya:
Так же отображаются, у ретина-экранов в 4 раза больше физических пикселей, а логических — столько же, сколько было раньше.
Давайте я всем сразу отвечу, а не по одному комментарию :)
Ага, я постфикс неправильно вспомнил :) Думаешь, это так важно?
Можно же опеределять, что подключение плохое, особенно на «Андроидах»: http://bolknote.ru/all/3341/
Не, тут не надо. Можно просто сделать media queries и делать @import в этом условии.
Не понял в чём вопрос.
Потому что серверной стороне надо как-то знать какие картинки готовы для Ретины, а какие — нет. Серверная сторона узнаёт это по постфиксу.
У лебедева про jpeg немного неверно проиллюстрированно. И если остановить загрузку посередине, то картинка будет гораздо более худшего качества чем если бы она была с вдвое меньшим разрешением. Можно убедиться на медленных соединениях, что картинка даже перед самым последним «проходом» загрузки оставляет желать лучшего.
Небольшой доклад в тему с Google I/O 2013.
Комментарий для Toz:
Я уже давно не видел медленного соединения, потому и не помню уже как это выглядит :) Если будет время, поэксперементирую.
Комментарий для rodem:
Ничего себе маленький — 40 минут! Гелекси Эс IV — 441 dpi! Божежьмой!
Кстати, вот же ещё srcset:
Того и гляди скоро появится кругом.
Комментарий для rodem:
Этих стандартов — как грязи, я знаю три штуки. Реализован сейчас только один (в Вебките), да и тот только для фоновых изображений. Так что нам ещё долго ждать, пока что-то будет принято, реализовано и распространится.
А пока даже border-width нельзя сделать в один физический пиксель толщиной!
Комментарий для Евгения Степанищева:
Если будет единый стандарт, тогда проще будет менять скрипты, на него будут рассчитывать и так далее. А сейчас самый массовый вариант именно на Айфонах и с @2x. На Андроидах все рассовывается по папкам, но это, как мне кажется, чуть менее наглядно получается. Труднее видеть, что заретинено, что нет. Поэтому я для себя бы выбрал именно Айфонный вариант.
(это все размышления, конечно же все это ерунда и главное, чтобы выглядело красиво)
Комментарий для Leonya:
Ну тогда весь этот сыр-бор просто не нужен. Гоняться за особенностями каких-то девайсов — неблагодарное занятие. Увеличивать размер страниц и итоговый трафик, добавлять серверный код для обработки изображений, учитывая при этом все возможные действия с этими изображениями, и всё это только ради того, чтобы где-то на ретине картинка выглядела чуть лучше (и не исключено, что для этого обычному человеку понадобится микроскоп)? Не вижу смысла...
http://pepelsbey.net/pres/clear-and-sharp/
Комментарий для petya:
Это нормально — не видеть в этом смысла, обычные люди в будущее не смотрят.
Комментарий для Un1oR:
Простите, а вы с какой целью привели эту ссылку? Там есть решение лучше, чем предложенное мною или что?
Комментарий для Евгения Степанищева:
Будущее должно быть лучше настоящего, а ресайз графики под клиента — это тупиковый путь. Раньше в веб-дизайне считалось очень дурным тоном вставлять картинку на страницу, насильно масштабируя ее атрибутами, а теперь вот некоторые (тот же пепелсбей!) советуют именно так и делать, заставляя клиента при открытии каждой фотки выполнять двумерную интерполяцию!
Кроме того, новые технологии должны облегчать жизнь, а не усложнять. Одно дело — это когда есть технология Х, которая поддерживается клиентами на уровне стандарта, а другое — это когда для поддержки нужно изобретать велосипеды, а потом еще и самостоятельно поддерживать и допиливать эти велосипеды.
Не думаю, что костыли под ретину, это будущее.
Будущее за полным отказом от пикселей (когда отдельный пискель станет значительно меньше разрешающей способности глаза), векторной графикой и фотоформатом, приспособленным под произвольное разрешение. Из совсем утопического — фрактальное сжатие, из более реального — насколько я помню, для вейвлет-кодирования выходное разрешение не очень важно, картинка будет гладкой в любом случае, результат лучше, чем у масштабированного jpeg.
Комментарий для petya:
Раньше считалось дурным тоном в хорошем обществе иметь загар и заниматься зарядкой, а теперь, смотрите-ка, все наоборот!
Времена меняются и как было раньше никого не волнует, кроме историков.
Простите, а вы вообще вёрсткой занимаетесь? Большая часть того, что сейчас появляется, лишь усложняет жизнь — начиная с «дивной» вёрстки.
Комментарий для maxim-zotov.livejournal.com:
Конечно не это будущее. Будущее — костыли для тех, у кого не Ретина. Чуть более далёкое будущее — отказ от неретиновых экранов
Чудесное будущее, но пока недостижимое. Фрактальное и вейвлетное сжатие нас не спасут, нет у них этих чудесных свойств, на которые вы рассчитываете. Нас мог бы спасти ИИ, который смог бы перерисовывать любое фото в любое разрешение, но смысла в этом нет — у глаза конечные возможности, 250 точек на дюйм это для него совсем не предел, конечно, но стоит поднять это вчетверо и глаза уже не различат где 1000, а где 2000 dpi.
Главная проблема ретины — об ее поддержке задумываются только те, кто покупает себе макбук с ретиной. :)
Комментарий для Konstantin:
Главная проблема Ретины в том, что люди думают, что она только в технике Эпл. Ретина, конечно, торговая марка Эпл, но люди вокруг зовут ретинами любые экраны с большими dpi.
Теперь посмотрите на картинку:
http://img-fotki.yandex.ru/get/9321/35419492.c6/0_71c72_3a567f9e_L#%D0%A1%D0%BD%D0%B8%D0%BC%D0%BE%D0%BA%2B%D1%8D%D0%BA%D1%80%D0%B0%D0%BD%D0%B0%2B2013-05-26%2B%D0%B2%2B10.28.08.png%7Chttp%3A%2F%2Ffotki.yandex.ru%2Fusers%2Fbolknote%2Fview%2F466034%2F%3Fpage%3D2#500x305
Это кадр из выступления на Google I/O, ссылку на которую мне дали выше. Естественно, это не вся техника с большим dpi, пожалуй, сейчас труднее найти смартфоны без ретины, чем с ретиной. На очереди планшеты, раз Эпл там сделал Ретину, то появятся (если ещё не появились) ретиновые планшеты других производителей. Ноутбуки будут появляться медленнее всего (всё-таки это дорого), но шаг уже сделан — на картинке представлен Хроумбук с ретиной.
Комментарий для Евгения Степанищева:
Извините, но аналогия неудачная. Вы говорите о каких-то древних предрассудках, а я говорю о том, что было совсем недавно, и имело под собой вполне здравые и логичные основания.
Занимаюсь, причем очень давно, иначе бы не писал на эту тему. Насчет дивной верстки — она базируется на нормальной поддержке браузерами CSS (второй версии), и когда эта долгожданная поддержка повсеместной, она сильно УПРОСТИЛА жизнь верстальщика.
Комментарий для petya:
Имело — хорошее слово. Раньше смысла масштабировать картинку не было, это было вредно — лишний трафик и никакой пользы. Теперь есть очевидная польза.
И как только верстальщики стали её повсеместно использовать, оказалось, что во многих случаях она не делает то, что нужно — не даёт поменять страницу как хочется, а так же не даёт гибко задавать layout. И полезли всякие флексбоксы, vw/vh и прочее.
Мы живём во время становления стандартов, текущее положение дел далеко ещё от идеала, хоть и лучше, чем 10 лет назад, но до превращения вёрстки в тривиальное занятие (или нормальная автоматизация этого дела, что предпочтительнее) пока далеко. Сложность пока только растёт, а с ней и зарплата верстальщиков.
Сверстать таблицами мог любой дурак 10 лет назад, сейчас нормально сверстать дивами что угодно, порой, задача нетривиальная.
Комментарий для Евгения Степанищева:
Давайте рассмотрим этот вопрос на примере «обычного» сайта. Допустим, это блог, куда заливаются картинки размером 800*600 точек. Возьмем три ситуации: 1) картинка заливается и вставляется на страницу в своем реальном размере 800*600 (предварительно обработанная в редакторе, либо же обработка происходит автоматически во время загрузки); 2) картинка заливается в размере в 2 раза больше (1600*1200), а вставляется как 800*600; 3) происходит определение разрешения экрана пользователя (как в вашем варианте), сервер отдает нужную версию картинки, а вставляется все равно как 800*600.
В случае 1 ситуация такая — все получат и почти гарантированно увидят одно и то же изображение, на сервере один файл, лишнего кода нет.
В случае 2 ситуация такая — все получат (но вряд ли увидят!) одно и то же изображение, на сервере один файл, лишнего кода нет. Что увидят пользователи сайта, зависит от браузера, а если точнее — от алгоритма ресемплинга изображений, который будет применен для отображения картинки в «неродном» разрешении. И этот алгоритм будет точно не самым лучшим по качеству, иначе страницы бы открывались по несколько секунд с полной загрузкой процессора! Скорее всего, это будет какая-нибудь билинейная интерполяция, чтобы побыстрее. И результат будет явно хуже варианта 1. Кроме того, 99% юзеров видят сайт на обычном мониторе, и они никаких эффектов, кроме ухудшения картинки, увеличения времени загрузки и тормозов браузера при прокрутке страницы, не увидят.
В случае 3 ситуация такая — на сервере N изображений, которые отдаются клиенту в зависимости от его разрешения, каждый получит свою версию, хотя все версии все равно будут вставляться на страницу в одном размере, и если этот размер не родной для конкретного файла, то см. выше о ресемплинге. Ну и еще лишний код и на сервере, и на клиенте.
Так где же «очевидная польза»? В том, что обладатели экранов с высоким разрешением, возможно, получат картинку чуть лучше (хотя они ее скорее всего не просили)? Мне кажется, игра не стоит свеч.
Комментарий для petya:
Вы какую-то ерунду, простите, сейчас говорите, что выдаёт незнание вами предмета.
В случае №1 масштабированное изображение увидят пользователи Ретины — картинка 800×600 при указанных размерах 800×600 растянется до 1600×1200. В случае №2 ровно наоборот — пользователи Ретины увидят всё нормально, а пользователи без Ретины увидят смаштрабированное изображение.
Вы, похоже, не представляете на что способны современные процессоры. Скажите, вы вообще замечаете, что у меня сайт сделан под Ретину и только под неё?
Сейчас многие браузеры позволяют переключать алгоритм, а те, которые не позволяют, используют метод ближайших соседей.
Да вы просто никогда не видели как смотрятся обычные изображение на Ретине. Это просто «мыло», если выбирать из двух сайтов — сделанный для Ретины и нет, то я ни секунды не колеблясь, выберу первый.
Комментарий для Евгения Степанищева:
Я думаю в первую очередь о подавляющем большинстве пользователей, у которых обычные мониторы. То, что 1% пользователей с ретиной (а может, и меньше) увидят картинки в большем разрешении, меня мало радует в сравнении с появляющимися минусами. Может, вы живете в другом мире, в котором ретины у каждого второго, но я отталкиваюсь от своей статистики. Причем я даже уверен, что по вашему сайту статистика будет сильно отличаться от средней по рунету, сюда зайдет весьма узкий контингент.
Представляю, но не вижу смысла тратить вычислительные ресурсы на манипуляции с картинками на веб-страницах, с заведомо плохим результатом.
Для меня вопрос не в вашем сайте, а в самом этом подходе в применении к некоему среднестатистическому сайту.
Многие — это какие? Сижу на десктопе под виндой, ни в одном таких настроек не вижу. Кроме того, как вы думаете, какой процент обычных пользователей сможет переключить алгоритм ресемплинга в браузере? А метод «ближайших соседей» — это жуть...
В какой-то мере это так, но не совсем — у меня эппловских устройств нет, да и не хочется, но в руках держал разные ноуты и планшеты, а насчет отображения картинок на сайтах — просто не обратил внимания, надо будет проверить. Но если картинки «замыленные», то как раз вероятно, что это результат работы не самых лучших алгоритмов масштабирования при растягивании.
Комментарий для Евгения Степанищева:
Кстати, если вы имели в виду не настройку браузера, а обработку css-свойства «image-rendering», то это тоже не вариант, т. к. реально используемый алгоритм остается загадкой.
Комментарий для petya:
Нет, не остаётся. В стандарте ( http://dev.w3.org/csswg/css-images/ ) написано, в частности:
У Эксплорера же выпиленная сейчас фича прямо указывала алгоритм в названии: -ms-interpolation-mode:bicubic и -ms-interpolation-mode:nearest-neighbor;
Комментарий для petya:
Я вам ещё раз говорю: сейчас смартфоны без ретины встречаются реже, чем с оной. Планшеты подтягиваются, ноутбуки на очереди. Смотреть надо в будущее и учиться работать с ретиной заранее.
Вы мне так и не рассказали чем результат плох.
Вы утверждали выше, что сайт с картинками для ретины будет тормозить, а сами даже не замечаете, что мой сайт как раз сделан под ретину.
Многие — это вебкит, опера, файрфокс и ИЕ (версии 9 и ниже).
Да причём тут Эпл-то? Ретина, как я уже сказал, — уже общее название всех экранов с большим dpi.
А с чего им быть не замыленным-то? Картинка вдвое увеличивается, она не может остаться качественной с любым алгоритмом.
Комментарий для Евгения Степанищева:
А у файрфокса вот что: Since version 1.9 (Firefox 3.0), Gecko uses bilinear resampling (*high quality*). https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering
Так что насчет ФФ я угадал... :)
Насколько я понимаю, у других под high quality подразумевается либо bilinear, либо bicubic, которые очень далеки от совершенства.
Комментарий для Евгения Степанищева:
Алгоритмами, которые просто не могут дать хорошего результата.
Да у вас картинок-то и нет практически, и в оформлении графики нет, а я говорю о сайтах, где на одной странице идет пара-тройка десятков больших фото в неродных разрешениях. Вот там и начинаются тормоза. А если возможностей процессора хватает, чтобы не тормозить, это все равно можно увидеть по его загрузке. У меня в трее всегда висит монитор системных ресурсов, и при заходе на такие страницы я вижу это невооруженным глазом. Есть и другие факторы, которые реально потребляют очень много ресурсов, когда используются бездумно — тени, прозрачность, и т. д.
Хорошо, пусть будет так, если «люди вокруг зовут ретинами любые экраны с большими dpi». Только вот devicePixelRaatio у них будет разным, из чего следует, что картинки для «ретин» надо генерировать либо отдельно для разных коеффициентов, либо делать одну большущую для самого большого (я так понял, что на данный момент это 3), а остальные «ретины» будут делать даунскалинг.
Если исходное изображение качественное, то есть каждый пиксель несет информацию, то при качественном масштабировании в 2 раза на экране с такой плотностью точек, как у Ретины, этого вообще не должно быть заметно. Конкретно: для 21.5 дюймового экрана с разрешением 1920×1080 ppi составляет 102, у вашего макбука — 227, поэтому, если мы посмотрим на какую-то картинку, то на экране Ретины она будет все равно визуально меньше, даже при ее увеличении в 2 раза!
Я, когда в своё время ковырял эту тему, нашел идеальное решение, которое, пока, нигде не работает — это использование content: attr(<uri>, url). Сейчас мы используем замещение через JavaScript, когда картинка грузится без src, а дальше через js замещается на src-x1 или src-x2
Комментарий для o-mokhov.ya.ru:
Ты, кажется, где-то писал про это. Но не работающих вещей много, интереснее то, что работает :)
Комментарий для Евгения Степанищева:
Евгений, добрый день. Описанный вами способ обнаружения ретины очень удобен, но вот проблема: некоторые браузеры не применяют куку «retina» к запросам текущей страницы (например, последний firefox). Сначала нужно обновить страницу или перейти по ссылке, тогда уже кука будет отправлена на сервер.
Комментарий для Валерий:
Вы в этом полностью уверены? Я сейчас провёл эксперимент — стёр куку в FF и обновил страницу моего блога. Картинки прилетели именно для «ретины».
Комментарий для Евгения Степанищева:
Странно, спасибо, буду ещё экспериментировать.
Комментарий для Евгения Степанищева:
Евгений, подскажите, почему вы не указываете path и domain для куки? Получается, что в браузере будет храниться столько кук, сколько страниц пользователь посетил на сайте:)
Комментарий для Евгения Степанищева:
Евгений, на счёт FF — протестировал, не работает. Пробовал такой вариант ещё:
htaccess:
html:
В FF картинка для ретины показывается только после рефреша, в остальных браузерах — всё ОК.
Комментарий для Валерий:
Хм, интересно. А какая ОС?
Комментарий для Валерий:
Мой промах :)
Комментарий для Евгения Степанищева:
Тестировал FF 31.0 на Mac OS 10.9.4 (с ретиной) и Windows 8 (без ретины).
Ещё опытным путём было проверено, что куку не отправляет IE 11.
Для тестирования видоизменил код следующим образом:
htaccess:
html:
Ну и, соответственно, картинки называются test@1x.png и test@2x.png
Так вот, в FF и IE картинка не грузится при первом заходе (так как кука не приходит на сервер), после рефреша всё ок. В Опере, Хроме и Сафари всё работает с первого раза как надо. Пока никак не могу понять, в чём дело.
Комментарий для Евгения Степанищева:
Причем, фишка в том, что если заменить код:
на:
то всё заработает без проблем в FF и IE.
Комментарий для Валерий:
Последнее вполне понятно. А вот поведение FF с cookie больше похоже на последствие какой-то оптимизации.
Комментарий для Евгения Степанищева:
Если придумаете решение — поделитесь, пожалуйста:)
Комментарий для Валерий:
Поделюсь, конечно :) Только надо как-то придумать как повторять баг. У меня под «Маком» он не повторяется.
Комментарий для Евгения Степанищева:
http://tmp.figaroo.ru/retina/ — Евгений, можете проверить? Красный квадрат — картинка для не-ретины, зелёный квадрат — картинка для ретины. Если картинка не загрузилась — значит, куки нет. /* Этот комментарий после прочтения можно удалить. Если боитесь переходить по левым ссылкам — могу выложить исходный код примера. */ У меня в FF (включая 32-ую версию) под MacBookPro Retina 15 (старшая модель, 2012 г.) сначала картинка не грузится (т. к. нет куки), после рефреша показывается зеленый квадрат. В FF под виртуалкой (Parallels Desktop) в Win 8 сначала картинка не грузится, после рефреша показывается красный квадрат. В остальных браузерах сразу показывается зеленый или красный квадрат. P.S.: простите, если надоел вам с этой проблемой:)
Комментарий для Валерий:
Хм. У меня тоже не загрузилась картинка.
Нет, не надоели, что вы.
У меня мысль возникала — что если в скрипте, где ставится куки, попробовать использовать document.open(); document.write(’test’); document.close(); не изменится ли поведение FF?
Комментарий для Евгения Степанищева:
Попробовал. Результат остался тем же...
Комментарий для Валерий:
Видимо, это какая свежая оптимизация в FF. На их собственном сайте ( https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script ) написано следующее:
В реальности, как мы видим, это теперь не так. Видимо, они применили какую-то новую оптимизацию. Возможно она как-то выключается. Вопрос в том — как. Я предположил, что если писать в содержимое страницы, это затормозит парсер, но нет.
А у вас нет наблюдений когда это произошло с FF? На какой версии?
Комментарий для Евгения Степанищева:
Скачал FF 20.0 и 28.0 версий, потестил в них — картина не изменилась. Может быть, это не глюк FF, а я что-то не так делаю?
Комментарий для Валерий:
Cомневаюсь. А у меня на странице работает нормально или тоже для Ретины картинки со второго раза появляются?
Комментарий для Евгения Степанищева:
У меня в FF на вашем сайте грузятся картинки для ретины в независимости от того, с какого компьютера я зайду (с ретиной или без). За исключением аватарки, конечно:)
Комментарий для Валерий:
Совсем странно. И перезагрузка страницы не помогает?
Комментарий для Евгения Степанищева:
Нет. Кука R = 0, картинки для ретины.
Комментарий для Валерий:
А как вы узнали, что картинки для ретины?
Комментарий для Валерий:
У меня вот таким скриптом кука выдаётся:
Он у вас не срабатывает?
Комментарий для Евгения Степанищева:
Я зашел через FF с другого компьютера (Win 8, не ретина). Посмотрел значение куки через firebug. Через него же посмотрел разрешение картинок. Кука R = 0, картинки высокого разрешения. Могу скриншот прислать))
Комментарий для Валерий:
Нет, не надо. Лучше посмотрите что код выше у вас выдаёт под Ff, не работает он что ли?
Комментарий для Евгения Степанищева:
Код-то работает, кука выставляется правильно. А вот картинки отдаются так, как будто бы кука всегда = 1.
Комментарий для Валерий:
Странно, что-то поломалось, видимо. Разберусь потом, у меня сейчас большой проект идёт, не до этого совсем.
Ларчик просто открывался — у меня перестали что-то значить файлы .htaccess. Видимо хостер что-то поменял в настройках.
Так и есть. Пишу deny from all — никакой реакции. Придётся как-то иначе выкручиваться или консультироваться у хостера что это такое.
Комментарий для Евгения Степанищева:
Понятно. А я продолжу разбираться с FF.
// Это Валерий, я обзавёлся OpenID :)