Cmo funcionan los navegadores: lo que hay

detrs de los navegadores web actuales

By Tali Garsiel and Paul Irish

Publicacin: agosto 5th, 2011
Comments: 3

Prlogo
Este completo manual sobre las operaciones internas de WebKit y Gecko es el
resultado de las extensas investigaciones realizadas por la desarrolladora israel Tali
Garsiel. Durante varios aos ha estado revisando toda la informacin publicada sobre
las caractersticas internas de los navegadores web (consulta la seccin Recursos) y ha
pasado mucho tiempo leyendo su cdigo fuente. Tali escribi lo siguiente:

"En los aos en los que Internet Explorer acaparaba el 90% del mercado, el
navegador se poda considerar poco ms que "caja negra", pero ahora que los
navegadores de cdigo abierto dominan ms de la mitad del mercado, es un buen
momento para echar un vistazo al interior de los navegadores y ver lo que
esconden. Bueno, lo que esconden millones de lneas de cdigo en C++..."

Tali ha publicado su investigacin en su sitio web, pero como sabamos que se mereca
un pblico ms amplio, lo hemos publicado aqu tambin tras hacer algunas
modicaciones.
Como desarrolladora web, conocer las caractersticas internas de las operaciones
de los navegadores sirve para tomar mejores decisiones y para conocer los
motivos que justican las prcticas de desarrollo recomendadas. Aunque se trata
de un documento bastante extenso, te recomendamos que dediques un poco de tu
tiempo a examinarlo. Ten por seguro que no te arrepentirs.
Paul Irish, Relaciones con desarrolladores de Chrome

Introduccin
Los navegadores son probablemente el software ms utilizado de todos. En este
manual se explica su funcionamiento interno. Veremos qu ocurre cuando escribes

google.com en la barra de direcciones hasta que la pgina de Google aparece en la

pantalla.

ndice
1. Introduccin
1. Los navegadores de los que hablaremos
2. La funcin principal de un navegador
3. Componentes principales del navegador
2. El motor de renderizacin
1. Motores de renderizacin
2. El ujo principal
3. Ejemplos del ujo principal
3. Anlisis y construccin del rbol de DOM
1. Anlisis (general)
1.
2.
3.
4.
5.
6.
7.

Gramticas
Analizador: combinacin de analizadores lxicos
Traduccin
Ejemplo de anlisis
Deniciones formales de vocabulario y sintaxis
Tipos de analizadores
Cmo generar analizadores automticamente

2. Analizador de HTML
1.
2.
3.
4.
5.
6.
7.
8.
9.

Denicin de gramtica HTML

No es una gramtica libre de contexto
DTD de HTML
DOM
El algoritmo de anlisis
El algoritmo de tokenizacin
Algoritmo de construccin de rbol
Acciones al nalizar el anlisis
Tolerancia a errores de los navegadores

3. Anlisis 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. Anlisis especulativo
3. Hojas de estilo
4. Construccin del rbol de renderizacin
1. Relacin del rbol de renderizacin con el rbol de DOM
2. El ujo de construccin del rbol
3. Computacin de estilos
1. Datos de estilo compartidos

1. Datos de estilo compartidos

2. rbol de reglas de Firefox
1. Divisin en estructuras
2. Cmo computar los contextos de estilo con el rbol de reglas
3. Cmo manipular las reglas para obtener coincidencias fcilmente
4. Cmo aplicar las reglas en el orden de cascada correcto
1. Orden en cascada de la hoja de estilo
2. Especicidad
3. Cmo ordenar las reglas
4. Proceso gradual
5. Diseo
1.
2.
3.
4.
5.
6.
7.

Sistema de bit de modiacin (dirty bit)

Diseo global e incremental
Diseo asncrono y sncrono
Optimizaciones
El proceso de diseo
Clculo del ancho
Salto de lnea

6. Pintura
1.
2.
3.
4.

Global e incremental
Orden del proceso de pintura
Lista de visualizacin de Firefox
Almacenamiento de guras rectangulares de WebKit

7. Cambios dinmicos
8. Subprocesos del motor de renderizacin
1. Bucle de eventos
9. Modelo de formato visual de CSS2
1.
2.
3.
4.
5.

El elemento canvas
Modelo de cajas de CSS
Esquema de posicionamiento
Tipos de cajas
Posicionamiento
1. Relativo
2. Flotante
3. Absoluto y jo

6. Representacin en capas
10. Recursos

Los navegadores de los que hablaremos

En la actualidad se utilizan principalmente cinco navegadores: Internet Explorer,

Firefox, Safari, Chrome y Opera. Los ejemplos de este documento se reeren a
navegadores de cdigo abierto, como Firefox, Chrome y Safari (este ltimo es en parte
de cdigo abierto). Segn las estadsticas sobre navegadores de StatCounter,
actualmente (agosto de 2011) el uso conjunto de Firefox, Safari y Chrome representa el
60%. Por tanto, en estos momentos los navegadores de cdigo abierto constituyen
una parte importante del mercado de los navegadores.

La funcin principal de un navegador

La funcin principal de un navegador es solicitar al servidor los recursos web que elija
el usuario y mostrarlos en una ventana. El recurso suele ser un documento HTML, pero
tambin puede ser un archivo PDF, una imagen o un objeto de otro tipo. El usuario
especica la ubicacin del recurso mediante el uso de una URI (siglas de Uniform
Resource Identier, identicador uniforme de recurso).
La forma en la que el navegador interpreta y muestra los archivos HTML se determina
en las especicaciones de CSS y HTML. Estas especicaciones las establece el
consorcio W3C (World Wide Web Consortium), que es la organizacin de estndares
de Internet.
Durante aos, los navegadores cumplan solo una parte de las especicaciones y
desarrollaban sus propias extensiones. Esto provoc graves problemas de
compatibilidad para los creadores de contenido web. En la actualidad, la mayora de
los navegadores cumplen las especicaciones en mayor o menor grado.
Las interfaces de usuario de los distintos navegadores tienen muchos elementos en
comn. Estos son algunos de los elementos comunes de las interfaces de usuario:
una barra de direcciones donde insertar las URI,
botones de avance y retroceso,
opciones de marcadores,
un botn para detener la carga de los documentos actuales y otro para volver a
cargarlos,
un botn de inicio que permite volver a la pgina de inicio.
Estas coincidencias resultan extraas, ya que la interfaz de usuario de los navegadores
no se incluye en ninguna de las especicaciones formales, sino que procede de la
experiencia acumulada a lo largo de los aos y de los elementos que los navegadores
han imitado unos de otros. La especicacin de HTML5 no dene los elementos que
debe incluir la interfaz de usuario de los navegadores, pero muestra algunos elementos
comunes. Entre estos elementos se encuentran la barra de direcciones, la barra de
estado y la barra de herramientas. Existen, por supuesto, caractersticas nicas de
cada navegador, como el administrador de descargas de Firefox.

Componentes principales del navegador

A continuacin se especican los componentes principales de un navegador (1.1).
1. Interfaz de usuario: incluye la barra de direcciones, el botn de
avance/retroceso, el men de marcadores, etc. (en general, todas las partes
visibles del navegador, excepto la ventana principal donde se muestra la pgina
solicitada).
2. Motor de bsqueda: coordina las acciones entre la interfaz y el motor de
renderizacin.
3. Motor de renderizacin: es responsable de mostrar el contenido solicitado. Por
ejemplo, si el contenido solicitado es HTML, ser el responsable de analizar el
cdigo 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 realiza implementaciones en
segundo plano para cada plataforma.
5. Servidor de la interfaz: permite presentar widgets bsicos, como ventanas y
cuadros combinados. Muestra una interfaz genrica que no es especca de
ninguna plataforma. Utiliza mtodos de la interfaz de usuario del sistema
operativo en segundo plano.
6. Intrprete de JavaScript: permite analizar y ejecutar el cdigo 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
especicacin de HTML (HTML5) dene el concepto de "base de datos web",
que consiste en una completa (aunque ligera) base de datos del navegador.

Figura : componentes principales del navegador

Es importante decir que Chrome, a diferencia de la mayora de los navegadores,

implementa varias instancias del motor de renderizacin, una por cada pestaa. Cada
pestaa representa un proceso independiente.

El motor de renderizacin
La responsabilidad del motor de renderizacin es "renderizar", es decir, mostrar el
contenido solicitado en la pantalla del navegador.
De forma predeterminada, el motor de renderizacin puede mostrar imgenes y
documentos HTML y XML. Puede mostrar otros tipos mediante el uso de
complementos (o extensiones); por ejemplo, puede mostrar documentos PDF
mediante un complemento capaz de leer archivos PDF. Sin embargo, en este captulo
nos centraremos en su uso principal: mostrar imgenes y cdigo HTML con formato
denido con CSS.

Motores de renderizacin
Nuestros navegadores de referencia (Firefox, Chrome y Safari) estn basados en dos
motores de renderizacin. Firefox utiliza Gecko, un motor de renderizacin propio de
Mozilla. Tanto Safari como Chrome utilizan WebKit.
WebKit es un motor de renderizacin de cdigo abierto que empez siendo un motor
de la plataforma Linux y que fue modicado posteriormente por Apple para hacerlo
compatible con Mac y Windows. Puedes obtener ms informacin en webkit.org.

El ujo principal
El motor de renderizacin empieza recibiendo el contenido del documento solicitado
desde la capa de red, normalmente en fragmentos de 8.000 bytes.
A continuacin, el motor de renderizacin realiza este ujo bsico:

Figura : ujo bsico del motor de renderizacin

El motor de renderizacin empieza a analizar el documento HTML y convierte las

etiquetas en nodos DOM en un rbol denominado "rbol de contenido". Analiza los
datos de estilo, tanto en los archivos CSS externos como en los elementos de estilo.
Los datos de estilo, junto con las instrucciones visuales del cdigo HTML, se utilizan
para crear otro rbol: el rbol de renderizacin.

El rbol de renderizacin contiene rectngulos con atributos visuales, como el color y

las dimensiones. Los rectngulos estn organizados en el orden en el que aparecern
en la pantalla.
Una vez construido el rbol de renderizacin, se inicia un proceso de "diseo". Esto
signica que a cada nodo se le asignan las coordenadas exactas 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 renderizacin y se 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 renderizacin intentar mostrar el contenido en
pantalla lo antes posible. No esperar a que se analice el cdigo HTML para empezar a
crear y disear el rbol de renderizacin. Se analizarn y se mostrarn algunas partes
del contenido, mientras que se sigue procesando el resto del contenido que llega de la
red.

Ejemplos del ujo principal

Figura : ujo principal de WebKit

Figura : ujo principal del motor de renderizacin Gecko de Mozilla

(3.6)

En las guras 3 y 4 se puede ver que, aunque WebKit y Gecko utilizan una terminologa
ligeramente diferente, el ujo es bsicamente el mismo.
Gecko denomina al rbol de elementos formateados visualmente "rbol de marcos".
Cada uno de los elementos es un marco. WebKit utiliza los trminos "rbol de
renderizacin" y "objetos de renderizacin" en lugar de los anteriores. WebKit utiliza el
trmino "diseo" para colocar los elementos, mientras que Gecko lo denomina
"reujo". WebKit utiliza el trmino "asociacin" para conectar los nodos DOM con
informacin visual para crear el rbol de renderizacin. Una pequea diferencia no
semntica es que Gecko dispone de una capa extra entre el cdigo HTML y el rbol de
DOM. Esta capa se denomina "depsito de contenido" y est dedicada a la creacin
de elementos DOM. Vamos a ver cada una de las partes del ujo:

Anlisis (general)
Dado que el anlisis es un proceso muy importante del motor del renderizacin, vamos
a verlo de una forma ms detallada. Comencemos por una breve introduccin a este
proceso.
Analizar un documento signica traducirlo a una estructura que tenga sentido, es decir,
algo que el cdigo pueda comprender y utilizar. El resultado del anlisis suele ser un
rbol de nodos que representa la estructura del documento. Este rbol se denomina
"rbol de anlisis" o "rbol de sintaxis".
Ejemplo: el anlisis de la expresin 2 + 3 - 1 podra dar como resultado este rbol:

Figura : nodo de rbol de expresin matemtica

Gramticas
El anlisis 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 gramtica determinista formada por un vocabulario y unas
reglas de sintaxis. Esto se denomina gramtica libre de contexto. Los lenguajes
humanos no son de este tipo y, por tanto, no se pueden analizar con tcnicas de
anlisis convencionales.

Analizador: combinacin de analizadores lxicos

El proceso de anlisis se puede dividir en dos subprocesos: anlisis lxico y anlisis
sintctico.
El anlisis lxico es el proceso de descomponer los datos de entrada en tokens. Los
tokens son el vocabulario del lenguaje, un conjunto de bloques de construccin
vlidos. En el lenguaje humano, equivaldra a todas las palabras que aparecen en el
diccionario de un determinado idioma.
El anlisis sintctico es la aplicacin de las reglas sintcticas del lenguaje.
Los analizadores normalmente dividen el trabajo entre dos componentes: el analizador
lxico (a veces denominado "tokenizador"), responsable de descomponer los datos de
entrada en tokens vlidos, y el analizador normal, responsable de construir el rbol
tras analizar la estructura del documento segn las reglas sintcticas del lenguaje. El
analizador lxico es capaz de ignorar caracteres irrelevantes, como espacios en blanco
y saltos de lnea.

Figura : del documento original al rbol de anlisis

El proceso de anlisis es iterativo. El analizador normalmente pide al analizador lxico

un nuevo token e intenta buscar coincidencias entre el token y una de las reglas de
sintaxis. Si se encuentra una coincidencia, se aade al rbol de anlisis un nodo
correspondiente al token y el 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 que coincide con todos los tokens
almacenados internamente. Si no encuentra ninguna regla, lanza una excepcin. Esto
signica que el documento no se considera vlido por tener errores de sintaxis.

Traduccin
Muchas veces, el rbol de anlisis no es el producto nal. El anlisis se utiliza
frecuentemente en la traduccin, es decir, en la conversin del documento de entrada
a otro formato. Un ejemplo sera la compilacin. El compilador, que compila un cdigo
fuente en cdigo de mquina, en primer lugar lo convierte en un rbol de anlisis y, a
continuacin, traduce el rbol a un documento de cdigo de mquina.

Figura : ujo de compilacin

Ejemplo de anlisis
En la gura 5 se observa un rbol de anlisis creado a partir de una expresin
matemtica. Intentemos denir un lenguaje matemtico simple y veamos el proceso de
anlisis.
Vocabulario: nuestro lenguaje puede incluir nmeros enteros, el signo ms y el signo
menos.
Sintaxis:
1. Los bloques de construccin de la sintaxis del lenguaje son expresiones,
trminos y operaciones.
2. Nuestro lenguaje puede incluir cualquier cantidad de expresiones.
3. Una expresin est formada por un "trmino" seguido de una "operacin" y de
otro trmino.
4. Una operacin es un token de suma o un token de resta.
5. Un trmino es un token de nmero entero o una expresin.
Analicemos la entrada 2 + 3 - 1 .
La primera subcadena que coincide con una regla es 2 ; segn la regla 5, es un
trmino. La segunda coincidencia es 2 + 3 , que coincide con la tercera regla (un
trmino seguido de una operacin y de otro trmino). La siguiente coincidencia solo se
utilizar al nal de la entrada. 2 + 3 - 1 es una expresin porque ya sabemos que

2+3 es un trmino, as que tenemos un trmino seguido de una operacin y de otro

trmino. 2 + + no coincide con ninguna regla, por lo que no sera una entrada vlida.

De niciones formales de vocabulario y sintaxis

El vocabulario se suele expresar mediante expresiones regulares.
Por ejemplo, nuestro lenguaje se denir de la siguiente forma:
INTEGER :0|[1-9][0-9]*
PLUS : +
MINUS: -

Como se puede observar, los nmeros enteros se denen mediante una expresin
regular.
La sintaxis normalmente se dene en un formato denominado notacin de BackusNaur (BNF). Nuestro idioma se denir de la siguiente forma:
expression := term operation
operation := PLUS | MINUS
term := INTEGER | expression

term

Dijimos que un lenguaje se puede analizar mediante analizadores normales si su

gramtica es una gramtica libre de contexto. Una denicin intuitiva de una gramtica
libre de contexto es una gramtica que se puede expresar completamente en notacin
de Backus-Naur (BNF). Puedes consultar una denicin formal en este artculo de
Wikipedia sobre las gramticas libres de contexto.

Tipos de analizadores
Existen dos tipos bsicos de analizadores: los descendentes y los ascendentes.
Utilizando una explicacin intuitiva, podramos decir que los analizadores
descendentes comprueban la estructura de nivel superior de la sintaxis e intentan
buscar una coincidencia, mientras que los analizadores ascendentes comienzan con
los datos de entrada y los van transformando gradualmente mediante las reglas
sintcticas empezando por el nivel ms bajo hasta que se cumplen las reglas de nivel
superior.
Veamos cmo analizan el contenido de ejemplo estos dos tipos de analizadores:
Un analizador descendente empieza desde la regla de nivel superior: identica 2 + 3
como una expresin. A continuacin, identica 2 + 3 - 1 como expresin (el
proceso de identicar la expresin se desarrolla buscando coincidencias con el resto
de las reglas, pero se empieza por la regla de nivel superior).

El analizador ascendente analiza los datos de entrada hasta que encuentra una
coincidencia con una regla y, a continuacin, sustituye la entrada coincidente con la
regla. Este proceso contina hasta que se analizan todos los datos de entrada. Las
expresiones con coincidencias parciales se colocan en la pila del analizador.
Pila

Entrada

2 + 3 - 1

trmino

+ 3 - 1

operacin del trmino

3 - 1

expresin

- 1

operacin de la expresin

expresin

Este tipo de analizador ascendente se conoce como analizador de desplazamientoreduccin debido a que los datos de entrada se desplazan hacia la derecha (imagina
un puntero que apunta primero al inicio de los datos de entrada y a continuacin se
desplaza hacia la derecha) y gradualmente se reducen segn las reglas sintcticas.

Cmo generar analizadores automticamente

Existen herramientas capaces de generar analizadores automticamente. Se
denominan generadores de analizadores. Estos generadores crean automticamente
un analizador funcional utilizando la gramtica del lenguaje (vocabulario y reglas
sintcticas) establecida por el desarrollador. Los generadores de analizadores son muy
tiles, ya que, para crear un analizador, es necesario disponer de un profundo
conocimiento del proceso de anlisis, y no resulta fcil crear manualmente un
analizador optimizado.
WebKit utiliza dos generadores de analizadores muy conocidos: Flex, para crear un
analizador lxico, y Bison, para crear un analizador normal (tambin se conocen como
"Lex" y "Yacc"). La entrada de Flex consiste en un archivo con deniciones de
expresiones regulares de los tokens. La entrada de Bison consiste en las reglas
sintcticas del lenguaje en formato BNF.

Analizador de HTML
El trabajo del analizador de HTML es analizar las marcas HTML y organizarlas en un
rbol de anlisis.

De nicin de gramtica HTML

Es la sintaxis y el vocabulario denidos en las especicaciones creadas por la
organizacin W3C. La versin actual es HTML4 y actualmente se est trabajando en
HTML5.

No es una gramtica libre de contexto

Como ya vimos en la introduccin al anlisis, la sintaxis de la gramtica se puede
denir formalmente mediante formatos como BNF.
Lamentablemente, no todos los temas sobre analizadores convencionales se pueden
aplicar al lenguaje HTML (los he incluido porque se utilizarn en el anlisis de CSS y
JavaScript). El lenguaje HTML no se puede denir fcilmente mediante la gramtica
libre de contexto que necesitan los analizadores.
Existe un formato formal para denir el lenguaje HTML: DTD (denicin de tipo de
documento); sin embargo, no es una gramtica libre de contexto.
Parece algo extrao a primera vista: el lenguaje HTML es bastante similar al XML. Hay
una gran variedad de analizadores de XML disponibles. Existe una variacin XML del
lenguaje HTML, el XHTML, as que, cul es la diferencia?
La diferencia radica en que el lenguaje HTML es ms "permisivo", ya que permite
omitir ciertas etiquetas que se aaden de forma implcita, a veces se omite el principio
o el nal de las etiquetas, etc. En conjunto, es una sintaxis "exible", en oposicin a la
sintaxis rgida y exigente del lenguaje XML.
Esta diferencia aparentemente pequea es, en realidad, abismal. Por un lado, esta es
la razn 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 difcil escribir una
gramtica formal. En resumen: el lenguaje HTML no se puede analizar fcilmente
mediante analizadores convencionales (porque no dispone de una gramtica libre de
contexto) ni mediante analizadores de XML.

DTD DE HTML
La denicin de HTML est en formato DTD. Este formato se utiliza para denir
lenguajes de la familia SGML. Contiene deniciones de todos los elementos
permitidos, de sus atributos y de su jerarqua. Como vimos antes, la denicin DTD del
lenguaje HTML no forma una gramtica libre de contexto.
Existen algunas variaciones de la denicin DTD. El modo estricto se ajusta
nicamente a las especicaciones, pero otros modos admiten el marcado utilizado
anteriormente por los navegadores. El objetivo es mantener la compatibilidad con el
contenido ms antiguo. La denicin DTD estricta actual se encuentra en la siguiente
pgina: www.w3.org/TR/html4/strict.dtd

DOM
El rbol de salida ("rbol de anlisis") est formado por elementos DOM y nodos de
atributo. DOM son las siglas de "Document Object Model" (modelo de objetos del
documento). Es la presentacin de objetos del documento HTML y la interfaz de los

elementos HTML para el mundo exterior, como JavaScript.

La raz del rbol es el objeto Document.
El modelo DOM guarda una relacin 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 traducira en el siguiente rbol de DOM:

Figura : rbol de DOM del marcado de ejemplo

Al igual que el HTML, la organizacin W3C ha especicado el modelo DOM. Puedes

consultarlo en la pgina www.w3.org/DOM/DOMTR. Es una especicacin genrica
para la manipulacin de documentos. Un mdulo especco describe elementos HTML
especcos. Puedes consultar las deniciones HTML en la pgina
www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-denitions.html.
Cuando digo que el rbol contiene nodos DOM, quiero decir que est construido con
elementos que implementan una de las interfaces DOM. Los navegadores utilizan
implementaciones concretas que tienen otros atributos que el navegador utiliza
internamente.

El algoritmo de anlisis
Como vimos en las secciones anteriores, el lenguaje HTML no se puede analizar
mediante los analizadores ascendentes y descendentes normales.
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 vlido,
3. la naturaleza iterativa del proceso de anlisis. Normalmente, el cdigo no cambia
durante el anlisis. Sin embargo, en el caso del cdigo HTML, las etiquetas de
secuencias de comandos que contienen document.write pueden aadir
tokens adicionales, por lo que el proceso de anlisis llega a modicar los datos
de entrada.
Al no poder utilizar las tcnicas de anlisis normales, los navegadores crean
analizadores personalizados para analizar el cdigo HTML.
El algoritmo de anlisis se describe de forma detallada en la especicacin de HTML5.
El algoritmo presenta dos fases: la tokenizacin y la construccin del rbol.
La tokenizacin es el anlisis lxico, es decir, el anlisis y la conversin en tokens de
los datos de entrada. Entre los tokens HTML se encuentran las etiquetas iniciales, las
etiquetas nales y los valores de atributos.
El tokenizador reconoce el token, lo enva al constructor del rbol y consume el
siguiente carcter para reconocer el siguiente token, y as sucesivamente hasta llegar
al nal de los datos.

Figura : ujo de anlisis de HTML (tomado de la especicacin de

HTML5)

El algoritmo de tokenizacin

El algoritmo produce un token HTML. El algoritmo se expresa como una mquina de

estado. Cada estado consume uno o varios caracteres del ujo de entrada y actualiza
el siguiente estado de acuerdo con esos caracteres. La decisin est inuenciada por
el estado de tokenizacin actual y por el estado de construccin del rbol. Esto
signica que el mismo carcter consumido producir resultados diferentes para el
siguiente estado correcto en funcin del estado actual. El algoritmo es demasiado
complejo para describirlo en su totalidad, as que veremos algunos ejemplos sencillos
que nos ayudarn a comprender el principio.
Ejemplo bsico de tokenizacin del siguiente cdigo HTML:
<html>
<body>
Hello world
</body>
</html>

El estado inicial es el de "estado de datos". Cuando se encuentra el carcter <, el

estado cambia a estado de etiqueta abierta. Al consumir un carcter a-z, se crea el
estado "token de etiqueta inicial" y el estado cambia a estado de nombre de
etiqueta. Este estado se mantiene hasta que se consume el carcter >. Todos los
caracteres se aaden al nombre del nuevo token. En nuestro caso, el nuevo token es
un token html.
Al llegar a la etiqueta >, se emite el token actual y el estado cambia a estado de datos.
Se siguen los mismos pasos para la etiqueta <body>. Hasta ahora, se han emitido las
etiquetas html y body. Ahora volvemos al estado de datos. Al consumir el carcter H
de Hello world, se crea y se emite un token de carcter, y as sucesivamente hasta
llegar al carcter < de </body>. Se emite un token de carcter 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 al estado de nombre de etiqueta. De
nuevo, el estado se mantiene hasta llegar a >. A continuacin, se emite el token de la
nueva etiqueta y se vuelve al estado de datos. La entrada </html> se tratar como el
caso anterior.

Figura : tokenizacin de la entrada de ejemplo

Algoritmo de construccin de rbol

Cuando se crea un analizador, se crea el objeto "Document". Durante la fase de
construccin, se modica el rbol de DOM que incluye el objeto "Document" en su raz
y se aaden elementos. El constructor del rbol procesa cada nodo emitido por el
tokenizador. Por cada token, la especicacin dene qu elementos de DOM son
relevantes y cules se deben crear para este token. Adems de aadirse al rbol de
DOM, el elemento se aade a una pila de elementos abiertos. Esta pila permite corregir
incidencias de anidacin y de etiquetas no cerradas. El algoritmo tambin se describe
como una mquina de estado. Los estados se denominan "modos de insercin".
Veamos cul sera el proceso de construccin del rbol para los datos de entrada del
ejemplo:
<html>
<body>
Hello world
</body>
</html>

La entrada a la fase de construccin del rbol es una secuencia de tokens de la fase

de tokenizacin. El primer modo es el "modo inicial". 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 el elemento "HTMLHtmlElement" se cree y se aada al objeto raz
"Document".

El estado cambiar a "antes del encabezado". Recibimos el token "body". Se crear

implcitamente un elemento "HTMLHeadElement", aunque no tengamos ningn token
"head", y ese elemento se aadir al rbol.
Ahora pasamos al modo "en el encabezado" y, a continuacin, al modo "despus del
encabezado". El token del cuerpo se vuelve a procesar, se crea y se inserta un
elemento "HTMLBodyElement" y, por ltimo, el modo pasa a "en el cuerpo".
A continuacin, 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 aadir el resto de
caracteres.
La recepcin del token de nalizacin del cuerpo provocar una transferencia al modo
"despus del cuerpo". A continuacin, se recibir la etiqueta HTML nal, que har
que se pase al modo despus del cuerpo. Cuando se reciba el nal del token del
archivo, al anlisis nalizar.

Figura : construccin de rbol del cdigo HTML de ejemplo

Acciones al nalizar el anlisis

En esta fase, el navegador marcar el documento como interactivo y empezar a
analizar las secuencias de comandos que se encuentren en modo "aplazado", es decir,
aquellas que se deben ejecutar una vez que se ha analizado el documento. A
continuacin, el estado del documento se establecer como "completado" y se
activar un evento de "carga".

Se pueden ver los algoritmos completos para tokenizacin y la construccin del rbol
en la especicacin de HTML5.

Tolerancia a errores de los navegadores

Nunca se obtiene un error por "sintaxis no vlida" en una pgina HTML. Los
navegadores corrigen el contenido no vlido y siguen.
Tomemos este cdigo HTML como ejemplo:
<html>
<mytag>
</mytag>
<div>
<p>
</div>
Really lousy HTML
</p>
</html>

He debido de infringir un milln de reglas ("mytag" no es una etiqueta estndar, los

elementos "p" y "div" estn mal anidados, etc.), pero el navegador sigue mostrndolo
correctamente y no muestra ningn error. Por lo tanto, una gran parte del cdigo del
analizador corrige los errores del autor de contenido HTML.
La gestin de errores es bastante consistente en los navegadores, pero lo ms
increble es que no forma parte de la especicacin actual de 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 aos. Hay algunas construcciones HTML conocidas que no son vlidas
y que se repiten en muchos sitios. Los navegadores intentan corregirlas de acuerdo
con otros navegadores.
En cambio, en la especicacin de HTML5 s se denen algunos de estos requisitos.
WebKit lo resume en el comentario que se encuentra al principio de la clase de
analizador de HTML.

El analizador analiza la entrada tokenizada y la convierte en el documento, lo que

crea el rbol del documento. Si el documento est bien construido, el anlisis
resulta sencillo.
Lamentablemente, debemos tratar con muchos documentos HTML que no estn
bien construidos, por lo que el analizador debe ser tolerante con estos errores.
Se debe tener cuidado, como mnimo, con los siguientes errores:
1. El elemento que se debe aadir est prohibido explcitamente en alguna
etiqueta externa. En este caso, debemos cerrar todas las etiquetas hasta

llegar a la que prohbe el elemento y aadirlo a continuacin.

2. No est permitido aadir el elemento directamente. Es posible que el autor
del documento haya olvidado incluir una etiqueta en medio (o que la etiqueta
sea opcional). Este podra ser el caso de estas etiquetas: HTML HEAD BODY
TBODY TR TD LI (he olvidado alguna?).
3. Se quiere aadir un elemento de bloque dentro de un elemento integrado.
Hay que cerrar todos los elementos integrados hasta llegar al siguiente
elemento de bloque superior.
4. Si esto no funciona, se deben cerrar elementos hasta que se pueda aadir el
elemento o ignorar la etiqueta.

Veamos algunos ejemplos de tolerancia a errores de WebKit:

</br> en lugar de <br>

Algunos sitios utilizan </br> en lugar de <br>. Para poder ser compatible con Internet
Explorer y Firefox, WebKit trata la etiqueta como si fuera <br>.
Cdigo:
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.

Tabla perdida
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 jerarqua de dos tablas secundarias:

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

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

Cdigo:
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 encontrarn en el mismo nivel de la jerarqua.

Elementos de un formulario anidado

Si el usuario incluye un formulario dentro de otro, el segundo se ignorar.
Cdigo:
if (!m_currentFormElement) {
m_currentFormElement = new HTMLFormElement(formTag,
m_document);
}

Jerarqua de etiquetas demasiado profunda

El comentario habla por s solo.

www.liceo.edu.mx es un ejemplo de un sitio con un nivel de anidamiento de unas

1.500 etiquetas, todas ellas procedentes de una serie de etiquetas <b>s. No se
permite utilizar ms de 20 etiquetas anidadas del mismo tipo. A partir de ese
nmero, se ignoran todas.

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;
}

Etiquetas nales de cuerpo o HTML colocadas incorrectamente

De nuevo, el comentario habla por s solo.

Se tolera que HTML se rompa totalmente. Nunca cerramos la etiqueta del cuerpo
(body), ya que algunas pginas web cometen el error de cerrarla antes de que haya
acabado el documento. Por eso, nos jamos en la llamada "end()" para cerrar
elementos.

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

return;

As que ya sabis: a menos que queris aparecer como ejemplo en un fragmento de

cdigo de tolerancia a errores de WebKit, escribid el cdigo HTML correctamente.

Anlisis de CSS
Os acordis de los conceptos de anlisis que vimos en la introduccin? A diferencia
del lenguaje HTML, CSS tiene una gramtica libre de contexto y se puede analizar con
los tipos de analizadores descritos en la introduccin. De hecho, la especicacin del
lenguaje CSS dene su gramtica sintctica y lxica.
Veamos algunos ejemplos:
La gramtica lxica (el vocabulario) se dene mediante expresiones regulares para
cada token:
comment
\/\*[^*]*\*+([^/*][^*]*\*+)*\/
num
[0-9]+|[0-9]*"."[0-9]+
nonascii
nmstart
nmchar
name
ident

[\200-\377]
[_a-z]|{nonascii}|{escape}
[_a-z0-9-]|{nonascii}|{escape}

{nmchar}+
{nmstart}{nmchar}*

"ident" es la abreviatura de identicador, como el nombre de una clase. "name" es el

identicador de un elemento (y se hace referencia a l mediante "#").
La gramtica sintctica se describe en BNF.
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*] ')' ]
;

Explicacin: un conjunto de reglas es una estructura como la que se muestra a

continuacin.
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 dene formalmente en esta
denicin:
ruleset
: selector [ ',' S* selector ]*
'{' S* declaration [ ';' S* declaration ]* '}' S*
;

Esto signica que un conjunto de reglas es un selector o un nmero opcional de

selectores separados por una coma y por espacios (S signica espacio en blanco). Un
conjunto de reglas contiene una declaracin entre llaves u, opcionalmente, una serie
de declaraciones separadas por punto y coma. "declaration" y "selector" se denirn
en las siguientes deniciones de BNF.

Analizador de CSS de WebKit

WebKit utiliza generadores de analizadores Flex y Bison para crear analizadores

automticamente a partir de los archivos de gramtica de CSS. Como ya dijimos en la
introduccin a los analizadores, Bison crea un analizador ascendente de
desplazamiento-reduccin. Firefox utiliza 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 y selectores, as como otros objetos
relacionados con la gramtica de CSS.

Figura : anlisis de CSS

Orden de procesamiento de secuencias de comandos y

hojas de estilo
Secuencias de comandos
El modelo de la Web es sncrono. Los autores esperan que las secuencias de
comandos se analicen y se ejecuten inmediatamente cuando el analizador llega a la
etiqueta <script>. El anlisis del documento se detiene hasta que la secuencia de
comandos se ejecuta. La secuencia de comandos es externa, por lo que antes es
necesario recuperar el recurso de la red. Esta accin se realiza tambin de una forma
sncrona, es decir, que el anlisis se detiene hasta que se recupera el recurso. Este
modelo se utiliz durante muchos aos y est incluido en las especicaciones de
HTML 4 y 5. Los autores pueden marcar la secuencia de comandos como "aplazada".
De ese modo, no se detiene el anlisis del documento y la secuencia se ejecuta una
vez que se ha completado el anlisis. HTML5 aade una opcin que permite marcar la

secuencia de comandos como asncrona para que se analice y se ejecute en un

subproceso diferente.

Anlisis especulativo
Tanto WebKit y Firefox utilizan esta optimizacin. 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 que mejora la velocidad general. Nota: el analizador
especulativo no modica el rbol de DOM (de eso se encarga el analizador principal),
solo analiza las referencias a recursos externos, como secuencias de comandos
externas, hojas de estilo e imgenes.

Hojas de estilo
Las hojas de estilo, por otro lado, tienen un modelo diferente. Conceptualmente,
parece que, dado que las hojas de estilo no modican el rbol de DOM, no hay razn
para esperarlas y detener el anlisis del documento. Sin embargo, se produce una
incidencia cuando las secuencias de comandos solicitan informacin de estilo durante
la fase de anlisis del documento. Si el estilo an no se ha cargado ni analizado, la
secuencia de comandos obtendr respuestas incorrectas y, aparentemente, esto
causar muchas complicaciones. Parece que se trata de un caso extremo, pero es
bastante comn. Firefox bloquea todas las secuencias de comandos si todava se est
cargando y analizando una hoja de estilo. WebKit bloquea las secuencias de
comandos solo cuando intentan acceder a determinadas propiedades de estilo que se
pueden ver afectadas por las hojas de estilo descargadas.

Construccin del rbol de renderizacin

Mientras se est construyendo el rbol DOM, el navegador construye otro rbol: el
rbol de renderizacin. Este rbol est formado por elementos visuales que se
muestran en el mismo orden en que aparecern. Es la representacin visual del
documento. El propsito de este rbol es poder representar el contenido en el orden
correcto.
Firefox denomina a los elementos del rbol de renderizacin "marcos" (o "frames").
WebKit utiliza el trmino "renderizador" u "objeto de renderizacin" (o "render").
Un renderizador es capaz de representarse a s mismo y a sus elementos secundarios.
La clase "RenderObject" de WebKit, la clase bsica de los renderizadores, tiene la
siguiente denicin:
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, segn se describe en la especicacin de CSS2.
Contiene informacin geomtrica como el ancho, la altura y la posicin.
El tipo de caja se ve afectado por el atributo de estilo "display" relevante para el nodo
(consulta la seccin Computacin de estilos). Este es el cdigo de WebKit que se
utiliza para decidir qu tipo de renderizador se debe crear para un nodo DOM, segn el
atributo de visualizacin:
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:
o = new (arena) RenderBlock(node);
break;
case LIST_ITEM:
o = new (arena) RenderListItem(node);
break;
...
}
return o;
}

El tipo de elemento tambin 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
mtodo createRenderer. Los renderizadores apuntan a objetos de estilo que
contienen la informacin no geomtrica.

Relacin del rbol de renderizacin con el rbol de DOM

Los renderizadores corresponden a elementos DOM, pero la relacin no es de uno a
uno. Los elementos DOM no visuales no se insertan en el rbol de renderizacin. Un
ejemplo sera el elemento "head". Los elementos cuyo atributo de visualizacin se ha
asignado a "none" tampoco aparecen en el 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 se pueden describir en un solo
rectngulo. Por ejemplo, el elemento "select" tiene tres renderizadores: uno para el
rea de visualizacin, otro para el cuadro de lista desplegable y otro para el botn.
Adems, cuando el texto se divide en varias lneas porque el ancho no es suciente
para una lnea, las nuevas lneas se aaden como renderizadores adicionales.
Otro ejemplo con varios renderizadores sera un cdigo HTML roto. Segn la
especicacin de CSS, un elemento integrado debe contener nicamente elementos
de bloque o elementos integrados. Si el contenido es mixto, se crean renderizadores
de bloques annimos para incluir los elementos integrados.
Algunos objetos de renderizacin corresponden a un nodo DOM de un lugar del rbol
diferente. Los elementos otantes y aquellos con posicin absoluta quedan fuera del
ujo, en un lugar diferente del rbol y asignados al marco real. Deberan haber estado
en un marco de marcador.

Figura : el rbol renderizador y el rbol de DOM correspondiente (3.1)

La "ventana grca" es el bloque contenedor inicial. En WebKit, ser
el objeto "RenderView".

El ujo de construccin del rbol

En Firefox, la presentacin se registra como un detector de actualizaciones de DOM.
La presentacin delega la creacin de marcos en FrameConstructor y el constructor
resuelve el estilo (consulta la seccin Computacin de estilos) y crea un marco.
En WebKit, el proceso para resolver el estilo y crear un renderizador se denomina
"asociacin". Cada nodo DOM dispone de un mtodo de "asociacin". El proceso de
asociacin es sncrono, es decir, que la insercin de nodos en el rbol de DOM activa
el mtodo de "asociacin" del nuevo nodo.
Al procesar las etiquetas "html" y "body", se construye la raz del rbol de
renderizacin. El objeto de renderizacin raz se corresponde con lo que la
especicacin de CSS denomina "bloque contenedor", es decir, el bloque superior que
contiene el resto de los bloques. Sus dimensiones se corresponden con la ventana
grca, es decir, con las dimensiones del rea de visualizacin de la ventana del
navegador. Firefox lo denomina ViewPortFrame y WebKit RenderView. Este es el
objeto de renderizacin al que apunta el documento. El resto del rbol se construye
como una insercin de nodos DOM.
Consulta la especicacin de CSS2 en el modelo de procesamiento.

Computacin de estilos
Para crear el rbol de renderizacin, es necesario calcular las propiedades visuales de
cada uno de los objetos de renderizacin. Para hacerlo, hay que calcular las
propiedades de estilo de cada elemento.
El estilo incluye hojas de estilo de varios orgenes, elementos de estilo integrados y
propiedades visuales en el cdigo HTML (como la propiedad "bgcolor"). Estas ltimas
se transforman en las propiedades de estilo de CSS correspondientes.
Los orgenes de las hojas de estilo son las hojas de estilo predeterminadas del
navegador, las proporcionadas por el autor de la pgina y las proporcionadas por el
usuario del navegador (los navegadores permiten al usuario denir su estilo favorito. En
Firefox, por ejemplo, se puede hacer colocando una hoja de estilo en la carpeta de
perles del navegador).
La computacin de estilos conlleva algunas dicultades:
1. Al contener las numerosas propiedades de los estilos, los datos de estilo llegan a
alcanzar unas dimensiones considerables, lo que puede provocar un uso
excesivo de memoria.
2. La bsqueda de las reglas coincidentes de cada elemento puede afectar al
rendimiento si no se optimiza el proceso. Recorrer la lista completa de reglas de
cada elemento para encontrar coincidencias es una tarea muy pesada. Los
selectores pueden tener una estructura compleja, lo que puede hacer que se

empiece a buscar en una ruta que aparentemente sea buena, pero que
nalmente no sea as y se deba probar con otra ruta.
Pongamos como ejemplo este selector complejo:
div div div div{
...
}

Signica que las reglas se aplican a un elemento <div> que es el descendiente

de tres elementos "div". Supongamos que quieres comprobar si la regla se aplica
a un elemento <div> determinado. Debes seleccionar una ruta superior del rbol
para comprobarlo. Es posible que debas ascender por todo el rbol de nodos
solo para averiguar que nicamente existen dos elementos "div" y que la regla no
se aplica. A continuacin, debes probar con otras rutas del rbol.
3. Para aplicar las reglas, es necesario utilizar reglas en cascada bastante complejas
que denen la jerarqua de las reglas.
Veamos cmo se enfrentan los navegadores a estas dicultades:

Datos de estilo compartidos

Los nodos de WebKit hacen referencia los objetos de estilo (RenderStyle). Los nodos
pueden compartir estos objetos en algunas circunstancias. 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 ratn (por ejemplo, uno no puede
estar en ":hover" y el otro en otro estado).
2. Ninguno de los elementos debe tener un identicador.
3. Los nombres de las etiquetas deben coincidir.
4. Los atributos de clase deben coincidir.
5. El conjunto de atributos asignados debe ser idntico.
6. Los estados de enlace deben coincidir.
7. Los estados de enfoque deben coincidir.
8. Ningn elemento se debe ver afectado por selectores de atributos, es decir, no
debe presentar ninguna coincidencia con ningn selector que utilice un selector
de atributo en ninguna posicin dentro del selector.
9. No debe haber ningn atributo de estilo integrado en los elementos.
10. No debe haber ningn selector del mismo nivel en uso. WebCore simplemente
aplica un cambio global si detecta un selector del mismo nivel e inhabilita la
opcin de compartir estilos en todo el documento cuando est presente. Esto
incluye el selector + y selectores como ":rst-child" y ":last-child".

rbol de reglas de Firefox

Firefox cuenta con dos rboles adicionales para una computacin de estilos ms
sencilla: el rbol de reglas y el rbol de contextos de estilo. WebKit tambin cuenta con
objetos de estilo, pero no se almacenan en un rbol como el rbol de contextos de
estilo. Solo el nodo de DOM indica el estilo pertinente.

Figura : rbol de contextos de estilo (2.2)

Los contextos de estilo incluyen valores nales. Para computar los valores, se aplican
todas las reglas con las que se hayan encontrado coincidencias en el orden correcto y
se realizan manipulaciones que transforman los valores lgicos en concretos. Por
ejemplo, si el valor lgico 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. Adems, ahorra espacio.
Todas las reglas con las que se encuentra alguna coincidencia se almacenan en un
rbol. Los nodos inferiores de una ruta tienen mayor prioridad. 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 estilo de un nodo, las rutas se aaden al rbol.
La idea es que las rutas del rbol se muestren como las palabras de un lexicn.
Imaginemos, por ejemplo, que ya hemos computado este rbol de reglas:

Supongamos que necesitamos encontrar coincidencias para reglas de otros elementos

del rbol de contenido y obtenemos las siguientes reglas (en el orden correcto): B - E I. Ya tenamos esta ruta del rbol porque ya habamos computado la ruta A - B - E - I L, por lo que ahora tendremos menos trabajo que hacer.
Vamos a comprobar cmo guarda el rbol nuestro trabajo.

Divisin en estructuras
Los contextos de estilo se dividen en estructuras que incluyen informacin de estilo de
una cierta categora, 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 menos que las dena el elemento, se heredan del elemento principal. Las
propiedades no heredadas (denominadas propiedades "reset") utilizan los valores
predeterminados en caso de que no se denan.
El rbol guarda en cach estructuras completas (que incluyen los valores nales
computados) del rbol. De esa forma, si el nodo inferior no proporciona una denicin
para una estructura, se puede utilizar una estructura guardada en cach de un nodo
superior.

Cmo computar los contextos de estilo con el rbol de reglas

Cuando se computa el contexto de estilo de un elemento especco, primero se
computa una ruta del rbol de reglas o se utiliza una existente. A continuacin, se
aplican las reglas de la ruta para completar las estructuras del nuevo contexto de
estilo. Empezamos por el nodo inferior de la ruta, es decir, el nodo de mayor prioridad
(normalmente el selector ms especco), y recorremos el rbol en sentido ascendente
hasta completar la estructura. Si este nodo de reglas no incluye ninguna especicacin
para la estructura, podemos optimizarlo considerablemente (la mejor forma es recorrer
el rbol en sentido ascendente hasta encontrar un nodo que incluya una especicacin
completa y apuntar despus a este nodo) y compartir la estructura completa. Gracias a
este mtodo ahorramos valores nales y memoria.

Si encontramos deniciones parciales, recorremos el rbol en sentido ascendente

hasta completar la estructura.
Si no encontramos deniciones para la estructura, en caso de que esta sea de tipo
"heredada", apuntamos a la estructura del elemento principal del rbol de contextos.
En este caso, tambin conseguimos compartir las estructuras. Si la estructura es de
tipo "no heredada", se utilizarn los valores predeterminados.
Si el nodo ms especco no aade valores, tendremos que efectuar clculos
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 pueden compartir el contexto de estilo
completo.
Veamos un ejemplo. Supongamos que tenemos el siguiente cdigo 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.
2.
3.
4.
5.
6.

div {margin:5px;color:black}
.err {color:red}
.big {margin-top:3px}
div span {margin-bottom:4px}
#div1 {color:blue}
#div2 {color:green}

Para simplicar la tarea, digamos que tenemos que completar solo dos estructuras: la
estructura de color y la estructura de margen. La estructura 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 : nmero de la regla a la que apunta"):

Figura : rbol de reglas

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

Figura : rbol de contextos

Supongamos que analizamos el cdigo HTML y obtenemos la segunda etiqueta <div>.

Tendremos que crear un contexto de estilo para el nodo y completar sus estructuras de
estilo.
Buscamos las reglas que coincidan con <div> y descubrimos que son 1, 2 y 6. Esto
signica que ya existe una ruta del rbol que podemos utilizar para nuestro elemento,
por lo que solo necesitamos aadir 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 de reglas.
Ahora necesitamos completar las estructuras de estilo. Empezaremos completando la
estructura de margen. Como el ltimo nodo de regla (F) no se aade a la estructura de
margen, podemos ascender por el rbol hasta encontrar una estructura almacenada en
cach computada en la insercin de un nodo anterior y utilizarla. Encontraremos esta
estructura en el nodo B, que es el nodo de nivel ms superior que especica reglas de
margen.
Ya tenemos una denicin para la estructura de color, por lo que no podemos utilizar
una estructura almacenada en cach. Como el color tiene un atributo, no necesitamos
ascender por el rbol para completar otros atributos. Computamos el valor nal
(convertimos la cadena a RGB, etc.) y almacenamos en cach en este nodo la
estructura computada.
El trabajo relacionado con el elemento <span> es an ms sencillo. Buscamos las
reglas que coinciden con este elemento y llegamos a la conclusin de que la regla a la
que apunta es G, como el elemento "span" anterior. Como tenemos elementos del
mismo nivel que apuntan al 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 cabo en el rbol de contextos (aunque
la propiedad de color se hereda, Firefox trata esta propiedad como no heredada y la
guarda en cach en el rbol de reglas).
Por ejemplo, imaginemos que aadimos reglas para las fuentes de un pargrafo:
p {font-family:Verdana;font size:10px;font-weight:bold}

El elemento de prrafo, que es un elemento secundario del elemento "div" del rbol de
contextos, podra compartir la misma estructura de fuente que el elemento principal.
Este caso se podra aplicar si no se especicasen reglas de fuente para el prrafo.
En WebKit, no existen los rboles de reglas, por lo que las declaraciones que coinciden
se recorren cuatro veces. En primer lugar, se aplican las propiedades de alta prioridad
de menor importancia (estas propiedades se deben aplicar primero porque hay otras
que dependen de ellas, como "display"); a continuacin, se aplican las propiedades de
alta prioridad de mayor importancia; posteriormente, las propiedades de prioridad
normal de menor importancia y, por ltimo, las reglas de prioridad normal de mayor
importancia. Esto signica que las propiedades que aparezcan varias veces se
resolvern segn el orden de cascada correcto. La ltima es la ms importante.
En resumen, compartir objetos de estilo (ya sea en su totalidad o compartiendo
solamente algunas de sus estructuras) soluciona las incidencias 1 y 3. El rbol de

reglas de Firefox tambin ayuda a aplicar las propiedades en el orden correcto.

Cmo manipular las reglas para obtener coincidencias fcilmente

A continuacin se muestran las distintas fuentes de reglas de los modicadores 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" />

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

<p bgcolor="blue" />

Las dos ltimas fuentes coinciden fcilmente con el elemento, ya que este incluye los
atributos de estilo, y los atributos HTML se pueden asignar 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. Para resolver esta dicultad, las reglas se
manipulan para facilitar el acceso.
Despus de analizar la hoja de estilo, las reglas se aaden a uno de varios mapas
hash, de acuerdo con el selector. Existen mapas organizados por ID, nombre de clase
y nombre de etiqueta, y un mapa general para todo lo que no se puede incluir en estas
categoras. Si el selector es un ID, la regla se aadir al mapa de ID; si es una clase, se
aadir al mapa de clase, etc.
Esta manipulacin facilita considerablemente la tarea de asignacin de reglas. No hace
falta revisar cada declaracin, podemos extraer las reglas relevantes para un elemento
de los mapas. Esta optimizacin elimina ms del 95% de las reglas, por lo que ni
siquiera es necesario tenerlas en cuenta durante el proceso de bsqueda de
coincidencias (4.1).
Analicemos las reglas de estilo que se incluyen a continuacin:
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 la regla 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, solo queda averiguar qu reglas extradas de las claves
realmente coinciden.
Por ejemplo, si la regla del elemento "div" fuera la siguiente:
table div {margin:5px}

se extraera del mapa de etiqueta, porque la clave es el selector situado ms a la

derecha, pero no coincidira con el elemento "div", que no cuenta con un antecesor de
tabla.
Tanto WebKit como Firefox utilizan esta manipulacin.

Cmo aplicar las reglas en el orden de cascada correcto

El objeto de estilo tiene propiedades que se corresponden con cada atributo visual
(todos los atributos CSS, pero ms genricos). Si ninguna de las reglas que coinciden
dene la propiedad, algunas propiedades se pueden heredar del elemento principal del
objeto de estilo. Otras propiedades tienen valores predeterminados.
La incidencia se produce cuando existe ms de una denicin, y es entonces cuando
se debe utilizar el orden en cascada para resolverla.

Orden en cascada de la hoja de estilo

Una declaracin de una propiedad de estilo puede aparecer en varias hojas de estilo y
varias veces dentro de una misma hoja. Por ese motivo, el orden de aplicacin de las
reglas tiene una gran importancia. Este orden se conoce como "cascada". De acuerdo
con las especicaciones 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 tienen menos importancia y las del
usuario solo tienen prioridad sobre las del autor si estn marcadas como importantes.
Las declaraciones con el mismo orden se ordenan segn la especicidad y,
posteriormente, segn el orden en el que se han especicado. Los atributos visuales
HTML se traducen en las declaraciones CSS correspondientes. Se tratan como reglas
de autor de prioridad baja.

Especi cidad
La especicacin de CSS2 dene la especicidad del selector como se indica a
continuacin:
"1" si la declaracin es de un atributo "style" en lugar de una regla con un
selector; en caso contrario, "0" (= a),
nmero de atributos de ID del selector (= b),
nmero de otros atributos y pseudoclases del selector (= c),
nmero de nombres de elementos y de pseudoelementos del selector (= d).
La especicidad se obtiene al concatenar los cuatro nmeros a-b-c-d (en un sistema
de nmeros de base amplia).
La base numrica que se debe utilizar es el nmero de recuento ms elevado de una
de las categoras.
Por ejemplo, si a=14, se puede utilizar una base hexadecimal. En el improbable caso
de que a=17, se deber utilizar una base numrica de 17 dgitos. El ltimo caso sera el
de un selector como html body div div p... con 17 etiquetas en el selector, pero esto es
muy poco probable.
Algunos ejemplos:
*
{}
li
{}
li:first-line {}
ul li
{}
ul ol+li
{}
h1 + *[rel=up]{}
ul ol li.red {}
li.red.level {}
#x34y
{}
style=""

/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

Cmo ordenar las reglas

a=0
a=0
a=0
a=0
a=0
a=0
a=0
a=0
a=0
a=1

b=0
b=0
b=0
b=0
b=0
b=0
b=0
b=0
b=1
b=0

c=0
c=0
c=0
c=0
c=0
c=1
c=1
c=2
c=0
c=0

d=0
d=1
d=2
d=2
d=3
d=1
d=3
d=1
d=0
d=0

->
->
->
->
->
->
->
->
->
->

specificity
specificity
specificity
specificity
specificity
specificity
specificity
specificity
specificity
specificity

=
=
=
=
=
=
=
=
=
=

0,0,0,0
0,0,0,1
0,0,0,2
0,0,0,2
0,0,0,3
0,0,1,1
0,0,1,3
0,0,2,1
0,1,0,0
1,0,0,0

*/
*/
*/
*/
*/
*/
*/
*/
*/
*/

Despus de buscar coincidencias, las reglas se ordenan segn las reglas de cascada.
WebKit utiliza el ordenamiento de burbuja para listas pequeas 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)
{
int spec1 = r1.selector()->specificity();
int spec2 = r2.selector()->specificity();
return (spec1 == spec2) : r1.position() > r2.position() :
spec1 > spec2;
}

Proceso gradual
WebKit utiliza un indicador que muestra si se han cargado todas las hojas de estilo de
nivel superior (incluidas las de @imports). Si las hojas de estilo no se cargan por
completo al asociarlas, se utilizan marcadores de posicin (indicndolo en el
documento), que se vuelven a calcular una vez que se han cargado las hojas de estilo.

Diseo
Cuando el renderizador se crea y se aade al rbol, no tiene posicin ni tamao. El
clculo de estos valores se conoce como diseo o reujo.
HTML utiliza un modelo de diseo basado en ujo, lo que signica que, la mayora de
las veces, los clculos geomtricos se pueden realizar con una sola operacin. Los
elementos que entran posteriormente "en el ujo" no suelen inuir en la geometra de
los elementos que ya se encuentran en l, por lo que el diseo 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 ms de un clculo (3.5).
El sistema de coordenadas se reere al marco raz. Se utilizan las coordenadas
superior e izquierda.
El diseo consiste en un proceso recurrente. Se inicia en el renderizador raz, que
corresponde al elemento <html> del documento HTML. El diseo se aplica de forma
recurrente a travs de toda la jerarqua de marcos o de una parte de ella, calculando
informacin geomtrica para cada renderizador que lo requiere.
La posicin del renderizador raz es 0,0 y su dimensin es la ventana grca, es decir,
la parte visible de la ventana del navegador.
Todos los renderizadores incluyen un mtodo de "diseo" o de "reujo" y cada uno
activa el mtodo de diseo del elemento secundario al que se debe aplicar el diseo.

Sistema de bit de modi cacin (dirty bit)

Para no iniciar un proceso de diseo completo con cada pequea modicacin, el

navegador utiliza un sistema de bit de modicacin (dirty bit). Cuando se aade o se
modica un renderizador, tanto el propio renderizador como su elemento secundario se
marcan con el indicador "dirty", lo que signica que se deben someter a un proceso de
diseo.
Existen dos indicadores: "dirty" y "children are dirty". El indicador "children are dirty"
especica que, aunque el renderizador no haya sufrido cambios, al menos uno de sus
elementos secundarios necesita someterse a un proceso de diseo.

Diseo global e incremental

El proceso de diseo se puede activar en todo el rbol de renderizacin, lo que se
conoce como diseo "global". A continuacin se indican algunos motivos por los que
puede ser necesario un diseo global:
1. un cambio de estilo global que afecte a todos los renderizadores, como un
cambio de tamao de fuente,
2. un cambio de tamao de la pantalla.
El diseo puede ser incremental, en cuyo caso solo se sometern a un proceso de
diseo los renderizadores marcados como "dirty" (este hecho puede provocar daos
que pueden requerir procesos de diseo adicionales).
Cuando los renderizadores estn marcados como "dirty", se activa (de forma
asncrona) el diseo incremental (por ejemplo, cuando se aaden renderizadores
nuevos al rbol de renderizacin despus de incluir contenido adicional de la red en el
rbol de DOM).

Figura : diseo incremental en el que solo se someten a un proceso

de diseo los renderizadores modicados y sus elementos

secundarios (3.6)

Diseo asncrono y sncrono

El diseo incremental se efecta de forma asncrona. Firefox almacena "comandos de
reujo" para los diseos incrementales y un programador activa la ejecucin en lote de
estos comandos. WebKit tambin incluye un temporizador que ejecuta el diseo
incremental (se recorre el rbol y se aplica diseo a los renderizadores marcados como
"dirty").
Las secuencias de comandos que solicitan informacin de estilo, como "osetHeight",
pueden activar el diseo incremental de forma sncrona.
El diseo global se suele activar de forma sncrona.
A veces, el diseo se activa como una devolucin de llamada posterior a un diseo
inicial debido a los cambios que sufren algunos atributos, como la posicin de
desplazamiento.

Optimizaciones
Cuando se activa un proceso de diseo por un "cambio de tamao" o por un cambio
en la posicin del renderizador (no en su tamao), el tamao de los renderizadores se
toma de una cach en lugar de recalcularse.
En algunos casos, solo se modica un subrbol, por lo que el proceso de diseo no se
inicia desde la raz. Esto puede suceder en aquellos casos en los 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 tecla activara un diseo desde la raz) .

El proceso de diseo
El proceso de diseo suele seguir el patrn que se indica a continuacin:
1. El renderizador principal determina su propio ancho.
2. El renderizador principal analiza los elementos secundarios y:
1. Sita el renderizador secundario (establece su valor x e y).
2. Activa la aplicacin del diseo del renderizador secundario en caso
necesario (si est marcado como "dirty", si se trata de un diseo global 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 mrgenes y el relleno para establecer su propia
altura, que utilizar el elemento principal del renderizador principal.
4. Establece el bit de modicacin (dirty bit) en "false".

Firefox utiliza un objeto "state" (nsHTMLReowState) como parmetro de diseo

(conocido como "reujo"). Entre otros valores, el objeto de estado incluye el ancho de
los elementos principales.
El resultado del diseo de Firefox es un objeto "metrics" (nsHTMLReowMetrics) que
incluir la altura computada del renderizador.

Clculo del ancho

El ancho del renderizador se calcula utilizando el ancho del bloque contenedor, la
propiedad de estilo "width" del renderizador, los mrgenes y los bordes.
Utilicemos para nuestro ejemplo el siguiente elemento "div":
<div style="width:30%"/>

WebKit calculara su ancho de la siguiente forma (clase "RenderBox", mtodo

"calcWidth"):
El ancho del contenedor es el valor mximo 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 ancho del contenedor.
A continuacin, se aaden el relleno y los bordes horizontales.
Hasta ahora, hemos calculado el "ancho preferente". Ahora vamos a calcular los
anchos mnimo y mximo.
Si el ancho preferente es superior al ancho mximo, se utiliza el ancho mximo. Si, por
el contrario, es inferior al ancho mnimo (la unidad indivisible ms pequea), se utiliza el
ancho mnimo.
Los valores se almacenan en cach en caso de que se necesite activar un proceso de
diseo sin que vare el ancho.

Salto de lnea
El salto de lnea se produce cuando un renderizador decide que debe interrumpirse en
mitad del diseo. Se detiene y comunica el salto al renderizador principal. El
renderizador principal crea renderizadores adicionales y activa sus procesos de diseo.

Pintura
En la fase de pintura, se recorre el rbol de renderizacin y se activa el mtodo de
"pintura" de los renderizadores para que se muestre su contenido en la pantalla. En la
fase de pintura, se utiliza el componente de infraestructura de la interfaz.

Global e incremental
Al igual que ocurre en la fase de diseo, la pintura tambin puede ser un proceso
global (se pinta el rbol de renderizacin completo) o incremental. En el caso de la
pintura incremental, algunos de los renderizadores se modican de una forma que no
afecta a la totalidad del rbol. El renderizador modicado invalida su rectngulo
correspondiente en la pantalla. Esto hace que el sistema operativo considere esta
regin como modicada y que genere un evento de "pintura". El sistema operativo
fusiona ingeniosamente varias regiones en una. En Chrome, esta operacin resulta ms
complicada, ya que el renderizador se encuentra en un proceso diferente al proceso
principal. Chrome simula el comportamiento del sistema operativo hasta cierto punto.
La presentacin escucha estos eventos y delega el mensaje en la raz de la
renderizacin. Se recorre el rbol hasta llegar al renderizador correspondiente. En
consecuencia, se vuelve a pintar el renderizador y, normalmente, sus elementos
secundarios.

Orden del proceso de pintura

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. Este orden inuye en la pintura,
ya que las pilas se pintan de atrs 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.

Lista de visualizacin de Firefox

Firefox analiza el rbol de renderizacin y crea una lista de visualizacin para el rea
rectangular pintada que incluye los renderizadores relevantes para el rea rectangular
en el orden de pintura correcto (primero los fondos de los renderizadores, luego los
bordes, etc.). De esta forma, si se quiere volver a pintar el rbol, solo se tendr que
recorrer una vez (primero se pintan todos los fondos, despus todas las imgenes, a
continuacin todos los bordes, etc.).

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

Almacenamiento de guras rectangulares de WebKit

Antes de volver a iniciar un proceso de pintura, WebKit guarda el rectngulo antiguo
como un mapa de bits. Posteriormente, solo pinta el rea diferencial existente entre los
rectngulos nuevo y antiguo.

Cambios dinmicos
Los navegadores intentan ejecutar la menor cantidad posible de acciones cuando se
produce un cambio. Por tanto, si se producen cambios en el color de un elemento,
solo se volver a pintar ese elemento. Si se producen cambios en la posicin de un
elemento, se volver a disear y a pintar ese elemento, sus elementos secundarios y,
posiblemente, los elementos que estn a su mismo nivel. Si se aade un nodo DOM,
se activar un proceso de diseo y de nueva pintura del nodo. Si se producen cambios
de mayor importancia, como el aumento del tamao de fuente del elemento "html", se
invalidarn las cachs y se activar un nuevo proceso de diseo y de pintura del rbol
completo.

Subprocesos del motor de renderizacin

El motor de renderizacin solo consta de un subproceso. Casi todas las operaciones,
excepto las de red, se desarrollan en un nico subproceso. En Firefox y Safari, es el
subproceso principal del navegador. En Chrome, es el subproceso principal del
proceso de pestaa.
Las operaciones de red se pueden realizar mediante varios subprocesos paralelos. El
nmero de conexiones paralelas es limitado (normalmente, de dos a seis conexiones.
Por ejemplo, Firefox 3 utiliza seis).

Bucle de eventos
El subproceso principal del navegador es un bucle de eventos, que consiste en un
bucle innito que mantiene activo el proceso. Espera a que se inicien eventos (como
los de diseo y pintura) y los procesa. Este es el cdigo de Firefox para el bucle de
eventos principal:
while (!mExiting)
NS_ProcessNextEvent(thread);

Modelo de formato visual de CSS2

El elemento canvas

De acuerdo con la especicacin de CSS2, el trmino canvas describe "el espacio en

el que se representa la estructura de formato", es decir, el lugar en el que el navegador
pinta el contenido. Aunque el elemento canvas es innito para cada dimensin del
espacio, los navegadores eligen un ancho inicial en funcin de las dimensiones de la
ventana grca.
De acuerdo con las indicaciones de la pgina www.w3.org/TR/CSS2/zindex.html, el
elemento canvas es transparente si se incluye dentro de otro elemento o tiene un color
denido por el navegador si no se incluye en ningn elemento.

Modelo de cajas de CSS

El modelo de cajas de CSS describe las cajas rectangulares que se generan para los
elementos del rbol del documento y que se disean de 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 y relleno.

Figura : modelo de cajas de CSS2

Cada nodo genera entre 0y n cajas de este tipo.

Todos los elementos tienen una propiedad "display" que determina el tipo 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 de visualizacin
predeterminado de un elemento "div" es "block".
Puedes consultar un ejemplo de hoja de estilo predeterminada en la pgina
www.w3.org/TR/CSS2/sample.html.

Esquema de posicionamiento
A continuacin se indican los tres tipos de esquemas disponibles.
1. Flujo normal: el objeto se coloca en funcin del lugar que ocupa en el documento
(esto signica que el lugar que ocupa en el rbol de renderizacin es similar al
lugar que ocupa en el rbol de DOM) y se disea de acuerdo con sus
dimensiones y con el tipo de caja.
2. Flotante: el objeto se disea primero segn el ujo 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 renderizacin de una
forma diferente a la que se utiliza para colocarlo en el rbol de DOM.
La propiedad "position" y el atributo "oat" determinan el esquema de
posicionamiento.
Si se utilizan "static" y "relative", se genera un ujo normal.
Si se utilizan "absolute" y "xed", se produce un posicionamiento absoluto.

Cuando el posicionamiento es esttico, no se dene ninguna posicin, por lo que se

utiliza el posicionamiento predeterminado. En otros esquemas, el autor especica la
posicin: arriba, abajo, izquierda, derecha.
Los siguientes valores determinan el diseo de la caja:
tipo de caja,
dimensiones de la caja,
esquema de posicionamiento,
informacin externa, como el tamao de las imgenes y el tamao de la pantalla.

Tipos de cajas
Caja de bloque: forma un bloque (tiene su propio rectngulo en la ventana del
navegador).

Figura : caja de bloque

Caja integrada: no tiene bloque propio, sino que se incluye en un bloque de

contencin.

Figura : cajas integradas

Las cajas de bloque se colocan en vertical, una detrs de otra, mientras que las cajas
integradas se distribuyen horizontalmente.

Figura : formato de cajas de bloque e integradas

Las cajas integradas se colocan dentro de lneas o "cajas de lnea". 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 lneas tienen como mnimo la misma altura que la caja ms alta, aunque
pueden ser ms altas. En caso de que el ancho del contenedor no sea suciente, las
cajas integradas se colocan en diferentes lneas. Esto es lo que suele ocurrir en un
prrafo.

Figura : lneas

Posicionamiento
Relativo
Posicionamiento relativo: el elemento se coloca normalmente y, a continuacin, se
mueve segn el diferencial correspondiente.

Figura : posicionamiento relativo

Flotante

Una caja otante se desplaza a la izquierda o a la derecha de una lnea. Lo ms

interesante de este posicionamiento es que las dems cajas uyen a su alrededor. A
continuacin, se incluye un ejemplo con cdigo HTML:
<p>
<img style="float:right" src="images/image.gif" width="100"
height="100">
Lorem ipsum dolor sit amet, consectetuer...
</p>

La apariencia sera la siguiente:

Figura : caja otante

Absoluto y jo
El diseo se dene con exactitud independientemente del ujo normal. El elemento no
participa en el ujo normal. Las dimensiones son relativas al contenedor. En el
posicionamiento jo, el contenedor es la ventana grca.

Figura : posicionamiento jo

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

Representacin en capas
Las capas se especican con la propiedad "z-index" de CSS. Representa la tercera
dimensin de la caja, es decir, su posicin 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, y los elementos que quedan
encima se colocan en la parte superior, ms cerca del usuario. En caso de
superposicin, se oculta el elemento que queda debajo.
Las pilas se ordenan segn la propiedad "z-index". Las cajas que tienen la propiedad
"z-index" forman una pila local. La ventana grca forma 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:

Figura : posicionamiento jo

Aunque el elemento "div" rojo preceda al verde en el marcado y se pinte en primer

lugar en un ujo normal, el valor de la propiedad "z-index" es superior, por lo que se
encuentra ms adelantado en la pila de la caja raz.

Recursos
1. Arquitectura del navegador
1. Grosskurth, Alan. A Reference Architecture for Web Browsers (pdf)
2. Gupta, Vineet. How Browsers Work - Part 1 - Architecture
2. Anlisis
1. Aho, Sethi, Ullman, Compilers: Principles, Techniques, and Tools, tambin
conocido como "The Dragon Book" (El libro del dragn), Addison-Wesley,
1986
2. Rick Jellie. 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 (vdeo de Google Tech Talks)
3. L. David Baron, Mozilla's Layout Engine
4. L. David Baron, Mozilla Style System Documentation
5. Chris Waterson, Notes on HTML Reow
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. Especicaciones de W3C
1. HTML 4.01 Specication
2. W3C HTML5 Specication
3. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specication
6. Instrucciones de creacin 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 ao 2000 y se familiariz con el "malco"
modelo de capas de Netscape. Al igual que Richard Feynmann, senta
fascinacin por descubrir cmo funcionaban las cosas, por lo que empez a
investigar los mecanismos de funcionamiento interno de los navegadores y a
documentar todos sus descubrimientos. Tali tambin ha publicado una pequea
gua sobre rendimiento de aplicaciones cliente.

Traducciones
Esta pgina se ha traducido al japons dos veces! Cmo funcionan los navegadores:

lo que hay detrs de los navegadores web actuales (ja) por @_kosei_ y
WEB
por @ikeike443 y
@kiyoto01. Gracias a todos!