CSS3 рецепты для WebKit. Сделано для мобильных устройств. Что общего для каждого WebKit порта

Android и iPhone – войны браузеров

Часть 1. WebKit спешит на помощь

Разработка приложения для браузера, отвечающего за мониторинг состояния сети

Серия контента:

Суммарно, платформы iPhone и Android насчитывают более 100000 приложений, доступных для скачивания из самых разных источников. При этом имеются в виду «родные» приложения, т.е. приложения, которые разрабатываются и собираются средствами соответствующего SDK, а затем устанавливаются на мобильное устройство. Подобные «родные» приложения позволяют эффективно реализовать технические возможности мобильного устройства, включая поддержку беспроводных сетей, Bluetooth и хранилищ данных, функции акселерометра или компаса и другие технологические чудеса и новинки, которые делают мобильные устройства столь привлекательными для пользователей. Популярность «родных» приложений для платформ iPhone и Android чрезвычайно велика, однако помимо этого мобильные устройства предоставляют широкие возможности для разработки Web-приложений.Мобильные технологии давно вышли из детского возраста, а с ними достиг определенной зрелости и мобильный Интернет.

Эта статья является первой в серии из двух частей, посвященной разработке приложений для браузеров на платформах iPhone и Android. Цель этой серии – познакомить читателя с основными принципами создания собственных мобильных Web-приложений. Возможности мобильных приложений не ограничиваются запуском Web-сайта на мобильном устройстве. Мы рассмотрим базовые технологии и подходы, используемые в разработке мобильных приложений, которые позволяют выделить этот раздел разработки ПО в отдельную самостоятельную дисциплину.

Популярность Web-платформы объясняется тем, что ее использование позволяет решить множество проблем, традиционно являющихся бичом разработчиков и системных администраторов. Среди них:

• Проблемы установки: установка Web-приложений не вызывает никаких проблем – просто установите или скопируйте их на сервер и скажите вашим клиентам, какой URL-адрес нужно указать в браузере.
• Проблемы масштабирования: Web-приложения легко масштабируются на пул серверов высокопроизводительного центра обработки данных, а для обслуживания приложений используются готовые инструменты управления Web-сайтом.
• Проблемы архивирования и восстановления данных: Web-приложения используют централизованное хранилище данных, тем самым упрощая задачу восстановления в случае сбоев.
• Вопросы пользовательского интерфейса: комбинация of HTML, Cascading Style Sheets (CSS) , JavaScript и графических изображений позволяет создать многофункциональный пользовательский интерфейс, который значительно превосходит по своим возможностям и внешнему виду интерфейсы, разработанные средствами «родных» SDK. Последние, как правило, не в состоянии обеспечить полноценный эффект присутствия для игровых приложений и не гарантируют необходимую функциональность для интерактивных информационных терминалов.
• Простота использования: большинство приложений требуют простых и понятных в использовании элементов пользовательского интерфейса, позволяющих легко выполнять повседневные операции.

Наиболее привлекательный аспект модели дистрибуции приложений через Интернет состоит в том, что она позволяет превратить ПО в своего рода сервис по подписке, представляющий собой взаимовыгодный способ поставки программного обеспечения. «Каким образом?» – спросите вы. Давайте рассмотрим этот вопрос подробнее.

Модель дистрибуции ПО с помощью Web-интерфейса позволяет покупателям опробовать продукт перед покупкой с минимальным риском и по минимальной цене. Если пробная версия понравилась клиенту, то все, что требуется от него для дальнейшего использования программного продукта – это оплатить покупку кредитной картой (или с помощью системы PayPal). Более того, модель ПО как сервис (SaaS) предоставляет пользователям удобный и выгодный способ покупки ПО без каких-либо значительных авансовых затрат, гарантируя окупаемость вложений в течение первого месяца использования, а не в отдаленном будущем.

Дело в том, что поддержка Web-браузеров на мобильных устройствах практически отсутствовала. Ситуация кардинально изменилась с появлением технологии, получившей название WebKit, которая уверенно заняла свое место в сфере мобильных устройств именно благодаря iPhone.

Всего за несколько лет платформа iPhone стала Web-клиентом номер один в мире. Почему? Потому что WebKit вкупе с надежной работой Интернет-соединения позволили использовать Web-сервисы на мобильных устройствах гораздо эффективнее, чем на каких-либо других современных браузерах. Другие игроки рынка мобильных устройств также обратили внимание на новую технологию, и теперь весь рынок можно разделить на компании, которые используют WebKit, компании, которые собираются использовать WebKit и компании, придумывающие отговорки для того, чтобы не использовать WebKit.

Итак, что же такое WebKit?

WebKit и HTML5

WebKit – движок браузера, используемый как для поддержки браузера Mobile Safari на платформе iPhone, так и для поддержки браузера на платформе Android. Безусловно, WebKit используется и в других мобильных устройствах, однако в рамках этой статьи мы ограничимся рассмотрением платформ iPhone и Android.

WebKit – проект с открытым кодом, берущий свое начало из разработки K Desktop Environment (KDE). Именно проекту WebKit современные Web-приложения для мобильных устройств обязаны своим появлением на свет. Технологические и конструктивные характеристики мобильного устройства, безусловно, играют важную роль, однако мобильных пользователей в первую очередь интересует контент. Если мобильное устройство обеспечивает доступ лишь к малой части Интернет-контента, то вряд ли оно сможет попасть в топ-лист наиболее популярных устройств.

Большинство из нас предпочитает жить полноценной жизнью: если мы открываем какой-либо Web-сайт на портативном компьютере сидя дома, мы рассчитываем увидеть тот же контент, когда открываем этот сайт, сидя в поезде. Контент – вот основная проблема мобильных приложений. Независимо от того, где мы находимся, и чем мы занимаемся, нам нужен доступ к интересующим нам данным. Технология WebKit обеспечивает полноценный контент на платформах iPhone и Android.

Стоит отметить, что WebKit используется и в настольных компьютерах, например, в браузере Safari, который является основным браузером платформы Mac OS X. Независимо от того, рассматривается ли версия для настольных компьютеров или движок браузера для iPhone или Android, WebKit остается наиболее передовой технологией, поддерживающей HTML и CSS. Фактически, WebKit поддерживает стили CSS, которые пока еще не отображаются браузерами на других движках – в качестве примера можно указать ряд свойств, определяемых спецификацией HTML5.

HTML5 представляет собой набор предварительных технических спецификаций, определяющих технологии, которые базируются на использовании браузеров, таких, например, как хранилища данных на стороне клиента с поддержкой SQL, перемещения, преобразования и так далее. Разработка спецификации HTML5 пока еще на закончена, однако как только основные принципы будут четко сформулированы и реализованы в браузерах на большинстве платформ, весьма скромный начальный этап развития Web-приложений станет забытым прошлым. Разработка Web-приложений займет значительный сегмент в сфере разработки ПО, причем речь идет не только о приложениях для браузеров настольных компьютеров, но и для мобильных браузеров. Из побочного продукта мобильные приложения превратятся в основной товар на рынке Web-приложений.

Конструктивные особенности разработки мобильных Web-приложений

Если вы приняли решение освоить технологии Web-разработки, то в вашем распоряжении оказывается весьма ограниченный выбор средств. Прежде всего, приложение может быть создано непосредственно на сервере в виде файла, содержащего код HTML, CSS и JavaScript. При этом HTML-контент может поставляться в виде статических HTML-файлов, а может генерироваться динамически за счет использования различных технологий, работающих на стороне сервера, например, таких как PHP, ASP.NET, Java Servlets и др. В любом случае, с точки зрения вопросов, рассматриваемых в данной статье, все сводиться к коду HTML, и здесь наиболее важным для нас моментом является то, что технология WebKit позволяет браузерам воспроизводить HTML на мобильных устройствах.

Чтобы выполнить Web-приложение на мобильном устройстве (iPhone или Android), пользователю надо запустить браузер и ввести URL-адрес соответствующего сервиса, например: http://yourcompanyname.com/applicationurl.

При этом диапазон предлагаемых мобильных Web-приложений достаточно широк: от стандартного Web-сайта до мобильного Web-приложения, разработанного специально для конкретной мобильной платформы.

Отображение стандартных сайтов

Движок WebKit в сочетании с интуитивно понятным и удобным пользовательским интерфейсом платформ iPhone и Android позволяет просматривать на мобильном устройстве практически любые Web-сайты. Web-страницы отображаются вполне корректно в отличие от предыдущего поколения мобильных браузеров, которые произвольно переносили фрагменты контента или вовсе не отображали их. При загрузке страниц в браузере с поддержкой WebKit, содержимое страницы, как правило, масштабируется. При этом масштаб выбирается таким образом, чтобы вся страница целиком уместилась на экране, хотя и в сильно уменьшенном, зачастую нечитаемом виде, как показано на рисунке 1. Тем не менее, страницу можно прокручивать, увеличивать, двигать, обеспечивая удобный доступ ко всем элементам контента. По умолчанию браузер использует окно шириной 980 пикселей.

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

Web-страницы, созданные с учетом особенностей мобильных устройств

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

Несмотря на то, что WebKit позволяет корректно отобразить Web-страницу на экране мобильного устройства, существует определенная разница между устройствами, использующими мышку, такими как портативные или настольные компьютеры, и сенсорными устройствами, такими как смартфоны iPhone или Android. Сенсорные устройства отличаются физическими размерами площади «клика», отсутствием функции наведения курсора на какой-либо элемент и другой последовательностью событий. Таким образом, если вы хотите создать Web-сайт, который был бы удобен как для обычных, так и для мобильных пользователей, необходимо учитывать следующие особенности мобильных устройств:

• Браузеры iPhone и Android в состоянии отобразить Web-страницу целиком в достаточно «читабельном» виде – качество отображения этих браузеров значительно выше, чем у стандартных мобильных браузеров, – так что не спешите упрощать дизайн вашего сайта.
• Размер подушечек пальцев значительно превосходит размер указателя мышки. Учитывайте этот фактор при разработке элементов навигации по сайту. Не располагайте ссылки слишком близко друг к другу, иначе пользователь не сможет щелкнуть на одной ссылке, не задев при этом соседнюю.
• Элементы, отображаемые при наведении курсора, не будут работать на мобильных устройствах. Пользователь просто не может «навести» палец на какой-либо элемент так же, как курсор мышки.
• События, определяемые нажатием и удерживанием кнопки мышки, перетаскиванием мышкой и т.п., на сенсорных экранах реализуются другим способом. Какие-то из этих событий смогут отработать и на мобильных устройствах, но в целом не следует рассчитывать, что мобильный браузер и браузер настольного компьютера будут выполнять одни и те же последовательности действий.

Детальное обсуждение этих аспектов вы можете найти в статье «iPhone in Action » (см. раздел ). В нашей статье мы ограничимся рассмотрением преимуществ WebKit, а не его недостатков.

Рассмотрим наиболее очевидную проблему, с которой сталкиваются пользователи iPhone или Android при доступе к Web-сайтам, а именно ограниченный размер экрана. Фактически экран современного мобильного устройства имеет размер 320x480 или 480x320, при условии, что пользователь предпочитает просматривать Web-контент в альбомной конфигурации. Как видно из рисунка 1, WebKit в состоянии корректно отобразить Web-страницу, разработанную для стандартных настольных компьютеров. Тем не менее, при масштабировании Web-страницы, ее текст может оказаться слишком мелким для чтения, так что пользователю придется воспользоваться функциями прокрутки, сдвига и увеличения, прежде чем он сможет прочитать текст. Как бороться с этим ограничением?

Наиболее простой способ создать страницу, одинаково хорошо отображаемую в окне мобильного браузера и в окне браузера настольного компьютера, это использование специального мета-тега viewport .

Мета-тег – это HTML-тег, размещаемый в заголовке HTML-документа. Самый простой пример использования тега viewport выглядит следующим образом: . При добавлении этого мета-тега к HTML-странице, ее отображение в окне мобильного браузера масштабируется наиболее оптимальным образом (см. рисунок 2). Браузеры, не поддерживающие viewport, просто игнорируют этот тег.

В отдельных случаях полезно заранее определить параметры масштабирования окна, как это показано на рисунке 3.

Для определения конкретных параметров масштабирования, укажите точное значение атрибута content мета-тега viewport: . Изменяя значение параметра initial-scale, изображение может быть уменьшено или увеличено. Для платформ iPhone и Android лучше использовать значения от 1.0 до 1.3. Мета-тег viewport также поддерживает минимальный и максимальный масштаб, что позволяет ограничить возможности пользователя модифицировать масштаб страницы в процессе ее загрузки.

В то время как конструктивные характеристики iPhone, в частности размер экрана 320x480, практически не изменились с момента его появления, параметры устройств на платформе Android имеют достаточно широкий диапазон, так как мобильные устройства на этой платформе выпускаются различными производителями и предназначены для самых разных групп пользователей. Таким образом, если вы хотите, чтобы ваше Web-приложение пользовалось популярностью у мобильных пользователей, следует учитывать возможную разницу в размерах и разрешении экрана, а также конструктивных особенностях устройств на базе Android.

Опыт показывает, что помимо конструктивных различий, существующих между различными мобильными устройствами на базе Android, само программное обеспечение Android пытается установить настройки загружаемой Web-страницы в зависимости от свойств браузера мобильного устройства. Помимо стабильности, платформа Android отличается постоянно меняющимся набором функций и возможностей. Настройки конкретного устройства на базе Android, скорее всего, будут отличаться от настроек вашей среды разработки, в зависимости от версии SDK и производителя устройства. На рисунке 4 показан экран настройки браузера в версии V1.6 Android Emulator. Настройки экрана предоставляют пользователю возможность определить уровень масштабирования изображения на экране (far, near, medium) или выбрать режим автоматического масштабирования страницы.

В мире мобильных устройств самая постоянная величина – это перемены, так что следует учитывать развитие и обновление рынка мобильного ПО. Например, настройки браузера Sprint Hero включают в себя набор опций, который в корне отличается от стандартных параметров, используемых при загрузке Web-страницы. Браузер Hero построен на платформе Android V1.5 с использованием рядя модификаций, сделанных компанией HTC. К счастью, при использовании мета-тега viewport специфические настройки Hero будут игнорироваться.

До сих пор мы видели, что WebKit вполне справляется с загрузкой Web-страницы, хотя и в сильно уменьшенном и трудночитаемом виде. Затем мы расширили контроль над тем, как страница отображается на экране мобильного устройства за счет использования мета-тега viewport. Теперь отображаемая страница гораздо более удобна для чтения и навигации. Но этого все еще недостаточно для того, чтобы наша страница выглядела и функционировала как Web-приложение.

Сделано для мобильных устройств

Перейдем к рассмотрению особенностей дизайна Web-странцы, предназначенной для мобильной аудитории. В качестве конкретного примера рассмотрим страницу регистрации сервиса GMail электронной почты Google.

Так выглядит эта страница в окне браузера настольного компьютера:

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

Страница, показанная на рисунке 6, безусловно рассчитана на мобильных пользователей. На экране отображаются только те элементы страницы, которые необходимы пользователю для дальнейшей работы – не требуется никакой дополнительной прокрутки, смещения или масштабирования.

Теперь рассмотрим окно просмотра электронных писем мобильной версии Gmail. Поскольку экранное пространство, доступное приложению, весьма ограничено, окно просмотра сообщений имеет дополнительные кнопки и элементы навигации. При этом отображаемые навигационные элементы перекрывают окно для просмотра сообщений. Кроме того, не следует использовать слишком много фреймов или элементов прокрутки div , если этого можно избежать. Мобильная версия Gmail решает эту проблему путем использования всплывающего меню, которое появляется, как только пользователь заканчивает прокрутку страницы. Всплывающее меню содержит 3 кнопки: Archive , Delete и More . При нажатии на кнопку More появляются дополнительные элементы меню (см. рисунок 7).

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

Следует учитывать, что мы не хотим намеренно обеднять дизайн и сокращать возможности работы мобильных пользователей, обладающих развитыми многофункциональными браузерами для платформ iPhone и Android. С этой точки зрения полезно обратить внимание на элемент, отображаемый внизу страницы Gmail (см. рисунок 8):

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

Теперь рассмотрим случай, когда вы хотите создать приложение, использующее Web-технологии, но выглядящее при этом как «родное» мобильное приложение.

Контент, специфичный для конкретной платформы

Следующий шаг – это разработка контента, специфичного для конкретной мобильной платформы. При этом формат и интерфейс страницы определяются таким образом, чтобы в результате страница выглядела как «родное» приложение для конкретной платформы, а не как стандартный Web-сайт общего доступа. Что мы имеем в виду под «родным» приложением?

Прежде чем углубиться в дискуссию о том, как сделать Web-приложение максимально похожим на «родное» приложение для конкретной платформы, давайте оставим в стороне общие свойства браузеров iPhone и Android и вкратце остановимся на визуальных отличиях, существующих между этими платформами.

Приложения iPhone имеют свой специфический вид и интерфейс. Покажите кому-нибудь снимок экрана iPhone и, если только этот человек не свалился буквально на днях с луны, он практически наверняка сразу же скажет, что это iPhone. Покажите этому же человеку снимок экрана мобильного устройства на базе Android, и ответ уже не будет столь однозначным. В чем причина? Существует несколько возможных объяснений. Во-первых, iPhone появился на рынке гораздо раньше устройств на базе Android и успел приобрести огромное количество поклонников. Вспомните людей, выстраивающихся в очередь, чтобы заплатить немалые деньги за ограниченные возможности V1 iPhone. Нравится вам iPhone или нет, этот продукт Apple является в настоящее время лидером рынка. А как обстоит дело с Android?

Платформа Android является относительно новым продуктом, и во многих аспектах выступает в качестве антипода iPhone, так как рассчитана в первую очередь для открытого сообщества. Платформа Android используется в самых разных устройствах (телефонах и других бытовых приборах). Для простоты обсуждения в этой статье мы ограничимся использованием Android в мобильных телефонах.

С течением времени, количество устройств в мире на базе Android превзойдет количество iPhone. Это объясняется тем, что устройства на платформе Android выпускаются целым рядом компаний и будут поддерживаться самыми различными сетями передачи данных. При таком значительном количестве игроков на рынке мобильных устройств Android, несомненно, следует ожидать определенной фрагментации рынка на базе внешнего вида и параметров устройств. Эта тенденция прослеживается на примере интерфейса SenseUI от компании HTC. Этот привлекательный внешний вид и интерфейс не поддерживается базовыми версиями Android SDK и не совместим с другими устройствами на базе Android. Компании Motorola, Google и Verizon объединили свои усилия для разработки нового устройства DROID на базе Android. Это первый коммерческий продукт на платформе Android версии 2.0.

Сравните разнообразие систем на базе Android с единообразным внешним видом iPhone. iPhone – особо ценная собственность Apple. Внешний вид приложений iPhone может слегка измениться со временем, но эти незначительные изменения вряд ли сравнятся с различными версиями систем Android, количество которых достаточно велико даже сейчас, когда платформа находится в самом начале своего развития.

Итак, что необходимо сделать для того, чтобы максимально приблизить внешний вид и интерфейс приложения к «родным» программам?

Если бы такая задача стояла перед нами до появления Web 2.0, это была бы действительно серьезная проблема. Ранние попытки поддержки нескольких клиентских браузеров (мобильных и стационарных) основывались на использовании нескольких подходов, например:

• Разработка полностью параллельных сайтов
• Динамическая генерация контента в зависимости от параметра userAgent
• Использование прокси-серверов, которые смогли бы трансформировать контент в зависимости от каждого конкретного устройства. Подобная технология с успехом использовалась компанией RIM для организации доступа к электронной почте с мобильного устройства клиента.

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

К счастью, нам и не придется это делать. В эпоху WebKit и CSS разницу во внешнем виде и интерфейсе различных мобильных устройств можно преодолеть благодаря использованию таблиц стилей и media-запросов (media query), позволяющих использовать разные стили в зависимости от конкретного типа устройства. Технология media-запросов позволяет получить информацию о клиенте. Традиционно, браузер отправляет серверу значение userAgent , которое позволяет серверу идентифицировать конкретный браузер и определить контент, который должен быть передан клиенту. Используя media-запрос, браузер выбирает стиль страницы, исходя из своих возможностей. Следующий пример демонстрирует выбор таблицы стилей, предназначенной для смартфонов: . А этот запрос определяет таблицу стилей для настольных компьютеров: .

Internet Explorer V6

На момент написания этой статьи Internet Explorer V6 занимал примерно 20-30% общего рынка браузеров, однако рассмотрение возможностей IE V6 не входит в задачи данной статьи.

Более подробную информацию о media-запросах вы можете найти в предварительном варианте спецификации (см. раздел ).

Рассмотрим пример использования media-запросов для разработки приложения, отображающего состояние серверов сети.

Программа мониторинга сети

Задача этого приложения – мониторинг работы нескольких серверов. Независимым разработчикам программного обеспечения зачастую приходится обеспечивать поддержку нескольких приложений на нескольких серверах. Если вы занимаетесь разработкой ПО сколько-нибудь значимое время, то наверняка вы уже сталкивались с разными типами серверов и разными типами приложений. Все это означает, что вполне возможна такая ситуация, когда вы не сможете использовать единый инструмент для отслеживания работы всех необходимых приложений. В этом случае имеет смысл воспользоваться мобильным приложением для мониторинга сети (netmon). Приложение обеспечивает всю требуемую функциональность, оставаясь при этом достаточно гибким и удобным для доступа с мобильного устройства.

Приложение netmon включает список серверов, работу которых необходимо отслеживать. Для каждого сервера собираются ключевые индикаторы производительности (KPI). Ключевые индикаторы производительности – основной инструмент, который в течение многих лет используют студенты MBA для оценки текущего состояния бизнеса. С точки зрения хостинга Web-приложений, в качестве KPI могут использоваться следующие показатели:

• Количество транзакций за прошедший период времени
  • Заказы
  • Запросы на получение каталогов
  • Электронные сообщения
  • Количество просмотров страницы
• Время, прошедшее с момента последней транзакции
  • Заказа
  • Обмена электронными данными
  • Сообщения от бизнес-партнера
  • Загрузки файла от вендора через FTP
• Доступна ли база данных
• Дата последнего резервного копирования
• Средняя сумма заказа (в долларах)
• Объем свободного места на диске
• Пропускная способность за последний час, день, месяц

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

Поскольку работа конкретного приложения требует своих условий и ресурсов, программа netmon должна обладать достаточной гибкостью, чтобы учитывать особенности каждого приложения. Для обеспечения подобного уровня гибкости, мы начнем с определения наиболее общей структуры данных, позволяющей учитывать параметры состояния каждой системы. В Части 2 мы подробнее остановимся на том, откуда поступают эти данные, и как они обновляются. Пока что ограничимся следующей информацией:

• Имя сайта
• URL-адрес сайта (домашней страницы)
• URL-адрес для получения обновлений
• Статус: ОК или нет
• Краткая сводка: описание состояния сервера, которое будет либо иметь значение ОК, либо содержать текстовую строку с указанием наиболее серьезной проблемы для данного сервера
• Элементы: это набор пар имя/значение, которые нам потребуются для передачи текущих значений KPI для соответствующего сайта.

Наше приложение будет отображать полученные индикаторы эффективности в удобном для навигации виде, максимально используя возможности CSS, jQuery и WebKit для того, чтобы привлечь внимание пользователя к проблемным зонам. Как мы уже упоминали, основная цель при разработке данного приложения – возможность выполнять его на платформе iPhone, Android и на настольном компьютере в браузере Safari.

Разработка приложения для мониторинга сети

Современные Web-страницы должны создаваться в декларативном виде, определяющем организационную структуру и контент страницы. Позиционирование и форматирование страницы выполняется при помощи каскадных таблиц стилей CSS и, в большинстве случаев, с использованием JavaScript. Фактически, библиотеки JavaScript стали настолько популярны, что их использование сегодня – это скорее правило, чем исключение. В приложении, рассматриваемом в данной статьи, мы воспользуемся популярной библиотекой JavaScript jQuery. Наше приложение будет выполняться на платформе iPhone, Android и на настольном компьютере. При этом будет использоваться один и тот же код HTML, а все необходимые отличия будут реализованы в таблицах стилей. Здесь необходимо отметить, что мы сознательно не прикладывали каких-либо значительных усилий для разработки привлекательного внешнего вида приложения. Более того, в качестве фона сознательно были выбраны броские, не гармонирующие друг с другом цвета, чтобы привлечь дополнительное внимание читателя к организации таблиц стилей. В Части 2 мы слегка улучшим внешний вид приложения, а пока его HTML-код выглядит так, как показано в листинге 1.

Листинг 1. HTMLкод приложения if (navigator.userAgent.indexOf("iPhone") != -1) { document.write(""); } else if (navigator.userAgent.indexOf("Android") != -1) { document.write(""); } else { document.write(""); } function setupTestData() { try { netmon.initialize(); if (netmon.resources.length > 0) { jQuery.each(netmon.resources,function (index, value) { $("#mainContent").append(netmon.render(index,value)); }); $(".serverentry").click (function() {$(this).find(".serveritems").toggle();}); $(".serveritems").hide(); } } catch (e) { alert(e); } } My Network Resources My Servers My User Agent

Беглый просмотр предлагаемого HTML-кода позволяет выделить следующие основные особенности:

• В коде используются два внешних файла JavaScript: один файл библиотеки jQuery и один вспомогательный файл для нашего приложения.
• Для масштабирования отображаемого контента в коде используется мета-тег viewport.
• Основная таблица стилей определяется файлом netmon.css.
• Для определения вспомогательной таблицы стилей используется параметр userAgent . В зависимости от его значения будет подгружена таблица стилей для iPhone, Android или для браузера настольного компьютера.
• В процессе загрузки страницы для отображения данных используется jQuery и вспомогательная функция, определенная в файле netmon.js.
• В основном коде страницы используется несколько тегов div .
• И наконец, в коде присутствует ссылка на страницу, которая показывает строку userAgent . Эта ссылка не имеет никакого отношения к работе приложения и используется исключительно для демонстрации.

Прежде чем приступить к подробному разбору таблиц стилей и файла netmon.js, которые, собственно, и определяют основную работу приложения, давайте взглянем на наше приложение в его текущем состоянии. Еще раз обратите внимание, что мы используем три различных таблицы стилей: по одной для каждой из трех поддерживаемых платформ. Чтобы процесс разработки приложения был более наглядным, каждая таблица определяет свой фоновый цвет. На рисунке 9 наша страница открыта в настольном браузере Desktop Safari и имеет синий фон.

Рисунок 11 демонстрирует внешний вид приложения в окне браузера iPhone (цвет фона - зеленый).

Основная таблица стилей, хранящаяся в файле netmon.js, приведена в листинге 2.

Листинг 2. Основная таблица стилей body { color: #888888; font-family: Helvetica; font-size:14px; margin: 0px; padding: 0; } .details { margin: 0px; padding: 0px; background-color: white; border: solid; border-width: 1px; -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border-bottom-left-radius: 8px; -webkit-border-bottom-right-radius: 8px; } .OK { color: #000000; } .BAD { color: #ff0000; } .odd { background-image: -webkit-gradient(linear, left top, right bottom,from(#ccc) ,to(#999)); } .even { background-image: -webkit-gradient(linear, left top, right bottom,from(#999) ,to(#ccc)); } .serverentry a { float: right; color: #ffffff; } .serveritems{ color: #000; } #header h1 { margin: 0; padding: 0; text-align: center; color: #000; }

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

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

Устанавливать разный размер шрифта для мобильной и настольной платформы.

Проверить соответствующие функции WebKit. Это имело бы существенное значение, если бы для работы приложения использовался браузер без поддержки WebKit, например Firefox.

Листинг 3 демонстрирует код iphone.css файла.

Листинг 3. Файл iphone.css body { background-color: #00ff00; } .serverentry { -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border-bottom-left-radius: 8px; -webkit-border-bottom-right-radius: 8px; } .name { font-size: 2em; } .summary{ font-size: 1.5em; } .serverentry a { font-size: 1.5em; }

Как мы видим, в качестве фонового цвета тега body используется зеленый цвет (#00ff00), а размер шрифта настраивается для более удобного чтения с экрана мобильного устройства. Наконец, давайте взглянем на файл netmon.js, в котором определяется список серверов и функция, выводящая данные каждого сервера (используемая в листинге 4). Часть кода файла для краткости пропущена, полный его текст доступен в разделе ).

Листинг 4. Файл netmon.js var netmon = { initialize: function () { }, resources: [ { name: "msiservices.com", homeurl: "http://msiservices.com", pingurl: "http://msiservices.com/netmon.php", status: "OK", summary: "OK", items: [ {name: "DiskSpace", value: "22.13 GB"}, {name: "Database Up?", value: "Yes"} ] }, { name: "server 2", homeurl: "http://someurl", pingurl: "http://someurl/netmon.jsp", status: "OK", summary: "OK", items: [ {name: "DiskSpace", value: "100.8 GB"}, {name: "Database Up?", value: "Yes"} ] }, // additional entries clipped for brevity ], render: function(index,itm) { try { var ret = "; ret += ""; ret += "" + itm.name + " Show
"; if (itm.status != "OK") { ret += "-" + itm.summary + "
"; } ret += ""; jQuery.each(itm.items,function (j,itemdetail) { ret += ">" + itemdetail.name + "=" + itemdetail.value + "
"; }); ret += ""; ret += ""; return ret; } catch (e) { return "Error rendering item [" + itm.name + "] " + e + ""; } } };

Если строка состояния какого-либо сервера не равна ОК, то соответствующая запись сервера выводится красным, как видно из определения класса в файле CSS. Кроме того, если проверка статуса сервера выявила какие-то проблемы (статус не равен OK), дополнительно выводится краткое описание проблемы. На рисунках 9-11 видно, что на сервере 4 не хватает свободного дискового пространства. При нажатии на строку этого сервера на экран выведется подробное сообщение о проблеме (см. рисунок 12).

При нажатии на ссылку show справа от имени сервера открывается домашняя страница этого сервера. Наличие такой ссылки очень удобно по двум причинам: во-первых, это избавит вас от неприятной необходимости заучивать наизусть URL-адрес каждого сервера, а во-вторых, это избавит вас от еще более неприятной необходимости вводить этот URL-адрес с клавиатуры мобильного устройства (пусть даже и самой удобной).

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

Заключение

Эта статья знакомит с принципами разработки Web-приложений для iPhone и Android с использованием технологии WebKit. В Части 2 мы расширим возможности нашего приложения, добавив функцию обновления данных с использованием вызовов Ajax.

Для многих из нас, разработчиков, WebKit - черный ящик . Мы бросаем в него HTML, CSS, JS и кучу изображений, и WebKit, как-то… магически, выдает нам веб-страницу, которая выглядит и работает хорошо.
Но на самом деле, как говорит мой коллега Илья Григорик :

Веб-кит не является черным ящиком. Это - белый ящик. И не просто белый, но и открытый ящик.

Так-что, давайте попробуем разобраться в некоторых вещах:

• Что такое WebKit?
• Чем WebKit не является?
• Как WebKit используется WebKit-браузерами?
• Почему WebKit-ы не одинаковые?

Теперь, особенно после новости, что Опера перешла на WebKit , нас окружает множество WebKit-браузеров, и достаточно сложно сказать, что их объединяет, а где они идут своим путем. Ниже, я надеюсь, мы постараемся пролить немного света на этот вопрос. В итоге, вы сможете лучше определять отличия браузера, отправлять баги в правильный трэкер, и вести кроссбраузерную разработку более эффективно.

Стандартные компоненты веб-браузера

Давайте перечислим несколько компонентов современных браузеров:

• Парсинг (Разбор HTML, XML, CSS, Javascript)
• Макет (Layout)
• Рендеринг текста и графики
• Декодировка изображений
• Взаимодействия с GPU
• Доступ к сети
• Аппаратное ускорение

Какие из них общие для всех WebKit браузеров? В значительной степени только первые два.

Остальные компоненты каждый WebKit «порт» реализует по своему. Давайте разберемся что это значит.

WebKit порты

Существует множество WebKit «портов», и я предоставляю Ария Хидаят, WebKit хакер и тех. директор в Sencha право рассказать об этом :

Самым популярной ассоциацией к понятию WebKit, обычно является вид WebKit-а от Apple’s, который работает на Mac OS X (первая и оригинальная WebKit библиотека). Как вы можете догадаться, различные интерфейсы реализованны, используя различные нативные библиотеки Mac OS X, в основном сосредоточенные в компоненте CoreFoundation . Например, если вы определяете цветную плоскую кнопку, с особым радиусом контура, WebKit знает где и как рисовать эту кнопку. В тоже время, окончательная отрисовка кнопки (в виде пикселей на мониторе пользователя) ложиться на плечи CoreGraphics .

Как я упоминал выше, используемый CoreGraphics, уникален для каждого WebKit порта. Chrome для Mac-а, к примеру, использует Skia .

В какой-то момент, WebKit был «портирован» под разные платформы, как десктопные, так и мобильные. Такая вариация обычно называется «WebKit порт». Для Safari Windows, Apple также самостоятельно портировала WebKit для запуска под Windows, используя своей (с ограниченной реализацией) CoreFoundation библиотеки.

… не смотря на факт, что Safari под Windows теперь мертв .

Кроме этого, также было множество других «портов» (см. полный список). Google создал и продложает поддерживать свой Chromium порт. Также существует WebKitGtk, основанный на Gtk+. Nokia (а теперь Trolltech, который перекупил его) поддерживает WebKit Qt порт, который стал популярен в качестве QtWebKit модуля .

Некоторые порты WebKit

• Safari
  - Safari под OS X и Safari под Windows два разных порта
  - Ночная сборка WebKit это сборка исходного кода Mac «порта», который используется для Safari, только новее
• Мобильный Safari
  - Развивался в приватной ветке, но позднее был открыт .
  - Chrome под iOS (использует Apple’s WebView; чуть позже о разнице)
• Chrome (Chromium)
  - Chrome под Android (использует непосредственно «порт» Chromium)
  - Chromium также является основой для браузеров: Yandex , , Sogou , и скоро, Opera.
• Android браузер
  - Использует последний исходный код WebKit, доступный на момент релиза.
• Еще большее количество портов : Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, etc

Разные порты могут фокусироваться на разных задачах. Фокус Mac порта - разделение между браузером и операционной системой, и предоставление биндигов Obj-C и С++ для встраивание рендеринг движка в нативные приложения. Фокус Chromium порта - всецело на браузере. QtWebKit предлагает свой порт использовать вместе со своей кросс-платформенной архитектурой приложений, в качестве движка для рендеринга.

Что общее во всех WebKit браузерах

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

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

И так, во первых, WebKit разбирает HTML одинаково. Ну, за исключением того, что Chromium единственный порт, на данный момент, где включена поддержка потоков для разбора HTML .

… Хорошо, но после разбора HTML, DOM дерево конструировается одинаково. Ну, на самом деле Shadow DOM включен только для Chromium порта, тоесть построение DOM-а варьируется. Тоже для кастомных элементов.

… Хорошо, WebKit создает window и document объекты для всех одинаково. Правда, хотя свойства и конструкиии которые они предоставляют, могут зависит от использования переключателей функций (feature flags).

… Разбор CSS одинаков. Поедание вашего CSS и преобразование его в CSSOM довольно таки стандартно. Ага, хотя Chrome поддерживает только -webkit- префиксы, когда Apple и другие браузеры поддерживают устаревшие префиксы -khtml- и -apple-.

… Макет… позиционирование? Это же как хлеб с маслом. Везде одинаково, правильно? Ну уже! Субпиксельный макет и насыщенная макетная арифметика является частью WebKit, но отличается от порта к порту.

Супер.

Так что, это сложно.

Теперь, давайте попробуем подвести итог, что общего в мире WebKit…

Что общего для каждого WebKit порта.

• DOM, window, document
  более или менее
• CSSOM
• Разбор CSS, свойство/значение
  различия в префиксах производителей
• Разбор HTML и построение DOM
  Одинаково, если мы забудем про Web Components.
• Макет и позиционирование
  Flexbox, Floats, block formating context… все общее
• Инструменты пользовательского интерфейса, и инструменты разработчика, типа Chrome DevTools он же WebKit inspector.
  Хотя с прошлого апреля, Safari использует свой собственный Safari инспектор, не-WebKit, с закрытыми исходниками.
• Такие функции как contenteditable, pushState, File API, большенство SVG, математика CSS трансформаций, Web Audio API, localStorage
  Хотя реализация может отличаться. Каждый порт может использовать свою собственную систему хранения для localStorage и может использовать разное audio API для Web Audio API.

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

Теперь, что не является общим для WebKit портов:

• Все связанное с GPU
  - 3D трансформации
  - WebGL
  - Декодирование видео
• Отрисовка 2D на экран
  - Технологии сглаживания
  - Рендеринг SVG и CSS градиентов
• Рендеринг текста и переносы
• Сетевые технологии (SPDY, пре-рендеринг, WebSocket транспорт)
• JavaScript движок
  - Движок JavaScriptCore лежит в репозитории WebKit. Но существуют биндинги в WebKit и для него, и для V8.
• Рендеринг элементов форм
• Поведение тэгов video и audio и поддержка кодеков
• Декодирование изображений
• Навигация назад/вперед
  - Часть pushState()
• SSL функции, такие как Strict Transport Security и Public Key Pins

Давайте взглянем на один из них: 2D графика зависит от порта, мы используем совершенно разные библиотеки для рендеринга на экран:

Или если вдаваться в подробности, недавно добавленная функция: CSS.supports() была включена для всех портов, за исключением win и wincairo, для которых не включены условные функции css3 (css3 conditional features).

Теперь, мы вдаемся в технические подробности… время стать педантичным. Даже сказанное выше не совсем корректно. На самом деле это WebCore, является общим компонентом. WebCore это макет, рендеринг, и DOM библиотека для HTML и SVG, и в основном то, что люди думают, когда они говорят WebKit. В самом деле «WebKit» технически - это слой биндингов между WebCore и «портами», хотя в обычной беседе это различие в основном не важно.

Диаграмма должна помочь:

Многие из компонентов WebKit переключаемые (показаны серыми).

Например, JavaScript движок WebKit-а, JavaScriptCore, является движком по-умолчанию в WebKit. (Изначально он основан на KJS (от KDE) с дней: когда WebKit начинался как ответвление KHTML. В тоже время, Chromium порт, переключается на V8 движок, и использует уникальные DOM биндинги.

Шрифты и рендеринг текста являются очень большой частью платформы. Существует 2 отдельных пути для текста в WebKit: Быстрый и Сложный. Оба требуют поддержку специфичную для платформы (реализованную на стороне порта), но Быстрый только должен знать как блитировать глифы (которые WebKit кэширует для платформы), когда Сложный полностью переносит рендеринг строк на уровень платформы и просто говорит «нарисуй это, пожалуйста».

«WebKit это как сэндвич. В прочем, в случае Chromium, это больше как тако. Вкусное тако из веб-технологий.
Dmitri Glazkov, Chrome WebKit hacker. Champion of Web Componets, and shadow dom.

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

Chrome (OS X) Safari (OS X) QtWebKit Android Browser Chrome for iOS Rendering Networking Fonts JavaScript

Skia	CoreGraphics	QtGui	Android stack/Skia	CoreGraphics
Chromium network stack	CFNetwork	QtNetwork	Fork of Chromium’s network stack	Chromium stack
CoreText via Skia	CoreText	Qt internals	Android stack	CoreText
V8	JavaScriptCore	JSC (V8 is used elsewhere in Qt)	V8	JavaScriptCore (without JITting) *

* Сноска про Chrome для IOS. Он использует UIWebView, как вы вероятно знаете. В соответствии с возможностями UIWebView, это означает что он может использовать только такой же рендеринг движок, как и Мобильный Safari, JavaScriptCore (а не V8) и однопоточную модель. Тем неменее, некоторый код заимствован из Chromium, такой как подсистема для работы с сетью, синхронизация инфраструктура закладок, omnibox, метрики и отчеты о сбоях (crash reporting). (Также, JavaScript на столько редко является узким местом на мобильных устройствах, что отсутствие JITting компилятора имеет минимальное влияние.)

Я очень часто вижу на сайтах свойства для какого-то конкретного браузера. Например, свойство "-moz-border-left-colors ", указывающее цвет левой рамки у элемента для Firefox . Давайте с Вами разберём, почему этого делать не стоит, а также укажу лишь единственный случай, когда -moz, -ms, -webkit и аналоги использовать можно.

Не буду особо говорить, что все эти свойства не входят в стандарт CSS , а потому не являются валидными. Как следствие, их реализация может быть в любой момент изменена (если так посчитают разработчики браузеров, ведь описания этих свойств в стандарте CSS нет), в итоге, Ваш сайт может сильно испортиться. Так же не буду особо объяснять, почему они портят общий вид кода. Всё это и так понятно.

Лучше разобрать причины того, зачем используют эти свойства. А причины тут две:

Отсутствие кроссбраузерности . Я могу смело сказать, что проблема кроссбраузерности уже в прошлом. Осталась только проблема некачественной вёрстки. Все современные браузеры адекватно всё обрабатывают. Минимальные недоразумения (например, border-radius у input в Opera ) легко решаются альтернативным подходом к задаче, когда все браузеры хорошо отобразят страницу без всяких "хаков ". И данная проблема не является поводом использования "левых" свойств.

Поддержка более старых браузеров . Причём именно "более ", а не просто старых. В старых браузерах этих свойств и в помине не было. Чтобы понять бессмысленность этого, стоит посмотреть статистику браузеров. Где-то 95% аудитории идёт по современным браузерам. Оставшиеся 5% пользуются непонятно чем. Портя код, Вы получите хороший вид ещё от силы на 1% браузеров. Поэтому сейчас лучше либо выводить сообщение о том, что стоит сменить браузер (у jQuery есть плагин jReject , который это делает), либо просто игнорировать. Более того, я сильно сомневаюсь, что среди этих 5% много людей, скорее всего, большинство там - это боты, которые отдают произвольные заголовки о клиенте. И старые боты могут отдавать тот же IE6 . Так же сюда входят те, кто по-прежнему тестирует свои сайты в старых браузерах.

Поэтому используйте CSS3 , там все возможности уже есть, и его смогут увидеть как раз 95% аудитории.

Однако, я пообещал сказать, когда свойства -moz, -ms, -webkit и прочие , можно использовать. Это нужно, если Вы хотите сделать, немного разный дизайн для разных браузеров. Причём именно "немного ", а если нужно полностью менять всё, то проще через JavaScript определить браузер и подключить отдельный файл стилей. Скажу честно, я с такой задачей не сталкивался, но это единственное, что мне пришло в голову, дабы хоть как-то оправдать "лишние " свойства CSS .

В Safari в iOS 11 Apple добавила несколько новых функций, которые должны позволить браузеру лучше отображать различный контент на сайте, а также ускорить его работу. Включить их просто - нужно зайти в Настроки > Safari > Дополнения > Experimental Features:

Разумеется, сразу непонятно, за что отвечает каждый пункт. Разберем их подробнее:

• Constant Properties - не позволяет изменять настройки на веб-страницах с различными настройками. Другими словами, предотвращается изменение веб-сайта или изменение его свойств после его загрузки.
• CSS display: contents - позволяет управлять генерацией поля элемента. Например, с его помощью можно сделать равномерные отступы между различными элементами на сайте без «костылей».
• CSS Spring Animation - разумеется, никакого отношения к весне не имеет, а всего лишь позволяет сделать реалистичную с точки зрения физики анимацию элементов на сайтах.
• Link Preload - нет, к предварительной загрузке ссылок это никакого отношения не имеет, эта функция в основном предназначена для предотвращения очистки предварительно загруженных ресурсов после проведения синтаксического анализа.
• Remove Legacy WebRTC API - в общем-то и так понятно, удаляет старый WebRTC (функция для передачи данных между браузером и приложением по принципу точка-точка. Пример - вы открываете ссылку в приложении VK - она открывается в копии Safari по технологии WebRTC).
• Secure Contexts API - функция, суть которой - убедиться, что данные на устройство были доставлены по безопасному протоколу (HTTPS) и не были перехвачены злоумышленниками.
• Subresourceintegrity - еще одна функция для обеспечения безопасности. Ее суть - владелец ресурса может указать его криптографический хэш, который потом сверяется с хэшем, вычисленным уже после загрузки ресурса на самом устройстве.
• Viewport Fit - позволяет сайтам изменять размер графических элементов под физический размер экрана устройства (то есть в теории если сайт это поддерживает, то не будет залезающих за края экрана его элементов).
• Web Animations - тут все очевидно, включение анимации на сайтах. При отключении может немного поднять производительность.
• WebGPU - позволяет использовать графический процессор для обработки информации на сайтах. Может ускорить работу браузера с насыщенными графикой сайтами, но вызовет повышенный нагрев устройства и уменьшит время автономной работы.
• Async Frame Scrolling - скроллинг, не привязанный к частоте обновления дисплея. Судя по всему он нужен для новых устройств со 120 Гц экраном для избежания лагов на сайтах, где они не могут выдать 120 fps. На старых 60 Гц экранах разницы не заметно.

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

На момент написания этой статьи Safari на iOS была самым сложным браузером. Как уже отмечалось в Главе 7, начиная с версии 2.0, IOS поддерживает большую (и странную) группу CSS-расширений, которые позволяют нам использовать аппаратно-ускоренную анимацию, переходы и даже 3D-эффекты. Некоторые из этих расширений, в зависимости от версии операционной системы, также работают и с Android и webOS браузерами.

WebKit функции

Многие CSS-свойства как параметр воспринимают функции. Эти функции — аппаратно-ускоренные WebKit-расширения.

Перечисленные здесь связанные с градиентом функции в iOS официально не поддерживаются (согласно Safari Reference Library). Тем не менее, они работают с OS 3.0 и более старыми устройствами, где они используют простой фон.

В таблице 9.7 перечислены функции, доступные для iPhone (есть и другие, но они работают только в настольном Safari). Некоторые из этих функций — например, scale и rotate — можно использовать также и в браузерах Android и webOS.

Табл. 9.7. Таблица CSS функций доступных в Safari на iOS Функция Описание

cubic-beizer(p1x, p1y, p2x, p2y)	Определяет кривую Безье для timing function.
matrix(m11, m12, m21, m22, tX, tY)	Определяет трансформационную матрицу из шести значений с двумя смещениями.
matrix3d(m00, m01, m02, m03, m10, m11, m12, m13, m20, m21, m22, m23, m30, m31, m31, m33)	Определяют трансформационную 3D матрицу 4×4.
perspective(depth)	Карты просмотра куба на пирамиде, основание которой находится далеко от зрителя.
rotate(angle)	Определяет 2D вращение вокруг начала координат элемента.
rotate3d(x, y, z, angle)	Определяет 3D вращение с в качестве вектора направления вращения.
rotateX(angle)	Указывает вращение по часовой стрелке вокруг оси Х.
rotateY(angle)	Указывает вращение по часовой стрелке вокруг оси Y.
rotateZ(angle)	Указывает вращение по часовой стрелке вокруг оси Z.
scale(scaleX, )	Выполняет операцию 2D масштабирования.
scale3d(scaleX, scaleY, scaleZ)	Выполняет операцию 3D масштабирования.
scaleX(value)	Масштабирование вдоль оси Х.
scaleY(value)	Масштабирование вдоль оси Y.
scaleZ(value)	Масштабирование вдоль оси Z.
skewX(angle)	Выполнение скошенного преобразования вдоль оси Х.
skewY(angle)	Выполнение скошенного преобразования вдоль оси Y.
translate(deltaX, )	Указывает вектор 2D смещения.
translate3d(deltaX, deltaY, deltaZ)	Указывает вектор 3D смещения.
translateX(value)	Выполняет смещение вокруг оси Х.
translateY(value)	Выполняет смещение вокруг оси Y.
translateZ(value)	Выполняет смещение вокруг оси Z.
from(color)	Определяет начальный цвет в последовательности.
to(color)	Определяет конечный цвет в последовательности.
color-stop(stop_percentage, color)	Указывает промежуточный цвет, который будет использоваться в последовательности в значении stop_percentage.
-webkit-gradient(linear, start_function, end_function, )	Определяет линейный градиент, используя стартовую точку, конечную точку и дополнительные промежуточные точки. Может быть использовано вместо любого изображения в CSS. Доступно начиная с iOS 3.0.
-webkit-gradient(radial, inner_center, inner_radius, outer_center, outer_radius, )	Определяет радиальный градиент с центральной (внутренней) точкой и другой точкой (внешней) с цветами, которые определяются серией функции color-stop. Доступно начиная с iOS 3.0.

CSS функции — это не новая особенность CSS, они доступны в любом браузере. На самомом деле, ты, наверное, уже знаком с некоторыми стандартными функциями — те же url(url_string) или rgba(red, green, blue, alpha) — для определения цвета.

Градиенты

Начиная с iOS 3.0 Safari поддерживает расширения CSS-градиента в качестве функции для тех ситуаций, где раньше мы использовали изображение (например, для фона). Для фона вместо функции url можно использовать функцию -webkit-gradient, с целью определить использование линейного или радиального градиента в качестве фона. Этот метод позволяет нам, используя минимум кода, делать действительно хорошие фоны для заголовков, контейнеров и ячеек. Для браузера Android применяем точно такой же код.

Некоторые примеры определения градиента:

/* Эффект солнца из правого верхнего угла */ body { background: -webkit-gradient(radial, 50% −50, 0, 50% 0, 300, from(#676767), to(black)) black; } body { background: -webkit-gradient(radial, 100% −10, 50, 70% 0, 200, from(yellow), to(white)) #FFC; } /* Простой линейный градиент */ li { background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#369), to(#3FF)) #369; } /* Простой 3D эффект */ h1 { background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#369), to(#369), color-stop(0.5, #58B)); }

Для значений позиций мы можем использовать проценты, абсолютные значения (без пикселей) или константы top, bottom, right и left. Например, в качестве второго параметра функции CSS мы можем использовать top right, а не 0% 0%. На рисунке 9.1 показано, как такие варианты могут выглядеть в браузере.

Рис. 9.1. Используя только CSS можно создать различные эффекты градиента для iPhone, iPod Touch, iPad, и устройств на базе Android.

Mobile Internet Explorer начиная с версии 6.0 поддерживает фильтры и переходы, используя CSS расширение со стилем filter. Можно применять , и другие эффекты.

Эффекты отражения

Эффекты отражения или зеркальные эффекты — одни из наиболее часто используемых эффектов в Web 2.0 проектах. Использоваться эти эффекты могут для любого контента, в том числе и для изображений. Но не забывай, что мы разрабатываем для мобильных устройств с их маленькими экранами и здесь не стоит тратить впустую слишком много пространства.

Отражение оригинального элемента не изменяет макет или размер исходного блока контента элемента. Это часть переполнения контейнера.

Чтобы сделать эффект отражения в Safari на iOS, используй свойство со следующим синтаксисом:

Webkit-box-reflect: direction offset ;

direction может быть above, below, left или right; offset — расстояние (в px или %) от исходного элемента, отражение которого должно появиться; дополнительный — это, как правило, функция градиента, которая будет работать как маска для отражения изображения. Если изображение маски не указано, то будет использоваться обычное зеркало.

У того типа эффекта отражения, который обычно используется на Web 2.0 сайтах следующие атрибуты:

Webkit-box-reflect: below 3px -webkit-gradient(linear, left top, left bottom, from(transparent), color-stop(0.5, transparent), to(white));

Маски изображений

Начиная с iOS 3.0 у нас есть доступ к типичной дизайнерской функции, которая отсутствовала в веб-разработке в течении многих лет: маски изображений. Маски изображений мы можем использовать, чтобы к исходному изображению применить любую правильную или неправильную обрезку или, если используется альфа-маска (или функция градиента) можно для любого изображения сделать классный визуальный эффект (например, fuzzy border). Свойства маски похожи на свойства фона. Для применения маски у нас в распоряжении есть сокращенное свойство ярлыка, и специфические свойства для определения каждого параметра.

Синтаксис shortcut версии с дополнительными параметрами:

Webkit-mask: attachment, clip, origin, image, repeat, composite, box-image;

Конечно, у нас есть отдельный доступ ко всем свойствам ( , и т.д.). Возможностей много, но обычно в качестве значения изображения используются изображение (альфа или нет, PNG или SVG) или функция градиента. Пример:

Переход

Переход (transition) — это автоматическая анимация, которая проявляется при изменении значения CSS свойства. Свойство должно быть определено браузером как способное к анимации (обычно это относится к свойствам позиции и размера). Официального списка свойств, которые могут работать с анимацией нет, но в целом позиция такая: любое свойство с числовыми значениями или значениями цвета может быть анимирован при помощи transition. При этом есть несколько исключений, как, например, дискретное свойство .

Помни, что эти смещения реализуются только силами CSS: для создания анимации мы не используем JavaScript или любой другой подобный метод. Может тебе покажется странным, но это простой и, одновременно, мощный метод.

Фреймворк для работы с transition доступен для браузеров Safari (начиная с iOS 2.0) и Android и, кроме того, на этих устройствах производительность при работе с transition выше.

Для реализации transition мы должны:

Определить свойства transition (продолжительность, задержка, где применяется, функция синхронизации) для элемента (-тов), который(-е) мы хотим анимировать.

Изменить значения свойств элемента (-ов) для анимации с использованием JavaScript или применить классы или вообще удалить их из элемента.

Убедиться, что анимация работает.

Правда, звучит просто? Теперь давай сделаем.

Свойства анимации

Анимацию можно определить при помощи свойства со следующим синтаксисом:

Webkit-transition: property duration timing_function delay [, ...];

Мы также можем использовать специфические свойства, указанные в таблице 9.8.

Табл. 9.8. Таблица свойств transition для WebKit Свойство Описание

	Определяет какое свойство или свойства будут использоваться для анимации. Можно использовать список значений, разделенных запятыми или постоянные значения.
	Определяет продолжительность перехода. Значение может быть 0 (нет анимации) или положительное значение в секундах (s используется в качестве единицы). Если для каждого свойства мы хотим задать разное время — можно использовать список разделенных запятыми значений в том же самом порядке, как и значения для свойства -webkit-transition-property.
	Определяет функцию, которая используется для вычисления промежуточных значений между начальным и конечным значениями свойства. Ты можешь использовать CSS функцию cubic-bezier или любую из следующих констант: ease, linear, ease-in, ease-out, и ease-in-out (чаще всего используется).

При помощи следующего примера кода реализуется анимация появления и исчезновения

Fade Sample #box { width: 200px; height: 200px; background-color: red; -webkit-transition: opacity 2s; } .hide { opacity: 0; } function fade() { var box = document.getElementById("box"); box.className = (box.className=="hide") ? "" : "hide"; box.innerHTML = box.className; } Fading

Такие же переходы мы можем использовать для изменения размера, перемещения, изменения цвета и даже для 3D-перемещений.

Завершение перехода

Завершение перехода, точно так же, как и любое другое событие DOM можно реализовать при помощи addEventListener из JavaScript. Когда ты убедишься, что анимация действительно закончилась, можно инициировать начало следующего перехода или же еще какое-нибудь другое действие. Для этого нам нужно отловить событие webkitTransitionEnd. Сделать это мы можем при помощи следующего кода:

Box.addEventListener("webkitTransitionEnd", function(event) { alert("Finished transition"); });

Анимации

Переход — это отличная вещь и самый простой способ реализовать анимацию на устройствах iPhone и Android. Если же тебе нужен точный контроль над анимацией на уровне ключевого кадра, можно воспользоваться CSS фреймворком для анимации. Если честно, я думаю, что это уже слишком для обработки только посредством CSS, непроцедурного и «не-разметочного» языка. Но работает это прекрасно.

В WebKit анимация делается при помощи свойства и синтаксис будет следующим:

Webkit-animation: name duration timing_function delay iteration_count direction

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

Табл. 9.9. Таблица анимаций для WebKit Свойство Описание

	Определяет имя анимации, которое будет использоваться ключевыми кадрами.
	Определяет продолжительность анимации (в секундах или милисекундах).
	Определяет функцию, которая используется для вычисления промежуточных величин между начальными и конечными значениями определенного свойства. Ты можешь использовать CSS функцию cubic-bezier() или любую из следующих констант: ease, linear, ease-in, ease-out и ease-in-out (используется чаще всего).
	Определяет задержку анимации, которая начинается с момента изменения свойства. Определятся может в секундах или милисекундах; значение по умолчанию — 0. Если используется отрицательная величина — анимация запускается сразу, но какой-то фрагмент анимации будет уже как бы проигран и, соответственно, пропущен.
	Определяет, сколько раз повторится анимация. Значение по умолчанию здесь 1, также в качестве значения может выступать любое целое число, специальная константа infinite или любое действительное число.
	Определяет, в каком направлении будет проигрываться анимация.

Разобравшись с этим перечнем, ты, должно быть, спрашиваешь себя, где именно определяется анимация? Что выступает в качестве объекта анимации? И ответить на эти вопросы помогут расширения WebKit для ключевых кадров.

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

Директива ключевого кадра

Чтобы определить, как будет работать анимация и что именно будет происходить, нужно определить специальное CSS эт-правило, которое называется . Это правило сопровождается именем анимации, которое определяется в -webkit-animation-name.

Внутри директивы ключевого кадра следует указать, сколько нам нужно селекторов или групп анимации в качестве ключевых кадров. Селектор определяется значением в процентах и константами from (эквивалент 0%) и to (эквивалент 100%). В каждом селекторе мы определяем все нужные для определенной точки анимации свойства и значения. При помощи -webkit-transition-timing-function мы можем определить синхронизацию для каждой анимационной группы.

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

Например, при помощи следующего кода мы перемещаем по квадратной траектории:

Fade Sample #box { width: 200px; height: 200px; background-color: red; position: absolute; top: 0px; left: 0px; } .squareAnimation { -webkit-animation-name: squarePath; -webkit-animation-duration: 4s; -webkit-animation-timing-function: linear; -webkit-animation-iteration-count: infinite; } @-webkit-keyframes squarePath { /* В качестве селектора можно использовать 0% или "from" */ from { top: 0px; left: 0px; } 25% { top: 0px; left: 100px; } 50% { top: 100px; left: 100px; } 75% { top: 100px; left: 0px; } /* В качестве селектора можно использовать 100% или "to" */ 100% { top: 0px; left: 0px; } } function start() { // Когда мы применяем свойство -webkit-animation, анимация начинается document.getElementById("box").className = "squareAnimation"; } Движение по квадратной траектории

Если мы указываем атрибуты -webkit-animation в начале элемента, то анимация начнется при загрузке страницы. Лучше определить анимацию как класс и применять этот класс к элементу, когда нужно запустить анимацию.

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

Можно использовать несколько вариантов: одну анимацию, которая изменяет сразу несколько свойств или одновременно применять разные анимации (с разными именами), каждая из которых будет изменять только одно свойство.

События анимации

Как и в случае с переходами смещениями, мы можем отследить события webkitAnimationStart, webkitAnimationIteration, и webkitAnimationEnd. При запуске эти события отправляют в качестве параметра объект WebKitAnimationEvent. Но для получения каждого изменения ключевого кадра события нет.

У объекта события есть специальные свойства animationName и elapsedTime, значения которых задаются в секундах.

Трансформации

Последняя группа WebKit CSS расширений, которую мы рассмотрим — функции преобразования (трансформации). Для генерации визуальных эффектов без использования изображений, canvas или SVG, мы можем применить эти функции к любому элементу. Функции преобразования работают в браузерах Safari, Android и webOS.

Работать с этими функциями очень просто: мы используем CSS свойство , применяя в качестве значения функции CSS, с которыми мы уже встречались ранее в этом разделе, например rotate, scale или translate3d (последняя только Safari).

Упрощенный вариант шаблона CardFlip выглядит так:

Card Flip body { margin: 0px; -webkit-user-select: none; } #container { height: 356px; width: 320px; background-color: rgba(56,108,179, 0.5); /* Отключаем подсветку */ -webkit-tap-highlight-color: rgba(0,0,0,0); /* Придаем некоторую глубину карте */ -webkit-perspective: 600; } .card { position: absolute; height: 300px; width: 200px; left: 60px; top: 28px; -webkit-transform-style: preserve-3d; -webkit-transition-property: -webkit-transform; -webkit-transition-duration: 1.5s; } .card.flipped{ -webkit-transform: rotateY(180deg); } /* Стилизуем карту и скрываем ее "обратную сторону" когда карта перевернута */ .face { position: absolute; height: 300px; width: 200px; -webkit-border-radius: 10px; -webkit-box-shadow: 0px 2px 6px rgba(0, 0, 0, 0.5); -webkit-backface-visibility: hidden; } .face > p { margin-top: 36px; margin-bottom: 0; text-align: center; font-size: 92px; } .front { color: rgb(78,150,249); background-color: rgb(34,65,108); } .back { color: rgb(34,65,108); background-color: rgba(78,150,249,0.5); /* Обеспечиваем переворот "обратной стороны" */ -webkit-transform: rotateY(180deg); } function flip(event) { var element = event.currentTarget; /* Toggle the setting of the classname attribute */ element.className = (element.className == "card") ? "card flipped" : "card"; }

♠ ♦
♣

♦ ♠
♣

Если проанализировать код, то мы увидим два элемента div которые составляют нашу карту — элемент.card. Один div — «передняя» поверхность, другой — «задняя». Обе поверхности расположены на одной и той же самой позиции (как абсолютные элементы) и задняя сторона запускается при повороте вокруг оси Y на 180 градусов.

Когда пользователь кликает по контейнеру card (с выведенной на экран передней или задней стороной), мы при помощи JavaScript применяем (или не применяем) CSS класс flipped, который вращает элемент на 180 градусов вокруг оси Y. И вуаля! Спереди (front) всегда будет отображаться только только одна поверхность, а другая будет автоматически скрыта. И вседа это будет происходить с красивой сглаженной анимацией, которую ты, к сожалению, не сможешь полностью оценить на рисунке 9.3.

Рис. 9.3. С 3D поворотом можно использовать прекрасные 3D эффекты для отображения тыльной строны элемента.