На основе небольшого опыта работы с iPad’ом решил накидать список моментов, с которыми будет полезно ознакомиться коллегам (в том числе и менеджерам с дизайнерами). Кроме того, при разработке были использованы некоторые методы адаптивной верстки, о которой тоже будет упомянуто.
Итак, какие у нас есть возможности по манипулированию страницей:
В HTML:
- подключение собственных стилей для устройств
<link rel="stylesheet" href="/styles/styleipad-hor.css" media="all and (orientation:landscape)">
<link rel="stylesheet" href="/styles/styleipad-vert.css" media="all and (orientation:portrait)">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1,
user-scalable=0">
// перестань менять масштаб, пожалуйста!
Это значит, что мы можем подключить свои css-файлы, в которых напишем стили для устройства, или задать какие-то специфические параметры работы.
В CSS:
/* iPads landscape */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px)
and (orientation : landscape) {
/* Пишем стили для горизонтальной ориентации устройств
с шириной экрана от 768 1024 пикселей */
.header {
...
}
}
Вот она, адаптивная... Собственно, тут со старыми стилями делаем, что хотим: увеличиваем отступ, задаем другие шрифты, располагаем блоки друг под другом вместо «в линию» на компьютере или вообще отключаем их вывод (мало ли).
В PHP:
Определение iPad
define('IS_IPAD', (bool) strpos($_SERVER['HTTP_USER_AGENT'], 'iPad'));
Можем выключить генерацию html-кода в нужных местах страницы.
В JS:
Определение iPad, его ориентации и куча дополнительных событий, связанных с особенностями устройства.
var isIpad = (navigator.userAgent.match(/iPad/i)); // определение его самого
var isPortrait = (window.orientation == 0 || window.orientation == 180);
// определение ориентации его самого
window.addEventListener('orientationchange', updateOrientation, false);
// отлавливание смены ориентации его самого
Немного про события и сенсорный экран
- В связи с особенностью устройства нет mouseover|mouseout. Все ваши красивые эффекты при наведении мыши не будут видны. В связи с этим появляется масса проблем с выпадающими подменю и другими элементами:
- если выпадение реагирует на hover, то его не случится, пока мы не тыкнем по экрану (hover срабатывает). Если на этом элементе еще и ссылка висит, то выпадашка появится, но сразу после этого произойдет переход по ссылке.
- если ссылки нет, но вы делали js-анимацию появления, то выпадашка появится. Но убрать ее будет невозможно: mouseout|mouseleave не сработает.
- единственный вид выпадашек, которые точно работают без большого количества кода являются самые простые, основанные на css:
.nav li .submenu { display: none; } .nav li:hover .submenu { display: block; }
- Есть touchstart, touchmove, touchend. Разумеется, пальца по экрану. При нажатии на экран срабатывает также и событие click. Срабатывает с небольшой задержкой в секунду и обводкой и миганием фона вокруг кликнутого элемента. Некрасиво, необычно, но apple лучше нас знает, как сигнализировать пользователю.
- На основе touch-событий появились дополнительные события, которые вы все успели безумно полюбить и уже жизнь без них не представляете: это всяческие swipe’ы, drag’и, hold’ы и другие. Здесь проблема состоит в том, что стандартный jquery их не поддерживает, мобильный jquery конфликтует со стандартным и остается использовать плагин
или писать обработчик самому. Лучше воспользуйтесь хаммером или zeptojs или поищите что-то еще. - Мультитач, опять же. Пример transform’а на том же хаммере.
- Еще трясти и наклонять его можно ведь, но это я не пробовал :)
- Самое неприятное: половина (оценочное суждение) js-плагинов не работает или работает некорректно с событиями iPad’а. Вот этот потрясный сложный плагин, который нас буквально спас для ПК-версии — он глючит и заставить его работать может только чудо. К сожалению, чудо скорее всего окажется говнокодом в красивом коде плагина.
И еще про дизайн
Теперь про то, с чем бороться было практически невозможно, ибо он уже был готов. Дизайн.
Рисовать макеты надо, учитывая реальное разрешение айпада, — 1024×768 точек. Он конечно все сожмет, растянет, полюбит и поймет (боже, какая пошлятина вышла). Но с родным разрешением ему жить проще. Плюс отступы браузера: он есть только один — шапка браузера, но про него тоже не надо забывать в обеих ориентациях.
- В связи со сложностью работы js-плагинов рекомендуется рисовать дизайн, который может работать на максимально простых элементах. Объяснять заказчику, почему на устройстве не работает «эта красивая штучка», которую прикрутили еще два месяца назад и как ему с этим жить, — не захочет ни один человек. А менеджеры — тоже люди.
- Стараться не перегружать страницу сложными элементами. iPad хотя и клевая няшка, но по производительности уступает компьютеру. Обидно, когда на такой красивой штуке начинаются тормоза.
- Всякие красивые приблуды вроде fancybox иногда оказываются неуместными. Вариант с галереей с минимальным дизайном в новом окне намного предпочтительнее и будет лучше поддерживаться устройствами с меньшим экраном.
- Уши в устройствах будут обрезаться. Если у нас есть основная ширина и у контента есть запас по высоте, то боковых ушей просто не будет (я имею ввиду красивые бэкграунды слева и справа, которые лежат за пределами основной области. Как тут:
- Помните: когда вы захотите перекомпоновать блоки между собой (скажем, разместить их не рядом, а один в другом) на дизайне для устройства, программисту придется писать несколько раз вывод одного и того же блока, что иногда означает много дополнительной возни с кодом, а ее и так мало что ли?
- Желательно пользоваться родными средствами устройства. Скажем, попытка прикрутить свой скроллер обернулась гигантскими мучениями с последующим отказом от него в пользу родного:
.scroll { position: relative; overflow: scroll; -webkit-overflow-scrolling: touch; }С которым тоже не все гладко.
И еще немного про больное.
Имеется галерея изображений. На ПК у изображений один размер. На горизонтальной ориентации iPad — другой. На вертикальной — третий (программисты справятся — и не такое делают!). Пропорции везде отличаются.
На другой странице у нас есть еще один блок, в котором выводятся эти же изображения, но с другими пропорциями. Сколько? Я насчитал 6 вариантов пропорций изображений. При этом две пары (iPad вертикальный и iPad горизонтальный на одной странице и такие же на другой) должны переходить друг в друга при повороте. То есть, при загрузке, мы не знаем под какие пропорции пережимать изображения.
Получается, нам надо пережать картинки под 6 вариантов изображений (код модуля один для двух страниц) и прописать для них стили и разметку. А если используется js-плагин для вывода, то потребуется его настройка на эти размеры и, возможно, переинициализация при повороте iPad’а. Это не все. Потом требования к размерам поменяются и вам придется заново отлаживать вывод для этих шести вариантов).
Еще нюанс: на разных версиях галереи отличается количество картинок (какого х.....???!!?!?!). Кроме того, разное количество картинок иногда вообще невозможно реализовать, если галерея выводится с пейджингом. Какой ставить размер страницы?
Думаю, первая проблема понятна: это безумный код, который сложно сопровождать и все ради какой-то галереи.
Облегчите программистам жизнь хотя бы одинаковыми пропорциями. А еще лучше — одинаковыми галереями! Сильное различие версий приводит к ветвлению кода, что всегда усложняет разработку, а еще больше — сопровождение и повышает количество багов (вам ли не знать?)
Но хватит ныть!
(Я сказал хватит!!!)
Ведь у iPad’а такой классный экран, давайте на него любоваться!! Очень четкий, красивый, супер!!
А что это такое ступеньками на логотипе, ведь на дизайне все было гладко? А это экран с высокой точностью, на котором вы, к сожалению, сможете заметить небольшие проблемы с картинками, сделанными на обычных компьютерах. Опять ныть начали?.. Отставить!! Умные люди уже придумали несколько способов, которые выведут PC-шную нечисть на чистую воду!
Я сам уже успел попробовать вариант с «@media all and (-webkit-min-device-pixel-ratio: 1.5) { ... }» на логотипе sibirix.ru и убедился, что он правда работает. Правда работает. Хватит ныть.
И напоследок: платформа развивается и тот же «-webkit-overflow-scrolling: touch;» появился относительно недавно в пятой версии iOS. Все время появляются новые возможности, а мы же их так сильно любим.
Будем следить!!