Transferir

Para muchos de nosotros, desarrolladores, WebKit - caja negra... Agregamos HTML, CSS, JS y un montón de imágenes, y WebKit, de alguna manera ... mágicamente, nos da una página web que se ve y funciona bien.
Pero realmente como dice mi colega Ilya Grigorik :

Kit web no es caja negra. Esta es una caja blanca. Y no solo blanco, sino también abierto caja.

Así que intentemos averiguar algunas cosas:

¿Qué es WebKit?
¿Qué no es WebKit?
¿Cómo utilizan WebKit los navegadores WebKit?
¿Por qué muchos WebKits no son iguales?

Ahora, especialmente después de la noticia de que Opera se ha cambiado a WebKit, estamos rodeados de una gran cantidad de navegadores WebKit, y es difícil decir qué los une y adónde van por su propio camino. A continuación, espero que intentemos arrojar algo de luz sobre este tema. Como resultado, puede identificar mejor las diferencias entre navegadores, enviar errores al rastreador correcto y desarrollar un navegador cruzado de manera más eficiente.

Componentes estándar del navegador web

Enumeremos algunos componentes de los navegadores modernos:

Análisis (análisis de HTML, XML, CSS, Javascript)
Diseño
Representación de texto y gráficos
Decodificar imágenes
Interacciones de GPU
Acceso a la red
Aceleracion de hardware

¿Cuáles son comunes a todos los navegadores WebKit? Prácticamente solo los dos primeros.

El resto de componentes que cada "puerto" de WebKit implementa a su manera. Veamos qué significa esto.

Puertos de WebKit

Hay muchos "puertos" de WebKit y yo proporciono Aria Hidayat, hacker de WebKit y esos. el director de Sencha tiene derecho a informar al respecto:

La asociación más popular con WebKit suele ser el tipo de WebKit de Apple, que se ejecuta en Mac OS X (la primera y original biblioteca de WebKit). Como puede imaginar, las diversas interfaces se implementan utilizando varias bibliotecas nativas de Mac OS X, principalmente en el componente CoreFoundation Por ejemplo, si define un botón plano de color con un radio de contorno especial, WebKit sabe dónde y cómo dibujar ese botón, mientras que la representación final del botón (como píxeles en el monitor del usuario) recae en CoreGraphics.

Como mencioné anteriormente, los CoreGraphics utilizados son únicos para cada puerto de WebKit. Chrome para Mac, por ejemplo, usa Skia.

En algún momento, WebKit fue portado a diferentes plataformas, tanto de escritorio como móviles. Esta variación se conoce comúnmente como el "puerto WebKit". Para Safari Windows, Apple también "portó WebKit" de forma independiente para ejecutarlo en Windows usando su biblioteca CoreFoundation (implementación limitada).

... a pesar de que Safari para Windows ya está muerto.

Aparte de eso, también había muchos otros "puertos" (ver lista completa). Google ha creado y sigue manteniendo su puerto de Chromium. También existe WebKitGtk basado en Gtk +. Nokia (y ahora Trolltech, quien lo compró) mantiene el puerto WebKit Qt, que se ha vuelto popular como módulo QtWebKit.

Algunos puertos de WebKit

Safari
- Safari en OS X y Safari en Windows dos puertos diferentes
- WebKit Nightly Build es una compilación del código fuente para el "puerto" de Mac utilizado por Safari, solo que más reciente
Safari móvil
- Desarrollado en una sucursal privada, pero luego se abrió.
- Chrome para iOS (usa WebView de Apple; un poco más adelante sobre la diferencia)
Cromo (cromo)
- Chrome para Android (utiliza el "puerto" de Chromium directamente)
- Chromium también es la base de los navegadores: Yandex ,, Sogou y, próximamente, Opera.
Navegador de Android
- Utiliza el último código fuente de WebKit disponible en el momento del lanzamiento.
Incluso más puertos: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK +, el puerto EFL (Tizen), wxWebKit, WebKitWinCE, etc.

Los diferentes puertos pueden enfocarse en diferentes tareas. El enfoque del puerto Mac es la separación entre el navegador y el sistema operativo, y la provisión de enlaces Obj-C y C ++ para incrustar el motor de renderizado en aplicaciones nativas. El enfoque del puerto de Chromium está completamente en el navegador. QtWebKit ofrece su puerto para ser utilizado junto con su arquitectura de aplicaciones multiplataforma como motor de renderizado.

Qué es común en todos los navegadores WebKit

Primero, echemos un vistazo a las características comunes que se utilizan en todos los navegadores WebKit:

Sabes que esto es gracioso, hice varios intentos para escribir este párrafo. Y cada vez que los miembros del equipo de Chrome me corrigieron, como verán ...

Entonces, en primer lugar, WebKit analiza HTML de la misma manera. Bueno, excepto que Chromium es el único puerto actualmente con soporte de transmisión para análisis HTML habilitado.
... Ok, pero después de analizar el HTML, el árbol DOM se construye de la misma manera. Bueno, en realidad Shadow DOM solo está habilitado para el puerto de Chromium, por lo que la construcción de DOM varía. También para elementos personalizados.
... Bueno, WebKit crea objetos de ventana y documento iguales para todos. Es cierto, aunque las propiedades y construcciones que proporcionan pueden depender del uso de indicadores de características.
... Analizar el CSS es lo mismo. Comer su CSS y convertirlo a CSSOM es bastante estándar. Sí, aunque Chrome solo admite los prefijos -webkit-, mientras que Apple y otros navegadores admiten los prefijos obsoletos -khtml- y -apple-.
... Layout ... posicionamiento? Es como pan y mantequilla. Es lo mismo en todas partes, ¿verdad? ¡Pues ya! El diseño de subpíxeles y la aritmética de diseño enriquecido son parte de WebKit, pero difieren de un puerto a otro.
Súper.

Entonces esto es difícil.

Ahora, intentemos resumir lo que es común en el mundo de WebKit ...

Lo que es común para cada puerto de WebKit.

DOM, ventana, documento
más o menos
CSSOM
Análisis de la propiedad / valor de CSS
diferencias en los prefijos del fabricante
Analizando HTML y construyendo el DOM
Es lo mismo si nos olvidamos de los componentes web.
Disposición y posicionamiento
Flexbox, Floats, contexto de formateo de bloques ... todo en común
Herramientas de interfaz de usuario y herramientas de desarrollo como Chrome DevTools, también conocido como inspector de WebKit.
Aunque desde abril pasado, Safari utiliza su propio inspector de Safari, no WebKit, de código cerrado.
Funciones como contenteditable, pushState, File API, la mayoría de SVG, CSS transform math, Web Audio API, localStorage
Sin embargo, la implementación puede diferir. Cada puerto puede usar su propio almacenamiento para localStorage y puede usar una API de audio diferente para la API de Web Audio.

Se está volviendo un poco confuso, así que intentemos ver algunas de las diferencias.

Ahora, lo que no es común para los puertos WebKit:

Cualquier cosa relacionada con la GPU
- Transformaciones 3D
- WebGL
- Decodificación de video
Dibujar 2D en la pantalla
- Tecnologías anti-aliasing
- Representación de degradados SVG y CSS
Representación de texto y separación de palabras
Tecnologías de red (SPDY, pre-renderizado, transporte WebSocket)
Motor de JavaScript
- El motor JavaScriptCore está en el repositorio de WebKit. Pero hay enlaces en WebKit tanto para él como para V8.
Representación de elementos de formulario
Comportamiento de etiquetas de audio y video y compatibilidad con códecs
Decodificación de imágenes
Navegación hacia atrás / adelante
- La parte pushState ()
Funciones SSL como estricta seguridad de transporte y pines de clave pública

Echemos un vistazo a uno de ellos: Gráficos 2D Depende del puerto, usamos bibliotecas completamente diferentes para renderizar en la pantalla:

O para entrar en más detalles, la característica recientemente agregada: CSS.supports () se ha habilitado para todos los puertos excepto win y wincairo, que no tienen habilitadas las características condicionales css3.

Ahora, nos metemos en los detalles técnicos ... es hora de ser pedantes. Incluso lo anterior no es del todo correcto. En realidad, es WebCore, es un componente común. WebCore es una biblioteca de diseño, renderizado y DOM para HTML y SVG, y básicamente lo que la gente piensa cuando dice WebKit. De hecho, "WebKit" es técnicamente una capa de enlaces entre WebCore y "puertos", aunque en una conversación normal esta distinción es en gran medida irrelevante.

El diagrama debería ayudar:

Muchos de los componentes de WebKit son intercambiables (se muestran en gris).

Por ejemplo, el motor JavaScript de WebKit, JavaScriptCore, es el motor predeterminado en WebKit. Se basa originalmente en KJS (de KDE) desde los días en que WebKit comenzó como una bifurcación de KHTML. Al mismo tiempo, el puerto de Chromium cambia al motor V8 y utiliza enlaces DOM únicos.

Las fuentes y la representación del texto son una parte muy importante de la plataforma. Hay 2 rutas separadas para el texto en WebKit: Rápido y Difícil. Ambos requieren soporte específico de la plataforma (implementado en el lado del puerto), pero Fast solo necesita saber cómo borrar glifos (que WebKit almacena en caché para la plataforma), cuando Complicated empuja por completo la representación de cadenas al nivel de la plataforma y solo dice dibujar esto, por favor.

“WebKit es como un sándwich. De lo contrario, en el caso de Chromium, es más como un taco. Deliciosos tacos de tecnologías web.
Dmitri Glazkov, hacker de Chrome WebKit. Campeón de Web Componets y shadow dom.

Ahora, ampliemos nuestra descripción general para ver algunos puertos y algunos subsistemas. A continuación se muestran los cinco puertos de WebKit, observe cómo el conjunto de herramientas difiere para cada uno, a pesar de los componentes comunes:

	Chrome (OS X)	Safari (OS X)	QtWebKit	Navegador de Android	Chrome para iOS
Representación	Skia	CoreGraphics	QtGui	Pila de Android / Skia	CoreGraphics
Redes	Pila de red de Chromium	CFNetwork	QtNetwork	Bifurcación de la pila de red de Chromium	Pila de cromo
Fuentes	CoreText a través de Skia	CoreText	Internos de Qt	Pila de Android	CoreText
JavaScript	V8	JavaScriptCore	JSC (V8 se usa en otras partes de Qt)	V8	JavaScriptCore (sin JITting) *

* Nota al pie sobre Chrome para IOS. Utiliza UIWebView como probablemente sepa. De acuerdo con las capacidades de UIWebView, esto significa que solo puede usar el mismo motor de renderizado que Mobile Safari, JavaScriptCore (no V8) y un modelo de un solo hilo. Sin embargo, parte del código se toma prestado de Chromium, como redes, infraestructura de sincronización de marcadores, omnibox, métricas e informes de fallas. (Además, JavaScript rara vez es un cuello de botella en dispositivos móviles que la falta de un compilador JITting tiene un impacto mínimo).

Bien, entonces ¿a dónde vinimos?

Y así, todo WebKit ahora es completamente diferente. Estoy asustado.

¡No vale la pena! La cobertura de prueba de diseño de WebKit es enorme. (28.000 pruebas en el último recuento), y no solo para las funciones existentes, sino también para todas las regresiones encontradas. De hecho, cada vez que aprende características DOM / CSS / HTML-5 nuevas o "secretas", las suites de prueba "layoutTest" suelen tener una gran demostración mínima.

Además, el W3C está haciendo esfuerzos para estandarizar el conjunto de pruebas. Esto significa que podemos esperar que tanto los puertos de WebKit como todos los demás navegadores se prueben con el mismo conjunto de pruebas, lo que nos llevará a reducir las peculiaridades y una web más interoperable. Para todos aquellos que pusieron su esfuerzo en asistir al evento Test The Web Forward ... ¡gracias!

Opera acaba de trasladarse a WebKit. ¿Qué saldrá de eso?

Robert Nyman y Rob Hawkes ya han abordado este tema, pero agregaré que una de las partes importantes del anuncio fue que Opera cambia a Chromium... Esto significa WebGL, Canvas, formularios HTML5, implementación de gráficos 2D, todas estas cosas serán iguales en Chrome y Opera ahora. Misma API e implementación de bajo nivel. Dado que Opera se basa en Chromium, es posible que sienta que está reduciendo su trabajo al verificar la compatibilidad en Opera y Chrome.
También debo señalar que todos Los navegadores Opera se traducirán a Chromium. Es decir, Opera para Windows, Mac, Linux y Opera Mobile (un navegador móvil completo). Incluso Opera Mini, un cliente ligero, se cambiará de la granja de renderización actual basada en Presto a otra basada en Chromium.

... y una compilación nocturna de WebKit. ¿Qué es?

Este es WebKit, que se ejecuta en el mismo código que Safari (aunque algunas bibliotecas internas han cambiado). En su mayoría, Apple lo ejecuta, por lo que el comportamiento y el conjunto de funciones coinciden con lo que puede encontrar en Safari. En muchos casos, Apple es conservador cuando se trata de habilitar funciones que otros puertos implementan o experimentan. De todos modos, para usar analogías, piense que ... una compilación nocturna de WebKit para Safari es como Chromium para Chrome. Agregar etiquetas

Android y iPhone - guerras de navegadores

Parte 1. WebKit se apresura al rescate

Desarrollar una aplicación de navegador responsable de monitorear el estado de la red.

Serie de contenido:

En total, las plataformas iPhone y Android tienen más de 100,000 aplicaciones disponibles para descargar desde una variedad de fuentes. Esto se refiere a aplicaciones "nativas", es decir. aplicaciones que se desarrollan y compilan con el SDK correspondiente y luego se instalan en un dispositivo móvil. Estas aplicaciones "nativas" permiten la implementación eficiente de las capacidades técnicas de un dispositivo móvil, incluido el soporte para redes inalámbricas, Bluetooth y almacenamiento de datos, funciones de acelerómetro o brújula y otras maravillas e innovaciones tecnológicas que hacen que los dispositivos móviles sean tan atractivos para los usuarios. La popularidad de las aplicaciones "nativas" para las plataformas iPhone y Android es extremadamente alta, pero además, los dispositivos móviles brindan amplias oportunidades para desarrollar aplicaciones Web. Las tecnologías móviles han salido de la infancia y con ellas la Internet móvil ha alcanzado una cierta madurez.

Este artículo es el primero de una serie de dos partes sobre el desarrollo de aplicaciones de navegador para las plataformas iPhone y Android. El propósito de esta serie es presentar al lector los principios básicos para crear sus propias aplicaciones web móviles. Las capacidades de las aplicaciones móviles no se limitan a ejecutar un sitio web en un dispositivo móvil. Consideraremos las tecnologías y enfoques básicos utilizados en el desarrollo de aplicaciones móviles, que hacen posible distinguir esta sección del desarrollo de software en una disciplina independiente separada.

La popularidad de la plataforma web se debe al hecho de que su uso le permite resolver muchos de los problemas que tradicionalmente acosan a los desarrolladores y administradores de sistemas. Entre ellos:

Problemas de instalación: la instalación de aplicaciones web es sencilla: simplemente instálelas o cópielas en el servidor e indique a sus clientes a qué URL apuntar en el navegador.
Problemas de escala: las aplicaciones web se escalan fácilmente a un grupo de servidores en un centro de datos de alto rendimiento y utilizan herramientas de administración de sitios web listas para usar para servir las aplicaciones.
Desafíos de recuperación y archivado de datos: las aplicaciones web utilizan un almacén de datos centralizado, lo que simplifica la tarea de recuperación ante desastres.
Consideraciones sobre la interfaz de usuario: la combinación de HTML, hojas de estilo en cascada (CSS), JavaScript y gráficos crea una interfaz de usuario rica que es muy superior en funcionalidad y apariencia a las interfaces desarrolladas con el SDK nativo. Estos últimos, por regla general, no pueden proporcionar un efecto de presencia completo para las aplicaciones de juego y no garantizan la funcionalidad necesaria para los terminales de información interactivos.
Facilidad de uso: la mayoría de las aplicaciones requieren elementos de interfaz de usuario simples y fáciles de usar para facilitar las operaciones diarias.

El aspecto más convincente del modelo de distribución de aplicaciones de Internet es que convierte el software en una especie de servicio de suscripción que es una forma mutuamente beneficiosa de entregar software. "¿Cómo?" - usted pregunta. Echemos un vistazo más de cerca a este tema.

El modelo de distribución de software basado en la Web permite a los clientes probar el producto antes de comprarlo con un riesgo mínimo y un costo mínimo. Si al cliente le gustó la versión de prueba, entonces todo lo que se requiere de él para seguir usando el producto de software es pagar la compra con una tarjeta de crédito (o usando el sistema PayPal). Además, el modelo de software como servicio (SaaS) brinda a los usuarios una forma conveniente y rentable de comprar software sin costos iniciales significativos, lo que garantiza un retorno de la inversión dentro del primer mes de uso, en lugar de en un futuro lejano.

El hecho es que prácticamente no había soporte para navegadores web en dispositivos móviles. La situación cambió drásticamente con la llegada de una tecnología llamada WebKit, que ha tomado su lugar con confianza en el campo de los dispositivos móviles gracias al iPhone.

En tan solo unos años, la plataforma iPhone se ha convertido en el cliente web número uno del mundo. ¿Por qué? Porque WebKit, junto con una conectividad confiable a Internet, hizo posible utilizar los servicios web en dispositivos móviles de manera mucho más eficiente que en cualquier otro navegador moderno. Otros jugadores móviles también se han dado cuenta de la nueva tecnología, y ahora todo el mercado se puede dividir en empresas que utilizan WebKit, empresas que van a utilizar WebKit y empresas que presentan excusas para no utilizar WebKit.

Entonces, ¿qué es WebKit?

WebKit y HTML5

WebKit es un motor de navegador que se utiliza tanto para admitir el navegador Mobile Safari en la plataforma iPhone como para admitir el navegador en la plataforma Android. Por supuesto, WebKit también se utiliza en otros dispositivos móviles, pero a los efectos de este artículo nos limitaremos a considerar las plataformas iPhone y Android.

WebKit es un proyecto de código abierto que se origina en el desarrollo del entorno de escritorio K (KDE). Es el proyecto WebKit al que deben su nacimiento las aplicaciones web modernas para dispositivos móviles. Las características tecnológicas y de diseño de un dispositivo móvil ciertamente juegan un papel importante, pero los usuarios móviles están interesados \u200b\u200bprincipalmente en el contenido. Si un dispositivo móvil proporciona acceso solo a una pequeña parte del contenido de Internet, es poco probable que pueda llegar a la lista superior de los dispositivos más populares.

La mayoría de nosotros preferimos vivir una vida plena: si abrimos un sitio web en una computadora portátil mientras estamos sentados en casa, esperamos ver el mismo contenido cuando visitamos ese sitio web mientras estamos en el tren. El contenido es el principal problema de las aplicaciones móviles. No importa dónde estemos o qué hagamos, necesitamos acceder a los datos que nos interesan. La tecnología WebKit ofrece contenido enriquecido en plataformas iPhone y Android.

Vale la pena señalar que WebKit también se usa en computadoras de escritorio, por ejemplo, en el navegador Safari, que es el navegador principal de la plataforma Mac OS X. Ya sea que se considere una versión de escritorio o un motor de navegador para iPhone o Android, WebKit sigue siendo la tecnología más avanzada. compatible con HTML y CSS. De hecho, WebKit admite estilos CSS que los navegadores aún no han representado en otros motores; por ejemplo, puede especificar una serie de propiedades definidas por la especificación HTML5.

HTML5 es un conjunto de especificaciones técnicas preliminares que definen tecnologías basadas en navegador, como el almacenamiento de datos del lado del cliente con soporte SQL, mover, transformar, etc. La especificación HTML5 aún no está completa, pero una vez que los fundamentos estén claramente articulados e implementados en los navegadores en la mayoría de las plataformas, los humildes comienzos de las aplicaciones web se convertirán en un pasado olvidado. El desarrollo de aplicaciones web ocupará un segmento importante en el desarrollo de software, y no se trata solo de aplicaciones para navegadores de escritorio, sino también de navegadores móviles. A partir de un subproducto, las aplicaciones móviles se convertirán en un producto básico en el mercado de aplicaciones web.

Características de diseño del desarrollo de aplicaciones web móviles

Una vez que haya tomado la decisión de dominar las tecnologías de desarrollo web, hay muy pocas herramientas a su disposición. En primer lugar, se puede crear una aplicación directamente en el servidor como un archivo que contiene código HTML, CSS y JavaScript. En este caso, el contenido HTML se puede entregar en forma de archivos HTML estáticos, o se puede generar dinámicamente mediante el uso de diversas tecnologías que trabajan en el lado del servidor, por ejemplo, como PHP, ASP.NET, Java Servlets, etc. En cualquier caso, desde el punto Desde el punto de vista de los problemas discutidos en este artículo, todo se reduce al código HTML, y aquí el punto más importante para nosotros es que la tecnología WebKit permite a los navegadores renderizar HTML en dispositivos móviles.

Para ejecutar una aplicación web en un dispositivo móvil (iPhone o Android), el usuario debe iniciar un navegador e ingresar la URL del servicio apropiado, por ejemplo: http://yourcompanyname.com/applicationurl.

Al mismo tiempo, la gama de aplicaciones web móviles ofrecidas es bastante amplia: desde un sitio web estándar hasta una aplicación web móvil desarrollada específicamente para una plataforma móvil específica.

Visualización de sitios estándar

El motor WebKit, combinado con la interfaz intuitiva y fácil de usar de las plataformas iPhone y Android, le permite ver casi cualquier sitio web en su dispositivo móvil. Las páginas web se muestran bastante correctamente, a diferencia de la generación anterior de navegadores móviles, que transportaban arbitrariamente partes de contenido o no las mostraban en absoluto. Cuando las páginas se cargan en un navegador compatible con WebKit, el contenido de la página tiende a escalar. En este caso, la escala se elige de modo que toda la página quepa en la pantalla, aunque en una forma muy reducida, a menudo ilegible, como se muestra en la Figura 1. Sin embargo, la página se puede desplazar, ampliar, mover, proporcionando un acceso conveniente a todos los elementos del contenido. ... De forma predeterminada, el navegador utiliza una ventana de 980px de ancho.

Si bien la visualización completa de una página web en una ventana del navegador es en sí misma una mejora significativa con respecto a la experiencia de los navegadores de generaciones anteriores, las capacidades de las tecnologías móviles modernas no se limitan a eso.

Páginas web optimizadas para dispositivos móviles

Si desea que su página web sea accesible tanto para usuarios móviles como para usuarios web en general, existen algunas otras opciones de optimización de aplicaciones web móviles que vale la pena considerar.

Aunque WebKit puede mostrar una página web correctamente en la pantalla de un dispositivo móvil, existe una diferencia entre los dispositivos que utilizan un mouse, como computadoras portátiles o de escritorio, y los dispositivos táctiles, como los teléfonos inteligentes iPhone o Android. Los dispositivos táctiles se distinguen por el tamaño físico del área de "clic", la ausencia de la función de pasar el cursor sobre cualquier elemento y otra secuencia de eventos. Por lo tanto, si desea crear un sitio web que sea conveniente para los usuarios generales y móviles, debe considerar las siguientes características de los dispositivos móviles:

Los navegadores de iPhone y Android son capaces de mostrar toda la página web en una forma bastante legible; la calidad de visualización de estos navegadores es mucho mayor que la de los navegadores móviles estándar, así que no se apresure a simplificar demasiado el diseño de su sitio.
El tamaño de las yemas de los dedos es mucho mayor que el tamaño del puntero del mouse. Considere este factor al diseñar los elementos de navegación de su sitio. No coloque enlaces demasiado cerca unos de otros, de lo contrario, el usuario no podrá hacer clic en un enlace sin tocar el adyacente.
Los elementos que se muestran al desplazar el mouse no funcionarán en dispositivos móviles. El usuario simplemente no puede "pasar" su dedo sobre ningún elemento de la misma manera que el cursor del mouse.
Los eventos determinados al presionar y mantener presionado el botón del mouse, arrastrar con el mouse, etc., se implementan en las pantallas táctiles de una manera diferente. Algunos de estos eventos pueden funcionar en dispositivos móviles, pero en general, no debe esperar que el navegador móvil y el navegador de escritorio realicen la misma secuencia de acciones.

Puede encontrar una discusión detallada de estos aspectos en el artículo " iPhone en acción"(Mira la sección). En este artículo, nos limitaremos a discutir las ventajas de WebKit, no sus desventajas.

Echemos un vistazo al problema más obvio que enfrentan los usuarios de iPhone o Android cuando acceden a sitios web: el tamaño limitado de la pantalla. De hecho, la pantalla de un dispositivo móvil moderno es de 320x480 o 480x320, siempre que el usuario prefiera ver el contenido web en configuración horizontal. Como puede ver en la Figura 1, WebKit puede mostrar correctamente una página web diseñada para computadoras de escritorio estándar. Sin embargo, cuando se aleja una página web, el texto puede ser demasiado pequeño para leerlo, por lo que el usuario tendrá que desplazarse, desplazarse y acercarse antes de poder leer el texto. ¿Cómo afrontar esta limitación?

La forma más sencilla de crear una página que se muestre igualmente bien en una ventana de navegador móvil y en una ventana de navegador de escritorio es utilizar una metaetiqueta personalizada ventana gráfica.

Una metaetiqueta es una etiqueta HTML que se coloca en el encabezado de un documento HTML. El ejemplo más simple de usar la etiqueta de la ventana gráfica se ve así: ... Cuando agrega esta metaetiqueta a una página HTML, su visualización en la ventana del navegador móvil se escala de la manera más óptima (consulte la Figura 2). Los navegadores que no admiten la ventana gráfica simplemente ignoran esta etiqueta.

En algunos casos, es útil predeterminar los parámetros de escala de la ventana, como se muestra en la Figura 3.

Para definir opciones de escala específicas, especifique el valor exacto para el atributo de contenido de la metaetiqueta de la ventana gráfica: ... Al cambiar el valor del parámetro de escala inicial, la imagen se puede reducir o ampliar. Para las plataformas iPhone y Android, es mejor usar valores entre 1.0 y 1.3. La metaetiqueta de la ventana gráfica también admite el escalado mínimo y máximo, lo que limita la capacidad del usuario para escalar la página mientras se carga.

Si bien las características de diseño del iPhone, en particular el tamaño de la pantalla de 320x480, se han mantenido prácticamente sin cambios desde sus inicios, los parámetros de los dispositivos en la plataforma Android tienen una gama bastante amplia, ya que los dispositivos móviles en esta plataforma son producidos por varios fabricantes y están destinados a una amplia variedad de grupos de usuarios. Por lo tanto, si desea que su aplicación web sea popular entre los usuarios de dispositivos móviles, debe tener en cuenta las posibles diferencias en los tamaños de pantalla, resoluciones y consideraciones de diseño para dispositivos Android.

La experiencia ha demostrado que, además de las diferencias de diseño entre varios dispositivos móviles Android, el propio software de Android intenta ajustar la configuración de la página web cargada según las propiedades del navegador del dispositivo móvil. Además de la estabilidad, la plataforma Android tiene un conjunto de características y capacidades en constante cambio. Es probable que la configuración de un dispositivo Android específico difiera de la de su entorno de desarrollo, según la versión del SDK y el fabricante del dispositivo. La figura 4 muestra la pantalla de configuración del navegador en el emulador de Android V1.6. La configuración de pantalla proporciona al usuario la capacidad de definir el nivel de zoom de la imagen en la pantalla (lejos, cerca, medio) o seleccionar el modo de escalado de página automático.

En el mundo de los dispositivos móviles, el cambio es el más constante, por lo que se debe considerar el desarrollo y la renovación del mercado de software móvil. Por ejemplo, la configuración del navegador de Sprint Hero incluye un conjunto de opciones que son completamente diferentes de la configuración predeterminada que se usa al cargar una página web. El navegador Hero se basa en la plataforma Android V1.5 utilizando una serie de modificaciones realizadas por HTC. Afortunadamente, la configuración específica de Hero se ignorará al usar la metaetiqueta de la ventana gráfica.

Hasta ahora, hemos visto que WebKit puede manejar la carga de una página web bastante bien, aunque en una forma muy reducida y difícil de leer. Luego ampliamos el control sobre cómo se muestra la página en la pantalla del móvil mediante el uso de la metaetiqueta de la ventana gráfica. La página mostrada ahora es mucho más fácil de leer y navegar. Pero esto todavía no es suficiente para que nuestra página se vea y funcione como una aplicación web.

Hecho para dispositivos móviles

Pasemos a analizar las características de diseño de una página web para una audiencia móvil. Como ejemplo concreto, considere la página de registro de correo electrónico de Google para GMail.

Así es como se ve esta página en una ventana del navegador de escritorio:

La ventana del navegador de escritorio muestra contenido informativo a la izquierda y la ventana de registro en sí está en el panel derecho. En una ventana del navegador móvil, la misma página tiene un aspecto completamente diferente.

La página que se muestra en la Figura 6 definitivamente está dirigida a usuarios móviles. La pantalla muestra solo los elementos de la página que son necesarios para que el usuario trabaje en el futuro; no se requiere desplazamiento, desplazamiento o escala adicionales.

Ahora veamos el visor de correo electrónico de la versión móvil de Gmail. Dado que el espacio de pantalla disponible para la aplicación es muy limitado, el visor de mensajes tiene botones y elementos de navegación adicionales. En este caso, los elementos de navegación mostrados se superponen a la ventana para ver los mensajes. Además, no use demasiados marcos o divs de desplazamiento si puede evitarlo. La versión móvil de Gmail resuelve este problema mediante el uso de un menú emergente que aparece tan pronto como el usuario termina de desplazarse por la página. El menú emergente contiene 3 botones: Archivo, Eliminar y Más... Pulsando el botón Más aparecen elementos de menú adicionales (consulte la Figura 7).

Esta es realmente una aplicación diseñada para dispositivos móviles.

Hay que tener en cuenta que no queremos empobrecer deliberadamente el diseño y reducir la experiencia de los usuarios móviles que han desarrollado navegadores multifuncionales para las plataformas iPhone y Android. Desde este punto de vista, es útil notar el elemento que se muestra en la parte inferior de la página de Gmail (ver Figura 8):

Si el usuario prefiere la funcionalidad extendida de la versión de escritorio, brinde la opción de descargar la versión apropiada de la página.

Ahora considere el caso en el que desea crear una aplicación que utiliza tecnologías web, pero parece una aplicación móvil nativa.

Contenido específico de la plataforma

El siguiente paso es desarrollar contenido específico para una plataforma móvil específica. Esto define el formato y la interfaz de la página para que la página resultante parezca una aplicación nativa para una plataforma en particular, en lugar de un sitio web público estándar. ¿Qué entendemos por aplicación "nativa"?

Antes de sumergirnos en la discusión sobre cómo hacer que una aplicación web sea lo más similar posible a una aplicación nativa para una plataforma en particular, dejemos de lado las propiedades generales de los navegadores de iPhone y Android y analicemos brevemente las diferencias visuales entre estas plataformas.

Las aplicaciones de iPhone tienen su propio aspecto e interfaz específicos. Muestre a alguien una captura de pantalla del iPhone y, a menos que esta persona literalmente se cayera de la luna el otro día, es casi seguro que dirá de inmediato que es un iPhone. Muestre a la misma persona una captura de pantalla de un dispositivo móvil Android y la respuesta no será tan clara. ¿Cuál es la razón? hay varias explicaciones posibles. En primer lugar, el iPhone apareció en el mercado mucho antes que los dispositivos Android y logró adquirir una gran cantidad de fanáticos. Piense en la gente haciendo cola para pagar mucho dinero por las capacidades limitadas del iPhone V1. Te guste o no el iPhone, este producto de Apple es actualmente el líder del mercado. ¿Y Android?

La plataforma Android es un producto relativamente nuevo y, en muchos sentidos, actúa como lo opuesto al iPhone, ya que está diseñado principalmente para la comunidad abierta. La plataforma Android se utiliza en una amplia variedad de dispositivos (teléfonos y otros electrodomésticos). Para facilitar la discusión, este artículo nos limitará a usar Android en teléfonos móviles.

Con el tiempo, la cantidad de dispositivos Android en el mundo superará la cantidad de iPhones. Esto se debe a que los dispositivos Android son fabricados por una variedad de empresas y serán compatibles con una amplia variedad de redes de datos. Con un número tan significativo de jugadores en el mercado móvil de Android, no hay duda de que se debe esperar cierta fragmentación del mercado en función de la apariencia y los parámetros de los dispositivos. Esta tendencia es evidente en HTC SenseUI. Esta apariencia atractiva no es compatible con el SDK de Android base y no es compatible con otros dispositivos Android. Motorola, Google y Verizon han unido fuerzas para desarrollar un nuevo dispositivo DROID basado en Android. Este es el primer producto comercial en la plataforma Android 2.0.

Compare la diversidad de los sistemas Android con la apariencia uniforme del iPhone. El iPhone es una propiedad particularmente valiosa de Apple. La apariencia de las aplicaciones de iPhone puede cambiar ligeramente con el tiempo, pero es poco probable que estos cambios menores se comparen con las diversas versiones de los sistemas Android, cuyo número es bastante grande incluso ahora, cuando la plataforma se encuentra en sus primeras etapas.

Entonces, ¿qué se debe hacer para que la apariencia y la interfaz de la aplicación sean lo más parecidas posible a los programas "nativos"?

Si este fuera el desafío antes de la Web 2.0, sería un gran problema. Los primeros intentos de admitir varios navegadores de clientes (móviles y de escritorio) se basaron en varios enfoques, por ejemplo:

Desarrollo de sitios completamente paralelos
Generación de contenido dinámico en función del parámetro userAgent
El uso de servidores proxy que podrían transformar el contenido en función de cada dispositivo específico. Esta tecnología ha sido utilizada con éxito por RIM para proporcionar acceso al correo electrónico desde el dispositivo móvil de un cliente.

Estos enfoques pueden ser bastante aceptables en los casos en que el desarrollo lo llevan a cabo equipos grandes y bien financiados. ¿Y el resto del mundo? No todo el mundo tiene recursos económicos importantes, especialistas altamente calificados y tiempo ilimitado para implementar tales estrategias. Además, como ya hemos señalado, la Internet móvil de la generación anterior de navegadores no puede considerarse conveniente o popular de usar, por lo que, en cualquier caso, no se detenga en métodos y enfoques obsoletos.

Afortunadamente, no tenemos que hacer esto. En la era de WebKit y CSS, la diferencia en la apariencia de los diferentes dispositivos móviles se puede salvar mediante el uso de hojas de estilo y consultas de medios para permitir diferentes estilos según el tipo específico de dispositivo. La tecnología de consultas de medios le permite obtener información sobre el cliente. Tradicionalmente, el navegador envía un valor userAgent al servidor, lo que permite que el servidor identifique un navegador en particular y determine el contenido que se entregará al cliente. Mediante una consulta de medios, el navegador elige el estilo de la página en función de sus capacidades. El siguiente ejemplo demuestra la selección de una hoja de estilo para teléfonos inteligentes: ... Y esta consulta define una hoja de estilo para escritorios: .

Internet Explorer V6

En el momento de escribir este artículo, Internet Explorer V6 tiene una participación de aproximadamente el 20-30% del mercado total de navegadores, pero IE V6 está más allá del alcance de este artículo.

Puede encontrar más información sobre las consultas de medios en el borrador de la especificación (consulte la sección).

Consideremos un ejemplo del uso de consultas de medios para desarrollar una aplicación que muestra el estado de los servidores de red.

Programa de monitoreo de redes

El propósito de esta aplicación es monitorear el funcionamiento de múltiples servidores. Los proveedores de software independientes a menudo tienen que admitir varias aplicaciones en varios servidores. Si ha estado desarrollando software durante un tiempo significativo, probablemente ya se haya encontrado con diferentes tipos de servidores y diferentes tipos de aplicaciones. Todo esto significa que una situación es bastante posible cuando no puede usar una sola herramienta para rastrear el trabajo de todas las aplicaciones necesarias. En este caso, tiene sentido utilizar una aplicación móvil para el monitoreo de la red (netmon). La aplicación proporciona todas las funciones necesarias sin dejar de ser flexible y de fácil acceso desde un dispositivo móvil.

La aplicación netmon incluye una lista de servidores para monitorear. Los indicadores clave de rendimiento (KPI) se recopilan para cada servidor. Los KPI son la herramienta principal que los estudiantes de MBA han utilizado durante muchos años para evaluar el estado actual de una empresa. Desde una perspectiva de alojamiento de aplicaciones web, las siguientes métricas se pueden utilizar como KPI:

Número de transacciones durante el último período de tiempo
- Pedidos
- Solicitudes de directorio
- Mensajes de correo electrónico
- Vistas de página
Tiempo transcurrido desde la última transacción
- Orden
- Intercambio de datos electrónicos
- Mensajes de un socio comercial
- Carga de archivos del proveedor a través de FTP
¿Está disponible la base de datos?
Fecha de la última copia de seguridad
Monto promedio del pedido (USD)
Espacio libre en disco
Ancho de banda para la última hora, día, mes

Las métricas anteriores y otros parámetros operativos similares le permiten evaluar el estado de un sistema o aplicación específicos. Por ejemplo, durante la temporada navideña, revisamos la cantidad de pedidos realizados en algunos de nuestros sitios. Si los datos no muestran un aumento constante en el número de pedidos cada hora, realizamos un análisis más detallado de la situación.

Dado que una aplicación en particular requiere sus propias condiciones y recursos, netmon debe ser lo suficientemente flexible para adaptarse a las características específicas de cada aplicación. Para proporcionar este nivel de flexibilidad, comenzamos por definir la estructura de datos más general para acomodar el estado de cada sistema. En la Parte 2, veremos más de cerca de dónde provienen estos datos y cómo se actualizan. Por ahora, nos limitaremos a la siguiente información:

Nombre del sitio
URL del sitio (página de inicio)
URL para recibir actualizaciones
Estado: OK o no
Breve: una descripción del estado del servidor, que estará bien o contendrá una cadena de texto que indique el problema más grave para ese servidor
Elementos: este es un conjunto de pares de nombre / valor que necesitamos para comunicar los valores actuales de KPI para el sitio respectivo.

Nuestra aplicación mostrará los indicadores de rendimiento resultantes de una manera fácil de navegar, aprovechando al máximo el poder de CSS, jQuery y WebKit para llamar la atención del usuario sobre áreas problemáticas. Como ya mencionamos, el objetivo principal al desarrollar esta aplicación es poder ejecutarla en el iPhone, Android y computadoras de escritorio en el navegador Safari.

Desarrollo de aplicaciones de monitoreo de redes

Las páginas web modernas deben crearse de forma declarativa que defina la estructura organizativa y el contenido de la página. El posicionamiento y el formato de la página se realiza mediante hojas de estilo CSS en cascada y, en la mayoría de los casos, mediante JavaScript. De hecho, las bibliotecas de JavaScript se han vuelto tan populares que su uso hoy en día es más la regla que la excepción. En la aplicación que se analiza en este artículo, usaremos la popular biblioteca de JavaScript jQuery. Nuestra aplicación se ejecutará en las plataformas iPhone, Android y de escritorio. Esto utilizará el mismo código HTML e implementará las diferencias necesarias en las hojas de estilo. Cabe señalar aquí que deliberadamente no hicimos ningún esfuerzo significativo para desarrollar una apariencia atractiva para la aplicación. Además, el fondo se eligió deliberadamente para que fuera pegadizo, fuera de armonía entre sí, a fin de llamar la atención adicional del lector sobre la organización de las hojas de estilo. En la Parte 2, mejoraremos ligeramente la apariencia de la aplicación, pero por ahora su HTML se parece al que se muestra en el Listado 1.

Listado 1. Código HTML de la aplicación

Mis recursos de red

Mi agente de usuario

Un vistazo rápido al código HTML propuesto revela las siguientes características principales:

El código utiliza dos archivos JavaScript externos: un archivo de biblioteca jQuery y un archivo auxiliar para nuestra aplicación.
El código utiliza la metaetiqueta de la ventana gráfica para escalar el contenido mostrado.
La hoja de estilo principal está definida por el archivo netmon.css.
El parámetro userAgent se utiliza para definir la hoja de estilo auxiliar. Dependiendo de su valor, se cargará una hoja de estilo para iPhone, Android o para un navegador de escritorio.
Durante la carga de la página, jQuery y una función auxiliar definida en el archivo netmon.js se utilizan para mostrar los datos.
Hay varias etiquetas div utilizadas en el código principal de la página.
Finalmente, en el código, hay un enlace a una página que muestra la cadena userAgent. Este enlace no tiene nada que ver con la aplicación y se utiliza únicamente con fines de demostración.

Antes de entrar en una vista detallada de las hojas de estilo y el archivo netmon.js que realmente definen el funcionamiento básico de la aplicación, echemos un vistazo a nuestra aplicación en su estado actual. Tenga en cuenta nuevamente que estamos usando tres hojas de estilo diferentes, una para cada una de las tres plataformas compatibles. Para que el proceso de desarrollo de la aplicación sea más visual, cada tabla define su propio color de fondo. En la Figura 9, nuestra página está abierta en Desktop Safari y tiene un fondo azul.

La Figura 11 muestra la apariencia de la aplicación en una ventana del navegador de iPhone (el color de fondo es verde).

La hoja de estilo principal almacenada en el archivo netmon.js se muestra en el Listado 2.

Listado 2. Hoja de estilo principal

body (color: # 888888; font-family: Helvetica; font-size: 14px; margin: 0px; padding: 0;) .details (margin: 0px; padding: 0px; background-color: white; border: solid; border -width: 1px; -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border-bottom-left-radius: 8px; -webkit-border-bottom -radio-derecho: 8px;) .OK (color: # 000000;) .BAD (color: # ff0000;) .odd (imagen de fondo: -webkit-gradient (lineal, arriba a la izquierda, abajo a la derecha, de (#ccc ), a (# 999));) .even (background-image: -webkit-gradient (lineal, arriba a la izquierda, abajo a la derecha, desde (# 999), a (#ccc));) .serverentry a (float: right; color: #ffffff;) .serveritems (color: # 000;) #header h1 (margin: 0; padding: 0; text-align: center; color: # 000;)

El uso de una hoja de estilo personalizada para cada plataforma le permite realizar las siguientes tareas:

Cambia el esquema de color de la página. Esto permite, en primer lugar, demostrar claramente el papel de la hoja de estilo y, en segundo lugar, mostrar lo fácil que es seleccionar la hoja de estilo deseada según el valor del parámetro userAgent.
Establezca diferentes tamaños de fuente para plataformas móviles y de escritorio.
Verifique las características correspondientes de WebKit. Esto sería significativo si la aplicación se estuviera ejecutando en un navegador sin compatibilidad con WebKit, como Firefox.

El Listado 3 muestra el código del archivo iphone.css.

Listado 3. El archivo iphone.css

body (background-color: # 00ff00;) .serverentry (-webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border-bottom-left-radius: 8px; -webkit-border-bottom-right-radius: 8px;) .name (font-size: 2em;) .summary (font-size: 1.5em;) .serverentry a (font-size: 1.5em;)

Como podemos ver, el color de fondo de la etiqueta del cuerpo es verde (# 00ff00) y el tamaño de la fuente se ajusta para facilitar la lectura en la pantalla del dispositivo móvil. Finalmente, echemos un vistazo al archivo netmon.js, que define una lista de servidores y una función que genera datos para cada servidor (usado en el Listado 4). Por brevedad, se ha omitido parte del código del archivo; su texto completo está disponible en la sección).

Listado 4. El archivo netmon.js

var netmon \u003d (initialize: function () (), resources: [(nombre: "msiservices.com", homeurl: "http://msiservices.com", pingurl: "http://msiservices.com/netmon.php ", estado:" OK ", resumen:" OK ", elementos: [(nombre:" DiskSpace ", valor:" 22.13 GB "), (nombre:" ¿Base de datos activada? ", valor:" Sí ")]), (nombre: "servidor 2", homeurl: "http: // algunaurl", pingurl: "http: //someurl/netmon.jsp", estado: "OK", resumen: "OK", elementos: [(nombre: "DiskSpace", valor: "100.8 GB"), (nombre: "Database Up?", Value: "Yes")]), // entradas adicionales recortadas para abreviar], render: function (index, itm) (try ( var ret \u003d "; ret + \u003d"

"; ret + \u003d" "+ itm.name +" mostrar
"; si (itm.status! \u003d" OK ") (ret + \u003d" - "+ itm.summary +"
";) ret + \u003d"

"; jQuery.each (itm.items, function (j, itemdetail) (ret + \u003d"\u003e "+ itemdetail.name +" \u003d "+ itemdetail.value +"
";)); ret + \u003d"

"; ret + \u003d"

"; return ret;) catch (e) (return"

Error al representar el elemento ["+ itm.name +"] "+ e +"

"; } } };

Si la barra de estado de cualquier servidor no está bien, entonces el registro del servidor correspondiente se muestra en rojo, como se ve en la definición de clase en el archivo CSS. Además, si la verificación del estado del servidor reveló algún problema (el estado no es igual a OK), también se muestra una breve descripción del problema. En las figuras 9-11, puede ver que el servidor 4 se está quedando sin espacio libre en el disco. Al hacer clic en la línea de este servidor, se mostrará un mensaje detallado sobre el problema (consulte la Figura 12).

Haciendo clic en el enlace show a la derecha del nombre del servidor, se abre la página de inicio de ese servidor. Tener un enlace de este tipo es muy conveniente por dos razones: primero, le ahorra la molestia de tener que memorizar la URL de cada servidor, y segundo, le ahorra la necesidad aún más frustrante de ingresar esa URL desde el teclado de su dispositivo móvil ( incluso el más conveniente).

Entonces, si podemos ejecutar netmon con éxito en un dispositivo móvil, la tarea de soporte del servidor no debería causar ningún problema.

Conclusión

Este artículo presenta los principios del desarrollo de aplicaciones web para iPhone y Android utilizando la tecnología WebKit. En la Parte 2, ampliaremos las capacidades de nuestra aplicación agregando una función para actualizar datos usando llamadas Ajax.

Transferir

Kit web no es caja negra. Esta es una caja blanca. Y no solo blanco, sino también abierto caja.

Así que intentemos averiguar algunas cosas:

¿Qué es WebKit?
¿Qué no es WebKit?
¿Cómo utilizan WebKit los navegadores WebKit?
¿Por qué muchos WebKits no son iguales?

Componentes estándar del navegador web

Enumeremos algunos componentes de los navegadores modernos:

Análisis (análisis de HTML, XML, CSS, Javascript)
Diseño
Representación de texto y gráficos
Decodificar imágenes
Interacciones de GPU
Acceso a la red
Aceleracion de hardware

¿Cuáles son comunes a todos los navegadores WebKit? Prácticamente solo los dos primeros.

El resto de componentes que cada "puerto" de WebKit implementa a su manera. Veamos qué significa esto.

Puertos de WebKit

Hay muchos "puertos" de WebKit y yo proporciono Aria Hidayat, hacker de WebKit y esos. el director de Sencha tiene derecho a informar al respecto:

La asociación más popular con WebKit suele ser el tipo de WebKit de Apple, que se ejecuta en Mac OS X (la primera y original biblioteca de WebKit). Como puede imaginar, las diversas interfaces se implementan utilizando varias bibliotecas nativas de Mac OS X, principalmente en el componente CoreFoundation Por ejemplo, si define un botón plano de color con un radio de contorno especial, WebKit sabe dónde y cómo dibujar ese botón, mientras que la representación final del botón (como píxeles en el monitor del usuario) recae en CoreGraphics.

Como mencioné anteriormente, los CoreGraphics utilizados son únicos para cada puerto de WebKit. Chrome para Mac, por ejemplo, usa Skia.

En algún momento, WebKit fue portado a diferentes plataformas, tanto de escritorio como móviles. Esta variación se conoce comúnmente como el "puerto WebKit". Para Safari Windows, Apple también "portó WebKit" de forma independiente para ejecutarlo en Windows usando su biblioteca CoreFoundation (implementación limitada).

... a pesar de que Safari para Windows ya está muerto.

Aparte de eso, también había muchos otros "puertos" (ver lista completa). Google ha creado y sigue manteniendo su puerto de Chromium. También existe WebKitGtk basado en Gtk +. Nokia (y ahora Trolltech, quien lo compró) mantiene el puerto WebKit Qt, que se ha vuelto popular como módulo QtWebKit.

Algunos puertos de WebKit

Safari
- Safari en OS X y Safari en Windows dos puertos diferentes
- WebKit Nightly Build es una compilación del código fuente para el "puerto" de Mac utilizado por Safari, solo que más reciente
Safari móvil
- Desarrollado en una sucursal privada, pero luego se abrió.
- Chrome para iOS (usa WebView de Apple; un poco más adelante sobre la diferencia)
Cromo (cromo)
- Chrome para Android (utiliza el "puerto" de Chromium directamente)
- Chromium también es la base de los navegadores: Yandex ,, Sogou y, próximamente, Opera.
Navegador de Android
- Utiliza el último código fuente de WebKit disponible en el momento del lanzamiento.
Incluso más puertos: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK +, el puerto EFL (Tizen), wxWebKit, WebKitWinCE, etc.

Qué es común en todos los navegadores WebKit

Primero, echemos un vistazo a las características comunes que se utilizan en todos los navegadores WebKit:

Sabes que esto es gracioso, hice varios intentos para escribir este párrafo. Y cada vez que los miembros del equipo de Chrome me corrigieron, como verán ...

Entonces, en primer lugar, WebKit analiza HTML de la misma manera. Bueno, excepto que Chromium es el único puerto actualmente con soporte de transmisión para análisis HTML habilitado.
... Ok, pero después de analizar el HTML, el árbol DOM se construye de la misma manera. Bueno, en realidad Shadow DOM solo está habilitado para el puerto de Chromium, por lo que la construcción de DOM varía. También para elementos personalizados.
... Bueno, WebKit crea objetos de ventana y documento iguales para todos. Es cierto, aunque las propiedades y construcciones que proporcionan pueden depender del uso de indicadores de características.
... Analizar el CSS es lo mismo. Comer su CSS y convertirlo a CSSOM es bastante estándar. Sí, aunque Chrome solo admite los prefijos -webkit-, mientras que Apple y otros navegadores admiten los prefijos obsoletos -khtml- y -apple-.
... Layout ... posicionamiento? Es como pan y mantequilla. Es lo mismo en todas partes, ¿verdad? ¡Pues ya! El diseño de subpíxeles y la aritmética de diseño enriquecido son parte de WebKit, pero difieren de un puerto a otro.
Súper.

Entonces esto es difícil.

Ahora, intentemos resumir lo que es común en el mundo de WebKit ...

Lo que es común para cada puerto de WebKit.

DOM, ventana, documento
más o menos
CSSOM
Análisis de la propiedad / valor de CSS
diferencias en los prefijos del fabricante
Analizando HTML y construyendo el DOM
Es lo mismo si nos olvidamos de los componentes web.
Disposición y posicionamiento
Flexbox, Floats, contexto de formateo de bloques ... todo en común
Herramientas de interfaz de usuario y herramientas de desarrollo como Chrome DevTools, también conocido como inspector de WebKit.
Aunque desde abril pasado, Safari utiliza su propio inspector de Safari, no WebKit, de código cerrado.
Funciones como contenteditable, pushState, File API, la mayoría de SVG, CSS transform math, Web Audio API, localStorage
Sin embargo, la implementación puede diferir. Cada puerto puede usar su propio almacenamiento para localStorage y puede usar una API de audio diferente para la API de Web Audio.

Se está volviendo un poco confuso, así que intentemos ver algunas de las diferencias.

Ahora, lo que no es común para los puertos WebKit:

Cualquier cosa relacionada con la GPU
- Transformaciones 3D
- WebGL
- Decodificación de video
Dibujar 2D en la pantalla
- Tecnologías anti-aliasing
- Representación de degradados SVG y CSS
Representación de texto y separación de palabras
Tecnologías de red (SPDY, pre-renderizado, transporte WebSocket)
Motor de JavaScript
- El motor JavaScriptCore está en el repositorio de WebKit. Pero hay enlaces en WebKit tanto para él como para V8.
Representación de elementos de formulario
Comportamiento de etiquetas de audio y video y compatibilidad con códecs
Decodificación de imágenes
Navegación hacia atrás / adelante
- La parte pushState ()
Funciones SSL como estricta seguridad de transporte y pines de clave pública

Echemos un vistazo a uno de ellos: Gráficos 2D Depende del puerto, usamos bibliotecas completamente diferentes para renderizar en la pantalla:

El diagrama debería ayudar:

Muchos de los componentes de WebKit son intercambiables (se muestran en gris).

“WebKit es como un sándwich. De lo contrario, en el caso de Chromium, es más como un taco. Deliciosos tacos de tecnologías web.
Dmitri Glazkov, hacker de Chrome WebKit. Campeón de Web Componets y shadow dom.

	Chrome (OS X)	Safari (OS X)	QtWebKit	Navegador de Android	Chrome para iOS
Representación	Skia	CoreGraphics	QtGui	Pila de Android / Skia	CoreGraphics
Redes	Pila de red de Chromium	CFNetwork	QtNetwork	Bifurcación de la pila de red de Chromium	Pila de cromo
Fuentes	CoreText a través de Skia	CoreText	Internos de Qt	Pila de Android	CoreText
JavaScript	V8	JavaScriptCore	JSC (V8 se usa en otras partes de Qt)	V8	JavaScriptCore (sin JITting) *

Bien, entonces ¿a dónde vinimos?

Y así, todo WebKit ahora es completamente diferente. Estoy asustado.

Opera acaba de trasladarse a WebKit. ¿Qué saldrá de eso?

... y una compilación nocturna de WebKit. ¿Qué es?

Este es WebKit, que se ejecuta en el mismo código que Safari (aunque algunas bibliotecas internas han cambiado). Principalmente Apple lo ejecuta, por lo que el comportamiento y el conjunto de funciones coinciden con lo que encontrará en Safari. En muchos casos, Apple es conservador cuando se trata de habilitar funciones que otros puertos implementan o experimentan. De todos modos, para usar analogías, piense que ... una compilación nocturna de WebKit para Safari es como Chromium para Chrome.

navegadores web

desarrollo web

Agregar etiquetas

Un motor de navegador es un programa especial que funciona con páginas web. Procesa una página HTML descargada de Internet y transforma su código en una representación familiar para los usuarios. Los motores de navegador de Internet se utilizan en los propios navegadores, así como en los clientes de correo electrónico. No todos los navegadores web se basan en su propia plataforma única. Muchos de ellos utilizan soluciones populares y probadas por el tiempo. Este artículo analiza qué plataformas existen para crear navegadores y en qué se diferencian entre sí.

El uso de un motor de renderizado para crear navegadores tiene muchas ventajas:

Facilita la búsqueda y eliminación de errores de código.
Una oportunidad conveniente para mejorar un solo componente en varios programas a la vez.
Se facilita el proceso de cambio de la interfaz gráfica de la aplicación.
Se necesita facilidad para crear nuevos programas para los deseos de un desarrollador específico o de un usuario específico.

Estas soluciones se utilizan con mucha frecuencia en la programación: al crear videojuegos, sistemas operativos para programas complejos, etc. Algunos especialistas están trabajando para mejorar y optimizar el motor, introduciendo nuevas características y funciones útiles en él. Otros se dedican a la creación de los propios programas basados \u200b\u200ben la plataforma desarrollada.

Un buen ejemplo es el motor Trident de Microsoft. Solo se utiliza en una amplia variedad de aplicaciones en una empresa determinada. La base se está desarrollando, también se están desarrollando proyectos derivados.

Cada solución tiene sus pros y sus contras. Por ejemplo, muchos usuarios notan que Mozilla Firefox funciona mucho mejor con más pestañas abiertas que la competencia. Este es un logro de la plataforma en la que está construido el navegador.

Tridente

Cuando un usuario instala un nuevo sistema operativo Windows, el primer navegador web que encuentra es Internet Explorer. Por lo tanto, su motor se considera el primero en la revisión.

Trident, o MSHTML, es un componente de software bastante antiguo desarrollado por Microsoft para sus propias necesidades. El proyecto se ha desarrollado continuamente desde 1997. Se utiliza en el navegador web de Microsoft: Internet Explorer, cliente de correo de Outlook, Windows Explorer (un programa de administración de archivos) y muchas otras aplicaciones de este desarrollador.

Es considerado uno de los motores de navegación con menos éxito por parte de los usuarios. No admite extensiones modulares de terceros: complementos, muestra incorrectamente muchas páginas de Internet, no tiene la velocidad más rápida.

Con el lanzamiento de Windows 10, la plataforma Trident evolucionó a EdgeHTML, tomando como base un motor obsoleto y fallido y creando uno nuevo que satisface todas las necesidades de los usuarios de hoy. A juzgar por los puntos de referencia (rendimiento del software y prueba de velocidad), Microsoft Edge (un navegador basado en EdgeHTML) alcanzó e incluso superó los programas populares utilizados para crear los navegadores Google Chrome y Mozilla Firefox.

Geco

Gecko es el motor utilizado en el popular navegador de Internet Mozilla Firefox y muchos otros programas. El código fuente del programa está disponible gratuitamente, es decir, cualquiera puede crear su propio navegador o cliente de correo electrónico basado en Gecko de forma totalmente gratuita.

Otra ventaja de Gecko es multiplataforma. Funciona en la gran mayoría de los sistemas operativos modernos: tanto para computadoras personales como para dispositivos móviles (a diferencia de Internet Explorer, que solo se ejecuta en Windows).

Gecko es compatible con todos los estándares y tecnologías modernos utilizados en el desarrollo de sitios web. Es una de las dos plataformas de navegador más populares. Admite la conexión de complementos. Los puntos de referencia y la experiencia personal de los usuarios muestran que los navegadores de este motor consumen la menor cantidad de recursos de una computadora personal y funcionan de manera estable con una gran cantidad de pestañas (por ejemplo, varios cientos).

Sobre la base de Gecko, se crean el popular navegador de Internet Mozilla Firefox, el cliente de correo Thunderbird, el programador de tareas Sunbird y un navegador web anónimo con soporte integrado para tecnologías VPN Tor.

KHTML

Una plataforma oscura utilizada para construir Konqueror, el administrador de archivos para el entorno KDE. Para los usuarios que no están familiarizados con los sistemas operativos de la familia Linux, es interesante porque a partir de este proyecto se ha creado el motor más popular del mundo, del que hablaremos más adelante.

WebKit

Este motor fue desarrollado por la mundialmente famosa corporación Apple basándose en la solución mencionada anteriormente: KHTML. Lanzado en 2001, este proyecto ha experimentado un desarrollo colosal y se ha convertido en uno de los más utilizados en el mundo.

Basado en WebKit, se creó el navegador web Safari, utilizado por defecto en los dispositivos iOS y líder en popularidad entre los navegadores: Google Chrome. La inmensa mayoría de los programas modernos para procesar el contenido de las páginas web se basan en WebKit. También se utiliza en la popular aplicación Steam para la distribución digital de juegos de PC de Valve.

Similar a Gecko, WebKit es multiplataforma y funciona muy bien en todas las plataformas populares. Muestra una gran estabilidad y rendimiento. Debido a la inmensa popularidad, la gran mayoría de extensiones se están desarrollando para esta solución. También se utiliza en plataformas móviles populares como Android e iOS. Es un motor gratuito, es decir, puede ser utilizado por cualquier persona de forma gratuita para crear sus propias aplicaciones.

En 2013, una nueva sucursal perteneciente a la corporación Google, Blink, se separó de WebKit. Este proyecto formó la base de la versión 28 de Chrome (y todas las posteriores), así como de su primo de código abierto, Chromium. Chromium se utiliza para crear el navegador Yandex, popular en Rusia. A partir de la versión 15, el navegador Opera también cambió a Blink.

Presto

Lanzado en 2003, el motor del navegador Presto se utilizó como base para Opera. Se ha estado desarrollando durante 10 años. En 2013, los desarrolladores de Opera decidieron deshacerse de Presto en favor del Blink más poderoso y popular de Google. Por el momento, el desarrollo del proyecto está parado.

¿Te resultó útil este artículo

En este artículo, veremos tres navegadores del popular motor WebKit. Cuando se trata de elegir un navegador web, los usuarios tienden a buscar los programas más famosos: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. Al mismo tiempo, muchos olvidan o no saben que los mismos Firefox, Chrome y, más recientemente, Opera se crean en base a proyectos de código abierto, lo que significa que estos programas se pueden modificar.

Esta oportunidad lleva al hecho de que muchos programadores han creado varios análogos de navegadores populares que ofrecen características bastante interesantes. Entonces, veamos varios representantes de dicho software.

Se distribuye de forma gratuita, tiene una interfaz rusa, funciona en Windows, Android, Mac, iOS. Este navegador hace diez años se conocía como MyIE2 y era un complemento de Internet Explorer, pero desde entonces ha cambiado mucho y ahora el programa utiliza el motor Webkit por defecto.

En la última versión, cuarta, el navegador ofrece varias funciones útiles, entre las cuales la más interesante es la capacidad de almacenar información en la "nube". Esto permite usar una cuenta en el programa para transferir información entre diferentes dispositivos, ya sea un dispositivo Android, un producto de campaña de Apple o una PC estacionaria.

Aunque la interfaz de Maxthon Cloud Browser está hecha al estilo de Chrome, tiene muchas más funciones. La barra lateral muestra iconos para acceder a las extensiones. Es conveniente que con un clic pueda deshabilitar o habilitar todos los complementos instalados, y puede descargar otros nuevos desde un sitio especial.

Se distribuye de forma gratuita, tiene una interfaz rusa, funciona en Windows. Un producto de Comodo, mejor conocido como desarrollador de software de seguridad. Comodo Dragon ya no es un desarrollo, sino un ensamblaje, ya que en términos de funcionalidad se diferencia poco de Chrome.

No hay muchas diferencias con el navegador original y todas se relacionan con problemas de seguridad. La primera diferencia clave con Google Chrome es el modo realmente de incógnito, Comodo Dragon no usa una ID de usuario única y HTTP-REFERRER, que no permite rastrear al usuario en la red.

La segunda diferencia radica en el negocio principal de Comodo, la seguridad del usuario. Asume que tiene sus propios servidores DNS seguros para la transmisión del tráfico. Además, a petición del usuario, el tráfico no solo de Dragon, sino también de todas las demás aplicaciones puede pasar por ellos. Los servidores DNS seguros bloquean automáticamente el acceso a los sitios que se han marcado como no confiables en la propia red de definición de amenazas web de Comodo.

Se distribuye de forma gratuita, tiene una interfaz rusa, funciona en Windows. Yandex Browser es un navegador basado en Chromium lanzado recientemente por la empresa rusa Yandex. En este producto, los desarrolladores simplemente agregaron los servicios de Yandex al panel de enlaces rápidos. También se agregó y mejoró el modo "Turbo", que se puede encontrar en Opera. En general, resultó no ser un mal navegador dirigido a los usuarios de Yandex.