Не можна сказати, що валідний, кросбраузерності код, який коректно відображається на старших настільних братів дасть зовсім іншу картину при запуску на мобільній платформі - зараз вже ситуація куди краще, ніж раніше. Однак, як показує практика, все ще залишилися деякі нюанси, які необхідно враховувати. Про тих, з якими мені довелося зіткнутися в процесі тестування в Safari під iOS я хочу сьогодні розповісти.
загальні положення
Перш, ніж починати усувати проблеми зовнішнього вигляду проекту на iOS пристроях, добре б відразу визначитися - що буде більш рентабельно. Я досить часто спостерігав ситуацію, коли сайт обростає непотрібними, зайвими конструкціями на догоду прийнятного виду з айфона. А якщо оригінальна версія сайту ще грішить і флешем ...
Іноді набагато краще (як з економічної, так і з точки зору юзабіліті) використовувати мобільну версію, зі своїми стилями і скриптами. Визначити, з якого пристрою до нас прийшов користувач нескладно:
Підключати стилі без використання JS можна 2 способами:
- через @media в основному файлі стилів
- вказуючи в head шлях до стилю
Приклад першого способу описаний нижче, в пункті «Зображення», другий же виглядає так:
Принцип дії в обох варіантах один - ми використовуємо в якості ідентифікатора максимальне дозволу пристрою, на якому буде відображатися проект. Можна, до речі, записати те саме, тільки без "only" - це свого роду захист від старих браузерів.
В принципі, можна відразу відсилати користувача на мобільну версію сайту (приклад для iPad):
Однак, як показує практика, мобільна версія не завжди зручна і, що більш важливо - не завжди звична користувачеві. Краще дайте право вибору: наприклад, при першому переході на сайт сторінку з питанням / пропозицією використовувати мобільну версію.
зображення:
Веб розробники, перевіряючи свій код на життєздатність під iOS час зрідка стикаються з проблемою використання великих зображень як фону. Причому, «великих» слід розуміти як об'ємних по вирішенню. Як виявилося, існує штучне обмеження для Safari під управлінням iOS.
Якщо коротко, то справа йде так:
- Якщо на борту яблучного девайса ОЗУ менше 256 Мб, то максимальний розмір зображень, який можна використовувати безболісно - 3 мегапікселі (що, фактично, ≤ 3 * 1024 * 1024 = 3 145 728 пікс.)
- Пристрої, значення обсягу ОЗУ яких більше 256 Мб, коректно відобразять зображення до 5 мегапікселів.
Основною мотивацією цього рішення, за версією самої Apple, є невисока швидкість передачі даних в EDGE, 3G і Wi-Fi мережах, однак жорстка прив'язка до обсягу пам'яті явно дає зрозуміти, що це не що інше, як спроба уникнути «гальм», які неминуче виникнуть під час декодування і масштабування великих зображень.
Варто зауважити, що дані обмеження актуальні для зображень .GIF. PNG, і .TIFF формату. Що стосується зображень формату JPEG, то можна з чистою совістю використовувати зображення до 32 мегапікселів, але тільки в режимі сабсемплінга. Нагадаю, що при збереженні зображення в тому ж Photoshop, сабсемплінг автоматично використовується для рівня якості «Low» і «Medium». Це, в свою чергу, означає те, що фактично ж, максимальна роздільна здатність при кодуванні в більш-менш прийнятній якості обмежена тими ж 32/16 = 2 мегапікселямі.
Спеціально перерізуємо наше зображення на зменшене, довантажуючи його одним з вищеописаних способів, наприклад - через @media:
Для екранів з дозволом> 1024 буде відображатися фон, зазначений в CSS раніше.
Скрипти, час виконання яких перевищує 10 секунд, примусово вбиваються - причому, не факт, що це буде упереджений етап: в кращому разі може статися, що користувач побачить те, що йому бачити не слід, по крайней мере, не натиснувши пару кнопок.
Оптимізація, тільки оптимізація. І тестируйте ваші скрипти. Причому, саме на тих пристроях, де вони повинні працювати. На випадок, якщо хтось забув - приведу код того, як це зробити:
І набагато краще, якщо час виконання буде максимально віддалене від критичних 10 секунд - ви ніколи не знаєте, що ще висить у фоні і від'їдає ресурси і яка саме версія девайса буде у користувача в руках (відповідно - продуктивність). Хоча, за скрипти, які навіть близько підходять до цієї позначки, слід відривати руки.
За замовчуванням у мобільній версії Safari є одна неприємна особливість, яку помічаєш, коли перевіряєш проект на сувору відповідність макету:
кути елементів input і textarea закругляются.
Вирішується це просто - обнуленням через CSS властивості border-radius:
Я це вважаю за краще робити конструкцією для всіх браузерів відразу [параноя]. хоча можна обійтися і одним рядком.
Виявилося, що і з Label'амі у нас проблема. Як відомо, при натисканні на label можна здійснювати дію зі зв'язаним елементом, наприклад, з чекбоксів. Як виявилося, мобільна версія Safari і цьому чинить опір, рішуче не роблячи нічого при кліці на вищезгаданий.
Варіантів розв'язання проблеми кілька, існує і на чистому js, без підключення сторонніх бібліотек, однак мені сподобалася реалізація на jQuery:
Бувають випадки (см.актівние карти), коли js зайвий раз використовувати не хочеться і необхідно при наведенні на батьківський елемент вивести раніше прихований дочірній. На перший погляд правильна конструкція:
Однак, результатом цього на iPhone буде ... анічогісінько.
Справа в тому, що в такому ключі браузер не сприймає псевдоклас: hover, тому що він застосований до елементу div.
Для коректної роботи на iPhone необхідно застосовувати hover-ефекти саме до заслання:
(Не забуваємо про правила вкладеності елементів: в даному випадку використовуємо саме span для успішного проходження валідації).
І обов'язково - для посилань:
При такому підході при кліці на посилання не відбуватиметься перезавантаження сторінки, і, в той же час, ми отримаємо працює hover на айфоне - тому що для девайсів з сенсорним екраном діють наступні правила:
- Клік по посиланню -> перехід за посиланням
- Клік-1 за посиланням із заданим псевдоклас: hover ->: hover властивості,
- Клік-2 по посиланню з заданим псевдоклас: hover -> перехід за посиланням.
Саме наболіле прозвучало і, на сьогодні - все.
У планах - матеріал про визначення орієнтації пристрою