TUTORIALES ACTUALIZACIONES RECURSOS

109 Comments and 5 Reactions

Cómo funcionan los navegadores: lo que hay detrás de los navegadores webactuales

Publicación ago. 5, 2011By Tali Garsiel & Paul Irish

Este completo manual sobre las operaciones internas de WebKit y Gecko es el resultado de las extensas investigaciones realizadas por ladesarrolladora israelí Tali Garsiel. Durante varios años ha estado revisando toda la información publicada sobre las característ icas internas delos navegadores web (consulta la sección Recursos) y ha pasado mucho t iempo leyendo su código fuente. Tali escribió lo siguiente:

Tali ha publicado su investigación en su sitio web , pero como sabíamos que se merecía un público más amplio, lo hemos publicado aquí tambiéntras hacer algunas modificaciones.

Como desarrolladora web, conocer las características internas de las operaciones de los navegadores sirve para tomarmejores decisiones y para conocer los motivos que justifican las prácticas de desarrollo recomendadas. Aunque se tratade un documento bastante extenso, te recomendamos que dediques un poco de tu t iempo a examinarlo. Ten por seguro que no tearrepentirás.

Paul Irish, Relaciones con desarrolladores de Chrome

Prólogo

PDFmyURL.com

Los navegadores son probablemente el software más utilizado de todos. En este manual se explica su funcionamiento interno. Veremosqué ocurre cuando escribes google.com en la barra de direcciones hasta que la página de Google aparece en la pantalla.

1. Introducción

1. Los navegadores de los que hablaremos

2. La función principal de un navegador

3. Componentes principales del navegador

2. El motor de renderización

1. Motores de renderización

2. El flujo principal

3. Ejemplos del flujo principal

3. Análisis y construcción del árbol de DOM

1. Análisis (general)

1. Gramáticas

2. Analizador: combinación de analizadores léxicos

3. Traducción

4. Ejemplo de análisis

5. Definiciones formales de vocabulario y sintaxis

6. Tipos de analizadores

7. Cómo generar analizadores automáticamente

2. Analizador de HTML

1. Definición de gramática HTML

2. No es una gramática libre de contexto

3. DTD de HTML

4. DOM

Introducción

Índice

PDFmyURL.com

5. El algoritmo de análisis

6. El algoritmo de tokenización

7. Algoritmo de construcción de árbol

8. Acciones al finalizar el análisis

9. Tolerancia a errores de los navegadores

3. Análisis de CSS

1. Analizador de CSS de WebKit

4. Orden de procesamiento de secuencias de comandos y hojas de estilo

1. Secuencias de comandos

2. Análisis especulativo

3. Hojas de estilo

4. Construcción del árbol de renderización

1. Relación del árbol de renderización con el árbol de DOM

2. El flujo de construcción del árbol

3. Computación de estilos

1. Datos de estilo compartidos

2. Árbol de reglas de Firefox

1. División en estructuras

2. Cómo computar los contextos de estilo con el árbol de reglas

3. Cómo manipular las reglas para obtener coincidencias fácilmente

4. Cómo aplicar las reglas en el orden de cascada correcto

1. Orden en cascada de la hoja de estilo

2. Especificidad

3. Cómo ordenar las reglas

4. Proceso gradual

5. Diseño

1. Sistema de bit de modifiación (dirty bit)

2. Diseño global e incremental

PDFmyURL.com

3. Diseño asíncrono y síncrono

4. Optimizaciones

5. El proceso de diseño

6. Cálculo del ancho

7. Salto de línea

6. Pintura

1. Global e incremental

2. Orden del proceso de pintura

3. Lista de visualización de Firefox

4. Almacenamiento de figuras rectangulares de WebKit

7. Cambios dinámicos

8. Subprocesos del motor de renderización

1. Bucle de eventos

9. Modelo de formato visual de CSS2

1. El elemento canvas

2. Modelo de cajas de CSS

3. Esquema de posicionamiento

4. Tipos de cajas

5. Posicionamiento

1. Relativo

2. Flotante

3. Absoluto y fijo

6. Representación en capas

10. Recursos

En la actualidad se utilizan principalmente cinco navegadores: Internet Explorer, Firefox, Safari, Chrome y Opera. Los ejemplos de estedocumento se refieren a navegadores de código abierto, como Firefox, Chrome y Safari (este últ imo es en parte de código abierto). Segúnlas estadíst icas sobre navegadores de StatCounter , actualmente (agosto de 2011) el uso conjunto de Firefox, Safari y Chrome

Los navegadores de los que hablaremos

PDFmyURL.com

representa el 60%. Por tanto, en estos momentos los navegadores de código abierto constituyen una parte importante del mercado delos navegadores.

La función principal de un navegador es solicitar al servidor los recursos web que elija el usuario y mostrarlos en una ventana. El recursosuele ser un documento HTML, pero también puede ser un archivo PDF, una imagen o un objeto de otro t ipo. El usuario especifica laubicación del recurso mediante el uso de una URI (siglas de Uniform Resource Identifier, identificador uniforme de recurso).

La forma en la que el navegador interpreta y muestra los archivos HTML se determina en las especificaciones de CSS y HTML. Estasespecificaciones las establece el consorcio W3C (World Wide Web Consort ium), que es la organización de estándares de Internet. Durante años, los navegadores cumplían solo una parte de las especificaciones y desarrollaban sus propias extensiones. Esto provocógraves problemas de compatibilidad para los creadores de contenido web. En la actualidad, la mayoría de los navegadores cumplen lasespecificaciones en mayor o menor grado.

Las interfaces de usuario de los dist intos navegadores t ienen muchos elementos en común. Estos son algunos de los elementos comunesde las interfaces de usuario:

una barra de direcciones donde insertar las URI,

botones de avance y retroceso,

opciones de marcadores,

un botón para detener la carga de los documentos actuales y otro para volver a cargarlos,

un botón de inicio que permite volver a la página de inicio.

Estas coincidencias resultan extrañas, ya que la interfaz de usuario de los navegadores no se incluye en ninguna de las especificacionesformales, sino que procede de la experiencia acumulada a lo largo de los años y de los elementos que los navegadores han imitado unos deotros. La especificación de HTML5 no define los elementos que debe incluir la interfaz de usuario de los navegadores, pero muestra algunoselementos comunes. Entre estos elementos se encuentran la barra de direcciones, la barra de estado y la barra de herramientas. Existen,por supuesto, característ icas únicas de cada navegador, como el administrador de descargas de Firefox.

A continuación se especifican los componentes principales de un navegador (1.1).

La función principal de un navegador

Componentes principales del navegador

PDFmyURL.com

1. Interfaz de usuario: incluye la barra de direcciones, el botón de avance/retroceso, el menú de marcadores, etc. (en general, todas laspartes visibles del navegador, excepto la ventana principal donde se muestra la página solicitada).

2. Motor de búsqueda: coordina las acciones entre la interfaz y el motor de renderización.

3. Motor de renderización: es responsable de mostrar el contenido solicitado. Por ejemplo, si el contenido solicitado es HTML, será elresponsable de analizar el código HTML y CSS y de mostrar el contenido analizado en la pantalla.

4. Red: es responsable de las llamadas de red, como las solicitudes HTTP. Tiene una interfaz independiente de la plataforma y realizaimplementaciones en segundo plano para cada plataforma.

5. Servidor de la interfaz: permite presentar widgets básicos, como ventanas y cuadros combinados. Muestra una interfaz genérica que no esespecífica de ninguna plataforma. Utiliza métodos de la interfaz de usuario del sistema operativo en segundo plano.

6. Intérprete de JavaScript: permite analizar y ejecutar el código JavaScript.

7. Almacenamiento de datos: es una capa de persistencia. El navegador necesita guardar todo tipo de datos en el disco duro (por ejemplo,las cookies). La nueva especificación de HTML (HTML5) define el concepto de "base de datos web", que consiste en una completa (aunqueligera) base de datos del navegador.

Figura 1: componentes principales del navegador

Es importante decir que Chrome, a diferencia de la mayoría de los navegadores, implementa varias instancias del motor de renderización,

PDFmyURL.com

una por cada pestaña. Cada pestaña representa un proceso independiente.

La responsabilidad del motor de renderización es "renderizar", es decir, mostrar el contenido solicitado en la pantalla del navegador.

De forma predeterminada, el motor de renderización puede mostrar imágenes y documentos HTML y XML. Puede mostrar otros t iposmediante el uso de complementos (o extensiones); por ejemplo, puede mostrar documentos PDF mediante un complemento capaz deleer archivos PDF. Sin embargo, en este capítulo nos centraremos en su uso principal: mostrar imágenes y código HTML con formatodefinido con CSS.

Nuestros navegadores de referencia (Firefox, Chrome y Safari) están basados en dos motores de renderización. Firefox utiliza Gecko, unmotor de renderización propio de Mozilla. Tanto Safari como Chrome utilizan WebKit.

WebKit es un motor de renderización de código abierto que empezó siendo un motor de la plataforma Linux y que fue modificadoposteriormente por Apple para hacerlo compatible con Mac y Windows. Puedes obtener más información en webkit.org .

El motor de renderización empieza recibiendo el contenido del documento solicitado desde la capa de red, normalmente en fragmentos de8.000 bytes.

A continuación, el motor de renderización realiza este flujo básico:

Figura 2: flujo básico del motor de renderización

El motor de renderización empieza a analizar el documento HTML y convierte las et iquetas en nodos DOM en un árbol denominado "árbol decontenido". Analiza los datos de estilo, tanto en los archivos CSS externos como en los elementos de estilo. Los datos de estilo, juntocon las instrucciones visuales del código HTML, se utilizan para crear otro árbol: el árbol de renderización.

Chapter 2

El motor de renderización

Motores de renderización

El flujo principal

PDFmyURL.com

El árbol de renderización contiene rectángulos con atributos visuales, como el color y las dimensiones. Los rectángulos están organizadosen el orden en el que aparecerán en la pantalla.

Una vez construido el árbol de renderización, se inicia un proceso de "diseño". Esto significa que a cada nodo se le asignan las coordenadasexactas del lugar de la pantalla en el que debe aparecer. La siguiente fase es la de pintura, en la que se recorre el árbol de renderización yse pinta cada uno de los nodos utilizando la capa de servidor de la interfaz de usuario.

Es importante comprender que se trata de un proceso gradual. Para mejorar la experiencia del usuario, el motor de renderización intentarámostrar el contenido en pantalla lo antes posible. No esperará a que se analice el código HTML para empezar a crear y diseñar el árbol derenderización. Se analizarán y se mostrarán algunas partes del contenido, mientras que se sigue procesando el resto del contenido quellega de la red.

Figura 3: flujo principal de WebKit

Ejemplos del flujo principal

PDFmyURL.com

Figura 4: flujo principal del motor de renderización Gecko de Mozilla ( 3.6)

En las figuras 3 y 4 se puede ver que, aunque WebKit y Gecko utilizan una terminología ligeramente diferente, el flujo es básicamente elmismo.

Gecko denomina al árbol de elementos formateados visualmente "árbol de marcos". Cada uno de los elementos es un marco. WebKit ut ilizalos términos "árbol de renderización" y "objetos de renderización" en lugar de los anteriores. WebKit ut iliza el término "diseño" para colocarlos elementos, mientras que Gecko lo denomina "reflujo". WebKit ut iliza el término "asociación" para conectar los nodos DOM coninformación visual para crear el árbol de renderización. Una pequeña diferencia no semántica es que Gecko dispone de una capa extra entreel código HTML y el árbol de DOM. Esta capa se denomina "depósito de contenido" y está dedicada a la creación de elementos DOM.Vamos a ver cada una de las partes del flujo:

Dado que el análisis es un proceso muy importante del motor del renderización, vamos a verlo de una forma más detallada. Comencemospor una breve introducción a este proceso.

Analizar un documento significa traducirlo a una estructura que tenga sentido, es decir, algo que el código pueda comprender y utilizar. Elresultado del análisis suele ser un árbol de nodos que representa la estructura del documento. Este árbol se denomina "árbol de análisis" o

Chapter 3

Análisis (general)

PDFmyURL.com

"árbol de sintaxis".

Ejemplo: el análisis de la expresión 2 + 3 - 1 podría dar como resultado este árbol:

Figura 5: nodo de árbol de expresión matemática

El análisis se basa en las reglas de sintaxis por las que se rige el documento, es decir, el lenguaje o el formato en el que está escrito.Todos los formatos que se pueden analizar deben tener una gramática determinista formada por un vocabulario y unas reglas de sintaxis.Esto se denomina gramática libre de contexto. Los lenguajes humanos no son de este t ipo y, por tanto, no se pueden analizar contécnicas de análisis convencionales.

El proceso de análisis se puede dividir en dos subprocesos: análisis léxico y análisis sintáctico.

El análisis léxico es el proceso de descomponer los datos de entrada en tokens. Los tokens son el vocabulario del lenguaje, un conjunto debloques de construcción válidos. En el lenguaje humano, equivaldría a todas las palabras que aparecen en el diccionario de un determinadoidioma.

El análisis sintáct ico es la aplicación de las reglas sintácticas del lenguaje.

Los analizadores normalmente dividen el trabajo entre dos componentes: el analizador léxico (a veces denominado "tokenizador"),responsable de descomponer los datos de entrada en tokens válidos, y el analizador normal, responsable de construir el árbol trasanalizar la estructura del documento según las reglas sintácticas del lenguaje. El analizador léxico es capaz de ignorar caracteresirrelevantes, como espacios en blanco y saltos de línea.

Gramáticas

Analizador: combinación de analizadores léxicos

PDFmyURL.com

Figura 6: del documento original al árbol de análisis

El proceso de análisis es iterativo. El analizador normalmente pide al analizador léxico un nuevo token e intenta buscar coincidencias entreel token y una de las reglas de sintaxis. Si se encuentra una coincidencia, se añade al árbol de análisis un nodo correspondiente al token yel analizador solicita otro token.

Si no coincide con ninguna regla, el analizador almacena el token internamente y sigue solicitando tokens hasta que encuentra una regla quecoincide con todos los tokens almacenados internamente. Si no encuentra ninguna regla, lanza una excepción. Esto significa que eldocumento no se considera válido por tener errores de sintaxis.

Muchas veces, el árbol de análisis no es el producto final. El análisis se utiliza frecuentemente en la traducción, es decir, en la conversión deldocumento de entrada a otro formato. Un ejemplo sería la compilación. El compilador, que compila un código fuente en código de máquina,en primer lugar lo convierte en un árbol de análisis y, a continuación, traduce el árbol a un documento de código de máquina.

Traducción

PDFmyURL.com

Figura 7: flujo de compilación

En la figura 5 se observa un árbol de análisis creado a part ir de una expresión matemática. Intentemos definir un lenguaje matemáticosimple y veamos el proceso de análisis.

Vocabulario: nuestro lenguaje puede incluir números enteros, el signo más y el signo menos.

Sintaxis:

1. Los bloques de construcción de la sintaxis del lenguaje son expresiones, términos y operaciones.

2. Nuestro lenguaje puede incluir cualquier cantidad de expresiones.

3. Una expresión está formada por un "término" seguido de una "operación" y de otro término.

4. Una operación es un token de suma o un token de resta.

Ejemplo de análisis

PDFmyURL.com

5. Un término es un token de número entero o una expresión.

Analicemos la entrada 2 + 3 - 1 . La primera subcadena que coincide con una regla es 2 ; según la regla 5, es un término. La segunda coincidencia es 2 + 3 , que coincide conla tercera regla (un término seguido de una operación y de otro término). La siguiente coincidencia solo se utilizará al final de la entrada. 2+ 3 - 1 es una expresión porque ya sabemos que 2+3 es un término, así que tenemos un término seguido de una operación y de otrotérmino. 2 + + no coincide con ninguna regla, por lo que no sería una entrada válida.

El vocabulario se suele expresar mediante expresiones regulares .

Por ejemplo, nuestro lenguaje se definirá de la siguiente forma:

INTEGER :0|[1-9][0-9]*PLUS : +MINUS: -

Como se puede observar, los números enteros se definen mediante una expresión regular.

La sintaxis normalmente se define en un formato denominado notación de Backus-Naur (BNF). Nuestro idioma se definirá de la siguienteforma:

expression := term operation termoperation := PLUS | MINUSterm := INTEGER | expression

Dijimos que un lenguaje se puede analizar mediante analizadores normales si su gramática es una gramática libre de contexto. Unadefinición intuit iva de una gramática libre de contexto es una gramática que se puede expresar completamente en notación de Backus-Naur (BNF). Puedes consultar una definición formal en este art ículo de Wikipedia sobre las gramáticas libres de contexto .

Existen dos t ipos básicos de analizadores: los descendentes y los ascendentes. Utilizando una explicación intuit iva, podríamos decir quelos analizadores descendentes comprueban la estructura de nivel superior de la sintaxis e intentan buscar una coincidencia, mientras quelos analizadores ascendentes comienzan con los datos de entrada y los van transformando gradualmente mediante las reglas sintácticas

Definiciones formales de vocabulario y sintaxis

Tipos de analizadores

PDFmyURL.com

empezando por el nivel más bajo hasta que se cumplen las reglas de nivel superior.

Veamos cómo analizan el contenido de ejemplo estos dos t ipos de analizadores:

Un analizador descendente empieza desde la regla de nivel superior: identifica 2 + 3 como una expresión. A continuación, identifica 2 + 3 -1 como expresión (el proceso de identificar la expresión se desarrolla buscando coincidencias con el resto de las reglas, pero se empiezapor la regla de nivel superior).

El analizador ascendente analiza los datos de entrada hasta que encuentra una coincidencia con una regla y, a continuación, sustituye laentrada coincidente con la regla. Este proceso continúa hasta que se analizan todos los datos de entrada. Las expresiones concoincidencias parciales se colocan en la pila del analizador.

Pila Entrada 2 + 3 - 1término + 3 - 1operación del término 3 - 1expresión - 1operación de la expresión 1expresión

Este tipo de analizador ascendente se conoce como analizador de desplazamiento-reducción debido a que los datos de entrada se desplazan haciala derecha (imagina un puntero que apunta primero al inicio de los datos de entrada y a continuación se desplaza hacia la derecha) y gradualmentese reducen según las reglas sintácticas.

Existen herramientas capaces de generar analizadores automáticamente. Se denominan generadores de analizadores. Estos generadorescrean automáticamente un analizador funcional ut ilizando la gramática del lenguaje (vocabulario y reglas sintácticas) establecida por eldesarrollador. Los generadores de analizadores son muy útiles, ya que, para crear un analizador, es necesario disponer de un profundoconocimiento del proceso de análisis, y no resulta fácil crear manualmente un analizador optimizado.

WebKit ut iliza dos generadores de analizadores muy conocidos: Flex , para crear un analizador léxico, y Bison , para crear un analizadornormal (también se conocen como "Lex" y "Yacc"). La entrada de Flex consiste en un archivo con definiciones de expresiones regulares delos tokens. La entrada de Bison consiste en las reglas sintácticas del lenguaje en formato BNF.

El trabajo del analizador de HTML es analizar las marcas HTML y organizarlas en un árbol de análisis.

Cómo generar analizadores automáticamente

Analizador de HTML

PDFmyURL.com

Es la sintaxis y el vocabulario definidos en las especificaciones creadas por la organización W3C. La versión actual es HTML4 y actualmentese está trabajando en HTML5.

Como ya vimos en la introducción al análisis, la sintaxis de la gramática se puede definir formalmente mediante formatos como BNF.

Lamentablemente, no todos los temas sobre analizadores convencionales se pueden aplicar al lenguaje HTML (los he incluido porque seutilizarán en el análisis de CSS y JavaScript). El lenguaje HTML no se puede definir fácilmente mediante la gramática libre de contexto quenecesitan los analizadores.

Existe un formato formal para definir el lenguaje HTML: DTD (definición de t ipo de documento); sin embargo, no es una gramática libre decontexto.

Parece algo extraño a primera vista: el lenguaje HTML es bastante similar al XML. Hay una gran variedad de analizadores de XML disponibles.Existe una variación XML del lenguaje HTML, el XHTML, así que, ¿cuál es la diferencia?

La diferencia radica en que el lenguaje HTML es más "permisivo", ya que permite omit ir ciertas et iquetas que se añaden de forma implícita,a veces se omite el principio o el final de las et iquetas, etc. En conjunto, es una sintaxis "flexible", en oposición a la sintaxis rígida yexigente del lenguaje XML.

Esta diferencia aparentemente pequeña es, en realidad, abismal. Por un lado, esta es la razón principal por la que el HTML es tan popular:permite errores y facilita las cosas a los autores de contenido web. Por otro lado, hace que resulte difícil escribir una gramática formal. Enresumen: el lenguaje HTML no se puede analizar fácilmente mediante analizadores convencionales (porque no dispone de una gramáticalibre de contexto) ni mediante analizadores de XML.

La definición de HTML está en formato DTD. Este formato se utiliza para definir lenguajes de la familia SGML . Contiene definiciones detodos los elementos permit idos, de sus atributos y de su jerarquía. Como vimos antes, la definición DTD del lenguaje HTML no forma unagramática libre de contexto.

Existen algunas variaciones de la definición DTD. El modo estricto se ajusta únicamente a las especificaciones, pero otros modos admitenel marcado utilizado anteriormente por los navegadores. El objetivo es mantener la compatibilidad con el contenido más antiguo. La

Definición de gramática HTML

No es una gramática libre de contexto

DTD DE HTML

PDFmyURL.com

definición DTD estricta actual se encuentra en la siguiente página: www.w3.org/TR/html4/strict.dtd

El árbol de salida ("árbol de análisis") está formado por elementos DOM y nodos de atributo. DOM son las siglas de "Document ObjectModel" (modelo de objetos del documento). Es la presentación de objetos del documento HTML y la interfaz de los elementos HTML parael mundo exterior, como JavaScript. La raíz del árbol es el objeto Document .

El modelo DOM guarda una relación casi de uno a uno con el marcado. Veamos un ejemplo de marcado:

<html> <body> <p> Hello World </p> <div> <img src="example.png"/></div> </body></html>

El marcado anterior se traduciría en el siguiente árbol de DOM:

Figura 8: árbol de DOM del marcado de ejemplo

Al igual que el HTML, la organización W3C ha especificado el modelo DOM. Puedes consultarlo en la página www.w3.org/DOM/DOMTR . Es

DOM

PDFmyURL.com

una especificación genérica para la manipulación de documentos. Un módulo específico describe elementos HTML específicos. Puedesconsultar las definiciones HTML en la página www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definit ions.html .

Cuando digo que el árbol contiene nodos DOM, quiero decir que está construido con elementos que implementan una de las interfacesDOM. Los navegadores utilizan implementaciones concretas que t ienen otros atributos que el navegador utiliza internamente.

Como vimos en las secciones anteriores, el lenguaje HTML no se puede analizar mediante los analizadores ascendentes y descendentesnormales.

Las razones son:

1. la naturaleza permisiva del lenguaje,

2. el hecho de que los navegadores presenten una tolerancia a errores tradicional para admitir casos bien conocidos de HTML no válido,

3. la naturaleza iterativa del proceso de análisis. Normalmente, el código no cambia durante el análisis. Sin embargo, en el caso del código HTML,las etiquetas de secuencias de comandos que contienen document.write pueden añadir tokens adicionales, por lo que el proceso de análisisllega a modificar los datos de entrada.

Al no poder utilizar las técnicas de análisis normales, los navegadores crean analizadores personalizados para analizar el código HTML.

El algoritmo de análisis se describe de forma detallada en la especificación de HTML5 . El algoritmo presenta dos fases: la tokenización yla construcción del árbol.

La tokenización es el análisis léxico, es decir, el análisis y la conversión en tokens de los datos de entrada. Entre los tokens HTML seencuentran las et iquetas iniciales, las et iquetas finales y los valores de atributos.

El tokenizador reconoce el token, lo envía al constructor del árbol y consume el siguiente carácter para reconocer el siguiente token, y asísucesivamente hasta llegar al final de los datos.

El algoritmo de análisis

PDFmyURL.com

Figura 9: flujo de análisis de HTML (tomado de la especificación de HTML5)

El algoritmo produce un token HTML. El algoritmo se expresa como una máquina de estado. Cada estado consume uno o varios caracteresdel flujo de entrada y actualiza el siguiente estado de acuerdo con esos caracteres. La decisión está influenciada por el estado detokenización actual y por el estado de construcción del árbol. Esto significa que el mismo carácter consumido producirá resultadosdiferentes para el siguiente estado correcto en función del estado actual. El algoritmo es demasiado complejo para describirlo en sutotalidad, así que veremos algunos ejemplos sencillos que nos ayudarán a comprender el principio.

Ejemplo básico de tokenización del siguiente código HTML:

<html> <body> Hello world </body>

El algoritmo de tokenización

PDFmyURL.com

</html>

El estado inicial es el de "estado de datos". Cuando se encuentra el carácter < , el estado cambia a estado de etiqueta abierta. Alconsumir un carácter a-z , se crea el estado "token de etiqueta inicial" y el estado cambia a estado de nombre de etiqueta. Esteestado se mantiene hasta que se consume el carácter > . Todos los caracteres se añaden al nombre del nuevo token. En nuestro caso, elnuevo token es un token html .

Al llegar a la et iqueta > , se emite el token actual y el estado cambia a estado de datos. Se siguen los mismos pasos para la et iqueta<body> . Hasta ahora, se han emit ido las et iquetas html y body . Ahora volvemos al estado de datos. Al consumir el carácter H deHello world , se crea y se emite un token de carácter, y así sucesivamente hasta llegar al carácter < de </body> . Se emite un token decarácter por cada uno de los caracteres de Hello world .

Ahora volvemos al estado de etiqueta abierta. Al consumir la siguiente entrada / , se crea un token de etiqueta final y se pasa alestado de nombre de etiqueta. De nuevo, el estado se mantiene hasta llegar a > . A continuación, se emite el token de la nuevaetiqueta y se vuelve al estado de datos. La entrada </html> se tratará como el caso anterior.

PDFmyURL.com

Figura 10: tokenización de la entrada de ejemplo

Cuando se crea un analizador, se crea el objeto "Document". Durante la fase de construcción, se modifica el árbol de DOM que incluye elobjeto "Document" en su raíz y se añaden elementos. El constructor del árbol procesa cada nodo emit ido por el tokenizador. Por cadatoken, la especificación define qué elementos de DOM son relevantes y cuáles se deben crear para este token. Además de añadirse alárbol de DOM, el elemento se añade a una pila de elementos abiertos. Esta pila permite corregir incidencias de anidación y de etiquetas nocerradas. El algoritmo también se describe como una máquina de estado. Los estados se denominan "modos de inserción".

Veamos cuál sería el proceso de construcción del árbol para los datos de entrada del ejemplo:

<html> <body> Hello world </body></html>

Algoritmo de construcción de árbol

PDFmyURL.com

La entrada a la fase de construcción del árbol es una secuencia de tokens de la fase de tokenización. El primer modo es el "modoinicial". Si se recibe el token html, se pasará al modo "previo a html" y se volverá a procesar el token en ese modo. Esto hará que elelemento "HTMLHtmlElement" se cree y se añada al objeto raíz "Document".

El estado cambiará a "antes del encabezado". Recibimos el token "body". Se creará implícitamente un elemento "HTMLHeadElement",aunque no tengamos ningún token "head", y ese elemento se añadirá al árbol.

Ahora pasamos al modo "en el encabezado" y, a continuación, al modo "después del encabezado". El token del cuerpo se vuelve aprocesar, se crea y se inserta un elemento "HTMLBodyElement" y, por últ imo, el modo pasa a "en el cuerpo".

A continuación, se reciben los tokens de los caracteres de la cadena "Hello world". El primero hará que se cree y se inserte el nodo "Text",al que se añadirá el resto de caracteres.

La recepción del token de finalización del cuerpo provocará una transferencia al modo "después del cuerpo". A continuación, se recibirála et iqueta HTML final, que hará que se pase al modo después del cuerpo. Cuando se reciba el final del token del archivo, al análisisfinalizará.

PDFmyURL.com

Figura 11: construcción de árbol del código HTML de ejemplo

En esta fase, el navegador marcará el documento como interactivo y empezará a analizar las secuencias de comandos que se encuentrenen modo "aplazado", es decir, aquellas que se deben ejecutar una vez que se ha analizado el documento. A continuación, el estado deldocumento se establecerá como "completado" y se act ivará un evento de "carga".

Se pueden ver los algoritmos completos para tokenización y la construcción del árbol en la especificación de HTML5 .

Nunca se obtiene un error por "sintaxis no válida" en una página HTML. Los navegadores corrigen el contenido no válido y siguen.

Tomemos este código HTML como ejemplo:

Acciones al finalizar el análisis

Tolerancia a errores de los navegadores

PDFmyURL.com

<html> <mytag> </mytag> <div> <p> </div> Really lousy HTML </p></html>

He debido de infringir un millón de reglas ("mytag" no es una etiqueta estándar, los elementos "p" y "div" están mal anidados, etc.), pero elnavegador sigue mostrándolo correctamente y no muestra ningún error. Por lo tanto, una gran parte del código del analizador corrige loserrores del autor de contenido HTML.

La gestión de errores es bastante consistente en los navegadores, pero lo más increíble es que no forma parte de la especificación actualde HTML. Al igual que los marcadores y los botones de avance y retroceso, es algo que se ha ido desarrollando a lo largo de los años. Hayalgunas construcciones HTML conocidas que no son válidas y que se repiten en muchos sit ios. Los navegadores intentan corregirlas deacuerdo con otros navegadores.

En cambio, en la especificación de HTML5 sí se definen algunos de estos requisitos. WebKit lo resume en el comentario que se encuentra alprincipio de la clase de analizador de HTML.

PDFmyURL.com

Veamos algunos ejemplos de tolerancia a errores de WebKit:

Algunos sit ios utilizan </br> en lugar de <br>. Para poder ser compatible con Internet Explorer y Firefox, WebKit trata la et iqueta como sifuera <br>. Código:

if (t->isCloseTag(brTag) && m_document->inCompatMode()) { reportError(MalformedBRError); t->beginTag = true;}

Nota: los errores se gestionan de forma interna, es decir, no se muestran al usuario.

Una tabla perdida es una tabla incluida en el contenido de otra tabla, pero no en una celda. Ejemplo:

<table> <table> <tr><td>inner table</td></tr> </table> <tr><td>outer table</td></tr></table>

WebKit cambiará la jerarquía de dos tablas secundarias:

<table> <tr><td>outer table</td></tr></table><table>

</br> en lugar de <br>

Tabla perdida

PDFmyURL.com

<tr><td>inner table</td></tr></table>

Código:

if (m_inStrayTableContent && localName == tableTag) popBlock(tableTag);

WebKit utiliza una pila para el contenido del elemento actual y saca la tabla interna de la pila de la tabla externa. Las tablas se encontrarán en elmismo nivel de la jerarquía.

Si el usuario incluye un formulario dentro de otro, el segundo se ignorará. Código:

if (!m_currentFormElement) { m_currentFormElement = new HTMLFormElement(formTag, m_document);}

El comentario habla por sí solo.

bool HTMLParser::allowNestedRedundantTag(const AtomicString& tagName){

unsigned i = 0;for (HTMLStackElem* curr = m_blockStack; i < cMaxRedundantTagDepth && curr && curr->tagName == tagName; curr = curr->next, i++) { }return i != cMaxRedundantTagDepth;

Elementos de un formulario anidado

Jerarquía de etiquetas demasiado profunda

PDFmyURL.com

return i != cMaxRedundantTagDepth;}

De nuevo, el comentario habla por sí solo.

if (t->tagName == htmlTag || t->tagName == bodyTag ) return;

Así que ya sabéis: a menos que queráis aparecer como ejemplo en un fragmento de código de tolerancia a errores de WebKit, escribid el códigoHTML correctamente.

¿Os acordáis de los conceptos de análisis que vimos en la introducción? A diferencia del lenguaje HTML, CSS t iene una gramática libre decontexto y se puede analizar con los t ipos de analizadores descritos en la introducción. De hecho, la especificación del lenguaje CSS definesu gramática sintáctica y léxica .

Veamos algunos ejemplos: La gramática léxica (el vocabulario) se define mediante expresiones regulares para cada token:

comment \/\*[^*]*\*+([^/*][^*]*\*+)*\/num [0-9]+|[0-9]*"."[0-9]+nonascii [\200-\377]nmstart [_a-z]|{nonascii}|{escape}nmchar [_a-z0-9-]|{nonascii}|{escape}name {nmchar}+ident {nmstart}{nmchar}*

"ident" es la abreviatura de identificador, como el nombre de una clase. "name" es el identificador de un elemento (y se hace referencia a élmediante "#").

La gramática sintáctica se describe en BNF.

Etiquetas finales de cuerpo o HTML colocadas incorrectamente

Análisis de CSS

PDFmyURL.com

ruleset : selector [ ',' S* selector ]* '{' S* declaration [ ';' S* declaration ]* '}' S* ;selector : simple_selector [ combinator selector | S+ [ combinator? selector ]? ]? ;simple_selector : element_name [ HASH | class | attrib | pseudo ]* | [ HASH | class | attrib | pseudo ]+ ;class : '.' IDENT ;element_name : IDENT | '*' ;attrib : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S* [ IDENT | STRING ] S* ] ']' ;pseudo : ':' [ IDENT | FUNCTION S* [IDENT S*] ')' ] ;

Explicación: un conjunto de reglas es una estructura como la que se muestra a continuación.

div.error , a.error { color:red; font-weight:bold;}

"div.error" y "a.error" son selectores. La parte entre llaves contiene las reglas que se aplican a este conjunto de reglas. Esta estructura se defineformalmente en esta definición:

ruleset : selector [ ',' S* selector ]* '{' S* declaration [ ';' S* declaration ]* '}' S*

PDFmyURL.com

;

Esto significa que un conjunto de reglas es un selector o un número opcional de selectores separados por una coma y por espacios (S significaespacio en blanco). Un conjunto de reglas contiene una declaración entre llaves u, opcionalmente, una serie de declaraciones separadas por punto ycoma. "declaration" y "selector" se definirán en las siguientes definiciones de BNF.

WebKit ut iliza generadores de analizadores Flex y Bison para crear analizadores automáticamente a part ir de los archivos de gramática deCSS. Como ya dijimos en la introducción a los analizadores, Bison crea un analizador ascendente de desplazamiento-reducción. Firefoxutiliza un analizador descendente escrito manualmente. En ambos casos, los archivos CSS se analizan y se convierten en objetos"StyleSheet", cada uno de los cuales contiene reglas de CSS. Los objetos de regla de CSS contienen objetos de declaraciones yselectores, así como otros objetos relacionados con la gramática de CSS.

Figura 12: análisis de CSS

Analizador de CSS de WebKit

PDFmyURL.com

El modelo de la Web es síncrono. Los autores esperan que las secuencias de comandos se analicen y se ejecuten inmediatamente cuandoel analizador llega a la et iqueta <script>. El análisis del documento se detiene hasta que la secuencia de comandos se ejecuta. Lasecuencia de comandos es externa, por lo que antes es necesario recuperar el recurso de la red. Esta acción se realiza también de unaforma síncrona, es decir, que el análisis se detiene hasta que se recupera el recurso. Este modelo se utilizó durante muchos años y estáincluido en las especificaciones de HTML 4 y 5. Los autores pueden marcar la secuencia de comandos como "aplazada". De ese modo, nose detiene el análisis del documento y la secuencia se ejecuta una vez que se ha completado el análisis. HTML5 añade una opción quepermite marcar la secuencia de comandos como asíncrona para que se analice y se ejecute en un subproceso diferente.

Tanto WebKit y Firefox utilizan esta optimización. Al ejecutar las secuencias de comandos, otro subproceso analiza el resto del documento,busca en la red otros recursos necesarios y los carga. De esta forma, los recursos se pueden cargar mediante conexiones paralelas, lo quemejora la velocidad general. Nota: el analizador especulat ivo no modifica el árbol de DOM (de eso se encarga el analizador principal), soloanaliza las referencias a recursos externos, como secuencias de comandos externas, hojas de estilo e imágenes.

Las hojas de estilo, por otro lado, t ienen un modelo diferente. Conceptualmente, parece que, dado que las hojas de estilo no modifican elárbol de DOM, no hay razón para esperarlas y detener el análisis del documento. Sin embargo, se produce una incidencia cuando lassecuencias de comandos solicitan información de estilo durante la fase de análisis del documento. Si el est ilo aún no se ha cargado nianalizado, la secuencia de comandos obtendrá respuestas incorrectas y, aparentemente, esto causará muchas complicaciones. Parece quese trata de un caso extremo, pero es bastante común. Firefox bloquea todas las secuencias de comandos si todavía se está cargando yanalizando una hoja de estilo. WebKit bloquea las secuencias de comandos solo cuando intentan acceder a determinadas propiedades deestilo que se pueden ver afectadas por las hojas de estilo descargadas.

Mientras se está construyendo el árbol DOM, el navegador construye otro árbol: el árbol de renderización. Este árbol está formado porelementos visuales que se muestran en el mismo orden en que aparecerán. Es la representación visual del documento. El propósito de esteárbol es poder representar el contenido en el orden correcto.

Orden de procesamiento de secuencias de comandos y hojas de estiloSecuencias de comandos

Análisis especulat ivo

Hojas de estilo

Chapter 4

Construcción del árbol de renderización

PDFmyURL.com

Firefox denomina a los elementos del árbol de renderización "marcos" (o "frames"). WebKit ut iliza el término "renderizador" u "objeto derenderización" (o "render"). Un renderizador es capaz de representarse a sí mismo y a sus elementos secundarios. La clase "RenderObject" de WebKit, la clase básica de los renderizadores, t iene la siguiente definición:

class RenderObject{ virtual void layout(); virtual void paint(PaintInfo); virtual void rect repaintRect(); Node* node; //the DOM node RenderStyle* style; // the computed style RenderLayer* containgLayer; //the containing z-index layer}

Cada renderizador representa un área rectangular que normalmente se corresponde con la caja de CSS del nodo, según se describe en laespecificación de CSS2. Contiene información geométrica como el ancho, la altura y la posición. El t ipo de caja se ve afectado por el atributo de estilo "display" relevante para el nodo (consulta la sección Computación de estilos). Estees el código de WebKit que se utiliza para decidir qué t ipo de renderizador se debe crear para un nodo DOM, según el atributo devisualización:

RenderObject* RenderObject::createObject(Node* node, RenderStyle* style){ Document* doc = node->document(); RenderArena* arena = doc->renderArena(); ... RenderObject* o = 0;

switch (style->display()) { case NONE: break; case INLINE: o = new (arena) RenderInline(node); break; case BLOCK: o = new (arena) RenderBlock(node); break; case INLINE_BLOCK:

PDFmyURL.com

o = new (arena) RenderBlock(node); break; case LIST_ITEM: o = new (arena) RenderListItem(node); break; ... }

return o;}

El tipo de elemento también se tiene en cuenta. Por ejemplo, las tablas y los controles de los formularios tienen marcos especiales. En WebKit, si un elemento quiere crear un renderizador especial, sobrescribe el método createRenderer . Los renderizadores apuntan a objetos deestilo que contienen la información no geométrica.

Los renderizadores corresponden a elementos DOM, pero la relación no es de uno a uno. Los elementos DOM no visuales no se insertan en el árbolde renderización. Un ejemplo sería el elemento "head". Los elementos cuyo atributo de visualización se ha asignado a "none" tampoco aparecen enel árbol (los elementos con el atributo de visibilidad "hidden" sí aparecen en el árbol).

Algunos elementos DOM corresponden a varios objetos visuales. Estos suelen ser elementos con una estructura compleja que no sepueden describir en un solo rectángulo. Por ejemplo, el elemento "select" t iene tres renderizadores: uno para el área de visualización, otropara el cuadro de lista desplegable y otro para el botón. Además, cuando el texto se divide en varias líneas porque el ancho no essuficiente para una línea, las nuevas líneas se añaden como renderizadores adicionales. Otro ejemplo con varios renderizadores sería un código HTML roto. Según la especificación de CSS, un elemento integrado debe contenerúnicamente elementos de bloque o elementos integrados. Si el contenido es mixto, se crean renderizadores de bloques anónimos paraincluir los elementos integrados.

Algunos objetos de renderización corresponden a un nodo DOM de un lugar del árbol diferente. Los elementos flotantes y aquellos conposición absoluta quedan fuera del flujo, en un lugar diferente del árbol y asignados al marco real. Deberían haber estado en un marco demarcador.

Relación del árbol de renderización con el árbol de DOM

PDFmyURL.com

Figura 13: el árbol renderizador y el árbol de DOM correspondiente ( 3.1) La "ventana gráfica" es el bloque contenedor inicial. En WebKit, será elobjeto "RenderView".

En Firefox, la presentación se registra como un detector de actualizaciones de DOM. La presentación delega la creación de marcos enFrameConstructor y el constructor resuelve el est ilo (consulta la sección Computación de estilos) y crea un marco.

En WebKit, el proceso para resolver el est ilo y crear un renderizador se denomina "asociación". Cada nodo DOM dispone de un método de"asociación". El proceso de asociación es síncrono, es decir, que la inserción de nodos en el árbol de DOM activa el método de "asociación"del nuevo nodo.

Al procesar las et iquetas "html" y "body", se construye la raíz del árbol de renderización. El objeto de renderización raíz se corresponde conlo que la especificación de CSS denomina "bloque contenedor", es decir, el bloque superior que contiene el resto de los bloques. Susdimensiones se corresponden con la ventana gráfica, es decir, con las dimensiones del área de visualización de la ventana del navegador.

El flujo de construcción del árbol

PDFmyURL.com

Firefox lo denomina ViewPortFrame y WebKit RenderView . Este es el objeto de renderización al que apunta el documento. El resto delárbol se construye como una inserción de nodos DOM.

Consulta la especificación de CSS2 en el modelo de procesamiento .

Para crear el árbol de renderización, es necesario calcular las propiedades visuales de cada uno de los objetos de renderización. Parahacerlo, hay que calcular las propiedades de estilo de cada elemento.

El est ilo incluye hojas de estilo de varios orígenes, elementos de estilo integrados y propiedades visuales en el código HTML (como lapropiedad "bgcolor"). Estas últ imas se transforman en las propiedades de estilo de CSS correspondientes.

Los orígenes de las hojas de estilo son las hojas de estilo predeterminadas del navegador, las proporcionadas por el autor de la página y lasproporcionadas por el usuario del navegador (los navegadores permiten al usuario definir su est ilo favorito. En Firefox, por ejemplo, sepuede hacer colocando una hoja de estilo en la carpeta de perfiles del navegador).

La computación de estilos conlleva algunas dificultades:

1. Al contener las numerosas propiedades de los estilos, los datos de estilo llegan a alcanzar unas dimensiones considerables, lo que puedeprovocar un uso excesivo de memoria.

2. La búsqueda de las reglas coincidentes de cada elemento puede afectar al rendimiento si no se optimiza el proceso. Recorrer la listacompleta de reglas de cada elemento para encontrar coincidencias es una tarea muy pesada. Los selectores pueden tener unaestructura compleja, lo que puede hacer que se empiece a buscar en una ruta que aparentemente sea buena, pero que finalmente nosea así y se deba probar con otra ruta.

Pongamos como ejemplo este selector complejo:

div div div div{ ...}

Significa que las reglas se aplican a un elemento <div> que es el descendiente de tres elementos "div". Supongamos que quieres comprobarsi la regla se aplica a un elemento <div> determinado. Debes seleccionar una ruta superior del árbol para comprobarlo. Es posible que debasascender por todo el árbol de nodos solo para averiguar que únicamente existen dos elementos "div" y que la regla no se aplica. Acontinuación, debes probar con otras rutas del árbol.

Computación de estilos

PDFmyURL.com

3. Para aplicar las reglas, es necesario utilizar reglas en cascada bastante complejas que definen la jerarquía de las reglas.

Veamos cómo se enfrentan los navegadores a estas dificultades:

Los nodos de WebKit hacen referencia los objetos de estilo (RenderStyle). Los nodos pueden compartir estos objetos en algunascircunstancias. Los nodos son del mismo nivel, ya pertenezcan al mismo nodo principal o a otro nodo del mismo nivel que este, y:

1. Los elementos deben tener el mismo estado de ratón (por ejemplo, uno no puede estar en ":hover" y el otro en otro estado).

2. Ninguno de los elementos debe tener un identificador.

3. Los nombres de las etiquetas deben coincidir.

4. Los atributos de clase deben coincidir.

5. El conjunto de atributos asignados debe ser idéntico.

6. Los estados de enlace deben coincidir.

7. Los estados de enfoque deben coincidir.

8. Ningún elemento se debe ver afectado por selectores de atributos, es decir, no debe presentar ninguna coincidencia con ningún selector queutilice un selector de atributo en ninguna posición dentro del selector.

9. No debe haber ningún atributo de estilo integrado en los elementos.

10. No debe haber ningún selector del mismo nivel en uso. WebCore simplemente aplica un cambio global si detecta un selector del mismo nivel einhabilita la opción de compartir estilos en todo el documento cuando está presente. Esto incluye el selector + y selectores como ":first-child"y ":last-child".

Firefox cuenta con dos árboles adicionales para una computación de estilos más sencilla: el árbol de reglas y el árbol de contextos deestilo. WebKit también cuenta con objetos de estilo, pero no se almacenan en un árbol como el árbol de contextos de estilo. Solo el nodode DOM indica el est ilo pert inente.

Datos de estilo compartidos

Árbol de reglas de Firefox

PDFmyURL.com

Figura 14: árbol de contextos de estilo (2.2)

Los contextos de estilo incluyen valores finales. Para computar los valores, se aplican todas las reglas con las que se hayan encontradocoincidencias en el orden correcto y se realizan manipulaciones que transforman los valores lógicos en concretos. Por ejemplo, si el valorlógico es un porcentaje de la pantalla, se calculará y se transformará en unidades absolutas. La idea del árbol de reglas es muy ingeniosa,ya que permite compartir estos valores entre nodos para evitar que se vuelvan a computar. Además, ahorra espacio.

Todas las reglas con las que se encuentra alguna coincidencia se almacenan en un árbol. Los nodos inferiores de una ruta t ienen mayorprioridad. El árbol incluye todas las rutas de las coincidencias que se han encontrado para una regla. Las reglas se almacenan lentamente. Elárbol no se computa al principio de cada nodo, pero siempre que se debe computar el est ilo de un nodo, las rutas se añaden al árbol.

La idea es que las rutas del árbol se muestren como las palabras de un lexicón. Imaginemos, por ejemplo, que ya hemos computado esteárbol de reglas:

PDFmyURL.com

Supongamos que necesitamos encontrar coincidencias para reglas de otros elementos del árbol de contenido y obtenemos las siguientesreglas (en el orden correcto): B - E - I. Ya teníamos esta ruta del árbol porque ya habíamos computado la ruta A - B - E - I - L, por lo queahora tendremos menos trabajo que hacer.

Vamos a comprobar cómo guarda el árbol nuestro trabajo.

Los contextos de estilo se dividen en estructuras que incluyen información de estilo de una cierta categoría, como el borde o el color.Todas las propiedades de un estructura pueden ser heredadas o no heredadas. Las propiedades heredadas son propiedades que, a menosque las defina el elemento, se heredan del elemento principal. Las propiedades no heredadas (denominadas propiedades "reset") ut ilizanlos valores predeterminados en caso de que no se definan.

El árbol guarda en caché estructuras completas (que incluyen los valores finales computados) del árbol. De esa forma, si el nodo inferior noproporciona una definición para una estructura, se puede utilizar una estructura guardada en caché de un nodo superior.

Cuando se computa el contexto de estilo de un elemento específico, primero se computa una ruta del árbol de reglas o se utiliza unaexistente. A continuación, se aplican las reglas de la ruta para completar las estructuras del nuevo contexto de estilo. Empezamos por elnodo inferior de la ruta, es decir, el nodo de mayor prioridad (normalmente el selector más específico), y recorremos el árbol en sentido

División en estructuras

Cómo computar los contextos de estilo con el árbol de reglas

PDFmyURL.com

ascendente hasta completar la estructura. Si este nodo de reglas no incluye ninguna especificación para la estructura, podemos optimizarloconsiderablemente (la mejor forma es recorrer el árbol en sentido ascendente hasta encontrar un nodo que incluya una especificacióncompleta y apuntar después a este nodo) y compartir la estructura completa. Gracias a este método ahorramos valores finales y memoria.Si encontramos definiciones parciales, recorremos el árbol en sentido ascendente hasta completar la estructura.

Si no encontramos definiciones para la estructura, en caso de que esta sea de t ipo "heredada", apuntamos a la estructura del elementoprincipal del árbol de contextos. En este caso, también conseguimos compartir las estructuras. Si la estructura es de t ipo "noheredada", se utilizarán los valores predeterminados.

Si el nodo más específico no añade valores, tendremos que efectuar cálculos adicionales para transformarlos en valores reales.Posteriormente, almacenamos en caché en el árbol el resultado del nodo para que se pueda utilizar como elemento secundario.

En caso de que un elemento tenga un elemento de su mismo nivel que apunte al mismo nodo del árbol, ambos elementos puedencompartir el contexto de estilo completo.

Veamos un ejemplo. Supongamos que tenemos el siguiente código HTML:

<html> <body> <div class="err" id="div1"> <p> this is a <span class="big"> big error </span> this is also a <span class="big"> very big error</span> error </p> </div> <div class="err" id="div2">another error</div> </body></html>

Y las siguientes reglas:

1. div {margin:5px;color:black}

2. .err {color:red}

3. .big {margin-top:3px}

PDFmyURL.com

4. div span {margin-bottom:4px}

5. #div1 {color:blue}

6. #div2 {color:green}

Para simplificar la tarea, digamos que tenemos que completar solo dos estructuras: la estructura de color y la estructura de margen. Laestructura de color solo contiene un miembro, el color, mientras que la estructura de margen contiene los cuatro lados. El árbol de reglas que se obtiene tendrá la siguiente apariencia (los nodos se marcan así: "nombre del nodo : número de la regla a la queapunta"):

Figura 15: árbol de reglas

El árbol de contextos tendrá la siguiente apariencia (nombre del nodo : nodo de regla a la que apunta):

PDFmyURL.com

Figura 16: árbol de contextos

Supongamos que analizamos el código HTML y obtenemos la segunda etiqueta <div>. Tendremos que crear un contexto de estilo para elnodo y completar sus estructuras de estilo. Buscamos las reglas que coincidan con <div> y descubrimos que son 1, 2 y 6. Esto significa que ya existe una ruta del árbol que podemosutilizar para nuestro elemento, por lo que solo necesitamos añadir otro nodo para la regla 6 (nodo F del árbol de reglas). Crearemos un contexto de estilo y lo incluiremos en el árbol de contextos. El nuevo contexto de estilo apuntará al nodo F del árbol dereglas.

Ahora necesitamos completar las estructuras de estilo. Empezaremos completando la estructura de margen. Como el últ imo nodo de regla(F) no se añade a la estructura de margen, podemos ascender por el árbol hasta encontrar una estructura almacenada en caché computadaen la inserción de un nodo anterior y utilizarla. Encontraremos esta estructura en el nodo B, que es el nodo de nivel más superior queespecifica reglas de margen.

Ya tenemos una definición para la estructura de color, por lo que no podemos utilizar una estructura almacenada en caché. Como el colort iene un atributo, no necesitamos ascender por el árbol para completar otros atributos. Computamos el valor final (convert imos la cadenaa RGB, etc.) y almacenamos en caché en este nodo la estructura computada.

El trabajo relacionado con el elemento <span> es aún más sencillo. Buscamos las reglas que coinciden con este elemento y llegamos a la

PDFmyURL.com

conclusión de que la regla a la que apunta es G, como el elemento "span" anterior. Como tenemos elementos del mismo nivel que apuntanal mismo nodo, podemos compartir el contexto de estilo completo y apuntar solo al contexto del elemento "span" anterior.

En el caso de las estructuras que incluyen reglas heredadas del elemento principal, el proceso de almacenamiento en caché se lleva a caboen el árbol de contextos (aunque la propiedad de color se hereda, Firefox trata esta propiedad como no heredada y la guarda en caché enel árbol de reglas). Por ejemplo, imaginemos que añadimos reglas para las fuentes de un parágrafo:

p {font-family:Verdana;font size:10px;font-weight:bold}

El elemento de párrafo, que es un elemento secundario del elemento "div" del árbol de contextos, podría compartir la misma estructura de fuenteque el elemento principal. Este caso se podría aplicar si no se especificasen reglas de fuente para el párrafo.

En WebKit, no existen los árboles de reglas, por lo que las declaraciones que coinciden se recorren cuatro veces. En primer lugar, se aplicanlas propiedades de alta prioridad de menor importancia (estas propiedades se deben aplicar primero porque hay otras que dependen deellas, como "display"); a continuación, se aplican las propiedades de alta prioridad de mayor importancia; posteriormente, las propiedadesde prioridad normal de menor importancia y, por últ imo, las reglas de prioridad normal de mayor importancia. Esto significa que laspropiedades que aparezcan varias veces se resolverán según el orden de cascada correcto. La últ ima es la más importante.

En resumen, compartir objetos de estilo (ya sea en su totalidad o compartiendo solamente algunas de sus estructuras) soluciona lasincidencias 1 y 3. El árbol de reglas de Firefox también ayuda a aplicar las propiedades en el orden correcto.

A continuación se muestran las dist intas fuentes de reglas de los modificadores de estilo.

Reglas de CSS, tanto en hojas de estilo internas como en elementos de estilo:

p {color:blue}

Atributos de estilo integrados, como el siguiente:

<p style="color:blue" />

Cómo manipular las reglas para obtener coincidencias fácilmente

PDFmyURL.com

Atributos visuales HTML (que se asignan a reglas de estilo relevantes):

<p bgcolor="blue" />

Las dos últ imas fuentes coinciden fácilmente con el elemento, ya que este incluye los atributos de estilo, y los atributos HTML se puedenasignar utilizando el elemento como clave.

Como se comentó previamente en la incidencia 2, buscar una coincidencia con la regla de CSS puede resultar bastante complicado. Pararesolver esta dificultad, las reglas se manipulan para facilitar el acceso.

Después de analizar la hoja de estilo, las reglas se añaden a uno de varios mapas hash, de acuerdo con el selector. Existen mapasorganizados por ID, nombre de clase y nombre de etiqueta, y un mapa general para todo lo que no se puede incluir en estas categorías. Siel selector es un ID, la regla se añadirá al mapa de ID; si es una clase, se añadirá al mapa de clase, etc. Esta manipulación facilita considerablemente la tarea de asignación de reglas. No hace falta revisar cada declaración, podemos extraer lasreglas relevantes para un elemento de los mapas. Esta optimización elimina más del 95% de las reglas, por lo que ni siquiera es necesariotenerlas en cuenta durante el proceso de búsqueda de coincidencias (4.1).

Analicemos las reglas de estilo que se incluyen a continuación:

p.error {color:red}#messageDiv {height:50px}div {margin:5px}

La primera regla se insertará en el mapa de clase, la segunda en el mapa de ID y la tercera en el mapa de etiquetas. Para el siguiente fragmento de HTML:

<p class="error">an error occurred </p><div id=" messageDiv">this is a message</div>

En primer lugar, intentaremos buscar reglas para el elemento "p". El mapa de clase incluirá una clave "error" dentro de la que se encuentra laregla para "p.error". El elemento "div" tendrá reglas relevantes en el mapa de ID (la clave es el ID) y el mapa de etiqueta. Por tanto, soloqueda averiguar qué reglas extraídas de las claves realmente coinciden. Por ejemplo, si la regla del elemento "div" fuera la siguiente:

PDFmyURL.com

table div {margin:5px}

se extraería del mapa de etiqueta, porque la clave es el selector situado más a la derecha, pero no coincidiría con el elemento "div", que no cuentacon un antecesor de tabla.

Tanto WebKit como Firefox utilizan esta manipulación.

El objeto de estilo t iene propiedades que se corresponden con cada atributo visual (todos los atributos CSS, pero más genéricos). Sininguna de las reglas que coinciden define la propiedad, algunas propiedades se pueden heredar del elemento principal del objeto de estilo.Otras propiedades t ienen valores predeterminados.

La incidencia se produce cuando existe más de una definición, y es entonces cuando se debe utilizar el orden en cascada para resolverla.

Una declaración de una propiedad de estilo puede aparecer en varias hojas de estilo y varias veces dentro de una misma hoja. Por ese motivo, elorden de aplicación de las reglas tiene una gran importancia. Este orden se conoce como "cascada". De acuerdo con las especificaciones de CSS2,el orden en cascada es el siguiente (de menor a mayor):

1. declaraciones del navegador,

2. declaraciones normales del usuario,

3. declaraciones normales del autor,

4. declaraciones importantes del autor,

5. declaraciones importantes del usuario.

Las declaraciones del navegador son las que t ienen menos importancia y las del usuario solo t ienen prioridad sobre las del autor si estánmarcadas como importantes. Las declaraciones con el mismo orden se ordenan según la especificidad y, posteriormente, según el orden enel que se han especificado. Los atributos visuales HTML se traducen en las declaraciones CSS correspondientes. Se tratan como reglas deautor de prioridad baja.

Cómo aplicar las reglas en el orden de cascada correcto

Orden en cascada de la hoja de estilo

Especificidad

PDFmyURL.com

La especificación de CSS2 define la especificidad del selector como se indica a continuación:

"1" si la declaración es de un atributo "style" en lugar de una regla con un selector; en caso contrario, "0" (= a),

número de atributos de ID del selector (= b),

número de otros atributos y pseudoclases del selector (= c),

número de nombres de elementos y de pseudoelementos del selector (= d).

La especificidad se obtiene al concatenar los cuatro números a-b-c-d (en un sistema de números de base amplia).

La base numérica que se debe utilizar es el número de recuento más elevado de una de las categorías. Por ejemplo, si a=14, se puede utilizar una base hexadecimal. En el improbable caso de que a=17, se deberá utilizar una base numérica de17 dígitos. El últ imo caso sería el de un selector como html body div div p... con 17 etiquetas en el selector, pero esto es muy pocoprobable.

Algunos ejemplos:

* {} /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */ li {} /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */ li:first-line {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */ ul li {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */ ul ol+li {} /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */ h1 + *[rel=up]{} /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */ ul ol li.red {} /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */ li.red.level {} /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */ #x34y {} /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */ style="" /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

Después de buscar coincidencias, las reglas se ordenan según las reglas de cascada. WebKit ut iliza el ordenamiento de burbuja para listaspequeñas y el ordenamiento por mezcla para listas grandes. WebKit ordena las reglas sobrescribiendo el operador ">" para las reglas:

static bool operator >(CSSRuleData& r1, CSSRuleData& r2){

Cómo ordenar las reglas

PDFmyURL.com

int spec1 = r1.selector()->specificity(); int spec2 = r2.selector()->specificity(); return (spec1 == spec2) : r1.position() > r2.position() : spec1 > spec2;}

WebKit ut iliza un indicador que muestra si se han cargado todas las hojas de estilo de nivel superior (incluidas las de @imports). Si las hojasde estilo no se cargan por completo al asociarlas, se utilizan marcadores de posición (indicándolo en el documento), que se vuelven acalcular una vez que se han cargado las hojas de estilo.

Cuando el renderizador se crea y se añade al árbol, no t iene posición ni tamaño. El cálculo de estos valores se conoce como diseño oreflujo.

HTML utiliza un modelo de diseño basado en flujo, lo que significa que, la mayoría de las veces, los cálculos geométricos se pueden realizarcon una sola operación. Los elementos que entran posteriormente "en el flujo" no suelen influir en la geometría de los elementos que ya seencuentran en él, por lo que el diseño se puede aplicar de izquierda a derecha y de arriba a abajo en todo el documento. Hay excepciones,como las tablas HTML, que pueden requerir más de un cálculo (3.5).

El sistema de coordenadas se refiere al marco raíz. Se utilizan las coordenadas superior e izquierda.

El diseño consiste en un proceso recurrente. Se inicia en el renderizador raíz, que corresponde al elemento <html> del documento HTML.El diseño se aplica de forma recurrente a través de toda la jerarquía de marcos o de una parte de ella, calculando información geométricapara cada renderizador que lo requiere.

La posición del renderizador raíz es 0,0 y su dimensión es la ventana gráfica, es decir, la parte visible de la ventana del navegador.

Todos los renderizadores incluyen un método de "diseño" o de "reflujo" y cada uno activa el método de diseño del elemento secundario alque se debe aplicar el diseño.

Para no iniciar un proceso de diseño completo con cada pequeña modificación, el navegador utiliza un sistema de bit de modificación (dirtybit). Cuando se añade o se modifica un renderizador, tanto el propio renderizador como su elemento secundario se marcan con el indicador

Proceso gradual

Chapter 5

Diseño

Sistema de bit de modificación (dirty bit)

PDFmyURL.com

bit). Cuando se añade o se modifica un renderizador, tanto el propio renderizador como su elemento secundario se marcan con el indicador"dirty", lo que significa que se deben someter a un proceso de diseño.

Existen dos indicadores: "dirty" y "children are dirty". El indicador "children are dirty" especifica que, aunque el renderizador no haya sufridocambios, al menos uno de sus elementos secundarios necesita someterse a un proceso de diseño.

El proceso de diseño se puede activar en todo el árbol de renderización, lo que se conoce como diseño "global". A continuación se indicanalgunos motivos por los que puede ser necesario un diseño global:

1. un cambio de estilo global que afecte a todos los renderizadores, como un cambio de tamaño de fuente,

2. un cambio de tamaño de la pantalla.

El diseño puede ser incremental, en cuyo caso solo se someterán a un proceso de diseño los renderizadores marcados como "dirty" (estehecho puede provocar daños que pueden requerir procesos de diseño adicionales). Cuando los renderizadores están marcados como "dirty", se act iva (de forma asíncrona) el diseño incremental (por ejemplo, cuando seañaden renderizadores nuevos al árbol de renderización después de incluir contenido adicional de la red en el árbol de DOM).

Diseño global e incremental

PDFmyURL.com

Figura 17: diseño incremental en el que solo se someten a un proceso de diseño los renderizadores modificados y sus elementos secundarios(3.6)

El diseño incremental se efectúa de forma asíncrona. Firefox almacena "comandos de reflujo" para los diseños incrementales y un programadoractiva la ejecución en lote de estos comandos. WebKit también incluye un temporizador que ejecuta el diseño incremental (se recorre el árbol y seaplica diseño a los renderizadores marcados como "dirty"). Las secuencias de comandos que solicitan información de estilo, como "offsetHeight", pueden activar el diseño incremental de forma síncrona. El diseño global se suele activar de forma síncrona. A veces, el diseño se activa como una devolución de llamada posterior a un diseño inicial debido a los cambios que sufren algunos atributos, comola posición de desplazamiento.

Cuando se activa un proceso de diseño por un "cambio de tamaño" o por un cambio en la posición del renderizador (no en su tamaño), el tamañode los renderizadores se toma de una caché en lugar de recalcularse. En algunos casos, solo se modifica un subárbol, por lo que el proceso de diseño no se inicia desde la raíz. Esto puede suceder en aquellos casos enlos que el cambio es local y no afecta a los elementos que lo rodean, como el texto insertado en campos de texto (de lo contrario, cada teclaactivaría un diseño desde la raíz) .

El proceso de diseño suele seguir el patrón que se indica a continuación:

1. El renderizador principal determina su propio ancho.

2. El renderizador principal analiza los elementos secundarios y:

1. Sitúa el renderizador secundario (establece su valor x e y).

2. Activa la aplicación del diseño del renderizador secundario en caso necesario (si está marcado como "dirty", si se trata de un diseñoglobal o por alguna otra causa), lo que hace que se calcule la altura del renderizador secundario.

3. El renderizador principal utiliza las alturas acumulativas de los elementos secundarios y las alturas de los márgenes y el relleno para establecersu propia altura, que utilizará el elemento principal del renderizador principal.

4. Establece el bit de modificación (dirty bit) en "false".

Firefox utiliza un objeto "state" (nsHTMLReflowState) como parámetro de diseño (conocido como "reflujo"). Entre otros valores, el objetode estado incluye el ancho de los elementos principales. El resultado del diseño de Firefox es un objeto "metrics" (nsHTMLReflowMetrics) que incluirá la altura computada del renderizador.

El ancho del renderizador se calcula utilizando el ancho del bloque contenedor, la propiedad de estilo "width" del renderizador, los márgenes

Diseño asíncrono y síncrono

Optimizaciones

El proceso de diseño

Cálculo del ancho

PDFmyURL.com

y los bordes. Utilicemos para nuestro ejemplo el siguiente elemento "div":

<div style="width:30%"/>

WebKit calcularía su ancho de la siguiente forma (clase "RenderBox", método "calcWidth"):

El ancho del contenedor es el valor máximo de la propiedad "availableWidth" de los contenedores y 0. En este caso, la propiedad"availableWidth" es la propiedad "contentWidth", que se calcula así:

clientWidth() - paddingLeft() - paddingRight()

Las propiedades "clientWidth" y "clientHeight" representan el interior de un objeto, excluyendo el borde y la barra de desplazamiento.

El ancho de los elementos es el atributo de estilo "width", que se calcula como un valor absoluto computando el porcentaje del anchodel contenedor.

A continuación, se añaden el relleno y los bordes horizontales.

Hasta ahora, hemos calculado el "ancho preferente". Ahora vamos a calcular los anchos mínimo y máximo. Si el ancho preferente es superior al ancho máximo, se utiliza el ancho máximo. Si, por el contrario, es inferior al ancho mínimo (la unidad indivisiblemás pequeña), se utiliza el ancho mínimo.

Los valores se almacenan en caché en caso de que se necesite act ivar un proceso de diseño sin que varíe el ancho.

El salto de línea se produce cuando un renderizador decide que debe interrumpirse en mitad del diseño. Se detiene y comunica el salto alrenderizador principal. El renderizador principal crea renderizadores adicionales y act iva sus procesos de diseño.

En la fase de pintura, se recorre el árbol de renderización y se act iva el método de "pintura" de los renderizadores para que se muestre sucontenido en la pantalla. En la fase de pintura, se utiliza el componente de infraestructura de la interfaz.

Salto de línea

Chapter 6

Pintura

PDFmyURL.com

Al igual que ocurre en la fase de diseño, la pintura también puede ser un proceso global (se pinta el árbol de renderización completo) o incremental.En el caso de la pintura incremental, algunos de los renderizadores se modifican de una forma que no afecta a la totalidad del árbol. El renderizadormodificado invalida su rectángulo correspondiente en la pantalla. Esto hace que el sistema operativo considere esta región como modificada y quegenere un evento de "pintura". El sistema operativo fusiona ingeniosamente varias regiones en una. En Chrome, esta operación resulta máscomplicada, ya que el renderizador se encuentra en un proceso diferente al proceso principal. Chrome simula el comportamiento del sistemaoperativo hasta cierto punto. La presentación escucha estos eventos y delega el mensaje en la raíz de la renderización. Se recorre el árbol hastallegar al renderizador correspondiente. En consecuencia, se vuelve a pintar el renderizador y, normalmente, sus elementos secundarios.

Haz clic aquí para conocer el orden del proceso de pintura en CSS2. Es el orden en el que se apilan los elementos en los contextos de pila. Esteorden influye en la pintura, ya que las pilas se pintan de atrás hacia delante. El orden de apilamiento de un renderizador de bloque es el siguiente:

1. color de fondo,

2. imagen de fondo,

3. borde,

4. elementos secundarios,

5. contorno.

Firefox analiza el árbol de renderización y crea una lista de visualización para el área rectangular pintada que incluye los renderizadores relevantespara el área rectangular en el orden de pintura correcto (primero los fondos de los renderizadores, luego los bordes, etc.). De esta forma, si sequiere volver a pintar el árbol, solo se tendrá que recorrer una vez (primero se pintan todos los fondos, después todas las imágenes, a continuacióntodos los bordes, etc.).

Para optimizar el proceso, Firefox no añade elementos que vayan a quedar ocultos, como los elementos que quedan totalmente ocultosbajo otros elementos opacos.

Antes de volver a iniciar un proceso de pintura, WebKit guarda el rectángulo antiguo como un mapa de bits. Posteriormente, solo pinta el áreadiferencial existente entre los rectángulos nuevo y antiguo.

Los navegadores intentan ejecutar la menor cantidad posible de acciones cuando se produce un cambio. Por tanto, si se producen cambios en elcolor de un elemento, solo se volverá a pintar ese elemento. Si se producen cambios en la posición de un elemento, se volverá a diseñar y a pintarese elemento, sus elementos secundarios y, posiblemente, los elementos que estén a su mismo nivel. Si se añade un nodo DOM, se activará un

Global e incremental

Orden del proceso de pintura

Lista de visualización de Firefox

Almacenamiento de figuras rectangulares de WebKit

Chapter 7

Cambios dinámicos

PDFmyURL.com

proceso de diseño y de nueva pintura del nodo. Si se producen cambios de mayor importancia, como el aumento del tamaño de fuente delelemento "html", se invalidarán las cachés y se activará un nuevo proceso de diseño y de pintura del árbol completo.

El motor de renderización solo consta de un subproceso. Casi todas las operaciones, excepto las de red, se desarrollan en un único subproceso. EnFirefox y Safari, es el subproceso principal del navegador. En Chrome, es el subproceso principal del proceso de pestaña. Las operaciones de red se pueden realizar mediante varios subprocesos paralelos. El número de conexiones paralelas es limitado (normalmente, dedos a seis conexiones. Por ejemplo, Firefox 3 utiliza seis).

El subproceso principal del navegador es un bucle de eventos, que consiste en un bucle infinito que mantiene activo el proceso. Espera a que seinicien eventos (como los de diseño y pintura) y los procesa. Este es el código de Firefox para el bucle de eventos principal:

while (!mExiting) NS_ProcessNextEvent(thread);

De acuerdo con la especificación de CSS2 , el término canvas describe "el espacio en el que se representa la estructura de formato", esdecir, el lugar en el que el navegador pinta el contenido. Aunque el elemento canvas es infinito para cada dimensión del espacio, losnavegadores eligen un ancho inicial en función de las dimensiones de la ventana gráfica.

De acuerdo con las indicaciones de la página www.w3.org/TR/CSS2/zindex.html , el elemento canvas es transparente si se incluye dentrode otro elemento o t iene un color definido por el navegador si no se incluye en ningún elemento.

El modelo de cajas de CSS describe las cajas rectangulares que se generan para los elementos del árbol del documento y que se diseñande acuerdo con el modelo de formato visual. Cada caja consta de un área de contenido (por ejemplo, texto, una imagen, etc.) y de áreas circundantes opcionales de margen, borde yrelleno.

Chapter 8

Subprocesos del motor de renderización

Bucle de eventos

Chapter 9

Modelo de formato visual de CSS2El elemento canvas

Modelo de cajas de CSS

PDFmyURL.com

Figura 18: modelo de cajas de CSS2

Cada nodo genera entre 0y n cajas de este t ipo. Todos los elementos t ienen una propiedad "display" que determina el t ipo de caja que se generará. Ejemplos:

block - generates a block box.inline - generates one or more inline boxes.none - no box is generated.

Aunque el tipo de caja predeterminado es "inline", la hoja de estilo del navegador establece otros tipos predeterminados. Por ejemplo, el tipo devisualización predeterminado de un elemento "div" es "block". Puedes consultar un ejemplo de hoja de estilo predeterminada en la página www.w3.org/TR/CSS2/sample.html .

A continuación se indican los tres t ipos de esquemas disponibles.

1. Flujo normal: el objeto se coloca en función del lugar que ocupa en el documento (esto significa que el lugar que ocupa en el árbol de

Esquema de posicionamiento

PDFmyURL.com

renderización es similar al lugar que ocupa en el árbol de DOM) y se diseña de acuerdo con sus dimensiones y con el tipo de caja.

2. Flotante: el objeto se diseña primero según el flujo normal y, posteriormente, se mueve hacia la derecha o hacia la izquierda todo lo posible.

3. Posicionamiento absoluto: el objeto se coloca en el árbol de renderización de una forma diferente a la que se utiliza para colocarlo en el árbolde DOM.

La propiedad "posit ion" y el atributo "float" determinan el esquema de posicionamiento.

Si se utilizan "stat ic" y "relat ive", se genera un flujo normal.

Si se utilizan "absolute" y "fixed", se produce un posicionamiento absoluto.

Cuando el posicionamiento es estático, no se define ninguna posición, por lo que se utiliza el posicionamiento predeterminado. En otros esquemas, elautor especifica la posición: arriba, abajo, izquierda, derecha.

Los siguientes valores determinan el diseño de la caja:

t ipo de caja,

dimensiones de la caja,

esquema de posicionamiento,

información externa, como el tamaño de las imágenes y el tamaño de la pantalla.

Caja de bloque: forma un bloque (t iene su propio rectángulo en la ventana del navegador).

Figura 19: caja de bloque

Caja integrada: no t iene bloque propio, sino que se incluye en un bloque de contención.

Tipos de cajas

PDFmyURL.com

Figura 20: cajas integradas

Las cajas de bloque se colocan en vert ical, una detrás de otra, mientras que las cajas integradas se distribuyen horizontalmente.

Figura 21: formato de cajas de bloque e integradas

PDFmyURL.com

Las cajas integradas se colocan dentro de líneas o "cajas de línea". Cuando las cajas se alinean tomando como punto de referencia su base,es decir, la parte inferior de un elemento se alinea con otra caja tomando como referencia una parte diferente a la inferior, las líneas t ienencomo mínimo la misma altura que la caja más alta, aunque pueden ser más altas. En caso de que el ancho del contenedor no sea suficiente,las cajas integradas se colocan en diferentes líneas. Esto es lo que suele ocurrir en un párrafo.

Figura 22: líneas

Posicionamiento relat ivo: el elemento se coloca normalmente y, a continuación, se mueve según el diferencial correspondiente.

PosicionamientoRelativo

PDFmyURL.com

Figura 23: posicionamiento relativo

Una caja flotante se desplaza a la izquierda o a la derecha de una línea. Lo más interesante de este posicionamiento es que las demáscajas fluyen a su alrededor. A continuación, se incluye un ejemplo con código HTML:

<p> <img style="float:right" src="images/image.gif" width="100" height="100"> Lorem ipsum dolor sit amet, consectetuer...</p>

La apariencia sería la siguiente:

Flotante

PDFmyURL.com

Figura 24: caja flotante

El diseño se define con exactitud independientemente del flujo normal. El elemento no part icipa en el flujo normal. Las dimensiones sonrelat ivas al contenedor. En el posicionamiento fijo, el contenedor es la ventana gráfica.

Figura 25: posicionamiento fijo

Absoluto y fijo

PDFmyURL.com

Nota: la caja fija no se moverá aunque el usuario se desplace por el documento.

Las capas se especifican con la propiedad "z-index" de CSS. Representa la tercera dimensión de la caja, es decir, su posición a lo largo del"eje z".

Las cajas se dividen en pilas (denominadas "contextos de pila"). En cada pila, los elementos que quedan debajo se pintan en primer lugar, ylos elementos que quedan encima se colocan en la parte superior, más cerca del usuario. En caso de superposición, se oculta el elementoque queda debajo. Las pilas se ordenan según la propiedad "z-index". Las cajas que t ienen la propiedad "z-index" forman una pila local. La ventana gráficaforma la pila exterior.

Ejemplo:

<style type="text/css"> div { position: absolute; left: 2in; top: 2in; }</style>

<p> <div style="z-index: 3;background-color:red; width: 1in; height: 1in; "> </div> <div style="z-index: 1;background-color:green;width: 2in; height: 2in;"> </div> </p>

Se obtendrá el siguiente resultado:

Representación en capas

PDFmyURL.com

Figura 26: posicionamiento fijo

Aunque el elemento "div" rojo preceda al verde en el marcado y se pinte en primer lugar en un flujo normal, el valor de la propiedad "z-index" es superior, por lo que se encuentra más adelantado en la pila de la caja raíz.

1. Arquitectura del navegador

1. Grosskurth, Alan. A Reference Architecture for Web Browsers (pdf)

2. Gupta, Vineet. How Browsers Work - Part 1 - Architecture

2. Análisis

1. Aho, Sethi, Ullman, Compilers: Principles, Techniques, and Tools, también conocido como "The Dragon Book" (El libro del dragón),Addison-Wesley, 1986

2. Rick Jelliffe. The Bold and the Beautiful: two new drafts for HTML 5

3. Firefox

1. L. David Baron, Faster HTML and CSS: Layout Engine Internals for Web Developers

2. L. David Baron, Faster HTML and CSS: Layout Engine Internals for Web Developers (vídeo de Google Tech Talks)

3. L. David Baron, Mozilla's Layout Engine

Chapter 10

Recursos

PDFmyURL.com

4. L. David Baron, Mozilla Style System Documentation

5. Chris Waterson, Notes on HTML Reflow

6. Chris Waterson, Gecko Overview

7. Alexander Larsson, The life of an HTML HTTP request

4. WebKit

1. David Hyatt, Implementing CSS(part 1)

2. David Hyatt, An Overview of WebCore

3. David Hyatt, WebCore Rendering

4. David Hyatt, The FOUC Problem

5. Especificaciones de W3C

1. HTML 4.01 Specification

2. W3C HTML5 Specification

3. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification

6. Instrucciones de creación de navegadores

1. Firefox: https://developer.mozilla.org/en/Build_Documentation

2. WebKit: http://webkit.org/building/build.html

Tali Garsiel es una desarrolladora de Israel. Empezó su andadura como desarrolladora web en el año 2000 y se familiarizócon el "maléfico" modelo de capas de Netscape. Al igual que Richard Feynmann, sentía fascinación por descubrir cómofuncionaban las cosas, por lo que empezó a investigar los mecanismos de funcionamiento interno de los navegadores y adocumentar todos sus descubrimientos. Tali también ha publicado una pequeña guía sobre rendimiento de aplicacionescliente .

Esta página se ha traducido al japonés ¡dos veces! Cómo funcionan los navegadores: lo que hay detrás de los navegadoresweb actuales (ja) por @_kosei_ y ブラウザってどうやって動いてるの？（モダンWEBブラウザシーンの裏側 por @ikeike443y @kiyoto01 . ¡Gracias a todos!

Traducciones

PDFmyURL.com

Salvo disposic ión en contra, el contenido de esta página está sujeto a la licencia Reconocimiento 3.0 de Creative Commons y los ejemplos de código a la licenciaApache 2.0.

Índice

PDFmyURL.com

ÍndiceTraducciones

PDFmyURL.com