Webkit браузеры что это
WebKit is an open source Web content engine for browsers and other applications.
We value real-world web compatibility, standards compliance, stability, performance, battery life, security, privacy, portability, usability, and relative ease of understanding and modifying the code (hackability).
Project Goals
Web Content Engine
The project’s primary focus is content deployed on the World Wide Web, using standards-based technologies such as HTML, CSS, JavaScript and DOM. However, we also want to make it possible to embed WebKit in other applications, and to use it as a general-purpose display and interaction engine.
Open Source
WebKit should remain freely usable for both open source and proprietary applications. To that end, we use BSD-style and LGPL licenses. Specifically, we aim for licensing compatible with LGPL 2.1+. We do not currently plan to move to LGPL 3. In addition, we strive to create a courteous, welcoming environment that feels approachable to newcomers. WebKit maintains a public IRC chat room and a public mailing list where the ideas of contributors both new and old are heard and discussed with equal weight.
Compatibility
For users browsing the web, compatibility with their existing sites is essential. We strive to maintain and improve compatibility with existing web content, sometimes even at the expense of standards. We use regression testing to maintain our compatibility gains.
Standards Compliance
WebKit aims for compliance with relevant web standards, and support for new standards In addition to improving compliance, we participate in the web standards community to bring new technologies into standards, and to make sure new standards are practical to implement in our engine. We use regression testing to maintain our standards compliance gains.
Stability
The main WebKit code base should always maintain a high degree of stability. This means that crashes, hangs and regressions should be dealt with promptly, rather than letting them pile up.
Performance
Maintaining and improving speed and memory use is an important goal. We never consider performance “good enough”, but strive to constantly improve. As web content becomes richer and more complex, and as web browsers run on more limited devices, performance gains continue to have value even if normal browsing seems fast enough. We consider speed, memory use, responsiveness and frame rate to be important aspects of performance.
Battery Life
In addition to traditional performance metrics, we aim to minimize power consumption to maximize browsing battery life for portable devices.
Security
Protecting users from security violations is critical. We fix security issues promptly to protect users and maintain their trust.
Privacy
We believe privacy is a human right. WebKit code won’t track the user or otherwise violate their privacy. And we will strive to prevent websites and other parties from doing so.
Portability
The WebKit project seeks to address a variety of needs. We want to make it reasonable to port WebKit to a variety of desktop, mobile, embedded and other platforms. We will provide the infrastructure to do this with tight platform integration, reusing native platform services where appropriate and providing friendly embedding APIs.
Usability
To the extent that WebKit features affect the user experience, we want them to work in accordance with good human interface design principles, and to mesh well with platform-native HI conventions. Furthermore, we strive to integrate with platform accessibility features to allow access for all users, including those with disabilities.
Hackability
To make rapid progress possible, we try to keep the code relatively easy to understand, even though web technologies are often complex. We try to use straightforward algorithms and data structures when possible, we try to write clear, maintainable code, and we continue to improve names and code structure to aid understanding. When tricky “rocket science” code is truly needed to solve some problem, we try to keep it bottled up behind clean interfaces. In addition, we make heavy use of automated regression tests as a safety net, to allow aggressive changes with less risk of regressions.
What WebKit is Not
There are a few points that arise occasionally which we consider out of scope for the project.
WebKit is an engine, not a browser.
We do not plan to develop or host a full-featured web browser based on WebKit. Others are welcome to do so, of course.
WebKit is an engineering project not a science project.
For new features to be adopted into WebKit, we strongly prefer for the technology or at least the use case for it to be proven.
WebKit is not a bundle of maximally general and reusable code.
We build some general-purpose parts, but only to the degree needed to be a good web content engine.
WebKit is not the solution to every problem.
We focus on web content, not complete solutions to every imaginable technology need.
Доброго времени суток, Хабр! В очередной раз читая комментарии, наткнулся на мысль о том, что далеко не все понимают, как обстоит ситуация с браузерами для Windows на данный момент. От чего хотелось бы провести небольшой обзор текущего положения. Ну, и сразу к делу!
Браузерные движки
Браузер — программа не простая, это целый набор компонентов, взаимодействующих между собой. Для краткого обзора потребуются всего два компонента из множества — движок отрисовки содержимого и движок исполнения JavaScript.
Существующие движки отрисовки содержимого
- Trident (так же известный как MSHTML) — движок, ранее разрабатываемый Microsoft для браузера Internet Explorer;
- EdgeHTML — преемник Trident, ранее разрабатываемый Microsoft для браузера Legacy Edge (ранее просто Edge);
- WebKit — движок, разрабатываемый Apple для браузера Safari;
- Blink — преемник WebKit, разрабатываемый Google для браузера Chrome;
- Gecko — движок, разрабатываемый Mozilla для браузера Firefox;
- Servo — исследовательский проект Mozilla, некоторые технологии со временем перетекают в Gecko.
Существующие движки исполнения JavaScript
- Chakra JScript — движок JS, ранее разрабатываемый Microsoft для браузера Internet Explorer;
- Chakra JavaScript — преемник Chakra JScript, ранее разрабатываемый Microsoft для браузера Legacy Edge;
- Nitro — движок JS, разрабатываемый Apple для браузера Safari;
- V8 — движок JS, разрабатываемый Google для браузера Chrome;
- SpiderMonkey — движок JS, разрабатываемый Mozilla для браузера Firefox.
И тут вроде бы очевидно, какие браузеры какие движки используют, но Microsoft внёс не много путаницы в понимание данной темы, поэтому рассмотрим браузеры отдельно.
Браузеры
Chromium
Chromium — это open-source ответвление браузера Chrome. Браузеры на основе Chromium составляют большую часть из всех используемых браузеров на планете Земля.
Обычно, браузеры на базе Chromium между собой отличаются только визуально, ведь у всех под капотом движки Blink и V8, хотя, какие-то компании пытаются привнести больше функционала в браузер, чем имеется.
Это в конечном итоге встанет разработчикам браузеров боком, потому что в любой момент главный разработчик Chromium — Google может вставить палки в колёса разработчикам модификаций.
Всех браузеров на основе Chromium подсчитать одному человеку вряд ли под силу, поэтому приведу список только тех, что помню:
- Chrome — в представлении не нуждается, браузер от Google;
- Chr Edge — новый браузер от Microsoft со старым названием. Поговаривают, отличается большей производительностью от Chrome. С некоторых пор предустанавливается в систему;
- Brave — браузер с повышенной безопасностью настолько, что приватный режим использует Tor;
- Яндекс.Браузер, Opera, Vivaldi, тысячи их.
Firefox
Firefox использует движки Gecko и SpiderMonkey для своей работы. Имеет небольшое количество базирующихся на Firefox браузеров, но самый известный — Tor Browser. Является единственным рубежом до полного перехода интернета на браузеры на основе Chromium.
Internet Explorer
Это любимая всеми утилита для скачивания браузеров. Как и Chrome — не нуждается в представлении. До 11 версии использовал движки Trident и Chakra JScript. В 11 версии, за исключением режима совместимости, стал использовать движки Trident и Chakra JavaScript. Этот браузер ещё долго будет использоваться для всякого рода систем видеонаблюдения, поскольку имеет, почему-то, популярный в узких кругах API для расширений. В Windows 8 и Windows 8.1 имел особую модификацию движка Trident на базе WinRT для Metro режима.
(Legacy) Edge
Браузер, начавший своё существование с кодовым названием Project Spartan, являлся новым браузером от Microsoft в 2015 году, использующим движки EdgeHTML и Chakra JavaScript. Конечной целью проекта была полная совместимость с сайтами, отлично работающими в Chrome. В итоге — получилось нечто своеобразное, но, очевидно, не выжившее под давлением Google.
Safari
Safari? А нет его больше, этого вашего Safari, кончился.
Нецелевое использование браузеров
Вроде бы браузеры — законченный продукт, ни добавить ни отнять. Однако, они используются в разного рода других приложениях. Причины в следующем (в порядке убывания значимости):
- П р ограммистов на JS нечем занять;
- На JS+HTML новичкам проще программировать;
- Кроссплатформенность;
- Требуется возможность отображать веб-страницы.
Приведу примеры подобного использования:
Chromium
Нынешние браузеры настолько сложны, что одному человеку создать собственный браузер не под силу (либо это должен быть гений). Они по сложности сравнимы с операционными системами! А, постойте, вот и первый кандидат на нецелевое использование — Chrome OS. Да, весь пользовательский интерфейс — просто модифицированный Chromium.
Однако, помимо этого, в виде CEF (Chromium Embedded Framework), Chromium используется в:
Internet Explorer
Почти любое Win32 приложение, умеющее отображать WEB-страницы и при этом в распакованном виде занимающее меньше 60 мегабайт использует внутри Internet Explorer. Кстати, это касается не только маленьких по размеру приложений, например, Visual Studio использует Internet Explorer для отображения WEB-страниц, когда это требуется в работе IDE. Ещё существуют HTA приложения — древний предшественник CEF на базе Internet Explorer. И ведь до сих пор работает.
(Legacy) Edge
Новым приложениям — новые движки! Любое UWP приложение, использующее внутри отображение WEB-страниц работает на базе Edge. Не то, чтобы Microsoft запрещали использовать что-то другое, но никто просто и не старался. Так же, пока что, в предварительных сборках Windows новая клавиатура с GIF панелью тоже использует Edge для рендеринга. В будущих версиях, полагаю, перейдут на Chr Edge.
Производительность
Постойте, столько приложений, а что там с производительностью? Лично я — не специалист в оценке производительности, но хочу поделится с вами некоторыми занимательными фактами.
Prefetcher
В Windows есть такая штука — Prefetcher. Она занимается подгрузкой программ в ОЗУ при старте ОС и на протяжении её работы. Штука эта достаточно умная, и она анализирует чаще всего запускаемые программы, чтобы в дальнейшем их подгружать.
Как это связано с браузерами? Идея в том, что это может смазать первый пользовательский опыт с другим браузером, например, пользуясь постоянно Chrome, имеете установленную версию Firefox. При запуске Firefox будет вести себя крайне медленно — медленнее, чем ваш основной браузер. Всё потому что он запылился в глазах Prefetcher. В конечном итоге всё будет работать быстро, но первое впечатление после долгого неиспользования будет ужасным. Особенно это касается пользователей с HDD или малым количеством ОЗУ.
Области распределённой памяти
Да, звучит не очень. Но суть, в данном случае, простая — если одна единица исполняемого кода требуется к исполнению больше одного раза, будь то exe или dll , то в память она загрузится лишь один раз. Поясню: если два различных приложения в ходе своей работы загрузят одну и ту же библиотеку, например, edgehtml.dll , то этот файл будет загружен в ОЗУ компьютера на самом деле только один раз, хотя, казалось бы, потребуется два или больше раз. Таким образом ОС экономит нам оперативную память.
Движки нормального человека
К чему это я? А вот дело в том, что в отличии от других браузеров, Internet Explorer и (Legacy) Edge предустановлены в систему, а их движки хранятся в папке System32 . Это, вкупе с API для разработки приложений, означает, что все приложения в системе, использующие данные движки будут загружать их в память только однажды. И этот принцип распространяется на все приложения.
У людей часто возникают проблемы с UWP приложениями, а точнее — с их скоростью запуска. Всё дело в WinRT — огромном наборе библиотек, при помощи которых UWP приложение взаимодействует с ОС. Если не использовать UWP приложения часто, то этот набор библиотек не будет прогружен в памяти полностью, и придётся ожидать окончания этого процесса перед использованием приложения. Но забавный факт — используя два и более UWP приложения время их старта и общая производительность резко увеличиваются и часто даже превосходят Win32 программы. Исключением из этого является приложение "Фотографии" — тут отдельная история, покрытая туманом.
Движки курильщика
А вот с приложениями (в том числе и браузерами) на основе Chromium это так не работает. Каждое приложение комплектует с собой собственную сборку библиотеки CEF, что, кроме раздувания размера приложения, не позволяет операционной системе иметь только одну копию dll в ОЗУ. Итого это сильно замедляет производительность при использовании множества подобных приложений. Помимо того, сам размер CEF довольно удручающий.
Microsoft Store
У многих возникает вопрос — почему в Microsoft Store нет ни одного браузера(не считая нескольких кривых поделок на EdgeHTML)? Ответ, на самом деле, прост — все браузеры, включая Chr Edge имеют собственную систему обновления, что прямо запрещено правилами Microsoft Store. В остальном никто никого не ограничивает.
Как удалить новый Microsoft Edge
Это не очень сложно. Для начала требуется найти папку с Microsoft Edge, она расположена по пути:
C:\Program Files (x86)\Microsoft\Edge\Application
Далее заходим в любую версию Edge и переходим в папку Installer . Полный путь может выглядеть следующим образом:
C:\Program Files (x86)\Microsoft\Edge\Application\83.0.478.58\Installer
Далее необходимо открыть командную строку от имени администратора в данной папке и выполнить следующую команду:
setup.exe --uninstall --system-level --verbose-logging --force-uninstall
Готово! Через несколько секунд этот браузер исчезнет из системы. Но при следующем же обновлении он появится снова, будте бдительны.
Заключение
Пожалуй, эта статья получилась даже больше, чем я предполагал. В любом случае, какой браузер использовать — выбор ваш, но, зато, вы теперь знаете чуточку больше. Всем спасибо.
Администраторы Хабра, пожалуйста, почините HabraStorage в Legacy Edge! Совсем не дело.
Одновременно с анонсом нового достижения — 300 миллионов пользователей Opera! — мы также анонсируем, что все наши новые продукты будут использовать движок WebKit для рендеринга и V8 для обработки JavaScript. Они будут основаны на опенсорсном браузере Chromium и его компонентах. Конечно же, браузер — это гораздо больше, чем просто движок, поэтому все эти перемены для обычных пользователей произойдут где-то далеко под капотом. Такие пользователи заметят только улучшившуюся совместимость с сайтами, особенно мобильными, большинство из которых были как следует протестированы только в браузерах на WebKit. Первым новым продуктом будет браузер для смартфонов, который мы покажем на Всемирном мобильном конгрессе (MWC) в Барселоне в конце февраля. Opera для десктопа и остальные продукты совершат переход позднее.
Если лень читать дальше
- Это не потребует изменений в привычном вам процессе разработки.
- Расширения, разработанные для предыдущих версий Opera, продолжат работать.
- Opera будет участвовать в разработке проектов Webkit и Chromium.
- Мы продолжим работу над развитием стандартов на благо веба.
Что это значит для веб-разработчиков?
Если коротко, это не должно как-то повлиять на вашу ежедневную работу. Продолжайте писать код по стандартам, а не для отдельных движков; тестируйте в разных браузерах: Opera, Firefox, Chrome, Safari и Internet Explorer; используйте все необходимые браузерные префиксы вместе с беспрефиксными свойствами в вашем CSS- и JavaScript-коде. Тем не менее, кое о чём стоит помнить:
- В Chromium, как и в Opera, есть встроенная поддержка медиакодеков WebM, Ogg Theora и Ogg Vorbis, но нет встроенной поддержки форматов H.264 и MP3 (однако, если эти кодеки доступны в ОС устройства, то всё заработает). Правильный способ определения поддержки — это метод canPlayType из HTML5. Самый простой способ добиться того, что каждый браузер получит нужный кодек — это подготовить видео в двух форматах WebM и H.264 и добавить в код два элемента или использовать canPlayType для проверки (см. подробности в статье Introduction to HTML5 video).
- Объект window.opera не будет существовать в будущих версиях Opera. Мы по-прежнему настойчиво рекомендуем разработчикам не использовать определение браузеров, а вместо этого определять поддерживаемые возможности: либо с помощью сторонних решений, вроде Modernizr, либо просто вручную.
Что это значит для разработчиков расширений?
Расширения получили огромную популярность среди пользователей Opera и безусловно продолжат работать в новой версии браузера. Мы разработали иструмент для конвертации знакомых вам OEX-расширений в формат, который сможет работать в новой версии Opera для десктопа, основанной на движке Chromium (видели бы вы этот огромный скрипт на Питоне!) Помимо этого, мы напишем руководства по конвертации и документацию по новым расширениям и конечно ответим на ваши вопросы. В общем, мы с удовольствием продолжим поддерживать разработчиков и пользователей расширений и постараемся сделать процесс перехода как можно более гладким.
Почему Opera меняет движок?
Когда мы только начинали в 1995 году, нам пришлось создать собственный движок для того, чтобы конкурировать с браузерами Netscape и Internet Explorer и двигать веб-стандарты и весь интернет вперёд. Когда мы начинали разработку спецификации HTML5, мы хотели написать такой документ, который улучшит общую совместимость браузеров.
Проект WebKit сегодня имеет такую поддержку стандартов, о которой мы могли только мечтать, когда начинали работу над нашим браузером. И вместо того, чтобы тратить все свои силы на повторение того, что уже реализовано в WebKit, мы можем сфокусироваться на изобретении чего-то нового, чтобы сделать лучший браузер. Изобретённые в Opera вкладки, экспресс-панель, сжатие данных, ускоряющее загрузку страниц, были в дальнейшем успешно подхвачены и внедрены многими производителями браузеров. Отправляя патчи прямо в проект WebKit, мы сможем улучшить поддержку стандартов не только в Opera, но и во многих других браузерах.
Мы безусловно продолжим нашу работу по улучшению веба с помощью стандартизации технологий. У нас есть 17-летний опыт в создании браузера и новых стандартов. Начатые в Opera стандарты, вроде HTML5, HTML5-видео, Media Queries являются жизненно важной частью современного веба.
Мы продолжим развитие веб-технологий и будем участвовать в проектах WebKit и Chromium. У нас есть большой опыт создания кроссплатформенных продуктов. В наших внутренних сборках мы экспериментируем с добавлением новых стандартов и отсутствующих технологий, которые поддерживает Presto, например, полная поддержка мультиколонок в CSS. В последние недели мы связывались с проектом WebKit и его контрибьюторами, чтобы обсудить наши намерения по участию в развитии проекта.
Поэтому в этом году мы отправляем сразу две валентинки: одну, как водится, открытому и совместимому вебу, а вторую проекту WebKit.
P.S. Первый патч, отправленный в WebKit этим утром, исправляет поддержку мультиколонок в CSS.
Для многих из нас, разработчиков, WebKit — черный ящик. Мы бросаем в него HTML, CSS, JS и кучу изображений, и WebKit, как-то… магически, выдает нам веб-страницу, которая выглядит и работает хорошо.
Но на самом деле, как говорит мой коллега Илья Григорик:
- Что такое WebKit?
- Чем WebKit не является?
- Как WebKit используется WebKit-браузерами?
- Почему многие WebKit не одинаковые?
Стандартные компоненты веб-браузера
Давайте перечислим несколько компонентов современных браузеров:
- Парсинг (Разбор HTML, XML, CSS, Javascript)
- Макет (Layout)
- Рендеринг текста и графики
- Декодировка изображений
- Взаимодействия с GPU
- Доступ к сети
- Аппаратное ускорение
Остальные компоненты каждый 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, используя 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, 360, Sogou, и скоро, Opera. - Android браузер
— Использует последний исходный код WebKit, доступный на момент релиза.
: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, etc
Что общее во всех 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, но отличается от порта к порту.
- Супер.
Так что, это сложно.
Точно также как Flickr и Github прячут реализованные функции за специальными флагами, WebKit делает тоже самое. Это позволяет портам включать/выключать любую функциональность на стадии компиляции с помощью WebKit compile-time Feature Flags. Функции также могут быть включены в режиме работы, с помощью параметров в командной строке (для Chromium) или конфигураций, таких как about:flags.
Теперь, давайте попробуем подвести итог, что общего в мире 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
Или если вдаваться в подробности, недавно добавленная функция: 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 | Skia | CoreGraphics | QtGui | Android stack/Skia | CoreGraphics |
Networking | Chromium network stack | CFNetwork | QtNetwork | Fork of Chromium’s network stack | Chromium stack |
Fonts | CoreText via Skia | CoreText | Qt internals | Android stack | CoreText |
JavaScript | 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. Что это?
Это mac порт WebKit, работающий на том же коде что и Safari (хотя некоторые внутренние библиотеки были изменены). В основном Apple руководит им, так что поведение и набор функций соответствует тому, что вы сможете найти в Safari. Во многих случаях Apple ведет себя консервативно, когда речь заходит о включении функций, которые другие порты реализуют или с которыми ведут эксперементы. В любом случае, если использовать аналогии, думайте что… ночная сборка WebKit для Safari, это как Chromium для Chrome.
Chrome Canary также использует последние исходные коды WebKit, однодневной давности или около того.
Бра́узер (англ. web browser, «веб-браузер» ) — прикладное программное обеспечение для просмотра веб-страниц, содержания веб-документов, компьютерных файлов и их каталогов; управления веб-приложениями; а также для решения других задач. [Источник 1]
Современные браузеры предоставляют к просмотру пользователю не только изображения и текст в соответствие с HTML кодом на полученной странице. Функциональность зависит от конкретного браузера. В наши дни веб обозреватели обладают очень большими возможностями: закладки, интеграция поиска в адресную строку, всевозможные расширения и т.д. [Источник 2]
Содержание
История
Первый браузер, который имел графический интерфейс, т.е. не только просто текст на черном фоне, был разработан в 1993 году и имел название NCSA Mosaic. Именно он послужил основой для создания других веб-обозревателей, так как, разработчики в свое время открыли его исходный код для всех желающих. Так, на основе NCSA Mosaic был разработан самый популярный в свое время браузер Netscape Navigator, произошло это в 1994 году, он имел ошеломительный успех и приносил неплохую прибыль компании его разработчика. Хочется отметить, что внутренним именем Netscape Navigator был — Mozilla.
Компания Microsoft не могла не заметить такой успех Netscape Navigator и разработала свой собственный браузер в 1995 году, так же сделанный на основе NCSA Mosaic. Как вы наверное уже догадались, название ему дали — Internet Explorer. Вследствие именно Internet Explorer (IE) стал неотъемлемой частью всех операционных систем этой компании. Так, как ОС Windows пользовалось огромное количество пользователей, IE быстро завоевал данную нишу и завоевал около 95% всего рынка. Это и привело к закрытию проекта Netscape Navigator, ведь конкурировать с такой монополией было невозможно.
Перед тем, как полностью кануть в лету, Netscape покупает компания AOL Time Warner, которая делает исходный код Navigator открытым. Далее AOL, в связи со своим закрытием, передает все права и свои разработки в новую компанию — Mozilla Foundation, которая продолжила развивать их идеи.
В 1996 году появилась Opera, которая, благодаря маленькому весу и быстрой загрузке страниц, стала в то время самой популярной альтернативой Internet Explorer в России и странах СНГ, да и по всему свету.
Internet Explorer же стал терять свои позиции, т.к. Microsoft не обновлял его аж до октября 2006 года, т.к. у них была завоевана и так большая часть рынка. Но Internet Explorer был к этому времени уже настолько глючным и имел множество дыр в безопасности, что со временем стал одним из самых нелюбимых и не популярных браузеров — так продолжается и в наше время, не смотря на появление его новых, намного улучшенных версий.
В ноябре 2004 года появился любимый многими веб-обозреватель Mozilla Firefox, который основывался на проекте Mozilla Suite. В 2006 году компания Apple выпустила свой продукт под названием Safari, а в 2008 году на рынок вступила и компания Google, выпустив свое детище под названием Google Chrome.
К сегодняшнему дню было создано и выпущено огромное множество различных интересных веб-обозревателей, как уже писалось выше — каждый из них обладает своими уникальными функциями и фишками. [Источник 3]
Основное функциональное назначение браузера
Прежде всего, браузеры предназначены для представления выбранного вами веб-ресурса, путем его запроса у сервера и отображения в окне браузера. Ресурсом, как правило, является HTML документ, но это может быть изображение, файл PDF или другого формата. Адрес, по которому находится ресурс, определяется по введенному пользователем URL. То, как браузер интерпретирует и отображает HTML файлы, определено в HTML и CSS спецификациях. Эти спецификации ведутся такой организацией как W3C (Word Wide Web Консорциум), которая занимается стандартизацией Web пространства.
Как ни странно, но ни в одной существующей формальной спецификации не затрагивается вопрос используемого в браузерах пользовательского интерфейса, он просто основан на лучших практических приемах, отточенных годами опыта и формировался в результате подражания друг друга браузерами. Новая HTML5 спецификация также не определяет какие элементы должен включать UI, однако она перечисляет некоторые наиболее распространенные из них. К их числу относится адресная строка, строка состояния и панель инструментов. Существуют, конечно же, особенности, характерные исключительно отдельным браузерам, к примеру, менеджер загрузок в Firefox. [Источник 4]
Принцип работы браузера
Браузер — это клиентская программа, позволяющая в простой форме посылать запросы серверам на загрузку веб-страниц. В задачи браузера помимо простейших операций по связи с серверами входит: обработка полученной HTML-разметки, интерпретация стилей и скриптов, контроль ошибок и по возможности их исправление, хранение пользовательской информации. Браузеры, представленные различными компаниями, могут по-разному реализовывать эти механизмы или игнорировать какие-либо из них. Такие возможности, объединенные в виде программы, называется браузерным движком.
Этапы рабочего процесса браузера:
- При вводе имени сайта в адресной строке, клике по ссылке в поисковой системе или на любом сайте, браузер посылает запрос серверу на загрузку определенной страницы
- Сервер получает запрос и проверяет, есть ли такая страница
- Сервер осуществляет передачу HTML-разметки страницы браузеру
- Браузер обрабатывает разметку и выводит результат пользователю
- Механизм рендеринга
Архитектура браузера
Интерфейс пользователя
Это буфер между пользователем и сердцем браузера — его движком. Именно ему приходится принимать все пожелания от пользователя и обрабатывать его действия.
Интерфейс пользователя обеспечивает стандартный набор функций (ввод информации, печать, визуализация процесса загрузки данных, панели инструментов и настроек) — в общем все то, что пользователь ждет от обычного ПО.
Высокоуровневый движок браузера
тот модуль отвечает за высокоуровневые действия браузера: начало загрузки страниц, их обновление, переходы вперед/назад, работа с закладками, историей и настройками браузера. Эти настройки влияют на работу графического движка. Например, ярким примером будет отключение стилей или javascript, выбор кодировки, масштаб и т.п.
Дополнительной задачей этого движка является информирование пользователя о текущей сессии браузера: ход загрузки документа, оповещение о javascript ошибках.
Графический движок
Это и есть самая главная часть любого веб браузера, его сердце и мозг. Графический движок отображает на экране содержимое запрашиваемого ресурса.
Именно эта часть браузера анализирует полученный HTML или XML, при этом учитывает влияние CSS и Javascript, а так же других объектов, расположенных на веб странице (например, изображения или flash). На основе всех этих данных, движок создает макет (разметку) страницы, который видит пользователь на экране.
Ключевыми компонентами графического движка являются HTML и CSS парсеры — сложные программные комплексы, поскольку они позволяет графическому движку отобразить документ даже при наличии ошибок в HTML и CSS.
Самые распространенные движки браузеров на сегодня:
Trident — Internet Explorer; Gecko — браузеры Mozilla; Webkit — Chrome, Safari; Presto — Opera. Некоторые из этих движков совмещают в себе графический и высокоуровневый движки.
Читайте также: