Pull to refresh

Comments 57

Можно предложить ещё два варианта:
— вынести в css, и использовать там media queries;
— использовать формат изображений, которые в начале файла содержат менее детализированное изображение, а при догрузке — более, и оставлять решение по поводу достаточности неполной загрузки на совести браузера.
Для второго, кстати, есть поддержка в PNG, так называемый Adam7.
UFO landed and left these words here
В дальнейшем для создания переводов рекомендую прибегать к гиперссылке http://habrahabr.ru/topic/add/translation/, тем обеспечивается специальное оформление (особый значок у заголовка блогозаписи, имя автора и гиперссылка на первоисточник в хвосте блогозаписи).
К отминусовавшим мой комментарий просьба: выскажите возражения, огласите пункты несогласия с моей рекомендацией.
Спасибо. В следующий раз обязательно воспользуюсь.
По существу я согласен со сторонниками srcset: если для каждого варианта сочинять media query, то легко можно задолбаться — пускай уж лучше браузер решает дело автоматически.

Брюс Лоусон (Bruce Lawson) также прав в своём мнении о синтаксисе srcset: можно и нужно улучшить написание.
Насчет «пускай лучше браузер сам решает» — не согласен.
То есть, конечно, какое-то разумное его поведение по умолчанию приветствуется.
Но и возможность при необходимости рулить вручную должна быть обязательно.
пускай уж лучше браузер решает дело автоматически.
И каждый браузер будет решать, что лучше для себя.
Именно так, когда-то вели себя некоторые браузеры и из-за этого верстальщики сейчас мучаются.
Нет, почему же. Автоматически, но по стандарту.
Вы забыли в кавычки обернуть «по стандарту». А так, если по стандарту, то всё ок.
Ну я и имею в виду, что в стандарте должно быть чётко прописано, как браузер должен автоматически обрабатывать эту ситуацию.
Использование media query осложняется ещё тем, что текст страницы (а значит и значение атрибута srcset скрипт может генерировать на лету, а вот генерируемый скриптом на лету css — это то, чего хотелось бы избежать.

Дать возможность браузеру выбирать изображение основываясь на скорости интернета и ряде других показателей на самом деле очень хорошая идея. Но и лишать человека возможности задавать некие пределы и исключения не есть хорошо. Мне нравится вариант с тегом picture т.к. код в нем легко читаем, в то же время использование родного тега img кажется более приемлемым вариантом. Возможно стоит использовать идею атрибута srcset, но в рамках структуры тега picture.
Почитал комментарии к первоисточнику.

Там ад.

Оказывается, в WhatWG ещё не решили окончательно, что такое «600w 200h 2x» вообще должно означать.

Одна версия: «600w 200h» означает размер картинки (600×200).

Другая версия: «600w 200h» означает, что картинка предназначается для устройств, на которых viewport (видимая часть вебостраницы) меньше шестисот пикселов по ширине и меньше двухсот пикселов по высоте.

Одна версия: «2x» означает, что размер картинки можно считать удвоенным.

Другая версия: «2x» означает, что картинка предназначается для устройств с удвоенным размером виртуального пиксела по сравнению с физическим (то есть для сетчаточных дисплеев нового iPhone и нового iPad).
Опять затыкают дыры в логике, вместо того, чтобы сесть и нормально на будущее продумать все. Ретины, кретины, и бета-каротины, какая разница какой именно дисплей? Разрешение не может быть основой для выбора типа изображений. Нужен кардинально другой подход, например тот же ppi гораздо больше расскажет про необходимый размер картинки.
UFO landed and left these words here
Его нигде не нужно брать, с ним нужно работать на уровне UA. Можно его передавать в заголовках HTTP запросов, можно добавлять в строку User Agent'а, можно вообще не заморачиваться, и пусть браузер сам из системы вытаскивает данные и применяет нужное условие.

Тут еще одна мысль возникла, что строка UA не стандартизировани ни капли, каждый строчит то, что хочет. А не помешало бы.
UFO landed and left these words here
Это не сложно исправить. Производителей мобильных OS не так много (именно там танцы с разрешениями актуальны)
UFO landed and left these words here
Все равно не вижу проблемы. Производителей ОС можно пересчитать по пальцам.
UFO landed and left these words here
Производителям мониторов добавить одно значение в список возвращаемых не проблема. Главное — политическая воля
UFO landed and left these words here
Переосмысление атрибута lowsrc.
Не буду говорить на счёт остального, но у подхода с srcset есть одно преимущество в сравнении с media-queries — браузер точно знает, какая картинка самая большая по размеру и при желании пользователя сохранить изображение на компьютер сохранит его именно в лучшем качестве.
Это не преимущество, это возможный побочный эффект, не более.
Почему вдруг не преимущество? Тут обсуждают как сделать так, чтобы на редких ретина-дисплеях изображение смотрелось получше, а я говорю о том, что абсолютно все пользователи смогут сохранять на компьютер изображения в высоком качестве вместо низкого
Мне почему-то кажется, что проблема не столько в картинках которые вставлены в текст, а проблема в картинках которые используются как эелементы дизайна. А их сохранять не надо.
Если моё мнение не правильное, то прошу прощения.
UFO landed and left these words here
UFO landed and left these words here
Вообще, браузер, наверное, будет предлагать выбор, какое именно изображение сохранять.
Можно и так. Главное, что будет возможность сохранить изображение в хорошем размере и качестве.
Сам я, наверное, предпочёл бы вариант, аналогичный реализованному в теге video:
Извините, случайно отправилось.

<img src="" width="" height="" alt="">
	<source src="" viewport="800px landscape">
	<source src="" viewport="480px portrait">
	<source src="" viewport="320px landscape">
</img>


Вот такой вариант. На атрибуте viewport, впрочем, не настаиваю. Но какой-то атрибут, управляющий загрузкой нужного изображения — должен быть.
UFO landed and left these words here
Я вообще не понимаю, зачем пользователя заставлять качать определённое изображение. Он сидит на iPad15 с размером пикселя 5х, но сейчас на Луне, а там только 7g интернет, который медленный. Пусть он качает изображение низкого качества. А я сижу на старом ноутбуке с хорошим инетом и хочу при увеличении масштаба видеть хорошее качество. Так дайте мне большую картинку несмотря на плохой ноут.
UFO landed and left these words here
Только вот смысла в ней не особо много. Всегда должна быть возможность вручную управлять размером контента.
UFO landed and left these words here
Это надуманная проблема. На какой процент эта возможность улучшит юзабилити? На ничтожно малый. Зато проблем пользователю добавит неслабо. Запустил торренты, загрузил канал. Браузер решил, что скорость низкая, начал грузить картинки в рвотнорефлексном качестве. Пользователя вырвало на клавиатуру и он или закрыл страницу, дабы не видеть этот ужас, или вручную придется перегружать картинки в более высоком качестве, или отключать режим «умной загрузки». Как результат, эта фича будет отключена насовсем. Хотели как лучше, а получилось как всегда
UFO landed and left these words here
С развитием tab'ов в браузерах «пялиться в белый экран» становится все менее актуальной проблемой, ибо загрузка контента почти всегда идет на фоне.
UFO landed and left these words here
Лично у меня кнопка Back припорошена пылью. Я все ссылки открываю в новом табе
UFO landed and left these words here
UFO landed and left these words here
А, про это свойство img я не подумал. Ну да. Впрочем, в оригинале предлагается picture с похожей структурой. Просто мне не нравится идея плодить теги. Их и так море, и большинство из них не используется.
UFO landed and left these words here
Ребят, я немного не в теме, но начал интересоваться.

Подскажите пожалуйста, а это для статических размеров?

Ну к примеру, открыли мы изображение на ПК с разрешением 1280 — размер изображения 120 px (к примеру). Открыли на другом ПК с разрешением 1024 — 100 px (к примеру). Открыли на телефоне — 30 px.

А если мы будем менять ширину (размер) окна — будет ли автоматически динамически меняться размер изображений / размера шрифта и тд?

Видел библиотеку одну, но она жутко тормозная. Клиент вешает достаточно сильно.
В простой адаптивной вёрстке, если менять размер окна браузера, то при достижении размеров, указанных в media query картинка будет заменяться. То есть, открыли в 1280 — картинка 120px, начали уменьшать — она не меняется (конечно, может меняться в размерах блок, в который положена картинка, но при этом сама картинка остаётся той же). Уменьшили до 1024 — картинка резко сменилась на ту, которая 100px, начали ещё уменьшать, до телефонных (предположим, 480px), картинка заменилась на ту, что 30px. И наоборот, открыли в мелком разрешении, начали увеличивать, картинка будет меняться на ту, что побольше. Загрузка нужной картинки (по крайней мере, мои эксперименты с браузерами так показывают) происходит тогда, когда окно становится нужного размера. То есть, если размер не менять, не нужные картинки не подгружаются.
То есть по сути — перескакивает. В ходе экспериментов выявлены небольшие поддормаживания в эти моменты. После появления в кэше становится, естественно лучше.

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

Грубо и плохо, но другого элегантного решения (не дискретного, а полноценного) найти не удалось.

Если подскажете — буду признателен.
Нет. SVG не пробовал, но там задача чуть шире — в том числе масштабируется и текст.
Only those users with full accounts are able to leave comments. Log in, please.