Приветствую!
Настала пора призадуматься о том, как будет выводится разрабатываемый мною сайт на различных устройствах. Начитался статей вдоволь, попутно нашел небольшой список дополнительных модулей, которые помогают в верстке:
- Bootstrap Layouts
- Chaos Tool Suite
- Page Manager
- Panels
- Paragraphs
Но, увы, даже с помощью них не могу понять, как мне сделать правильную для меня верстку. В большинстве важных советов слышу одно и то же - "используй CSS". Но, имхо, это не делает сайт адаптивным - это делает (может делать) адаптивной только верстку. А разница есть. Например, отдавать 25-меговый контент по бесплатному вай-фаю, или 1-меговый по мобильному инету. Конечно, программно на HTML/JS определить характеристики инет-канала невозможно, но можно программно определить физические характеристики окна вывода сайта в дюймах, используя ширину/высоту в пикселях и DPI. И уже на этом этапе решать, что грузить. Таким образом, напрашивается одно решение - в каждой странице должен быть JavaScript-загрузчик. Который сперва определяет, что грузить, и только потом грузит. Кстати, так ли это работает в многочисленных адаптивных темах? Если "нет", то как?
Собственно, что мне нужно:
- Определить набор размещений (Layout)
- Определить набор геометрических размеров окон вывода в дюймах
- Мочь привязать часть размещений из набора к любой странице сайта - исходя из набора геометрических размеров окон вывода
- Желательно мочь передать в любую вьюху параметрами - используемое размещение
Как я понимаю, п.1 можно сделать с помощью DS?
Как то можно и п.4, наверное через контекстные фильтры? Как?
А вот как решить весь вопрос в том виде, как я описал?
Спасибо.
Комментарии
Приветствую!
Я делал как то с мультисайтингом, использовал библиотеку мобайл детект, и если он выдавал мобильное устройство то редиректил на поддомен m.exemple.ru. А у него уже своя тема, свои шаблоны, свои стили.
Решение конечно. Если не найду лучшее - наверное сделаю так же.
На стороне сервера нельзя определить какой конкретно экран у клиента, только мобильный\не мобильный. Так что адаптивный шаблон можно сделать только средствами css\js
Да, я об этом писал выше:
Или, как предложили выше, делать поддомены с разными реализациями. Но это мне совсем не нравится. Если не будет анализа и редиректора на каждой странице - можно в поисковике нарваться на мобильную версию, сидя на десктопе.
Если у вас восьмёрка, то там в ядре есть модуль responsive images (или что-то в этом роде). Он позволяет загружать разные разрешения изображения под разные экраны. Всё остальное можно спокойно делать через цсс.
Нет. С помощью CSS мы можем только управлять отображением, например спрятать какую-то часть. Но спрятанное все равно будет грузиться.
Зачем что-то прятать, кроме картинок?
Получится, что у вас по одному url будт отдаваться 3 разных страницы: десктопная, планшетная, мобильная.
Разные - именно с точки зрения контента этих страниц.
Вроде бы раньше поисковики называли такое клоакингом, и пессимизировали за это.
Я бы выбрал все-таки версию с субдоменами - отдельно для мобильных (меньше контента), и общий для десктопов-планшетов, там можно и версткой разрулить.
Добавить скрипт, который будет определять устройство, и в случае несовпадения с версией страницы - предлагать перейти на другую версию.
Только не редиректить автоматом, а то бесят такие чересчур умные сайты.
Вообще-то ... планирую восемь) Мобильная (книжная, альбомная), то же для малых планшетов, то же для больших планшетов, альбомные для обычного и широкоформатного десктопа.
Да, почитал ... http://wiki.rookee.ru/kloaking/. Надо будет подумать. У меня и так сайт планируется 8-ми язычный, в URL'е уже присутствует язык типа http://сайт/ru/страница. Как вариант, попробовать "подмешивать" используемое размещение к языку. Типа http://сайт/ru-s/страница. Поэкспериментирую.
Учту. Скорее всего нужно в шапке переключатель повесить "адаптировать или нет" разметку.
Ну, 8 вариантов контента уж точно не надо, имхо.
Пользователь развернул телефон-планшет - не грузить же новую версию. Особенно, если гаджет лежит в сумке или в кармане, и болтается при ходьбе. Так можно батарею ненароком разрядить, и себе сервер заддосить.
Да, кстати - а почему не рассматриваете ТВ-версию? Нынче трудно найти телевизор без встроенного браузера.
Люди, верставшие такие версии, рассказывали, что это отдельный вид извращения, ибо браузеры в телевизорах ненамногим лучше IE, не к ночи будет помянут.
Не проще ли перешагнуть через себя и всё-таки научиться использовать медиа-запросы?
Ну раз мы говорим об адаптивном сайте, значит заранее себя готовим к тому, что физические размеры окна вывода могут быть сильно ограничены. На широкоформатном экране в сайдбарах можем раскидать различные блоки контекстной рекламы, информеров, новостей... И это не будет в напряг посетителю, ибо 80% полезного пространства будет занято "целевой" информацией. А теперь представим, что все это захотим вывести на смартфоне. Даже если все блоки расположить последовательно - посетителю придется скролить до крови, чтобы добраться до нужной важной для него инфы. Это не по фэн-шую.
Всё второстепенное задвигается вниз. А реклама и так джаваскриптом грузится, поэтому её показ ограничить не будет проблемой. Плюс, если говорить о множестве разрешений экранов, стоит вспомнить о режиме разделения экрана. Так что надо уже как минимум 16 вариантов))))))))
А ведь есть ещё такой критерий, как правши-левши.
Из-за особенностей работы полушарий, визуальная информация воспринимается ими по-разному.
Вот, например, первая попавшаяся в поиске ссылка, а я читал об этом в какой-то толстой книге по боевому НЛП.
))) не проще ли внимательно прочесть первое сообщение?
Медиа-запросы, повторюсь, работают с оформлением, но не с содержимым! За исключением картинок, там да - можно подсовывать забитые хард-кодом в стиле. Мне не надо так.
Может договоримся? Я просто хочу решить свой вопрос. Не нужно рассказывать как можно сделать немножко не так, и чуть-чуть по-другому.
Никаких 16 не будет - я планирую 8. Решать будет скрипт, а-ля:
<html lang="ru">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Test viewport</title>
<script type="text/javascript">
var width = window.innerWidth
|| document.documentElement.clientWidth
|| document.body.clientWidth;
var height = window.innerHeight
|| document.documentElement.clientHeight
|| document.body.clientHeight;
document.write('<p>Your viewport width is '+width+'x'+height+'</p>');
</script>
</head>
<body>
</body>
</html>
Размеры вьюпорта - вообще ни о чем.
У меня на ноуте экран 1366x768 а на смартфоне - 1920х1080.
"на смартфоне - 1920х1080." -для смартфона не в реальных пикселях считается, а в CSS пикселях (кажется так), там 1:3 или типа того, в итоге для смартфона разрешение будет 480x320 (могу ошибаться)
Ну, в скрипте вычисляются пикселы, я поэтому и написал, что сами по себе они ни о чем.
Ну я же давал ссылку в своем первом сообщении! DPI. Зная DPI, и зная размеры вьюпорта, мы без напряга рассчитаем физические размеры в дюймах. И уже, исходя из физических размеров, будем решать, что выводить, как выводить, а что совсем не выводить.
Вот тут неплохо все расписано.
Не надо целых 8.
Достаточно определиться с содержимым HTML. На планшетах и ниже одно, наостальных другое. Или вариант сделать на js фреймворка. Получать и строить ту структуру которую запросил клиент. Конечно же дело ваше с выбором способа реализации вашей задачи.
П.С. Не стоит критично относится к комментария здесь спецы с большим ВЛД. Скоро и вы в такого превратитесь:-) если только не уже
А что такое ВЛД?))
тоже интересно
"Если у вас восьмёрка, то там в ядре есть модуль responsive images (или что-то в этом роде). Он позволяет загружать разные разрешения изображения под разные экраны"
для семерки тоже есть
В таком случае Вам следует лучше изучить понятие адаптивности. О клоакинге уже писали выше.
Не знаю, как работает responsive images, если на пресетах, то это беда
Почему беда? И как будет не беда?
А разве не от настроек масштабирования зависит? Или это и есть оно по другому названое?
По делу. Автор, стоит дождаться выхода https://www.drupal.org/project/context_breakpoint или альтернативы (может и сейчас есть, не в курсе). Ну или другую тему в зависимости от разрешения. Под это тоже модули есть.
Возможно есть какие-то более "правильные" источники. Но просмотренные мной, включая вики, адаптивный дизайн рассматривают как "дизайн веб-страниц, обеспечивающий правильное отображение сайта на различных устройствах, подключённых к интернету и динамически подстраивающийся под заданные размеры окна браузера". В данной трактовке я, как разработчик, вправе самостоятельно решить понятие "правильности". А с "клоакингом" уже вопрос снят - в URL'е страниц будет присутствовать используемый код лайаута. Всё, одинаковых страниц (имеющих один адрес) не будет, будут версии страниц.
Интересный подход! Надо будет поразбираться.
И там говорится, что они должны отдавать разный контент? (Всё что не относится к html тегам есть контент)
Ну то есть при "грамотном" подходе каждое загруженное изображение получит как минимум по 3 прессета.. ну или 8? Всё это я считаю бесполезным мусором. Одно дело, когда в сайт долбятся одновременно 10кк анонимов, а другое - 3 калеки(мама, друг и сам разраб)
Там как обязанность - это не отмечено. По всему тексту нет упоминания о разном контенте. Но есть один абзац, где это практикуется, как вариант:
Вопрос с "клоакингом" в разрезе моих "хотелок", считаю, можно закрыть!
Вот неплохая статья по этой теме от 31 июля 2015, а вот интересная цитата оттуда:
Видео грузить точно на мобилку не стоит. Лучше js-ом подгружать.
Адаптивные картинки с помощью picture - вполне норм вариант. Стилей достаточно двух-трёх. (мобилка, планшет, всё что выше - то десктоп).
Не грузить на мобилку лишние стили - тоже вполне неплохое решение. Группировка файлов по медиа-запросам в advagg есть.
Не грузить на мобилке неиспользуемые скрипты - вопросик посложнее, но тоже решаемо, если заморочиться.
Разметку в целом можно вообще не трогать, те 5-6Кб разницы от скрываемой разметки - это капля в море.
Адаптивный != отзывчивый. Хотя терминология до сих пор спорна, кто-то называет так, кто-то эдак..
https://agente.ru/blog/adaptive-vs-responsive-web-design
В терминах статьи, автору нужен адаптивный.
А как надо-то? уменьшать картинки на каждом запросе?
А как правильно то?
Ну да))))
Ну например так http://nginx.org/ru/docs/http/ngx_http_image_filter_module.html
Причём сервак не грузит, отрабатывает моментально, при увеличении посещалки можно родной нжинковский кеш включить при желании. Для 3-х калек можно без кеша. На личном опыте месячный кеш давал производительность максимум 10-15% так что необходимость его использования далеко под вопросом. Как правило кропалки и ресайза хватает за глаза
Ого! не знал, не знал, спасибо! Может действительно пригодится, когда пресетов и картинок много.
Был тут помню один с порнушными комиксами, жаловался что сайт раздувает в десятки гигабайт.
А он свои миниатюры нигде не хранит?
Ну и в чём разница, где хранить жпег?
Можно настроить время и размер кэша, и вообще там куча крутилок А можно вообще не хранить.
С другой стороны, чото щас подумал, а чой-то он, сильно быстрее php-gd работает? Он же всё равно работает через libgd, правильно?
Если интересно то вот применение этой технологии в django https://adw0rd.com/2012/11/10/django-nginx-image/
Там рассказывается про модуль, но весь его смысл сводится только к формированию нужных урлов. В качестве ознакомления можно посмотреть какие урлы из каких делаются и конфиг нжинкса
ещё раз спасибо, положил в закладки
Да! Именно об этом и шла речь. Респект за статью.
Походил по настройкам advagg, не нашёл сходу, подскажите плз, где это?
И главное - что даёт группировка файлов по медиа-запросам?
Прошу прощения, пропустил слово "вроде" перед есть. =/
А так - версия для мелкоэкранов, обычно, попроще, так зачем грузить на устройство с медленным и конечным трафиком ненужные килобайты стилей для десктопной версии?
Вся эта замануха началась, имхо, не с разнообразия устройств вывода. А с возможности моментального изменения разрешения путем поворота устройства и переориентации. Если бы были претензии лет 10 назад, типа "я выставил на монике другое разрешение, а сайт так и не оптимизировался под него" - это были бы единицы на стопицотмильёнов. А сейчас у каждого смартфон, планшет, на алиэкспессе уже и часы с браузерами продают. И кто еще не приобрел чудо современной инженерии под названием "спиннер" - крутят планшеты и смартфоны в салонах общественного транспорта. Мимоходом проклиная веб дизайнеров в плане отсутствия тяги к перфекционизЪму. Тут сопротивляться бесполезно - ибо илита. Говорю не просто так, верите-нет, может совпадение. Сегодня пришлось ехать в метро некоторое время, и пришлось слушать краем уха азы дизайна в вагоне метро от двух подростков. Страшно жить.
Да ни в чём, собсна))) Другое дело зачем? Если к картинкам обратились один раз в жизни, то зачем их хранить вечно? Это первое. Второе. Что происходит при смене/добавлении/удалении прессета с картинками? Как вообще управлять всем этим дерьмищем? При дампе/переносе сайта тянем все картинки со стилями? Я понимаю - друпал для мазохистов, но зачем самостоятельно создавать себе проблемы?
Да, libgd. Начнём с того, что сам по себе php не отличается скоростью среди остальных языков. В статье есть бенчмарк модуля nginx и PIL питонья либа для работы с изображениями, при желании можно найти бенчмарки и с php-gd или сделать их самостоятельно
Да ни в чём, собсна))) Другое дело зачем? Если к картинкам обратились один раз в жизни, то зачем их хранить вечно? Это первое. Второе. Что происходит при смене/добавлении/удалении прессета с картинками? Как вообще управлять всем этим дерьмищем? При дампе/переносе сайта тянем все картинки со стилями? Я понимаю - друпал для мазохистов, но зачем самостоятельно создавать себе проблемы?
Да, libgd. Начнём с того, что сам по себе php не отличается скоростью среди остальных языков. В статье есть бенчмарк модуля nginx и PIL питонья либа для работы с изображениями, при желании можно найти бенчмарки и с php-gd или сделать их самостоятельно
В тему. Случайно набрёл на https://www.drupal.org/project/browscap
Если кто работал с ним, отпишите, как оно? Вроде выглядит на то что надо ТС.
Замечательно!
Загрузка кода и инсталляция нового экземпляра дру - одна команда в консоли, и минута работы.
Загрузка и активация контриб модуля - еще одна команда и пару сек работы.
Ждем вашего отчета о browscap )))
т. е. моего штоли? Может ТСу было бы интереснее чем мне?
Интересно, и обязательно гляну позже! Просто сейчас более другим зело занят.