• Превод

За много от нас разработчиците WebKit е черна кутия. Подхвърляме HTML, CSS, JS и куп изображения и WebKit, някак... магически, ни дава уеб страница, която изглежда и работи добре.
Но в действителност как казва моят колега Иля Григорик :

Уеб комплектът не е черна кутия. Това е бяла кутия. И не само бяло, но и отворена кутия.
И така, нека се опитаме да разберем някои неща:

• Какво е WebKit?
• Какво не е WebKit?
• Как се използва WebKit от браузърите на WebKit?
• Защо много WebKit не са еднакви?

Сега, особено след новината, че Opera е преминала към WebKit, сме заобиколени от много WebKit браузъри и е доста трудно да се каже какво ги обединява и къде вървят по свой собствен път. По-долу се надявам да се опитаме да хвърлим малко светлина върху този въпрос. В резултат на това вие ще можете по-добре да идентифицирате разликите в браузъра, да изпращате грешки на правилния инструмент за проследяване и да провеждате по-ефективно разработка на различни браузъри Стандартни компоненти на уеб браузър Нека изброим няколко компонента на съвременните браузъри:

• Парсиране (парсиране на HTML, XML, CSS, Javascript)
• Оформление
• Изобразяване на текст и графики
• Декодиране на изображения
• Взаимодействия с GPU
• Достъп до мрежата
• Хардуерно ускорение

Кои са общи за всички браузъри WebKit? До голяма степен само първите две.

Всеки „порт“ на WebKit внедрява останалите компоненти по различен начин. Нека да разберем какво означава това.

WebKit портове

Има много WebKit „портове“ и аз предоставям Ariya Hidayat, WebKit хакер и техн. Директорът на Sencha има право да говори за това:

Най-популярната асоциация с концепцията за WebKit обикновено е версията на WebKit на Apple, която работи на 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, само че е по-нов
• Мобилно сафари
  - Разработен в частен клон, но по-късно беше открит.
  - Chrome за iOS (използва WebView на Apple; повече за разликата по-късно)
• Chrome (Chromium)
  - Chrome за Android (използва директно „порта“ на Chromium)
  - Chromium е и основата за браузърите: Yandex, Sogou и скоро Opera.
• Android браузър
  - Използва най-новия изходен код на WebKit, наличен към момента на пускане.
• Още повече портове: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE и т.н.

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

Първо, нека да разгледаме общите характеристики, които се използват във всички браузъри WebKit:

Знаете, че е смешно, направих няколко опита да напиша този параграф. И всеки път членовете на екипа на Chrome ме коригираха, както ще видите...

И така, първо, WebKit анализира HTML по същия начин. Е, с изключение на това, че Chromium е единственият порт в момента, който включва поддръжка за нишки за анализ на HTML.

... Добре, но след анализиране на HTML, DOM дървото се конструира по същия начин. Е, всъщност Shadow DOM е активиран само за порта Chromium, което означава, че конструкцията на DOM варира. Също така за персонализирани елементи.

…Добре, WebKit създава обекти на прозорци и документи по един и същи начин за всички. Вярно е, въпреки че свойствата и конструкциите, които предоставят, може да зависят от използването на флагове за функции.

... CSS анализът е същият. Изяждането на вашия CSS и превръщането му в CSSOM е доста стандартно. Да, въпреки че Chrome поддържа само префикси -webkit-, когато Apple и други браузъри поддържат наследените префикси -khtml- и -apple-.

...Оформление...позициониране? Това е като хляб и масло. Навсякъде е едно и също, нали? Ами вече! Подпикселното оформление и богатата аритметика на оформлението са част от WebKit, но се различават от порт до порт.

Супер.

Така че, това е трудно.

Сега нека се опитаме да обобщим какво общо има в света на WebKit...

Какво е общо за всеки порт на WebKit.

• DOM, прозорец, документ
  Повече или по-малко
• CSSOM
• CSS анализ, свойство/стойност
  разлики в префиксите на производителя
• Разбор на HTML и изграждане на DOM
  Същото е, ако забравим за уеб компонентите.
• Оформление и позициониране
  Flexbox, Floats, блок форматиращ контекст... всичко е обичайно
• Инструменти за потребителски интерфейс и инструменти за разработчици, като Chrome DevTools, известен още като WebKit инспектор.
  Въпреки че от миналия април Safari използва свой собствен Safari Inspector, който не е WebKit и е със затворен код.
• Функции като contenteditable, pushState, File API, повечето SVG, математика за трансформация на CSS, Web Audio API, localStorage
  Въпреки че изпълнението може да варира. Всеки порт може да използва своя собствена система за съхранение за localStorage и може да използва различен аудио API за Web Audio API.

Става малко объркващо, така че нека се опитаме да разгледаме някои от разликите. Сега какво не е обичайно за портовете на WebKit:

• Всичко свързано с GPU
  - 3D трансформация
  - WebGL
  - Видео декодиране
• Изобразяване на 2D на екран
  - Anti-aliasing технологии
  - Изобразяване на SVG и CSS градиенти
• Изобразяване на текст и пренасяне
• Мрежови технологии (SPDY, предварително изобразяване, WebSocket транспорт)
• JavaScript двигател
  - Двигателят на JavaScriptCore е в хранилището на WebKit. Но има обвързвания в WebKit както за него, така и за V8.
• Изобразяване на елементи на формуляр
• Поведение на видео и аудио тагове и поддръжка на кодеци
• Декодиране на изображения
• Навигация назад/напред
  - Част pushState()
• SSL функции като строга транспортна сигурност и публични ключове

Нека да разгледаме един от тях: 2D графиките зависят от порта, ние използваме напълно различни библиотеки, за да изобразим на екрана:

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

Сега става технически... време да станем педантични. Дори казаното по-горе не е съвсем вярно. Това всъщност е WebCore, общ компонент. WebCore е библиотека за оформление, изобразяване и DOM за HTML и SVG и е основно това, за което хората си мислят, когато казват WebKit. Всъщност "WebKit" е технически слой от свързвания между WebCore и "портове", въпреки че в нормален разговор това разграничение е до голяма степен маловажно.

Диаграмата трябва да помогне:

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

Например JavaScript машината на WebKit, JavaScriptCore, е машината по подразбиране в WebKit. Първоначално е базиран на KJS (от KDE) от дните, когато WebKit стартира като разклонение на KHTML. В същото време портът на Chromium превключва към двигателя V8 и използва уникални DOM свързвания.

Шрифтовете и изобразяването на текст са много голяма част от платформата. В WebKit има 2 отделни пътя за текст: бърз и твърд. И двете изискват специфична за платформата поддръжка (имплементирана от страната на порта), но Fast трябва само да знае как да бликва глифове (които WebKit кешира за платформата), докато Complex премества изобразяването на низове изцяло на ниво платформа и просто казва „нарисувай това, Моля те."

„WebKit е като сандвич. Иначе в случая с Chromium е по-скоро тако. Вкусно тако от уеб технологиите.
Дмитрий Глазков, хакер на Chrome WebKit. Шампион на уеб компоненти и shadow dom.

Сега нека разширим обхвата и да разгледаме няколко порта и няколко подсистеми. По-долу са петте WebKit порта, обърнете внимание как наборът от инструменти за всеки е различен въпреки общите компоненти:

Chrome (OS X) Safari (OS X) QtWebKit Android браузър Chrome за iOSИзобразяване Работа в мрежа Шрифтове JavaScript

скиа	CoreGraphics	QtGui	Android стек/Skia	CoreGraphics
Мрежов стек на Chromium	CFNetwork	QtNetwork	Разклонение на мрежовия стек на Chromium	Chromium стек
CoreText чрез Skia	CoreText	Вътрешни елементи на Qt	Android стек	CoreText
V8	JavaScriptCore	JSC (V8 се използва другаде в Qt)	V8	JavaScriptCore (без JITting) *

* Бележка под линия за Chrome за iOS. Той използва UIWebView, както вероятно знаете. Според възможностите на UIWebView това означава, че той може да използва само същия двигател за изобразяване като Mobile Safari, JavaScriptCore (не V8) и еднонишков модел. Някои кодове обаче са заимствани от Chromium, като мрежовата подсистема, инфраструктурата за синхронизиране на отметки, полето за всичко, показателите и докладването за сривове. (Освен това JavaScript толкова рядко е тясно място на мобилни устройства, че липсата на JITting компилатор има минимално въздействие.)

Добре, откъде идваме? И така, всички WebKit вече са напълно различни. Уплашен съм.

Не си заслужава! Обхватът на WebKit на тестовете "layoutTest" е огромен. (28 000 теста при последно преброяване) и не само за съществуващи функции, но и за всички намерени регресии. Всъщност винаги, когато изучавате нови или „тайни“ DOM/CSS/HTML-5 функции, тестовите пакети „layoutTest“ обикновено имат отлична минимална демонстрация.

В допълнение, W3C полага усилия за стандартизиране на тестовия пакет. Това означава, че можем да очакваме както портовете на WebKit, така и всички други браузъри да бъдат тествани с едни и същи тестови пакети, което ще ни доведе до по-малко странности и по-оперативно съвместима мрежа. На всички, които положиха усилия, като присъстваха на събитието Test The Web Forward...благодарим!

Opera току-що се премести в WebKit. Какво ще излезе от това? Робърт Найман и Роб Хоукс вече засегнаха тази тема, но ще добавя, че една от важните части на съобщението беше, че Opera преминава към Chromium. Това означава, че WebGL, Canvas, HTML5 формуляри, внедряване на 2D графики, всички тези неща сега ще бъдат същите в 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. Добави тагове

В тази статия ще разгледаме три браузъра, базирани на популярния двигател 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. “Yandex.Browser” е наскоро пуснат браузър, базиран на Chromium от руската компания Yandex. В този продукт разработчиците просто добавиха услуги на Yandex към панела за бързи връзки. Режимът “Turbo”, който може да се намери в Opera, също беше добавен и подобрен. Като цяло не е лош браузър, насочен към потребителите на Yandex.

Android и iPhone - войни на браузъри

Част 1. WebKit идва на помощ

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

Серия съдържание:

Общо платформите iPhone и Android имат повече от 100 000 приложения, достъпни за изтегляне от различни източници. Това се отнася за „родни“ приложения, т.е. приложения, които са разработени и асемблирани с помощта на подходящия SDK и след това инсталирани на мобилно устройство. Такива „родни“ приложения ви позволяват ефективно да прилагате техническите възможности на мобилно устройство, включително поддръжка за безжични мрежи, Bluetooth и съхранение на данни, функции на акселерометър или компас и други технологични чудеса и иновации, които правят мобилните устройства толкова привлекателни за потребителите. Популярността на „родните“ приложения за платформите iPhone и Android е изключително висока, но освен това мобилните устройства предоставят широки възможности за разработване на уеб приложения.Мобилните технологии отдавна са напуснали детството, а с тях мобилният интернет достигна определена зрялост.

Тази статия е първата от поредица от две части за разработване на браузърни приложения за iPhone и Android. Целта на тази поредица е да запознае читателя с основните принципи за създаване на собствени мобилни уеб приложения. Възможностите на мобилните приложения не се ограничават до стартиране на уебсайт на мобилно устройство. Ще разгледаме основните технологии и подходи, използвани при разработването на мобилни приложения, които позволяват да се обособи този раздел от разработката на софтуер в отделна самостоятелна дисциплина.

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

• Проблеми с инсталирането: Инсталирането на уеб приложения е безпроблемно – просто ги инсталирайте или копирайте на сървъра и кажете на клиентите си какъв URL адрес да посочат в браузъра.
• Проблеми с мащабирането: Уеб приложенията лесно се мащабират до набор от сървъри във високопроизводителен център за данни и готови инструменти за управление на уеб сайтове се използват за обслужване на приложенията.
• Проблеми с архивирането и възстановяването на данни: Уеб приложенията използват централизирано съхранение на данни, като по този начин опростяват задачата за възстановяване в случай на повреда.
• Съображения за потребителски интерфейс: Комбинацията от HTML, каскадни стилови таблици (CSS), JavaScript и графики ви позволява да създадете богат потребителски интерфейс, който е значително по-добър по функционалност и външен вид от интерфейсите, разработени с помощта на собствени SDK. Последните, като правило, не са в състояние да осигурят пълноценен ефект на присъствие за игрални приложения и не гарантират необходимата функционалност за интерактивни информационни терминали.
• Лесна употреба: Повечето приложения изискват елементи на потребителския интерфейс, които са прости и лесни за използване, което ви позволява лесно да извършвате ежедневни операции.

Най-привлекателният аспект на модела за разпространение на интернет приложения е, че той позволява на софтуера да се превърне в един вид абонаментна услуга, взаимноизгоден начин за доставка на софтуер. "Как?" - ти питаш. Нека разгледаме този въпрос по-подробно.

Уеб базираният модел на разпространение на софтуер позволява на клиентите да изпробват продукта преди покупка с минимален риск и на минимална цена. Ако клиентът хареса пробната версия, тогава всичко, което се изисква от него за по-нататъшно използване на софтуерния продукт, е да плати за покупката с кредитна карта (или чрез PayPal). Освен това, моделът софтуер като услуга (SaaS) предоставя на потребителите удобен и рентабилен начин за закупуване на софтуер без значителни предварителни разходи, като гарантира възвръщаемост на инвестицията в рамките на първия месец на използване, а не в далечно бъдеще.

Факт е, че практически нямаше поддръжка за уеб браузъри на мобилни устройства. Ситуацията се промени драматично с появата на технология, наречена WebKit, която уверено зае своето място в областта на мобилните устройства благодарение на iPhone.

Само за няколко години платформата iPhone се превърна в уеб клиент номер едно в света. Защо? Тъй като WebKit, съчетан с надеждна интернет връзка, направи възможно използването на уеб услуги на мобилни устройства много по-ефективно, отколкото на всеки друг съвременен браузър. Други играчи на пазара на мобилни устройства също забелязаха новата технология и целият пазар вече може да бъде разделен на компании, които използват WebKit, компании, които ще използват WebKit, и компании, които си измислят извинения да не използват WebKit .

И така, какво е WebKit?

WebKit и HTML5

WebKit е браузърен двигател, използван за поддържане както на браузъра Mobile Safari на платформата iPhone, така и на браузъра на платформата Android. Разбира се, WebKit се използва и в други мобилни устройства, но за целите на тази статия ще се ограничим до разглеждането на платформите iPhone и Android.

WebKit е проект с отворен код, който произхожда от разработката на K Desktop Environment (KDE). Съвременните уеб приложения за мобилни устройства дължат раждането си на проекта WebKit. Технологичните и дизайнерски характеристики на мобилното устройство със сигурност играят важна роля, но мобилните потребители се интересуват преди всичко от съдържанието. Ако едно мобилно устройство предоставя достъп само до малка част от интернет съдържанието, тогава е малко вероятно то да стигне до топ списъка на най-популярните устройства.

Повечето от нас предпочитат да живеят пълноценен живот: ако отворим уеб сайт на лаптоп, докато седим у дома, очакваме да видим същото съдържание, когато отворим този сайт, докато седим във влака. Съдържанието е основният проблем на мобилните приложения. Без значение къде се намираме или какво правим, имаме нужда от достъп до данните, които ни интересуват. Технологията WebKit предоставя богато съдържание на платформите iPhone и Android.

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

HTML5 е набор от предварителни технически спецификации, които дефинират базирани на браузър технологии като съхранение на данни от страна на клиента с поддръжка на SQL, премествания, трансформации и т.н. Спецификацията на HTML5 все още е в процес на работа, но след като основните принципи бъдат ясно дефинирани и внедрени в браузърите на повечето платформи, скромното начало на уеб приложенията ще остане в миналото. Разработката на уеб приложения ще заеме значителен сегмент от индустрията за разработка на софтуер и говорим не само за приложения за настолни браузъри, но и за мобилни браузъри. Мобилните приложения ще се превърнат от страничен продукт в основен продукт на пазара на уеб приложения.

Характеристики на дизайна на разработката на мобилни уеб приложения

Ако решите да овладеете технологиите за уеб разработка, тогава имате много ограничен избор от инструменти на ваше разположение. На първо място, приложението може да бъде създадено директно на сървъра като файл, съдържащ HTML, CSS и JavaScript код. В този случай HTML съдържанието може да бъде предоставено под формата на статични HTML файлове или може да бъде генерирано динамично чрез използването на различни технологии, работещи от страната на сървъра, например като PHP, ASP.NET, Java Servlets и др. Във всеки случай, от гледна точка. За целите на тази статия всичко се свежда до HTML код и най-важният момент за нас тук е, че технологията WebKit позволява на браузърите да изобразяват HTML на мобилни устройства.

За да стартира уеб приложение на мобилно устройство (iPhone или Android), потребителят трябва да стартира браузър и да въведе URL адреса на съответната услуга, например: http://yourcompanyname.com/applicationurl.

В същото време диапазонът от предлагани мобилни уеб приложения е доста широк: от стандартен уеб сайт до мобилно уеб приложение, разработено специално за конкретна мобилна платформа.

Показване на стандартни сайтове

Механизмът WebKit, комбиниран с интуитивния и удобен потребителски интерфейс на платформите iPhone и Android, ви позволява да преглеждате почти всеки уеб сайт на вашето мобилно устройство. Уеб страниците се показват доста правилно, за разлика от предишното поколение мобилни браузъри, които произволно прехвърлят фрагменти от съдържание или изобщо не ги показват. Когато страниците се зареждат в браузър с активиран WebKit, съдържанието на страницата има тенденция да се мащабира. В този случай мащабът е избран така, че цялата страница да се побере на екрана, макар и в силно намалена, често нечетима форма, както е показано на Фигура 1. Страницата обаче може да се превърта, уголемява, мести, осигурявайки удобен достъп до всички елементи на съдържанието. По подразбиране браузърът използва прозорец с ширина 980 пиксела.

Въпреки че пълното показване на уеб страница в прозорец на браузър е значително подобрение в сравнение с браузърите от предишно поколение, възможностите на съвременните мобилни технологии не се ограничават до това.

Уеб страници, проектирани с мисъл за мобилни устройства

Ако искате вашата уеб страница да бъде достъпна не само за обикновени уеб потребители, но и за мобилни потребители, има още няколко опции, които да разгледате за оптимизиране на мобилни уеб приложения.

Въпреки че WebKit позволява правилно показване на уеб страница на екрана на мобилно устройство, има определени разлики между базирани на мишка устройства, като лаптопи или настолни компютри, и сензорни устройства, като iPhone или смартфони с Android. Сензорните устройства се различават по физическите размери на зоната за „щракване“, липсата на функция за задържане на курсора върху всеки елемент и различна последователност от събития. По този начин, ако искате да създадете уебсайт, който е удобен както за редовни, така и за мобилни потребители, трябва да имате предвид следните характеристики на мобилните устройства:

• Браузърите на iPhone и Android са в състояние да изобразят цяла уеб страница в сравнително четима форма – качеството на изобразяване на тези браузъри е много по-високо от това на стандартните мобилни браузъри – така че не бързайте да опростявате дизайна на вашия сайт.
• Размерът на върха на пръстите е значително по-голям от размера на показалеца на мишката. Вземете предвид този фактор, когато разработвате елементи за навигация на сайта. Не поставяйте връзките твърде близо една до друга, в противен случай потребителят няма да може да кликне върху една връзка, без да удари следващата.
• Елементите на курсора няма да работят на мобилни устройства. Потребителят просто не може да „насочи“ пръста си върху който и да е елемент по същия начин като курсора на мишката.
• Събитията, дефинирани чрез натискане и задържане на бутона на мишката, плъзгане на мишката и т.н., се изпълняват по различен начин на сензорни екрани. Някои от тези събития може да работят и на мобилни устройства, но като цяло не трябва да очаквате мобилният браузър и браузърът за настолен компютър да изпълняват една и съща последователност от действия.

Подробно обсъждане на тези аспекти можете да намерите в статията " iPhone в действие“ (виж раздела). В нашата статия ще се ограничим до разглеждане на предимствата на WebKit, а не на неговите недостатъци.

Нека да разгледаме най-очевидния проблем, с който се сблъскват потребителите на iPhone или Android при достъп до уебсайтове: ограничен размер на екрана. Всъщност размерът на екрана на едно модерно мобилно устройство е 320x480 или 480x320, при условие че потребителят предпочита да гледа уеб съдържание в пейзажна конфигурация. Както можете да видите от Фигура 1, WebKit може да показва правилно уеб страница, предназначена за стандартни настолни компютри. Въпреки това, когато мащабирате уеб страница, текстът може да стане твърде малък за четене, така че потребителят трябва да превърта, панорамира и мащабира, преди да може да прочете текста. Как да се справим с това ограничение?

Най-лесният начин да създадете страница, която се показва еднакво добре в прозорец на мобилен браузър и прозорец на браузър на настолен компютър, е да използвате специален мета таг прозорец за изглед.

Мета тагът е HTML таг, поставен в главата на HTML документ. Най-простият пример за използване на етикета viewport изглежда така: . Чрез добавяне на този мета таг към HTML страница, нейното показване в прозореца на мобилния браузър се мащабира по най-оптималния начин (вижте Фигура 2). Браузърите, които не поддържат viewport, просто игнорират този етикет.

В някои случаи е полезно предварително да се дефинират параметрите за мащабиране на прозореца, както е показано на фигура 3.

За да дефинирате конкретни опции за мащабиране, посочете точната стойност на атрибута content на прозореца за изглед: мета таг. Чрез промяна на стойността на параметъра за начален мащаб изображението може да бъде намалено или увеличено. За платформи iPhone и Android е по-добре да използвате стойности от 1.0 до 1.3. Мета тагът на прозореца за изглед също поддържа минимално и максимално увеличение, което ви позволява да ограничите възможността на потребителя да променя мащаба на страницата, докато се зарежда.

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

Опитът показва, че в допълнение към разликите в дизайна, които съществуват между различните мобилни устройства с Android, самият софтуер на Android се опитва да зададе настройките на заредената уеб страница в зависимост от свойствата на браузъра на мобилното устройство. В допълнение към стабилността, платформата Android има постоянно променящ се набор от функции и възможности. Настройките на вашето конкретно устройство с Android вероятно ще се различават от вашата среда за разработка в зависимост от версията на SDK и производителя на устройството. Фигура 4 показва екрана за настройка на браузъра във V1.6 Android Emulator. Настройките на екрана предоставят на потребителя възможност да определи нивото на мащабиране на изображението на екрана (далеч, близо, средно) или да избере режим на автоматично мащабиране на страницата.

В света на мобилните устройства най-постоянното нещо е промяната, така че трябва да се вземе предвид развитието и обновяването на пазара на мобилен софтуер. Например настройките на браузъра Sprint Hero включват набор от опции, които са напълно различни от стандартните настройки, използвани при зареждане на уеб страница. Браузърът Hero е изграден на платформата Android V1.5, използвайки редица модификации, направени от HTC. За щастие, използването на мета тага viewport ще игнорира специфичните настройки на Hero.

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

Създаден за мобилни устройства

Нека да преминем към разглеждане на характеристиките на дизайна на уеб страница, предназначена за мобилна аудитория. Като конкретен пример разгледайте страницата за регистрация за имейл услугата на Google GMail.

Ето как изглежда страницата в прозорец на браузър на настолен компютър:

В прозореца на настолен браузър информационното съдържание се показва от лявата страна, а самият прозорец за регистрация е в десния панел. В прозорец на мобилен браузър същата страница има напълно различен външен вид.

Страницата, показана на фигура 6, определено е предназначена за мобилни потребители. Екранът показва само тези елементи на страницата, от които потребителят се нуждае за по-нататъшна работа - не е необходимо допълнително превъртане, панорамиране или мащабиране.

Сега нека да разгледаме прозореца за изглед на имейл на мобилната версия на Gmail. Тъй като пространството на екрана, достъпно за приложението, е много ограничено, програмата за преглед на съобщения разполага с допълнителни бутони и елементи за навигация. В този случай показаните навигационни елементи се припокриват с прозореца за преглед на съобщенията. Също така, не използвайте твърде много рамки или превъртащи div, ако можете да го избегнете. Мобилната версия на Gmail решава този проблем, като използва изскачащо меню, което се появява веднага щом потребителят приключи с превъртането на страницата. Изскачащото меню съдържа 3 бутона: Архивиране, Изтриване и Още. Когато щракнете върху бутона Още, се появяват допълнителни елементи от менюто (вижте Фигура 7).

Това наистина е приложение, предназначено за мобилни устройства.

Трябва да се има предвид, че не искаме умишлено да обедняваме дизайна и да намаляваме опита на мобилните потребители, които са разработили многофункционални браузъри за платформите iPhone и Android. От тази гледна точка е полезно да обърнете внимание на елемента, показан в долната част на страницата на Gmail (вижте Фигура 8):

Ако потребителят предпочита подобрената функционалност на настолната версия, дайте му възможност да изтегли подходящата версия на страницата.

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

Съдържание, специфично за платформата

Следващата стъпка е да се разработи съдържание, специфично за конкретна мобилна платформа. Това дефинира формата и интерфейса на страницата, така че получената страница да изглежда като родно приложение за конкретна платформа, а не като стандартен публичен уеб сайт. Какво имаме предвид под „родно“ приложение?

Преди да се задълбочим в дискусията за това как да направим уеб приложение възможно най-подобно на естествено приложение за конкретна платформа, нека оставим настрана общите характеристики на браузърите iPhone и Android и накратко да се докоснем до визуалните разлики, които съществуват между тези платформи .

Приложенията за iPhone имат свой специфичен външен вид и интерфейс. Покажете на някого екранна снимка на iPhone и, освен ако не е паднал от Луната онзи ден, почти сигурно веднага ще каже, че това е iPhone. Покажете на същия човек екранна снимка на мобилно устройство с Android и отговорът вече няма да е толкова ясен. Каква е причината? Има няколко възможни обяснения. Първо, iPhone се появи на пазара много по-рано от устройствата, базирани на Android, и успя да спечели огромен брой фенове. Помислете за хората, които се редят на опашка, за да платят най-скъпите пари за ограничените функции на V1 iPhone. Независимо дали харесвате iPhone или не, този продукт на Apple в момента е лидер на пазара. Какво ще кажете за Android?

Платформата Android е сравнително нов продукт и в много аспекти действа като антипод на iPhone, тъй като е предназначена предимно за отворената общност. Платформата Android се използва в голямо разнообразие от устройства (телефони и други домакински уреди). За по-лесно обсъждане в тази статия ще се ограничим до използването на Android в мобилни телефони.

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

Сравнете разнообразието от Android системи с последователния външен вид и усещане на iPhone. IPhone е особено ценна собственост на Apple. Външният вид на приложенията за iPhone може леко да се промени с течение на времето, но тези незначителни промени е малко вероятно да се сравнят с различните версии на системите Android, които са многобройни дори сега, когато платформата е в ранните си дни.

И така, какво трябва да се направи, за да се доближат външният вид и интерфейсът на приложението възможно най-близо до „родните“ програми?

Ако бяхме изправени пред това предизвикателство преди появата на Web 2.0, това наистина щеше да бъде сериозен проблем. Ранните опити за поддръжка на множество клиентски браузъри (мобилни и настолни) разчитаха на няколко подхода, например:

• Разработка на напълно паралелни сайтове
• Генериране на динамично съдържание в зависимост от параметъра userAgent
• Използване на прокси сървъри, които могат да трансформират съдържание в зависимост от всяко конкретно устройство. Подобна технология беше успешно използвана от RIM за предоставяне на достъп до имейл от мобилното устройство на клиента.

Такива подходи могат да бъдат напълно приемливи в случаите, когато разработката се извършва от големи, добре финансирани екипи. Какво трябва да направи останалият свят? Не всеки разполага със значителни финансови ресурси, висококвалифицирани специалисти и неограничено време за реализиране на подобни стратегии. Освен това, както вече отбелязахме, мобилният интернет от предишното поколение браузъри не може да се нарече удобен или популярен за използване, така че във всеки случай не трябва да се спирате на остарели методи и подходи.

За щастие няма да се налага да правим това. В ерата на WebKit и CSS разликите във външния вид и интерфейса на различните мобилни устройства могат да бъдат преодолени чрез използване на стилови таблици и медийни заявки, които позволяват използването на различни стилове в зависимост от конкретния тип устройство. Технологията за медийни заявки ви позволява да получите информация за клиента. Традиционно браузърът изпраща на сървъра стойност на userAgent, която позволява на сървъра да идентифицира конкретния браузър и да определи съдържанието, което трябва да бъде изпратено на клиента. Използвайки медийна заявка, браузърът избира стила на страницата въз основа на нейните възможности. Следващият пример демонстрира избор на стилов лист, предназначен за смартфони: . И тази заявка дефинира лист със стилове на работния плот: .

Internet Explorer V6

По време на писането на тази статия Internet Explorer V6 заема приблизително 20-30% от общия пазар на браузъри, но обсъждането на възможностите на IE V6 е извън обхвата на тази статия.

Повече информация за медийните заявки можете да намерите в черновата на спецификацията (вижте раздела).

Нека да разгледаме пример за използване на медийни заявки за разработване на приложение, което показва състоянието на мрежовите сървъри.

Програма за наблюдение на мрежата

Целта на това приложение е да наблюдава работата на няколко сървъра. Независимите разработчици на софтуер често трябва да поддържат множество приложения на множество сървъри. Ако сте се занимавали с разработка на софтуер за известно време, вероятно вече сте се сблъсквали с различни видове сървъри и различни видове приложения. Всичко това означава, че е напълно възможно да не можете да използвате нито един инструмент за проследяване на производителността на всички необходими приложения. В този случай има смисъл да използвате приложение за наблюдение на мобилна мрежа (netmon). Приложението предоставя цялата необходима функционалност, като същевременно остава гъвкаво и лесно за достъп от мобилно устройство.

Приложението netmon включва списък със сървъри, които трябва да бъдат наблюдавани. Ключовите показатели за ефективност (KPI) се събират за всеки сървър. Ключовите показатели за ефективност са основен инструмент, който MBA студентите използват от години, за да оценят текущото състояние на бизнеса. От гледна точка на хостинг на уеб приложения, следните индикатори могат да се използват като KPI:

• Брой транзакции през изминалия период от време
  • Поръчки
  • Заявки за каталози
  • Имейли
  • Брой показвания на страници
• Изминало време от последната транзакция
  • Поръчка
  • Електронен обмен на данни
  • Съобщения от бизнес партньор
  • Качване на файл от доставчика чрез FTP
• Налична ли е базата данни?
• Последна дата на архивиране
• Средна сума на поръчката (в долари)
• Количество свободно дисково пространство
• Ширина на честотната лента за последния час, ден, месец

Горните показатели и други подобни оперативни параметри ви позволяват да оцените изправността на конкретна система или приложение. Например по време на празничния сезон разглеждаме броя на поръчките, направени на някои от нашите сайтове. Ако данните не показват стабилно увеличение на броя на поръчките на всеки час, ние извършваме по-подробен анализ на ситуацията.

Тъй като всяко приложение има свои собствени изисквания и ресурси, netmon трябва да бъде достатъчно гъвкав, за да посрещне нуждите на всяко приложение. За да осигурим това ниво на гъвкавост, започваме с дефиниране на най-общата структура на данните, за да отчетем параметрите на състоянието на всяка система. В част 2 ще разгледаме по-подробно откъде идват тези данни и как се актуализират. Засега ще се ограничим до следната информация:

• Име на сайта
• URL адрес на сайта (начална страница)
• URL за получаване на актуализации
• Статус: Добре или не
• Кратко резюме: Описание на състоянието на сървъра, което или ще бъде ОК, или ще съдържа текстов низ, указващ най-сериозния проблем за този сървър
• Елементи: Това е набор от двойки име/стойност, които ще трябва да предадем текущите стойности на KPI за съответния сайт.

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

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

Съвременните уеб страници трябва да бъдат създадени в декларативна форма, която определя организационната структура и съдържанието на страницата. Позиционирането и форматирането на страницата се извършва с помощта на каскадни стилови таблици (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,функция (индекс, стойност) ( $("#mainContent").append(netmon.render(индекс,стойност)); )); $(".serverentry").click (функция() ( $(this ).find(".serveritems").toggle();)); $(".serveritems").hide(); ) ) catch (e) ( alert(e); ) ) My Network Resources My Сървъри My User Agent

Бърз преглед на предложения HTML код разкрива следните основни характеристики:

• Кодът използва два външни JavaScript файла: един jQuery библиотечен файл и един помощен файл за нашето приложение.
• Кодът използва мета тага на прозореца за изглед, за да мащабира показаното съдържание.
• Основният стилов лист се дефинира от файла netmon.css.
• Параметърът userAgent се използва за дефиниране на спомагателния стилов лист. В зависимост от стойността си стиловият лист ще бъде зареден за iPhone, Android или настолен браузър.
• Процесът на зареждане на страницата използва jQuery и помощна функция, дефинирана във файла netmon.js, за показване на данните.
• Кодът на главната страница използва няколко div тагове.
• И накрая, кодът съдържа връзка към страница, която показва низа userAgent. Тази връзка няма нищо общо с работата на приложението и се използва само за демонстрационни цели.

Преди да навлезем в детайлите на таблиците със стилове и файла netmon.js, които всъщност дефинират основната операция на приложението, нека да разгледаме нашето приложение в текущото му състояние. Моля, обърнете внимание отново, че използваме три различни листа със стилове: по един за всяка от трите поддържани платформи. За да направи процеса на разработка на приложението по-визуален, всяка таблица определя свой собствен цвят на фона. На фигура 9 нашата страница е отворена в браузъра Safari за настолен компютър и има син фон.

Фигура 11 показва външния вид на приложението в прозореца на браузъра на iPhone (цветът на фона е зелен).

Основният стилов лист, съхраняван във файла netmon.js, е показан в листинг 2.

Списък 2. Основен текст на листа със стилове (цвят: #888888; семейство шрифтове: Helvetica; размер на шрифта:14px; марж: 0px; подложка: 0;) .details (марж: 0px; подложка: 0px; цвят на фона: бял; граница: плътна; ширина на границата: 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 (цвят: #000000;) .BAD (цвят: #ff0000;) .odd (фоново изображение: -webkit-градиент(линеен, ляво горе, дясно долу ,from(#ccc) ,to(#999)); ) .even (background-image: -webkit-gradient(linear, ляво горе, дясно долу,from(#999) ,to(#ccc)); ) . serverentry a ( float: дясно; цвят: #ffffff; ) .serveritems ( цвят: #000; ) #header h1 ( марж: 0; padding: 0; text-align: center; color: #000; )

Използването на различен стилов лист за всяка платформа ви позволява да постигнете следните задачи:

Променете цветовата схема на страницата. Това позволява, първо, да се демонстрира ясно ролята на листа със стилове и второ, да се покаже колко лесно е да изберете желания лист със стилове в зависимост от стойността на параметъра userAgent.

Задайте различни размери на шрифта за мобилни и настолни платформи.

Проверете съответните функции на WebKit. Това би имало значителна разлика, ако приложението работи в браузър без поддръжка на WebKit, като например Firefox.

Листинг 3 показва кода за файла iphone.css.

Листинг 3. Файл iphone.css тяло ( цвят на фона: #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 (размер на шрифта: 2em;) .summary(размер на шрифта: 1,5em;) .serverentry a (font- размер: 1.5em; )

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

Списък 4. Файл Netmon.js var netmon = ( инициализиране: функция () (), ресурси: [ ( име: "msiservices.com", homeurl: "http://msiservices.com", pingurl: "http:// msiservices.com/netmon.php", състояние: "ОК", резюме: "ОК", елементи: [ (име: "DiskSpace", стойност: "22.13 GB"), (име: "База данни е нагоре?", стойност: "Да") ] ), (име: "сървър 2", домашен адрес: "http://someurl", pingurl: "http://someurl/netmon.jsp", състояние: "ОК", резюме: "ОК" , елементи: [ (име: "DiskSpace", стойност: "100,8 GB"), (име: "Базата данни е нагоре?", стойност: "Да") ] ), // допълнителни записи, изрязани за краткост ], изобразяване: функция( index,itm) ( try ( var ret = "; ret += ""; ret += "" + itm.name + " Показване
"; 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 "Грешка при рендиране на елемент [" + itm.name + "] " + e + ""; ) ) ) ;

Ако лентата на състоянието на някой сървър не е наред, тогава съответният запис на сървъра се показва в червено, както може да се види от дефиницията на класа в CSS файла. Освен това, ако проверката на състоянието на сървъра разкрие някакви проблеми (статусът не е ОК), допълнително се показва кратко описание на проблема. Фигури 9-11 показват, че Сървър 4 изчерпва свободното дисково пространство. Когато щракнете върху линията на този сървър, на екрана ще се покаже подробно съобщение за проблема (вижте Фигура 12).

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

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

Заключение

Тази статия представя принципите за разработване на уеб приложения за iPhone и Android с помощта на технологията WebKit. В Част 2 ще разширим възможностите на нашето приложение, като добавим функция за актуализиране на данни с помощта на Ajax извиквания.

Какво е Webkit?

Въз основа на двигателя са създадени браузъри като Midori, Maxthon, Konqueror, Arora и други. Но не само малко известни браузъри избират Webkit. Представяме на вашето внимание два „гиганта“ в света на браузърите - Safari от Apple и Chrome от Google (тези браузъри). Малко вероятно е някой да спори, че тези браузъри имат малка функционалност и ниска скорост на работа. Освен в десктоп браузърите, Webkit навлезе и в мобилните платформи, което още веднъж потвърждава предимствата на безплатния софтуер. Същият Safari Mobile, разработен за iOS, успешно използва този двигател. Стандартните браузъри за платформите Android, HP WebOS и Samsung Bada също са изградени на Webkit.

Това е двигател, на базата на който са разработени много браузъри. Той е доста бърз и лек и перфектно се справя с всички стандарти, приети в уеб средата.

С всичко това този двигател е свободно разпространяван софтуер. Това са компонентите, които му позволиха да стане много популярен сред разработчиците на браузъри.

История на Webkit

Може би сте се чудили: „Защо безплатен софтуер?“ Нека да разгледаме историята на неговото създаване. Родителят на Webkit също е свободно разпространяван двигател, който се разработва за графичната среда на фамилия Unix системи. Този двигател се нарича KDE. През 1998 г. екип от програмисти, работещи върху KDE, реши да пусне свой собствен браузър за тази графична среда.

Такъв браузър беше пуснат и кръстен от създателите на Konqueror. Двигателят в основата на този браузър се нарича KHTML. 3 години по-късно, през 2001 г., Apple решава да създаде свой собствен браузър, за който използва KHTML източници, както и KJS JavaScript двигателя. В резултат на този синтез беше създаден проектът Webkit под „крилото“ на Apple. На негова основа в началото на 2003 г. беше пусната първата версия на браузъра от Apple - .

Друго „чудовище“ в света на информационните технологии, Google, също взе Webkit като основа при създаването на свой собствен браузър. И това е още един плюс към достойнствата на двигателя. Тъй като Google реши, че той е правилният за тях, това говори много. Самите разработчици заявиха, че е решено да не се преоткрива колелото, тъй като Webkit напълно отговаря на високите изисквания на компанията за поддържане на стандарти за уеб среда, както и доста висока скорост на работа.

Днес двигателят продължава активно да се развива и има големи перспективи. Това не е чудно, защото и Apple, и Google работят за подобряването му. И това е в допълнение към официалните разработчици на двигателя. Те от своя страна заявиха, че са в процес на работа, резултатът от която ще бъде пускането на второто поколение на техния продукт, чиято отличителна черта ще бъде вградената архитектура на отделни процеси (днес това е прилага се само в).

Популярна машина за обработка на уеб страници, която управлява Apple Safari и Google Chrome. Е безплатен софтуер. Характеризира се с висока скорост и отлична поддръжка на уеб стандарти.

WebKit е машината за уеб обработка, която захранва много браузъри. Сред тях са две от „Големите пет“ - както и по-малко популярни - Maxthon 3, Rekonq, Epiphany, RockMelt. Konqueror, Midori и Arora. Разработчиците на мобилни браузъри също използват този двигател в своите продукти, по-специално Safari Mobile за операционната система iOS и браузърите, вградени в мобилните платформи Android, Samsung Bada и HP WebOS.

Това разнообразие от браузъри се дължи на факта, че WebKit е безплатен софтуер и може да се използва от всеки, който се придържа към редица определени условия.

WebKit произхожда от безплатен двигател за обработка на уеб страници, разработен в рамките на популярната графична среда за операционни системи от семейството *nix - KDE. През 1998 г. разработчиците на KDE решават да създадат браузър специално за тази графична среда.

Браузърът се нарича Konqueror, а двигателят му е KHTML. През 2001 г. Apple започна да мисли за създаването на свой собствен браузър и взе изходния код на KHTML и двигателя за обработка на код KJS JavaScript, за да работи в рамките на новия проект. Проектът беше наречен WebKit.

През януари 2003 г. Apple представи първата версия на браузъра Safari, който използва двигателя WebKit. С течение на времето разработчиците на Konqueror включиха възможността да използват WebKit заедно с KHTML. Въпреки факта, че KHTML вече е зад WebKit по отношение на възможностите, разработчиците продължават да работят върху него.

Google също реши да използва WebKit двигателя при създаването на своя браузър. Като причина за този избор представители на компанията посочиха по-добрата поддръжка на уеб стандартите и високата скорост. Освен това Google планира да използва труда на разработчиците на Apple. Като се има предвид, че програмисти от две корпорации и много независими разработчици в момента работят върху двигателя, можете да сте сигурни, че WebKit ще стане още по-добър.