Комментарии 18
А можно вопрос не по теме: чем так хорош адаптивный дизайн по сравнению с хорошей и грамотной резиной? Все эти перекраивания интерфейса для разных размеров — у меня, например, явная с ними проблема: невозможно на телефоне найти то, что знаешь, как найти на десктопном сайте, ибо либо все в разные места уезжает, либо (и это хуже) еще и в какие-то отдельные подменю. В самом запущенном случае функционал вообще урезается.
Неужели кому-то это нужно (учится работать сразу в нескольких интерфейсах и запоминать, что где в разных «версиях» сайтов)? Всегда ищу «показать десктопную версию» и крайне негодую, если ее принудительно скрывают. При этом я не имею ничего против нативных приложений.
Неужели кому-то это нужно (учится работать сразу в нескольких интерфейсах и запоминать, что где в разных «версиях» сайтов)? Всегда ищу «показать десктопную версию» и крайне негодую, если ее принудительно скрывают. При этом я не имею ничего против нативных приложений.
На некоторые элементы, как, например, в шапке этой статьи адаптивный дизайн ложится просто прекрасно. Но в целом я согласен, сверстать что-то сложнее небольшого корпоративного сайта, особенно если там присутствует контент создаваемый пользователями — лучше сразу застрелиться.
Да, я знаю что это очень непопулярное мнение в наше время, но я честно пытался применить адаптивную верстку для средней величины проекта, который писали-верстали с нуля. Если интересно, могу рассказать про подводные камни, до которых мы «доплыли».
Да, я знаю что это очень непопулярное мнение в наше время, но я честно пытался применить адаптивную верстку для средней величины проекта, который писали-верстали с нуля. Если интересно, могу рассказать про подводные камни, до которых мы «доплыли».
НЛО прилетело и опубликовало эту надпись здесь
Первое, с чем я вообще раньше не сталкивался, это проблемы с баннерами, которые в обязательном порядке должны были занимать определенные места на сайте (справа от основного контента на странице). На этот счет был подписан договор еще до начала работы, и, естественно, никаких вариантов с тем, что реклама будут перемещаться вместе с контентом там не было.
Второе, менеджерское, это то, что гибкий процесс разработки средних и крупных проектов предполагает постоянное добавление каких-то новых, не запланированных изначально фич. Чем идеальнее получилась верстка какого-то раздела, тем больше шанс, что туда нужно будет кровь из носу добавить что-то еще. Соответственно время на разработку это новой фичи увеличится, минимум, вдвое, по количеству макетов. А то и вообще эту фичу «забудут» добавить в адаптивный вариант, ну знаете, как это бывает, давайте пока добавим, посмотрим, а потом… Конечно это потом никогда не настает.
Третье, чисто дизайнерское — некоторые элементы очень тесно связанны логически и взрывают пользователю мозг, если они находятся не на своих привычных местах. Ну, самый простой пример — например если прайс и краткое описание всегда идут справа от фотографии, то подробности — снизу. И хоть убей их расположение должно быть именно таким, любые его изменения делают юзабили хуже. А если это и есть 80% контента сайта, то вся «адаптивность» сводится к адаптации и верхнего меню и блока с копирайтом, с которыми, в общем-то, и так все хорошо, даже на мобильных телефонах.
Четвертое — многоколоночная верстка далеко не всегда предполагает четкую иерархию материала — вы не можете просто взять и поставить что-то выше, а что-то ниже.
Как-то так.
Второе, менеджерское, это то, что гибкий процесс разработки средних и крупных проектов предполагает постоянное добавление каких-то новых, не запланированных изначально фич. Чем идеальнее получилась верстка какого-то раздела, тем больше шанс, что туда нужно будет кровь из носу добавить что-то еще. Соответственно время на разработку это новой фичи увеличится, минимум, вдвое, по количеству макетов. А то и вообще эту фичу «забудут» добавить в адаптивный вариант, ну знаете, как это бывает, давайте пока добавим, посмотрим, а потом… Конечно это потом никогда не настает.
Третье, чисто дизайнерское — некоторые элементы очень тесно связанны логически и взрывают пользователю мозг, если они находятся не на своих привычных местах. Ну, самый простой пример — например если прайс и краткое описание всегда идут справа от фотографии, то подробности — снизу. И хоть убей их расположение должно быть именно таким, любые его изменения делают юзабили хуже. А если это и есть 80% контента сайта, то вся «адаптивность» сводится к адаптации и верхнего меню и блока с копирайтом, с которыми, в общем-то, и так все хорошо, даже на мобильных телефонах.
Четвертое — многоколоночная верстка далеко не всегда предполагает четкую иерархию материала — вы не можете просто взять и поставить что-то выше, а что-то ниже.
Как-то так.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
На сайте с демо еще много красивых примеров — некоторые можно взять на вооружение.
Кстати, 8кб модернайзера в плагине можно обменять на две строчки.
Будте любезны, приведите эти две строчки.
$('body').removeClass('no-js');
if ('ontouchstart' in document.documentElement) { $('body').addClass('touch'); }
Но там же может отсутствовать джейквери, infinius!
document.getElementsByTagName('body')[0].className.replace(/\bno-js\b/g, '');
if ('ontouchstart' in document.documentElement) { document.getElementsByTagName('body')[0].className += ' touch'; }
Как всё таки правильнее, in document.documentElement как в примере выше, или
(('ontouchstart' in window) || (navigator.msMaxTouchPoints > 0))?
(('ontouchstart' in window) || (navigator.msMaxTouchPoints > 0))?
var hasTouchSupport = ('ontouchstart' in window) || window.DocumentTouch && document instanceof DocumentTouch;
var bodyClass = "js " + (hasTouchSupport ? "touch" : "no-touch");
document.body.className = bodyClass;
В самом modernizr используется версия с дополнительной проверкой с помощью CSS
Последняя строка затрёт классы у body. Нужно как-то так, но появляется третья строка. Не по-мужски, нужно убрать перенос где-то.
var classes = document.body.className.replace(/\bno-js\b/g, 'js');
var isTouch = (('ontouchstart' in window) || ('onmsgesturechange' in window));
document.body.className = classes + (isTouch ? " touch" : " no-touch");
мне кажется не надо так много когда вываливать, его читать все равно нет смысла весь, достаточно описать словами как вы делаете конкретную фичу а потом фрагмент конкретного места кода для примера.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Адаптивное меню с поддержкой retina