What is WebKit and how does it relate to CSS? Web browser engines - what are they and what are they? Okay, so where have we come to?

• Translation

For many of us developers, WebKit is a black box. We throw HTML, CSS, JS, and a bunch of images at it, and WebKit, somehow... magically, gives us a web page that looks and works well.
But in reality, how says my colleague Ilya Grigorik :

• What is WebKit?
• What is WebKit not?
• How is WebKit used by WebKit browsers?
• Why are many WebKits not the same?

• Parsing (Parsing HTML, XML, CSS, Javascript)
• Layout
• Rendering text and graphics
• Image Decoding
• Interactions with GPU
• Network access
• Hardware acceleration

Each WebKit “port” implements the remaining components differently. Let's figure out what this means.

There are many WebKit "ports" and I provide Ariya Hidayat, WebKit hacker and tech. Director at Sencha has the right to talk about this:

As I mentioned above, the CoreGraphics used is unique to each WebKit port. Chrome for Mac, for example, uses Skia.

• Safari
  - Safari for OS X and Safari for Windows are two different ports
  - The WebKit nightly build is a build of the Mac source code "port" that is used for Safari, only newer
• Mobile Safari
  - Developed in a private branch, but was later opened.
  - Chrome for iOS (uses Apple's WebView; more on the difference later)
• Chrome (Chromium)
  - Chrome for Android (uses the Chromium “port” directly)
  - Chromium is also the basis for browsers: Yandex, Sogou, and soon, Opera.
• Android browser
  - Uses the latest WebKit source code available at the time of release.
• Even more ports: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, etc

First, let's look at the common features that are used in all WebKit browsers:

You know it's funny, I made several attempts to write this paragraph. And every time, members of the Chrome team corrected me, as you will see...

So, it's difficult.

Now, let's try to summarize what the world of WebKit has in common...

• DOM, window, document
  more or less
• CSSOM
• CSS Parsing, Property/Value
  differences in manufacturer prefixes
• Parsing HTML and building the DOM
  It's the same if we forget about Web Components.
• Layout and positioning
  Flexbox, Floats, block formatting context... everything is common
• UI tools and developer tools, such as Chrome DevTools aka WebKit inspector.
  Although since last April, Safari has been using its own Safari Inspector, a non-WebKit, closed source one.
• Features like contenteditable, pushState, File API, most SVG, CSS transformation math, Web Audio API, localStorage
  Although the implementation may vary. Each port can use its own storage system for localStorage and can use a different audio API for the Web Audio API.

• Everything related to GPU
  - 3D transformation
  - WebGL
  - Video decoding
• Rendering 2D to screen
  - Anti-aliasing technologies
  - Rendering SVG and CSS gradients
• Text rendering and hyphenation
• Network technologies (SPDY, pre-rendering, WebSocket transport)
• JavaScript engine
  - The JavaScriptCore engine is in the WebKit repository. But there are bindings in WebKit for both it and V8.
• Rendering Form Elements
• Behavior of video and audio tags and codec support
• Image Decoding
• Navigation back/forward
  - Part pushState()
• SSL features such as Strict Transport Security and Public Key Pins

Or to go into more detail, a recently added feature: CSS.supports() has been enabled for all ports except win and wincairo, which do not have css3 conditional features enabled.

Now, we're getting technical... time to get pedantic. Even what was said above is not entirely correct. This is actually WebCore, a generic component. WebCore is a layout, rendering, and DOM library for HTML and SVG, and is basically what people think of when they say WebKit. Indeed, "WebKit" is technically a layer of bindings between WebCore and "ports", although in normal conversation this distinction is largely unimportant.

The diagram should help:

Many of WebKit's components are switchable (shown in gray).

For example, WebKit's JavaScript engine, JavaScriptCore, is the default engine in WebKit. It is originally based on KJS (from KDE) from the days when WebKit started as a fork of KHTML. At the same time, the Chromium port switches to the V8 engine and uses unique DOM bindings.

Fonts and text rendering are a very big part of the platform. There are 2 separate paths for text in WebKit: Quick and Hard. Both require platform-specific support (implemented on the port side), but Fast only needs to know how to blit glyphs (which WebKit caches for the platform), while Complex takes the string rendering entirely to the platform level and just says "draw this, please."

Now, let's expand the overview and look at several ports and several subsystems. Below are the five WebKit ports, note how the toolset for each differs despite the common components:

* Footnote about Chrome for iOS. It uses UIWebView, as you probably know. According to UIWebView's capabilities, this means that it can only use the same rendering engine as Mobile Safari, JavaScriptCore (not V8) and a single-threaded model. However, some code is borrowed from Chromium, such as the networking subsystem, bookmark synchronization infrastructure, omnibox, metrics and crash reporting. (Also, JavaScript is so rarely a bottleneck on mobile devices that the lack of a JITting compiler has minimal impact.)

Not worth it! WebKit's coverage of "layoutTest" tests is enormous. (28,000 tests at last count), and not only for existing functions, but also for all regressions found. In fact, whenever you're learning new or "secret" DOM/CSS/HTML-5 features, the "layoutTest" test suites usually have an excellent minimal demo.

In addition, the W3C is making efforts to standardize the test suite. This means that we can expect that both WebKit ports and all other browsers will be tested with the same test suites, which will lead us to fewer quirks and a more interoperable web. To all those who put in the effort by attending the Test The Web Forward event...thank you!

Just recently I came across questions with the tag "webkit". Such questions are usually related to web issues related to CSS, jQuery, layouts, cross-browser compatibility issues, etc.

So what is "webkit" and how does it relate to CSS? I also noticed a lot of -webkit-... properties in the source code for various websites. Are the two related?

So, from the answers so far... WebKit is an HTML/CSS web browser rendering engine for Safari/Chrome. Do such mechanisms exist for IE/Opera/Firefox and what are the differences, pros and cons of using one over the other? Can I use WebKit features in Firefox for example?

Final question... Is WebKit supported by IE?

All major browsers use different rendering engines. I think this is a big reason why there are so many cross-browser compatibility issues!

So, is there some project or movement for a standard rendering engine that ALL browsers will use? Will HTML5 fix cross-browser compatibility issues?

Android and iPhone - browser wars

Development of a browser application responsible for monitoring network status

In total, the iPhone and Android platforms have more than 100,000 applications available for download from a variety of sources. This refers to “native” applications, i.e. applications that are developed and assembled using the appropriate SDK, and then installed on a mobile device. Such “native” applications allow you to effectively implement the technical capabilities of a mobile device, including support for wireless networks, Bluetooth and data storage, accelerometer or compass functions and other technological wonders and innovations that make mobile devices so attractive to users. The popularity of “native” applications for the iPhone and Android platforms is extremely high, but in addition, mobile devices provide ample opportunities for developing Web applications. Mobile technologies have long since left childhood, and with them the mobile Internet has reached a certain maturity.

This article is the first in a two-part series on developing browser apps for iPhone and Android. The purpose of this series is to introduce the reader to the basic principles of creating your own mobile Web applications. The capabilities of mobile applications are not limited to running a website on a mobile device. We will look at the basic technologies and approaches used in the development of mobile applications, which make it possible to distinguish this section of software development into a separate independent discipline.

The popularity of the Web platform is explained by the fact that its use allows solving many problems that have traditionally been the bane of developers and system administrators. Among them:

• Installation issues: Installing Web applications is hassle-free—just install or copy them to the server and tell your clients what URL to point to in the browser.
• Scaling issues: Web applications easily scale to a pool of servers in a high-performance data center, and ready-made Web site management tools are used to serve the applications.
• Data archiving and recovery issues: Web applications use centralized data storage, thereby simplifying the task of recovery in case of failures.
• User Interface Considerations: The combination of HTML, Cascading Style Sheets (CSS), JavaScript, and graphics allows you to create a rich user interface that is significantly superior in functionality and appearance to interfaces developed using native SDKs. The latter, as a rule, are not able to provide a full-fledged presence effect for gaming applications and do not guarantee the necessary functionality for interactive information terminals.
• Ease of Use: Most applications require user interface elements that are simple and easy to use, allowing you to easily perform day-to-day operations.

The most attractive aspect of the Internet application distribution model is that it allows software to become a kind of subscription service, a mutually beneficial way to deliver software. "How?" – you ask. Let's look at this issue in more detail.

The Web-based software distribution model allows customers to try the product before purchasing with minimal risk and at a minimal price. If the client liked the trial version, then all that is required from him to further use the software product is to pay for the purchase with a credit card (or using PayPal). Moreover, the software as a service (SaaS) model provides users with a convenient and cost-effective way to purchase software without any significant upfront costs, ensuring a return on investment within the first month of use rather than in the distant future.

The fact is that there was practically no support for Web browsers on mobile devices. The situation changed dramatically with the advent of a technology called WebKit, which confidently took its place in the field of mobile devices thanks to the iPhone.

In just a few years, the iPhone platform has become the number one Web client in the world. Why? Because WebKit, coupled with a reliable Internet connection, made it possible to use Web services on mobile devices much more efficiently than on any other modern browsers. Other players in the mobile device market have also taken notice of the new technology, and the entire market can now be divided into companies that are using WebKit, companies that are going to use WebKit, and companies that are making up excuses not to use WebKit.

So what is WebKit?

WebKit is a browser engine used to support both the Mobile Safari browser on the iPhone platform and the browser on the Android platform. Of course, WebKit is used in other mobile devices, but for the purposes of this article we will limit ourselves to considering the iPhone and Android platforms.

WebKit is an open source project that originates from the development of the K Desktop Environment (KDE). Modern Web applications for mobile devices owe their birth to the WebKit project. The technological and design characteristics of a mobile device certainly play an important role, but mobile users are primarily interested in content. If a mobile device provides access to only a small portion of Internet content, then it is unlikely to make it to the top list of the most popular devices.

Most of us prefer to live a fulfilling life: if we open a Web site on a laptop while sitting at home, we expect to see the same content when we open that site while sitting on a train. Content is the main problem of mobile applications. No matter where we are or what we do, we need access to the data that interests us. WebKit technology provides rich content on the iPhone and Android platforms.

It is worth noting that WebKit is also used on desktop computers, such as the Safari browser, which is the main browser of the Mac OS X platform. Regardless of whether it is the desktop version or the browser engine for iPhone or Android, WebKit remains the most advanced technology available. supporting HTML and CSS. In fact, WebKit supports CSS styles that are not yet rendered by browsers on other engines - for example, a number of properties defined by the HTML5 specification.

HTML5 is a set of preliminary technical specifications that define browser-based technologies such as client-side data storage with SQL support, moves, transformations, and so on. The HTML5 specification is still a work in progress, but once the basic principles are clearly defined and implemented in browsers on most platforms, the humble beginnings of Web applications will become a thing of the past. Web application development will occupy a significant segment of the software development industry, and we are talking not only about applications for desktop browsers, but also for mobile browsers. Mobile applications will turn from a by-product into the main product in the Web application market.

If you decide to master Web development technologies, then you have a very limited choice of tools at your disposal. First of all, the application can be created directly on the server as a file containing HTML, CSS and JavaScript code. In this case, HTML content can be supplied in the form of static HTML files, or can be generated dynamically through the use of various technologies that work on the server side, for example, such as PHP, ASP.NET, Java Servlets, etc. In any case, from the point For the purposes of this article, it all comes down to HTML code, and the most important point for us here is that WebKit technology allows browsers to render HTML on mobile devices.

To run a Web application on a mobile device (iPhone or Android), the user needs to launch a browser and enter the URL of the corresponding service, for example: http://yourcompanyname.com/applicationurl.

At the same time, the range of proposed mobile Web applications is quite wide: from a standard Web site to a mobile Web application developed specifically for a specific mobile platform.

The WebKit engine, combined with the intuitive and user-friendly user interface of the iPhone and Android platforms, allows you to view almost any Web site on your mobile device. Web pages are displayed quite correctly, unlike the previous generation of mobile browsers, which randomly transferred fragments of content or did not display them at all. When pages are loaded in a WebKit-enabled browser, the page content tends to scale. In this case, the scale is chosen so that the entire page fits on the screen, albeit in a greatly reduced, often unreadable form, as shown in Figure 1. However, the page can be scrolled, enlarged, moved, providing convenient access to all content elements . By default, the browser uses a window that is 980 pixels wide.

While fully displaying a Web page in a browser window is a significant improvement over the experience of previous generation browsers, the capabilities of modern mobile technologies are not limited to this.

If you want your Web page to be accessible not only to regular web users, but also to mobile users, there are a few more options to consider for optimizing mobile Web applications.

Although WebKit allows a Web page to be displayed correctly on a mobile device's screen, there are certain differences between devices that use a mouse, such as laptops or desktop computers, and touch devices, such as iPhone or Android smartphones. Touch devices differ in the physical dimensions of the “click” area, the lack of a function for hovering the cursor over any element, and a different sequence of events. Thus, if you want to create a website that is convenient for both regular and mobile users, you need to consider the following features of mobile devices:

• iPhone and Android browsers are capable of rendering an entire Web page in a fairly readable form—the rendering quality of these browsers is much higher than that of standard mobile browsers—so don't rush to simplify your site design.
• The size of the fingertips is significantly larger than the size of the mouse pointer. Take this factor into account when developing site navigation elements. Don't place links too close to each other, otherwise the user will not be able to click on one link without hitting the next one.
• Hover elements will not work on mobile devices. The user simply cannot “point” his finger over any element in the same way as the mouse cursor.
• Events defined by pressing and holding the mouse button, dragging the mouse, etc. are implemented in a different way on touch screens. Some of these events may also work on mobile devices, but in general you should not expect the mobile browser and desktop browser to perform the same sequence of actions.

A detailed discussion of these aspects can be found in the article " iPhone in Action"(see section). In our article we will limit ourselves to considering the advantages of WebKit, and not its disadvantages.

Let's look at the most obvious problem iPhone or Android users face when accessing websites: limited screen size. In fact, the screen size of a modern mobile device is 320x480 or 480x320, provided the user prefers to view Web content in a landscape configuration. As you can see from Figure 1, WebKit is able to correctly display a Web page designed for standard desktop computers. However, when a Web page is scaled, the text may become too small to read, so the user must scroll, pan, and zoom before being able to read the text. How to deal with this limitation?

The easiest way to create a page that displays equally well in a mobile browser window and in a desktop browser window is to use a special meta tag viewport.

A meta tag is an HTML tag placed in the head of an HTML document. The simplest example of using the viewport tag looks like this: . By adding this meta tag to an HTML page, its display in the mobile browser window is scaled in the most optimal way (see Figure 2). Browsers that don't support viewport simply ignore this tag.

In some cases, it is useful to define the window scaling parameters in advance, as shown in Figure 3.

To define specific zoom options, specify the exact value of the content attribute of the viewport: meta tag. By changing the value of the initial-scale parameter, the image can be reduced or enlarged. For iPhone and Android platforms, it is better to use values ​​from 1.0 to 1.3. The viewport meta tag also supports minimum and maximum zoom, which allows you to limit the ability of the user to modify the zoom of the page as it loads.

While the design characteristics of the iPhone, in particular the 320x480 screen size, have remained virtually unchanged since its introduction, the parameters of devices on the Android platform have a fairly wide range, since mobile devices on this platform are produced by different manufacturers and are intended for a wide variety of user groups. Thus, if you want your Web application to be popular with mobile users, you should take into account the possible differences in screen size, resolution, and design features of Android devices.

Experience has shown that in addition to the design differences that exist between various Android mobile devices, the Android software itself attempts to set the settings of the loaded Web page depending on the properties of the mobile device's browser. In addition to stability, the Android platform has an ever-changing set of features and capabilities. Your specific Android device's settings will likely be different from your development environment, depending on the SDK version and device manufacturer. Figure 4 shows the browser setup screen in V1.6 Android Emulator. Screen settings provide the user with the opportunity to determine the level of image scaling on the screen (far, near, medium) or select the automatic page scaling mode.

In the world of mobile devices, the most constant thing is change, so the development and renewal of the mobile software market must be taken into account. For example, the Sprint Hero browser settings include a set of options that are completely different from the standard settings used when loading a Web page. The Hero browser is built on the Android V1.5 platform using a number of modifications made by HTC. Fortunately, using the viewport meta tag will ignore Hero-specific settings.

So far, we've seen that WebKit is quite capable of loading a Web page, albeit in a greatly reduced and hard-to-read form. We then extended control over how the page is displayed on a mobile device screen through the use of the viewport meta tag. The displayed page is now much easier to read and navigate. But this is still not enough to make our page look and function like a Web application.

Let's move on to consider the design features of a Web page intended for a mobile audience. As a specific example, consider the registration page for the Google email service GMail.

This is what the page looks like in a desktop browser window:

The desktop browser window displays informational content on the left side, and the registration window itself is in the right panel. In a mobile browser window, the same page has a completely different appearance.

The page shown in Figure 6 is definitely designed for mobile users. The screen displays only those page elements that the user needs for further work - no additional scrolling, panning or zooming is required.

Now let's look at the email view window of the mobile version of Gmail. Because the screen space available to the application is very limited, the message viewer has additional buttons and navigation elements. In this case, the displayed navigation elements overlap the window for viewing messages. Also, don't use too many frames or scrolling divs if you can avoid it. The mobile version of Gmail solves this problem by using a pop-up menu that appears as soon as the user finishes scrolling the page. The pop-up menu contains 3 buttons: Archive, Delete and More. When you click the More button, additional menu items appear (see Figure 7).

This is truly an application designed for mobile devices.

It should be borne in mind that we do not want to deliberately impoverish the design and reduce the experience of mobile users who have developed multifunctional browsers for the iPhone and Android platforms. From this point of view, it is useful to pay attention to the element displayed at the bottom of the Gmail page (see Figure 8):

If the user prefers the enhanced functionality of the desktop version, give them the option to download the appropriate version of the page.

Now consider the case where you want to create an application that uses Web technologies, but looks like a native mobile application.

The next step is to develop content specific to a particular mobile platform. This defines the page format and interface so that the resulting page looks like a native application for a specific platform, rather than a standard public Web site. What do we mean by "native" application?

Before we delve into the discussion of how to make a Web application as similar as possible to a native application for a specific platform, let's put aside the common features of the iPhone and Android browsers and briefly touch on the visual differences that exist between these platforms.

iPhone applications have their own specific look and interface. Show someone a screenshot of an iPhone and, unless they just fell off the moon the other day, they'll almost certainly immediately say it's an iPhone. Show the same person a screenshot of an Android mobile device, and the answer will no longer be so clear. What is the reason? There are several possible explanations. Firstly, the iPhone appeared on the market much earlier than Android-based devices and managed to gain a huge number of fans. Think about the people lining up to pay top dollar for the limited features of the V1 iPhone. Whether you like the iPhone or not, this Apple product is currently the market leader. What about Android?

The Android platform is a relatively new product, and in many aspects acts as the antipode of the iPhone, as it is designed primarily for the open community. The Android platform is used in a wide variety of devices (phones and other household appliances). For simplicity of discussion, in this article we will limit ourselves to the use of Android in mobile phones.

Over time, the number of Android devices in the world will surpass the number of iPhones. This is because Android devices are made by a variety of companies and will be supported by a wide variety of data networks. With such a significant number of players in the Android mobile device market, we should certainly expect some fragmentation of the market based on the appearance and parameters of the devices. This trend can be seen in the SenseUI interface from HTC. This attractive look and feel is not supported by the underlying Android SDK and is not compatible with other Android devices. Motorola, Google and Verizon have joined forces to develop a new Android-based DROID device. This is the first commercial product on the Android 2.0 platform.

Compare the variety of Android systems with the consistent look and feel of the iPhone. The iPhone is a particularly valuable property of Apple. The appearance of iPhone apps may change slightly over time, but these minor changes are unlikely to compare with the various versions of Android systems, which are numerous even now that the platform is in its very early days.

So, what needs to be done in order to bring the appearance and interface of the application as close as possible to “native” programs?

If we had faced this challenge before the advent of Web 2.0, it would have been a serious problem indeed. Early attempts to support multiple client browsers (mobile and desktop) relied on several approaches, for example:

• Development of completely parallel sites
• Dynamic content generation depending on the userAgent parameter
• Using proxy servers that could transform content depending on each specific device. A similar technology was successfully used by RIM to provide access to email from a client’s mobile device.

Such approaches may be quite acceptable in cases where development is carried out by large, well-funded teams. What should the rest of the world do? Not everyone has significant financial resources, highly qualified specialists and unlimited time to implement such strategies. In addition, as we have already noted, the mobile Internet of the previous generation of browsers cannot be called convenient or popular to use, so in any case you should not dwell on outdated methods and approaches.

Fortunately, we won't have to do this. In the era of WebKit and CSS, differences in the appearance and interface of different mobile devices can be overcome by using style sheets and media queries, which allow different styles to be used depending on the specific type of device. Media query technology allows you to obtain information about the client. Traditionally, the browser sends the server a userAgent value, which allows the server to identify the specific browser and determine the content that should be sent to the client. Using a media query, the browser chooses the style of the page based on its capabilities. The following example demonstrates selecting a style sheet designed for smartphones: . And this query defines a desktop style sheet: .

At the time of this writing, Internet Explorer V6 occupied approximately 20-30% of the total browser market, however, discussing the capabilities of IE V6 is beyond the scope of this article.

More information about media queries can be found in the draft specification (see section).

Let's look at an example of using media queries to develop an application that displays the status of network servers.

The purpose of this application is to monitor the operation of several servers. Independent software developers often need to support multiple applications on multiple servers. If you have been involved in software development for any significant time, then you have probably already encountered different types of servers and different types of applications. All this means that it is quite possible that you will not be able to use a single tool to track the performance of all the necessary applications. In this case, it makes sense to use a mobile network monitoring application (netmon). The application provides all the required functionality, while remaining flexible and easy to access from a mobile device.

The netmon application includes a list of servers that need to be monitored. Key performance indicators (KPIs) are collected for each server. Key performance indicators are a primary tool that MBA students have been using for years to assess the current state of a business. From a Web application hosting perspective, the following indicators can be used as KPIs:

• Number of transactions over the past period of time
  • Orders
  • Requests for catalogs
  • Emails
  • Number of page views
• Time elapsed since last transaction
  • Order
  • Electronic Data Exchange
  • Messages from a business partner
  • Uploading a file from the vendor via FTP
• Is the database available?
• Last backup date
• Average order amount (in dollars)
• Amount of free disk space
• Bandwidth for last hour, day, month

The above indicators and other similar operational parameters allow you to assess the health of a specific system or application. For example, during the holiday season we review the number of orders placed on some of our sites. If the data does not show a stable increase in the number of orders every hour, we conduct a more detailed analysis of the situation.

Because each application has its own requirements and resources, netmon must be flexible enough to accommodate each application's needs. To provide this level of flexibility, we begin by defining the most general data structure to account for the state parameters of each system. In Part 2 we'll take a closer look at where this data comes from and how it is updated. For now we will limit ourselves to the following information:

• Site name
• Site URL (home page)
• URL to get updates
• Status: OK or not
• Quick Summary: A description of the server status that will either be OK or contain a text string indicating the most severe problem for that server
• Elements: This is a set of name/value pairs that we will need to pass the current KPI values ​​for the corresponding site.

Our application will display the resulting performance indicators in an easy-to-navigate format, making full use of CSS, jQuery, and WebKit to draw the user's attention to problem areas. As we have already mentioned, the main goal in developing this application is the ability to run it on the iPhone, Android platform and on a desktop computer in the Safari browser.

Modern Web pages must be created in a declarative form that defines the organizational structure and content of the page. Page positioning and formatting is done using Cascading Style Sheets (CSS) and, in most cases, JavaScript. In fact, JavaScript libraries have become so popular that their use today is the rule rather than the exception. In the application discussed in this article, we will use the popular JavaScript library jQuery. Our application will run on iPhone, Android and desktop platforms. The same HTML code will be used, and any necessary differences will be implemented in style sheets. It should be noted here that we have not consciously put any significant effort into designing an attractive appearance for the app. Moreover, flashy colors that do not harmonize with each other were deliberately chosen as the background in order to attract additional reader attention to the organization of style sheets. In Part 2 we'll slightly improve the appearance of the application, but for now the HTML code looks like the one shown in Listing 1.

A quick look at the proposed HTML code reveals the following main features:

• The code uses two external JavaScript files: one jQuery library file and one helper file for our application.
• The code uses the viewport meta tag to scale the displayed content.
• The main style sheet is defined by the netmon.css file.
• The userAgent parameter is used to define the auxiliary style sheet. Depending on its value, the style sheet will be loaded for iPhone, Android or desktop browser.
• The page load process uses jQuery and a helper function defined in the netmon.js file to display the data.
• The main page code uses several div tags.
• Finally, the code contains a link to a page that shows the userAgent string. This link has nothing to do with the operation of the application and is used for demonstration purposes only.

Before we get into the details of the style sheets and netmon.js file that actually define the basic operation of the application, let's take a look at our application in its current state. Please note again that we are using three different style sheets: one for each of the three supported platforms. To make the application development process more visual, each table defines its own background color. In Figure 9, our page is open in the Desktop Safari browser and has a blue background.

Figure 11 shows the appearance of the application in the iPhone browser window (background color is green).

The main style sheet stored in the netmon.js file is shown in Listing 2.

Using a different style sheet for each platform allows you to achieve the following tasks:

Listing 3 shows the code for the iphone.css file.

As we can see, the background color of the body tag is green (#00ff00), and the font size is adjusted to make it easier to read on a mobile device screen. Finally, let's take a look at the netmon.js file, which defines a list of servers and a function that prints each server's data (used in Listing 4). Part of the file code has been omitted for brevity; its full text is available in section ).

If the status bar of any server is not OK, then the corresponding server entry is displayed in red, as can be seen from the class definition in the CSS file. In addition, if checking the server status reveals any problems (the status is not OK), a brief description of the problem is additionally displayed. Figures 9-11 show that Server 4 is running out of free disk space. When you click on the line of this server, a detailed message about the problem will be displayed on the screen (see Figure 12).

Clicking the show link to the right of a server name opens that server's home page. Having such a link is very convenient for two reasons: firstly, it will save you from the unpleasant need to memorize the URL of each server, and secondly, it will save you from the even more unpleasant need to enter this URL from the keyboard of your mobile device ( even the most convenient one).

So, if we manage to successfully run netmon on a mobile device, the task of maintaining the servers should not cause any problems.

This article introduces the principles of developing Web applications for iPhone and Android using WebKit technology. In Part 2, we will expand the capabilities of our application by adding data updating functionality using Ajax calls.

A browser engine is a special program that works with web pages. It processes an HTML page downloaded from the Internet and converts its code into a presentation familiar to users. Internet browser engines are used in the browsers themselves, as well as in email clients. Not every web browser is built on its own unique platform. Many of them use popular and time-tested solutions. This article examines what platforms exist for creating browsers and how they differ from each other.

There are many benefits to using Rendering engines to create browsers:

• Makes it easier to find and fix code errors.
• A convenient opportunity to improve a single component in several programs at once.
• The process of changing the application's graphical interface is simplified.
• Ease of creating new programs to suit the wishes of a specific developer or the needs of a specific user.

Such solutions are very often used in programming: when creating video games, operating systems for complex programs, and so on. Some specialists are working on improving and optimizing the engine, introducing new features and useful functions into it. Others are engaged in creating the programs themselves based on the developed platform.

A striking example is the Trident engine from Microsoft. It alone is used in a large variety of applications of this corporation. As the foundation develops, derivative projects also develop.

Each solution has its pros and cons. For example, many users notice that Mozilla Firefox works much better with more tabs open than its competitors. This is an achievement of the platform on which the browser is based.

When a user installs a new Windows operating system, the first web browser they encounter is Internet Explorer. Therefore, its engine is considered first in the review.

Trident, or MSHTML, is a fairly old software component developed by Microsoft for its needs. The project has been continuously developing since 1997. Used in the Microsoft web browser - Internet Explorer, Outlook email client, Windows Explorer (a program for working with files) and many other applications from this developer.

It is considered by users to be one of the most unsuccessful browser engines. It does not support third-party modular extensions - plugins, displays many Internet pages incorrectly, and does not have the fastest operating speed.

With the release of Windows 10, the Trident platform evolved into EdgeHTML. The developers took the outdated, unsuccessful engine as a basis and created a new one that meets all the requirements of modern users. Judging by the benchmarks (software test of performance and speed), Microsoft Edge (a browser created based on EdgeHTML) has caught up and even surpassed the popular programs used to create the Google Chrome and Mozilla Firefox browsers.

Gecko is the engine used in the popular Internet browser Mozilla Firefox and many other programs. The source code of the program is freely available, that is, anyone can create their own browser or email client based on Gecko absolutely free of charge.

Another advantage of Geko is cross-platform. It works on the vast majority of modern operating systems: both for personal computers and mobile devices (unlike Internet Explorer, which operates only on Windows OS).

Gecko supports all modern standards and technologies used to create websites. It is one of the two most popular browser platforms. Supports connecting plugins. Benchmarks and personal experience of users show that browsers based on this engine consume the least amount of personal computer resources and work reliably with a large number of tabs (for example, several hundred).

Based on Geko, the popular Internet browser Mozilla Firefox, the Thunderbird email client, the Sunbird task scheduler, and an anonymous web browser with built-in support for Tor VPN technologies were created.

A little-known platform used to create Konqueror, the KDE file manager. For users who are not familiar with operating systems of the Linux family, it is interesting that the most popular engine in the world was created on the basis of this project, which will be discussed further.

This engine was developed by the world famous Apple corporation based on the above-mentioned solution - KHTML. Released in 2001, this project has received tremendous development and has become one of the most used in the world.

Based on WebKit, the Safari web browser was created, used by default in iOS devices and the leader in popularity among browsers - Google Chrome. The overwhelming number of modern programs for processing the content of web pages are based on WebKit. In addition, it is used in the popular Steam application, designed for the digital distribution of computer games from Valve.

Similar to Gecko, WebKit is cross-platform and runs perfectly on all popular platforms. Shows high stability and performance. Due to its enormous popularity, the vast majority of extensions are developed for this solution. Also used in popular mobile platforms such as Android and iOS. It is a free engine, which means it can be used for free by anyone to create their own applications.

In 2013, a new branch owned by Google, Blink, separated from WebKit. This project formed the basis of Chrome version 28 (and all subsequent versions), as well as its open source brother, Chromium. Chromium was used to create the popular Yandex Browser in Russia. Starting from version 15, the Opera browser also switched to Blink.

Created in 2003, the Presto browser engine was used as the basis for Opera. Developed over 10 years. In 2013, Opera developers decided to abandon the use of Presto in favor of the more powerful and popular Blink from Google. At the moment, the development of the project has been stopped.

Was the article helpful?