4.3.

4
4.3.3
4.3.2
4.3.1
4.2
4.1
3.1.7
3.1.6
3.1.5
3.1.4
3.1.3
3.1.2
3.1.1
3.2.9
3.2.8
3.2.7
3.2.6
3.2.5
3.2.4
3.2.3
3.2.2
3.2.1
3.3.1
3.4.3
3.4.2
3.4.1
9.5.3
9.5.2
9.5.1
2.3
4.3
9.4
9.3
9.2
9.1
8.1
6.4
6.3
6.2
6.1
5.7
5.6
5.5
5.4
5.3
5.2
5.1
4.4
2.2
2.1
1.3
1.2
1.1
3.1
3.2
3.3
3.4
9.5
9.6

HTML5 ROCKS
TUTORIALES
CMO FUNCIONAN LOS
NAVEGADORES: LO QUE HAY DETRS
DE LOS NAVEGADORES WEB
ACTUALES
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 modificaciones.
Como desarrolladora web, conocer las caractersticas internas de las operaciones de los navegadores sirve
para tomar mejores decisiones y para conocer los motivos que justifican 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 flujo principal
3. Ejemplos del flujo principal
3. Anlisis y construccin del rbol de DOM
1. Anlisis (general)
1. Gramticas
2. Analizador: combinacin de analizadores lxicos
3. Traduccin
4. Ejemplo de anlisis
5. Definiciones formales de vocabulario y sintaxis
6. Tipos de analizadores
7. Cmo generar analizadores automticamente
2. Analizador de HTML
1. Definicin de gramtica HTML
2. No es una gramtica libre de contexto
3. DTD de HTML
4. DOM
5. El algoritmo de anlisis
6. El algoritmo de tokenizacin
7. Algoritmo de construccin de rbol
8. Acciones al finalizar el anlisis
9. 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 flujo de construccin del rbol
3. Computacin de estilos
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. Especificidad
3. Cmo ordenar las reglas
4. Proceso gradual
5. Diseo
1. Sistema de bit de modifiacin (dirty bit)
2. Diseo global e incremental
3. Diseo asncrono y sncrono
4. Optimizaciones
5. El proceso de diseo
6. Clculo del ancho
7. Salto de lnea
6. Pintura
1. Global e incremental
2. Orden del proceso de pintura
3. Lista de visualizacin de Firefox
4. Almacenamiento de figuras rectangulares de WebKit
7. Cambios dinmicos
8. Subprocesos del motor de renderizacin
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. 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 refieren a navegadores de cdigo abierto, como Firefox, Chrome y Safari (este
ltimo es en parte de cdigo abierto). Segn lasestadsticas 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 especifica la ubicacin 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. Estas especificaciones 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 especificaciones 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 especificaciones 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 especificaciones 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 especificacin de HTML5 no define 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 especifican 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 especfica 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 especificacin de HTML (HTML5)
define 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.

Chapter 2

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 definido 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 modificado posteriormente por Apple para hacerlo compatible con Mac y Windows. Puedes obtener ms
informacin en webkit.org.

EL FLUJO 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 flujo bsico:

Figura
: flujo 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 significa 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 flujo principal

Figura : flujo principal de WebKit

Figura : flujo principal del motor de renderizacin Gecko de Mozilla (3.6)

En las figuras 3 y 4 se puede ver que, aunque WebKit y Gecko utilizan una terminologa ligeramente diferente, el
flujo 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
"reflujo". 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 flujo:

Chapter 3

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 significa 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 significa que el documento no se considera vlido por tener errores de sintaxis.

Traduccin
Muchas veces, el rbol de anlisis no es el producto final. 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 : flujo de compilacin

Ejemplo de anlisis
En la figura 5 se observa un rbol de anlisis creado a partir de una expresin matemtica. Intentemos definir 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 final 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.

Definiciones formales de vocabulario y sintaxis

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 nmeros enteros se definen mediante una expresin regular.
La sintaxis normalmente se define en un formato denominado notacin de Backus-Naur (BNF). Nuestro idioma se
definir de la siguiente forma:
expression := term operation term
operation := PLUS | MINUS
term := INTEGER | expression

Dijimos que un lenguaje se puede analizar mediante analizadores normales si su gramtica es una gramtica libre
de contexto. Una definicin intuitiva de una gramtica libre de contexto es una gramtica que se puede expresar
completamente en notacin de Backus-Naur (BNF). Puedes consultar una definicin 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: identifica 2 + 3 como una expresin. A
continuacin, identifica 2 + 3 - 1 como expresin (el proceso de identificar 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
+3-1
trmino
3-1
operacin del trmino
-1
expresin
operacin de la expresin 1
expresin
Este tipo de analizador ascendente se conoce como analizador de desplazamiento-reduccin 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 definiciones 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.

Definicin de gramtica HTML

Es la sintaxis y el vocabulario definidos en las especificaciones 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 definir 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 definir
fcilmente mediante la gramtica libre de contexto que necesitan los analizadores.
Existe un formato formal para definir el lenguaje HTML: DTD (definicin 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 final de las etiquetas, etc. En conjunto, es una sintaxis
"flexible", 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 definicin de HTML est en formato DTD. Este formato se utiliza para definir lenguajes de la familia SGML.
Contiene definiciones de todos los elementos permitidos, de sus atributos y de su jerarqua. Como vimos antes, la
definicin DTD del lenguaje HTML no forma una gramtica libre de contexto.
Existen algunas variaciones de la definicin DTD. El modo estricto se ajusta nicamente a las especificaciones,
pero otros modos admiten el marcado utilizado anteriormente por los navegadores. El objetivo es mantener la
compatibilidad con el contenido ms antiguo. La definicin 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 especificado el modelo DOM. Puedes consultarlo en la
pgina www.w3.org/DOM/DOMTR. Es una especificacin genrica para la manipulacin de documentos. Un
mdulo especfico describe elementos HTML especficos. Puedes consultar las definiciones HTML en la
pgina www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.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 modificar 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 especificacin 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 finales 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 final de los datos.

Figura : flujo de anlisis de HTML (tomado de la

especificacin 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 flujo de entrada y actualiza el siguiente estado de acuerdo con esos
caracteres. La decisin est influenciada por el estado de tokenizacin actual y por el estado de construccin del
rbol. Esto significa 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 tokenhtml.
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 alestado 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.

Fi
gura : 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 modifica 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 especificacin define 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 finalizacin del cuerpo provocar una transferencia al modo "despus del cuerpo". A
continuacin, se recibir la etiqueta HTML final, que har que se pase al modo despus del cuerpo. Cuando se
reciba el final del token del archivo, al anlisis finalizar.

Figura :
construccin de rbol del cdigo HTML de ejemplo

Acciones al finalizar 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 especificacin 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
especificacin 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 especificacin de HTML5 s se definen 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 finales 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 fijamos 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 especificacin del lenguaje CSS define su gramtica sintctica y lxica.
Veamos algunos ejemplos:
La gramtica lxica (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 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 define formalmente en esta definicin:
ruleset
: selector [ ',' S* selector ]*
'{' S* declaration [ ';' S* declaration ]* '}' S*
;

Esto significa que un conjunto de reglas es un selector o un nmero opcional de selectores

separados por una coma y por espacios (S significa 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 definirn en las siguientes definiciones 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 especificaciones 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 modifica 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 modifican 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.

Chapter 4

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 definicin:
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 especificacin 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 suficiente para una lnea, las nuevas
lneas se aaden como renderizadores adicionales.
Otro ejemplo con varios renderizadores sera un cdigo HTML roto. Segn la especificacin 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
flotantes y aquellos con posicin absoluta quedan fuera del flujo, 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 grfica" es el

bloque contenedor inicial. En WebKit, ser el objeto "RenderView".
El flujo de construccin del rbol
En Firefox, la presentacin se registra como un detector de actualizaciones de DOM. La presentacin delega la
creacin de marcos enFrameConstructor 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 especificacin de CSS denomina "bloque contenedor", es decir, el
bloque superior que contiene el resto de los bloques. Sus dimensiones se corresponden con la ventana grfica, 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 especificacin 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
definir su estilo favorito. En Firefox, por ejemplo, se puede hacer colocando una hoja de estilo en la carpeta de
perfiles del navegador).
La computacin 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 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 finalmente no sea 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 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 definen la
jerarqua de las reglas.
Veamos cmo se enfrentan los navegadores a estas dificultades:
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 identificador.
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 ":first-child" y ":lastchild".
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 finales. 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 defina el elemento, se heredan del elemento principal. Las
propiedades no heredadas (denominadas propiedades "reset") utilizan los 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 no proporciona una definicin 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 especfico, 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 especfico), y recorremos el rbol en sentido ascendente hasta completar la
estructura. Si este nodo de reglas no incluye ninguna especificacin para la estructura, podemos optimizarlo
considerablemente (la mejor forma es recorrer el rbol en sentido ascendente hasta encontrar un nodo que incluya
una especificacin completa y apuntar despus a este nodo) y compartir la estructura completa. Gracias a este
mtodo 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 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 especfico 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:

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

Para simplificar 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 significa 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 especifica reglas de margen.
Ya tenemos una definicin 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 final (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 especificasen 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 significa 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 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" />
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 dificultad, 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 define 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 definicin, 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 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 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 especificidad y, posteriormente, segn el orden en el que se han especificado. Los atributos visuales HTML se
traducen en las declaraciones CSS correspondientes. Se tratan como reglas de autor de prioridad baja.

Especificidad
La especificacin de CSS2 define la especificidad 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 especificidad 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:
*
{} /* 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 */

Cmo ordenar las reglas

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.

Chapter 5

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 reflujo.
HTML utiliza un modelo de diseo basado en flujo, lo que significa que, la mayora de las veces, los clculos
geomtricos se pueden realizar con una sola operacin. Los elementos que entran posteriormente "en el flujo" no
suelen influir 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 refiere 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 grfica, es decir, la parte
visible de la ventana del navegador.
Todos los renderizadores incluyen un mtodo de "diseo" o de "reflujo" y cada uno activa el mtodo de diseo del
elemento secundario al que se debe aplicar el diseo.

Sistema de bit de modificacin (dirty bit)

Para no iniciar un proceso de diseo completo con cada pequea modificacin, el navegador utiliza un sistema de
bit de modificacin (dirty bit). Cuando se aade 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
diseo.
Existen dos indicadores: "dirty" y "children are dirty". El indicador "children are dirty" especifica 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
modificados y sus elementos secundarios (3.6)
Diseo asncrono y sncrono

El diseo incremental se efecta de forma asncrona. Firefox almacena "comandos de reflujo" 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 "offsetHeight", 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 modifica 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 modificacin (dirty bit) en "false".
Firefox utiliza un objeto "state" (nsHTMLReflowState) como parmetro de diseo (conocido como "reflujo").
Entre otros valores, el objeto de estado incluye el ancho de los elementos principales.
El resultado del diseo de Firefox es un objeto "metrics" (nsHTMLReflowMetrics) 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.

Chapter 6

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 modifican de una forma que no afecta a la totalidad del rbol. El renderizador
modificado invalida su rectngulo correspondiente en la pantalla. Esto hace que el sistema operativo
considere esta regin como modificada 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 influye 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 figuras 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.

Chapter 7

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.
Chapter 8

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 infinito 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);

Chapter 9

MODELO DE FORMATO VISUAL DE CSS2

El elemento canvas
De acuerdo con la especificacin 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
infinito para cada dimensin del espacio, los navegadores eligen un ancho inicial en funcin de las dimensiones de
la ventana grfica.
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 definido 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 significa
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 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 renderizacin de una forma diferente a
la que se utiliza para colocarlo en el rbol de DOM.
La propiedad "position" y el atributo "float" determinan el esquema de posicionamiento.
Si se utilizan "static" y "relative", se genera un flujo normal.
Si se utilizan "absolute" y "fixed", se produce un posicionamiento absoluto.

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

posicionamiento predeterminado. En otros esquemas, el autor especifica 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 suficiente, 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 flotante se desplaza a la izquierda o a la derecha de una lnea. Lo ms interesante de este
posicionamiento es que las dems cajas fluyen 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 flotante

Absoluto y fijo
El diseo se define con exactitud independientemente del flujo normal. El elemento no participa en el flujo
normal. Las dimensiones son relativas al contenedor. En el posicionamiento fijo, el contenedor es la ventana
grfica.

Figura : posicionamiento fijo

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

REPRESENTACIN EN CAPAS
Las capas se especifican 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 grfica 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 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 ms adelantado en la pila de la caja raz.

Chapter 10

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 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 (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 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 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 "malfico" 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!
Salvo disposicin en contra, el contenido de esta pgina est sujeto a la licencia Reconocimiento 3.0 de Creative Commons y los ejemplos de
cdigo a la licencia Apache 2.0.