Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 57
Можно предложить ещё два варианта:
— вынести в css, и использовать там media queries;
— использовать формат изображений, которые в начале файла содержат менее детализированное изображение, а при догрузке — более, и оставлять решение по поводу достаточности неполной загрузки на совести браузера.
— вынести в css, и использовать там media queries;
— использовать формат изображений, которые в начале файла содержат менее детализированное изображение, а при догрузке — более, и оставлять решение по поводу достаточности неполной загрузки на совести браузера.
В дальнейшем для создания переводов рекомендую прибегать к гиперссылке http://habrahabr.ru/topic/add/translation/, тем обеспечивается специальное оформление (особый значок у заголовка блогозаписи, имя автора и гиперссылка на первоисточник в хвосте блогозаписи).
По существу я согласен со сторонниками srcset: если для каждого варианта сочинять media query, то легко можно задолбаться — пускай уж лучше браузер решает дело автоматически.
Брюс Лоусон (Bruce Lawson) также прав в своём мнении о синтаксисеsrcset: можно и нужно улучшить написание.
Брюс Лоусон (Bruce Lawson) также прав в своём мнении о синтаксисе
Насчет «пускай лучше браузер сам решает» — не согласен.
То есть, конечно, какое-то разумное его поведение по умолчанию приветствуется.
Но и возможность при необходимости рулить вручную должна быть обязательно.
То есть, конечно, какое-то разумное его поведение по умолчанию приветствуется.
Но и возможность при необходимости рулить вручную должна быть обязательно.
пускай уж лучше браузер решает дело автоматически.И каждый браузер будет решать, что лучше для себя.
Именно так, когда-то вели себя некоторые браузеры и из-за этого верстальщики сейчас мучаются.
Использование media query осложняется ещё тем, что текст страницы (а значит и значение атрибута srcset скрипт может генерировать на лету, а вот генерируемый скриптом на лету css — это то, чего хотелось бы избежать.
Дать возможность браузеру выбирать изображение основываясь на скорости интернета и ряде других показателей на самом деле очень хорошая идея. Но и лишать человека возможности задавать некие пределы и исключения не есть хорошо. Мне нравится вариант с тегом picture т.к. код в нем легко читаем, в то же время использование родного тега img кажется более приемлемым вариантом. Возможно стоит использовать идею атрибута srcset, но в рамках структуры тега picture.
Почитал комментарии к первоисточнику.
Там ад.
Оказывается, в WhatWG ещё не решили окончательно, что такое «600w 200h 2x» вообще должно означать.
Одна версия: «600w 200h» означает размер картинки (600×200).
Другая версия: «600w 200h» означает, что картинка предназначается для устройств, на которых viewport (видимая часть вебостраницы) меньше шестисот пикселов по ширинеи меньше двухсот пикселов по высоте.
Одна версия: «2x» означает, что размер картинки можно считать удвоенным.
Другая версия: «2x» означает, что картинка предназначается для устройств с удвоенным размером виртуального пиксела по сравнению с физическим (то есть для сетчаточных дисплеев нового iPhone и нового iPad).
Там ад.
Оказывается, в WhatWG ещё не решили окончательно, что такое «600w 200h 2x» вообще должно означать.
Одна версия: «600w 200h» означает размер картинки (600×200).
Другая версия: «600w 200h» означает, что картинка предназначается для устройств, на которых viewport (видимая часть вебостраницы) меньше шестисот пикселов по ширине
Одна версия: «2x» означает, что размер картинки можно считать удвоенным.
Другая версия: «2x» означает, что картинка предназначается для устройств с удвоенным размером виртуального пиксела по сравнению с физическим (то есть для сетчаточных дисплеев нового iPhone и нового iPad).
Опять затыкают дыры в логике, вместо того, чтобы сесть и нормально на будущее продумать все. Ретины, кретины, и бета-каротины, какая разница какой именно дисплей? Разрешение не может быть основой для выбора типа изображений. Нужен кардинально другой подход, например тот же ppi гораздо больше расскажет про необходимый размер картинки.
Его нигде не нужно брать, с ним нужно работать на уровне UA. Можно его передавать в заголовках HTTP запросов, можно добавлять в строку User Agent'а, можно вообще не заморачиваться, и пусть браузер сам из системы вытаскивает данные и применяет нужное условие.
Тут еще одна мысль возникла, что строка UA не стандартизировани ни капли, каждый строчит то, что хочет. А не помешало бы.
Тут еще одна мысль возникла, что строка UA не стандартизировани ни капли, каждый строчит то, что хочет. А не помешало бы.
Переосмысление атрибута lowsrc.
Не буду говорить на счёт остального, но у подхода с srcset есть одно преимущество в сравнении с media-queries — браузер точно знает, какая картинка самая большая по размеру и при желании пользователя сохранить изображение на компьютер сохранит его именно в лучшем качестве.
Это не преимущество, это возможный побочный эффект, не более.
Почему вдруг не преимущество? Тут обсуждают как сделать так, чтобы на редких ретина-дисплеях изображение смотрелось получше, а я говорю о том, что абсолютно все пользователи смогут сохранять на компьютер изображения в высоком качестве вместо низкого
Мне почему-то кажется, что проблема не столько в картинках которые вставлены в текст, а проблема в картинках которые используются как эелементы дизайна. А их сохранять не надо.
Если моё мнение не правильное, то прошу прощения.
Если моё мнение не правильное, то прошу прощения.
Да, здесь перевод явно получше будет.
Неее, это плюшки!)
Вообще, браузер, наверное, будет предлагать выбор, какое именно изображение сохранять.
Сам я, наверное, предпочёл бы вариант, аналогичный реализованному в теге video:
Извините, случайно отправилось.
Вот такой вариант. На атрибуте viewport, впрочем, не настаиваю. Но какой-то атрибут, управляющий загрузкой нужного изображения — должен быть.
<img src="" width="" height="" alt="">
<source src="" viewport="800px landscape">
<source src="" viewport="480px portrait">
<source src="" viewport="320px landscape">
</img>
Вот такой вариант. На атрибуте viewport, впрочем, не настаиваю. Но какой-то атрибут, управляющий загрузкой нужного изображения — должен быть.
Я вообще не понимаю, зачем пользователя заставлять качать определённое изображение. Он сидит на iPad15 с размером пикселя 5х, но сейчас на Луне, а там только 7g интернет, который медленный. Пусть он качает изображение низкого качества. А я сижу на старом ноутбуке с хорошим инетом и хочу при увеличении масштаба видеть хорошее качество. Так дайте мне большую картинку несмотря на плохой ноут.
Только вот смысла в ней не особо много. Всегда должна быть возможность вручную управлять размером контента.
Это надуманная проблема. На какой процент эта возможность улучшит юзабилити? На ничтожно малый. Зато проблем пользователю добавит неслабо. Запустил торренты, загрузил канал. Браузер решил, что скорость низкая, начал грузить картинки в рвотнорефлексном качестве. Пользователя вырвало на клавиатуру и он или закрыл страницу, дабы не видеть этот ужас, или вручную придется перегружать картинки в более высоком качестве, или отключать режим «умной загрузки». Как результат, эта фича будет отключена насовсем. Хотели как лучше, а получилось как всегда
А, про это свойство img я не подумал. Ну да. Впрочем, в оригинале предлагается picture с похожей структурой. Просто мне не нравится идея плодить теги. Их и так море, и большинство из них не используется.
Ребят, я немного не в теме, но начал интересоваться.
Подскажите пожалуйста, а это для статических размеров?
Ну к примеру, открыли мы изображение на ПК с разрешением 1280 — размер изображения 120 px (к примеру). Открыли на другом ПК с разрешением 1024 — 100 px (к примеру). Открыли на телефоне — 30 px.
А если мы будем менять ширину (размер) окна — будет ли автоматически динамически меняться размер изображений / размера шрифта и тд?
Видел библиотеку одну, но она жутко тормозная. Клиент вешает достаточно сильно.
Подскажите пожалуйста, а это для статических размеров?
Ну к примеру, открыли мы изображение на ПК с разрешением 1280 — размер изображения 120 px (к примеру). Открыли на другом ПК с разрешением 1024 — 100 px (к примеру). Открыли на телефоне — 30 px.
А если мы будем менять ширину (размер) окна — будет ли автоматически динамически меняться размер изображений / размера шрифта и тд?
Видел библиотеку одну, но она жутко тормозная. Клиент вешает достаточно сильно.
В простой адаптивной вёрстке, если менять размер окна браузера, то при достижении размеров, указанных в media query картинка будет заменяться. То есть, открыли в 1280 — картинка 120px, начали уменьшать — она не меняется (конечно, может меняться в размерах блок, в который положена картинка, но при этом сама картинка остаётся той же). Уменьшили до 1024 — картинка резко сменилась на ту, которая 100px, начали ещё уменьшать, до телефонных (предположим, 480px), картинка заменилась на ту, что 30px. И наоборот, открыли в мелком разрешении, начали увеличивать, картинка будет меняться на ту, что побольше. Загрузка нужной картинки (по крайней мере, мои эксперименты с браузерами так показывают) происходит тогда, когда окно становится нужного размера. То есть, если размер не менять, не нужные картинки не подгружаются.
То есть по сути — перескакивает. В ходе экспериментов выявлены небольшие поддормаживания в эти моменты. После появления в кэше становится, естественно лучше.
Немного поясню.
Не так давно стояла задача сделать динамическое изменение, поэтому смотрели в эту сторону, но в итоге пришли к JS коду, который пересчитывал.
Грубо и плохо, но другого элегантного решения (не дискретного, а полноценного) найти не удалось.
Если подскажете — буду признателен.
Немного поясню.
Не так давно стояла задача сделать динамическое изменение, поэтому смотрели в эту сторону, но в итоге пришли к JS коду, который пересчитывал.
Грубо и плохо, но другого элегантного решения (не дискретного, а полноценного) найти не удалось.
Если подскажете — буду признателен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[Перевод] HTML5 Адаптивные изображения