Pull to refresh

Comments 11

Один мой друг пару лет назад заявил что «хватит загружать сервер генерацией шаблонов», это должно делаться на фронтенде, а сервер будет только отдавать данные, по сути мы постепенно приходим именно к этому.

Я считаю, что отдавать только те данные, которые нужны при данном разрешении устройства — это один из промежуточных шагов в такому подходу
сконцентрироваться на стратегии подачи контента и структуре информации

Можно распечатать и повесить над столом :)
Спасибо за перевод отличной статьи — вдохновило на эксперименты
Новый UI Facebook делает очень похожие вещи.
статью следовало озаглавить «Условная загрузка для адаптивного веб-дизайна» как в оригинале. Отложенная это когда элемент не грузится до определенного момента, а у вас в переводе речь со всем про другое. Ссылка на Speed Up Your Site with Delayed Content сбивает еще больше.

ну а по теме, если оформлять этот способ в виде библиотеки, то никаких
document.documentElement.clientWidth > 640

по-хорошему нужно через медиавыражения в CSS скрывать или показывать определенный блок, а скрипт уже должен это подхватывать и грузить туда контент.

P.S. бразуер
Спасибо, поправил.
P.S. Ваш вариант написания слова браузер тоже доставляет радость.
вот так всегда. одно исправляешь, другое ломаешь :(
Разрешение экрана сегодня мне ничем не помогает. С одной стороны массовый лаптоп 1366х768, таблет — 1920х1080, телефон — 1280х720, с другой стороны важен физический размер экрана. Тк на телефоне ничего не рассмотришь и пальцами не натыкаешь…
Нужен надежный способ определить размеры
Тут показан принцип и идея того, что дополнительный контент не обязательно сразу грузить и потом скрывать.
Думаю скомпоновать идею определять тип устройства через media queries (вешать что-то типа флага к какому-нибудь элементу html если маленький экран или высокое dpi) и затем определяя javascript-ом этот флаг, подгружать по необходимости дополнительный контент.
Ох и наиграетесь же вы обрабатывать все случаи с ресайзом!
Sign up to leave a comment.

Articles