Meta name apple mobile web app capable

Мета-теги HTML для Apple Safari

Обзор html мата-тегов для браузеров Safari на платформах Mac OS X и iOS.

Apple Touch Icon

Иконка сайта в iOS на экране закладок и домашнем экране.

Иконки разных размеров указываются атрибутом sizes :

Apple Touch Icon Precomposed

Тоже самое что и apple touch icon , но с наложенными эффектами в стиле iOS с закругленными углами и т.д.

Mask Icon

Используется в MacOS при сохранении сайта на рабочий стол. Элементы SVG должны быть черного цвета, цвет задается атрибутом color .

Apple-Mobile-Web-App-Title

При добавлении сайта на домашний экран в iOS задает имя иконки.

Apple-Mobile-Web-App-Capable

В Safari iOS для закрепленных сайтов на экране «Домой» включает полноэкранный режим.

Apple-Mobile-Web-App-Status-Bar-Style

Задает стиль панели состояния при полноэкранном режиме.

Может иметь следующее значение:

default	Белый фон
black	Черный фон
black-translucent	Прозрачный фон и белый цвет иконок и шрифтов

default

black

black-translucent

Apple-Itunes-App

В iOS Safari выводит баннер с приложением в App Store.

Баннер не отобразится, если устройство не поддерживает приложение или оно недоступно для данной локали, подробнее на developer.apple.com.

Format-Detection

В iOS запрещает распознавать номера телефонов и адреса.

Источник

Страницы Интернета

пятница, 15 мая 2015 г.

HTML по стандартам

Изначально хотел назвать статью «HTML по ГОСТ`у», но потом выяснилось что у большинства программистов не было предмета «Метрология и стандартизация» и о «стандартизации», «сертификации», «унификации» не все слышали.

В i-Free я много занимаюсь разработкой веб-приложений. А поскольку их много, они разные и работают в разных условиях, то само собой приходится задумываться о стандартизации. Есть такой проект «Пуленепробиваемый HTML5» (http://html5boilerplate.com/), в котором разработчики решили создать идеальный шаблон странички. Он мне очень нравился, и все свои проекты я начинал именно с него. Но, исправляя баг за багом, делая все новые и новые приложения, я пришел к выводу, что многого в нем не хватает. В этой статье я хотел бы рассказать о том, что обычно пропускают при написание страничек и веб-приложений и показать, чем и зачем я прокачал свой шаблон пустой странички.

Указатель на язык:

Это идет в паре с hyphens в CSS. Таким образом браузер может более корректно расставлять переносы.

Убираем возможность масштабировать:

Это особенно полезно на телефонах с операционкой Bada, которые могут дождаться загрузки страницы и просто умножить разрешение на 2. Также мы отключаем zoom, т.к. в приложениях обычно никакого зума нет.

Ещё один тег для вышеописанной проблемы:

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

Запрещаем кэшировать документ:

Это помогает на некоторых девайсах избавиться от неадекватных попыток восстановления страницы. То есть попытки адекватные, но не все девайсы восстанавливают страницу без багов.

Mobile Internet Explorer позволяет принудительно активировать технологию ClearType для сглаживания шрифтов:

Не забываем добавить картинки для Apple устройств:

Этот мета-тег необходим для того, чтобы приложение открылось в полноэкранном режиме:

Ну и корректируем верхнюю полоску в iPhone:

Ну и Windows 8 берет пример с iPhone. Дополнительная разметка для описания:

Дополнительная разметка для оформления ссылки на приложение в меню:

Дополнительные настройки для окна. Видимо, это такая отсылка к HTA, который не пошел:

Просим IE переключиться в последний режим:

Отключаем панель работы с изображениями:

Просим IE оформлять все в классическом стиле без учета текущей темы операционки:

Запрещаем распознавать номера телефонов и адреса, а так-же выделять их:

Для обычной веб-странички лучше вставить набор CSS стилей, описывающих телефон и адрес, а не блокировать их распознание.

Полный набор для SEO:

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

Обязательно скидываем стили по умолчанию:

Свой reset я немного изменил. Он задавал background для TD тега, и это вызвало багу в старом IE, если мы заливаем всю строку через тег TR

Добавляем набор своих стандартных стилей:

А в них учтены ещё некоторые нюансы. Например убираем выделение в CSS:

Но оставляем его для полей ввода текста:

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

Ставить border картинкам обычно не забывают, т.к. он в reset.css, а вот vertical-align пропускают:

Ещё у меня хранится стандартный класс анимации, чтобы «мозолить глаза»:

Можно копировать его по мере надобности для кнопок, табиков и т.п. Суть в том, что когда он постоянно попадается на глаза, подключение анимации становится чем-то естественным. О ней уже не надо вспоминать как о фиче, которую нужно не забыть подключить.

А ещё в этих стилях я раскрашиваю плашку которая всегда идет вверху HTML шаблона:

Ну и конечно, ради любимого IE в самом начале добавим:

Этой строкой просим его не показывать нам табличку про то, что скрипты опасны и т.д. и т.п., а просто брать и включать JS

Ну и стили для портретной и альбомной ориентации:

Если будете переводить в HTA, есть такая вставка:

Тут указаны параметры для HTA файла (например, наличие системного меню, отсутствие скролла и т.п.). А также добавлен JS файл (по умолчанию он закомментирован):

Его задача сжать окно и отцентрировать его по середине экрана (если, конечно, это возможно).

Ну а с этим наверное уже знакомы?

Бежим по новым тегам HTML5 и пересоздаем их для старых IE.

Ну и прокачиваем Android

Например, убираем у них адресную строку. Для этого:

• Берем высоту страницы и увеличиваем её на два
• Скроллим вверх до 1px сверху
• Возвращаем высоту в исходное положение

Таким хаком на Android`ах исчезает адресная строка. А ещё можно добить тач, об этом говорил Иван Чашкин на DUMP-2014 (а ещё тут есть статья http://habrahabr.ru/company/mailru/blog/165213/ от Mail.ru). Суть в том, что, если переопределить все тач события и сделать им stopPropagation, то Android`ы перестанут тормозить с отправкой событий.

Просим закэшировать приложение для offline работы, если это возможно:

Там выше ещё про переносы и язык было, поэтому полный тег такой:

Как выглядит input обычного человека:

Как выглядит input курильщика:

Атрибуты элемента:

• placeholder — подсказка для ввода
• maxlength — ограничение количества вводимых символов
• spellcheck — проверка правописания
• autocorrect — автоматическое корректировка написанного
• autocapitalize — автоматическое преобразование регистра
• x-webkit-speech — голосовой ввод

Требования к элементу:

• Тип элемента должен соответствовать типу вводимых данных. Если это поле ввода пароля, оно должно иметь тип password. Вводимые символы при этом должны заменяться звездочками.
• Элемент должен сопровождаться примером того, какие данные требуется ввести.
• Элемент должен подсказывать пользователю данные для ввода на лету.
• Элемент должен проверять орфографические ошибки.
• Максимальная длина ввода должна быть ограничена.
• Если это поле ввода нового пароля, необходимо добавить кнопку «авто-генерация пароля». При нажатие на которую генерируется случайный пароль.
• Элемент должен содержать атрибут pattern, указывающий на ожидаемый тип данных.
• При работающем JavaScript, введенные пользователем данные обязательно должны проверяться на лету. Если данные не прошли проверку — необходимо немедленно уведомить об этом пользователя.

Рекомендации:

• Если это поле ввода пароля, необходимо добавить кнопку «посмотреть пароль» (обычно оформляется в виде «глаза»), при нажатие на которую тип поля становится text, и пользователь может проверить введенные данные.
• Если есть возможность авто-заполнения поля, её необходимо обязательно использовать. Либо поместить около элемента кнопку, при нажатие на которую будет срабатывать авто-заполнение.
• В зависимости от ситуации, иногда возможно использовать «автокоррекцию» и на лету удалять запрещенные символы. Опасность такой ситуации заключается в том, что пользователь может не заметить коррекцию и отправить данные, которые отличаются от того, что он хотел ввести.

Половину этих свойств можно переносить и на textarea. Тут и авто-дополнение, и проверка правописания, и голосовой ввод, подсказка, ограничение длины и т.д. Но есть ещё ряд дополнительных требований:

• Изменение размера поля должно быть запрещено (resize: none в CSS)
• Если это ввод некоего сообщения, необходимо информировать пользователя о том, сколько символов ему ещё можно ввести.

Замечания по верстке:

• Идеальная верстка должна выживать где-то в районе IE6. Стараемся по минимуму использовать inline-block. Заранее смотрим, что будет если он станет inline или block элементом.
• Position — это опасно. Желательно ничего никуда не позиционировать.
• Float — тоже к добру не приведет. Желательно вообще про него забыть.
• В дизайне надо сразу предусмотреть возможность того, что тот или иной фрагмент может отвалиться. В этом плане идеален стиль Metro. Как-то даже пришла в голову мысль, что Microsoft специально сделала такой стиль, в котором нет ни круглых углов, ни градиентов, ни теней. То есть ребята сразу отталкивались от своего браузера, чтобы никто не мог обвинить их в багах.

Progressive Enhancement и Graceful Degradation

Советую посмотреть доклад Сергея Горобцова из Яндекса про Progressive Enhancement и Graceful Degradation (http://tech.yandex.ru/education/shri/ekb-2013/talks/1500/) о том, как верстать так, чтобы было хорошо везде.

Что же ещё может понадобиться для стандартизации?

• Расческа для CSS (http://csscomb.ru/online/) поможет всему принять единый вид.
• Автопрефиксер Андрея Ситника поможет добить CSS-префиксы (http://habrahabr.ru/company/evilmartians/blog/176909/)
• Вот такой скрипт (http://bakhirev.biz/StalinGrad/zip/build/generation_pictures.zip) поможет нагенерировать кучу картинок (требует установленного imagemagick)

Так же в своем шаблоне я сразу подключаю несколько готовых модулей типа замены стандартных alert`ов, добавление автопрокрутки сбоку (как на хабре или вконтакте) и т.п. Но это уже велосипеды, которые выходят за рамки статьи.

А вот этот стандартный велосипед может пригодиться. Стандартный footer по микроразметке:

С другой стороны, у всех поисковиков она есть в документации, но никто её не поддерживает. Я использую этот footer, т.к. мало ли, может в будущем начнут использовать.

Источник

Safari HTML Reference

Supported Meta Tags

Apple-specific meta tags are described here.

Apple-Specific Meta Tag Keys

apple-mobile-web-app-capable

Sets whether a web application runs in full-screen mode.

Syntax

If content is set to yes , the web application runs in full-screen mode; otherwise, it does not. The default behavior is to use Safari to display web content.

You can determine whether a webpage is displayed in full-screen mode using the window.navigator.standalone read-only Boolean JavaScript property.

Availability

Available for iOS.

Support Level

apple-mobile-web-app-status-bar-style

Sets the style of the status bar for a web application.

Syntax

This meta tag has no effect unless you first specify full-screen mode as described in apple- apple-mobile-web-app-capable .

If content is set to default , the status bar appears normal. If set to black , the status bar has a black background. If set to black-translucent , the status bar is black and translucent. If set to default or black , the web content is displayed below the status bar. If set to black-translucent , the web content is displayed on the entire screen, partially obscured by the status bar. The default value is default .

Availability

Available for iOS.

Support Level

format-detection

Enables or disables automatic detection of possible phone numbers in a webpage in Safari on iOS.

Syntax

By default, Safari on iOS detects any string formatted like a phone number and makes it a link that calls the number. Specifying telephone=no disables this feature.

Support Level

viewport

Changes the logical window size used when displaying a page on iOS.

Syntax

Use the viewport meta key to improve the presentation of your web content on iOS. Typically, you use the viewport meta tag to set the width and initial scale of the viewport.

For example, if your webpage is narrower than 980 pixels, then you should set the width of the viewport to fit your web content. If you are designing a Safari on iOS-specific web application, you should set the width to the width of the device.

Table 1 describes the properties supported by the viewport meta key and their default values. When providing multiple properties for the viewport meta key, you should use a comma-delimited list of assignment statements. Follow these rules when setting multiple properties:

Do not use a semicolon as a delimiter.

A space may work as a delimiter, but a comma is preferred.

For numeric properties, if the value contains a nonnumeric character but starts with a number, then the number prefix is used as the value. For example, 1.0x is equivalent to 1.0 and 123×456 is equivalent to 123 . If the parameter doesn’t begin with a number, the value is 0 .

When referring to the dimensions of a device, you should use the constants described in Table 2 instead of hard-coding specific numeric values. For example, use device-width instead of 320 for the width, and device-height instead of 480 for the height in portrait orientation.

You do not need to set every viewport property. If only a subset of the properties are set, then Safari on iOS infers the other values. For example, if you set the scale to 1.0 , Safari assumes the width is device-width in portrait and device-height in landscape orientation. Therefore, if you want the width to be 980 pixels and the initial scale to be 1.0 , then set both of these properties.

For example, to set the viewport width to the width of the device, add this to your HTML file:

To set the initial scale to 1.0 , add this to your HTML file:

To set the initial scale and to turn off user scaling, add this to your HTML file:

Use the Safari on iOS console to help debug your webpages as described in the Safari Web Inspector Guide. The console contains tips to help you choose viewport values—for example, it reminds you to use the constants when referring to the device width and height.

Support Level

The width of the viewport in pixels. The default is 980 . The range is from 200 to 10,000 .

You can also set this property to the constants described in Table 2 .

The height of the viewport in pixels. The default is calculated based on the value of the width property and the aspect ratio of the device. The range is from 223 to 10,000 pixels.

You can also set this property to the constants described in Table 2 .

The initial scale of the viewport as a multiplier. The default is calculated to fit the webpage in the visible area. The range is determined by the minimum-scale and maximum-scale properties.

You can set only the initial scale of the viewport—the scale of the viewport the first time the webpage is displayed. Thereafter, the user can zoom in and out unless you set user-scalable to no . Zooming by the user is also limited by the minimum-scale and maximum-scale properties.

Specifies the minimum scale value of the viewport. The default is 0.25 . The range is from > 0 to 10.0 .

Specifies the maximum scale value of the viewport. The default is 5.0 . The range is from > 0 to 10.0 .

Determines whether or not the user can zoom in and out—whether or not the user can change the scale of the viewport. Set to yes to allow scaling and no to disallow scaling. The default is yes .

Setting user-scalable to no also prevents a webpage from scrolling when entering text in an input field.

Table 2 Special viewport property values

The width of the device in pixels.

The height of the device pixels.

Copyright © 2014 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2014-07-15

Источник