Что такое WebKit и как это связано с CSS? … и ночная сборка WebKit. Что это

  • Перевод

Для многих из нас, разработчиков, 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 варьируется. Тоже для пользовательских элементов (custom elements).
  • … Хорошо, 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 компилятора имеет минимальное влияние.)

    Хорошо, так к чему же мы пришли?И так, все WebKit полностью различные теперь. Я напуган.

    Не стоит! Покрытие WebKit тестами «layoutTest» огромное. (28,000 тестов по последним подсчетам), и не только для существующих функций, но также для всех найденных регрессий. На самом деле, когда бы вы не изучали новые или «тайные» функции DOM/CSS/HTML-5, наборы тестов «layoutTest» обычно имеют отличную минимальную демонстрацию.

    В дополнении, W3C предпринимает усилия для стандартизации набора тестов . Это означает, что мы можем ожидать что и WebKit порты, и все другие браузеры будут тестироваться одинаковыми наборами тестов, что приведет нас к уменьшению quirks and a more interoperable web. Для всех тех, кто приложил свои усилия, посетив событие Test The Web Forward … спасибо вам!

    Опера только что переехала на WebKit. Что из этого получится? Роберт Найман и Роб Хоукс уже коснулись этой темы , но я добавлю что, одной из важной частью анонса было то, что Opera переходит на Chromium . Это означает, что WebGL, Canvas, HTML5 формы, имплементация 2D graphics, все эти вещи будут одинаковыми на Chrome и Opera теперь. Одинаковое API, и низкоуровневая реализация. Так как Opera основана на Chromium, вы можете ощущать, что вы сокращаете свою работу, по проверке совместимости на Opera и Chrome.
    Я также должны обратить внимание, что все Opera браузеры будут переведены на Chromium. То есть, Opera для Windows, Mac, Linux и Opera Mobile (полноценный мобильный браузер). Даже Opera Mini, тонкий клиент, будет переключена с текущей рендеринг-фермы основанной на Presto, на другую, основанную на Chromium.… и ночная сборка WebKit. Что это? Это WebKit, работающий на том же коде что и Safari (хотя некоторые внутренние библиотеки были изменены). В основном Apple руководит им, так что поведение и набор функций соответствует тому, что вы сможете найти в Safari. Во многих случаях Apple ведет себя консервативно, когда речь заходит о включении функций, которые другие порты реализуют или с которыми ведут эксперементы. В любом случае, если использовать аналогии, думайте что… ночная сборка WebKit для Safari, это как Chromium для Chrome.
  • веб-браузеры
  • веб-разработка
    • Добавить метки

    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. Когда идет речь о выборе веб-обозревателя, пользователи, как правило, смотрят в сторону самых известных программ: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. При этом многие забывают или не знают о том, что тот же Firefox, Chrome и, с недавних пор, Opera созданы на базе проектов с открытым исходным кодом, а значит, эти программы можно модифицировать.

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

    Распространяется бесплатно, имеет русский интерфейс, работает на Windows, Android , Mac, iOS. Этот браузер десять лет назад был известен под названием MyIE2 и являлся дополнением к Internet Explorer, но с тех пор многое поменялось и теперь программа использует по умолчанию движок Webkit.

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

    Интерфейс у Maxthon Cloud Browser хоть и выполнен в стиле Chrome, но имеет гораздо больше возможностей. На боковой панели отображаются значки для доступа к расширениям. Удобно, что одним щелчком мыши можно отключить или включить все установленные дополнения, а скачать новые можно с специального сайта.

    Распространяется бесплатно, имеет русский интерфейс, работает на Windows. Продукт компании Comodo, которая более известна как разработчик защитного ПО. Comodo Dragon является более не разработкой, а сборкой, так как по функциональности он мало чем отличается от Chrome.

    Отличий от оригинального браузера получилось не много, и все они касаются вопросов безопасности. Первое ключевое отличие от Google Chrome это действительно режим инкогнито, Comodo Dragon не использует уникальный идентификатор пользователя и HTTP-REFERRER что не позволяет отслеживать пользователя в сети.

    Второе отличие заключается в ключевом виде деятельности Comodo - безопасности пользователя. Предполагает наличие собственных безопасных DNS-серверов для передачи трафика. Причём по желанию пользователя через них может идти трафик не только Dragon, но и всех остальных приложений. Безопасные DNS-сервера автоматически блокируют доступ к сайтам, которые были отмечены как ненадежные в собственной сети определения веб-угроз Comodo.

    Распространяется бесплатно, имеет русский интерфейс, работает на Windows. «Яндекс.Браузер» - вышедший совсем недавно браузер основанный на Chromium от российской компании Яндекс. В этом продукте разработчики просто добавили сервисы «Яндекса» на панель быстрых ссылок. Также был добавлен и доработан режим «Турбо», который можно встретить в Opera. В целом получился не плохой браузер, нацеленный на пользователей Яндекс.

    Браузерный движок – это специальная программа, которая работает с веб-страницами. Он обрабатывает загруженную из интернета HTML-страницу, и преобразует ее код в привычное для пользователей представление. Движки интернет-браузеров используются в самих браузерах, а также в почтовых клиентах. Далеко не каждый веб-обозреватель создан на своей собственной уникальной платформе. Многие из них используют популярные и проверенные временем решения. В данной статье рассматривается, какие существуют платформы для создания браузеров, и чем они отличаются друг от друга.

    Использование движков (Rendering engine) для создания обозревателей имеет множество преимуществ:

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

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

    Яркий пример – движок Trident от компании Microsoft. Он один используется в большом множестве приложений данной корпорации. Развивается основа – развиваются и производные проекты.

    Каждое решением имеет свои плюсы и минусы. Например, многие пользователи замечают, что Mozilla Firefox гораздо лучше работает с большим количеством открытых вкладок, чем конкуренты. Это достижение платформы, на основе которой создан обозреватель.

    Trident

    Когда пользователь устанавливает новую операционную систему Windows, первый веб-обозреватель, с которым он сталкивается – это Internet Explorer. Поэтому его движок рассмотрен в обзоре первым.

    Trident, или MSHTML – довольно старый программный компонент, разработанный корпорацией Microsoft для своих нужд. Проект непрерывно развивается с 1997 года. Используется в веб-обозревателе от Майкрософт – Internet Explorer, почтовом клиенте Outlook, Проводнике Виндовс (программа для работы с файлами) и множестве других приложений данного разработчика.

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

    С выходом Windows 10 платформа Trident эволюционировала в EdgeHTML.Разработчики взяли устаревший неудачный движок за основу и создали новую, отвечающий всем требованиям современным пользователей. Судя по проведенным бенчмаркам (программный тест производительности и скорости работы), Microsoft Edge (обозреватель, созданный на основе EdgeHTML) догнал и даже перегнал популярные программы, использованные для создания браузеров Google Chrome и Mozilla Firefox.

    Gecko

    Gecko – движок, используемый в популярном интернет-обозревателе Мозилла Фаерфокс и множестве других программ. Исходный код программы находится в свободном доступе, то есть каждый желающий может абсолютно бесплатно создать на основе Gecko свой собственный браузер или почтовый клиент.

    Другое преимущество Геко – кроссплатформенность. Он работает на подавляющем большинстве современных операционных систем: как для персональных компьютеров, так и для мобильных устройств (в отличие от Internet Explorer, который функционирует только на ОС Windows).

    Gecko поддерживает все современные стандарты и технологии, используемые при создании вебсайтов. Является одной из двух наиболее популярных браузерных платформ. Поддерживает подключение плагинов. Бенчмарки и личный опыт пользователей показывают, что браузеры на данном движке потребляют меньше всего ресурсов персонального компьютера и стабильно работают с большим количеством вкладок (например, несколько сотен).

    На основе Геко создан популярный интернет-обозреватель Mozilla Firefox, почтовый клиент Thunderbird, планировщик задач Sunbird, а также анонимный веб-браузер с встроенной поддержкой VPN-технологий Tor.

    KHTML

    Не особо известная платформа, используемая для создания Konqueror — файлового менеджера среды KDE. Для пользователей, не знакомых с операционными системами семейства Linux, интересен тем, что на основе данного проекта создан самый популярный движок в мире, речь о котором пойдет дальше.

    WebKit

    Этот движок разработан всемирно известной корпорацией Apple на основе вышеупомянутого решения – KHTML. Выпущенный в 2001 году, этот проект получил колоссальное развитие и стал одним из самых используемых в мире.

    На основе WebKit был создан веб-обозреватель Safari, используемый по умолчанию в iOS-устройствах и лидер по известности среди браузеров – Google Chrome. Подавляющее число современных программ для обработки содержимого веб-страниц имеют в своей основе ВебКит. Кроме того, он используется в популярном приложении Steam, предназначенном для цифровой дистрибуции компьютерных игр от компании Valve.

    Аналогично с Gecko, WebKit является кроссплатформенным и отлично запускается на всех популярных платформах. Показывает высокую стабильность и производительность работы. Ввиду огромной известности, под данное решение разрабатывается подавляющее большинство расширений. Также используется в популярных мобильных платформах, таких как Android и iOS. Является свободным движком, то есть может быть бесплатно использован любым человеком для создания собственных приложений.

    В 2013 году от WebKit отделилась новая ветка, принадлежащая корпорации Google – Blink. Этот проект лег в основу Chrome 28-й версии (и всех последующих), а также его собрата с открытым исходным кодом – Chromium. Chromium использован для создания популярного в России Yandex Browser. Начиная с 15-й версии на Blink перешел и браузер Opera.

    Presto

    Созданный в 2003 году, браузерный движок Presto использовался в качестве основы для Opera. Развивался на протяжении 10-ти лет. В 2013 разработчики Оперы решили отказаться от использования Presto в пользу более мощного и популярного Blink от Google. В данный момент развития проекта остановлено.

    Статья была полезна?

    Совсем недавно я встречал вопросы с тегом "webkit". Такие вопросы обычно связаны с веб-вопросами, связанными с CSS, jQuery, макетами, проблемами совместимости кросс-броузеров и т.д.

    Итак, что это за "webkit" и как он относится к CSS? Я также заметил множество свойств -webkit-... в исходном коде для различных веб-сайтов. Связаны ли эти два?

    Update

    Итак, из ответов до сих пор... WebKit - это механизм отображения веб-браузера HTML/CSS для Safari/Chrome. Существуют ли такие механизмы для IE/Opera/Firefox и каковы различия, плюсы и минусы использования одного над другим? Могу ли я использовать функции WebKit в Firefox, например?

    Окончательный вопрос... Поддерживается ли WebKit IE?

    Обновление 2

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

    Итак, есть ли какой-то проект или движение для стандартного механизма рендеринга, который будут использовать ВСЕ браузеры? Будет ли HTML5 устранять проблемы совместимости между браузерами?

    Loading...Loading...