Traducción de Artículo de Ajax XX

Que hace el markup
Una vez que te des cuenta de que tu markup es realmente sobre organización, podes verlo diferente. Mas que pensar que un H1 hace que el texto se vea mas grande, en color Negro, estilo Negritas, pensá el H1 como un heading. Como ve el usuario eso -- y si el usuario usa tu CSS, la suya, o alguna combinación de las dos--es una consideración secundaria. En su lugar, date cuenta de que el markup es realmente sobre proveer este nivel de organización; un p indica que ese texto está en un párrafo, img denota una imagen, div divide un página en secciones y así sucesivamente.
Deberías tener claro también que estilo y comportamiento (gestionadores de eventos y JavaScript) son aplicados a esta organización, después de todo. El markup tiene que estar en su lugar para operar sobre el o aplicarle estilo. Entonces, como probablemente tengas CSS en un archivo externo a tu HTML, la organización de tu markup está separada de su estilo, formato y comportamiento. Así como ciertamente podés cambiar el estilo de un elemento o pieza de texto desde JavaScript, es más interesante cambiar la organización que tu markup presenta.
Mientras que mantengas en la mente que tu markup solo provee organización, o marco, a tu página, estás adelante en el juego. Y un poco mas todavía, vas a ver como el navegador toma esta organización textual y la transforma en algo mucho más interesante --un grupo de objetos, cada uno de los cuales pueden ser cambiados, agregados o borrados.
Las ventajas del markup de texto
Antes de referirme al navegador Web, vale la pena considerar porqué el texto plano es absolutamente la mejor opción para almacenar tu HTML (para mas de esto, ver algunos pensamientos adicionales sobre markup ). Sin entrar en pro y contra, simplemente resalto que tu HTML es enviado a través de la red a una navegador Web toda vez que la página es vista (poniendo el cache y demás a un lado por motivos de simplicidad). Simplemente no hay abordaje más eficiente que pasar por texto. Objetos binarios, representaciones gráficas de la página, y partes reorganizadas del markup... todas ellas son mas difícil de enviar a través de la red que archivos de texto plano.
Adicionar a eso el valor que un navegador agregar a la ecuación. Los navegadores de hoy permiten a los usuarios cambiar el tamaño del texto, escalar imágenes, descargar el CSS o JavaScript de una página (en la mayoría de los casos) y mucho más --todo esto imposibilita todo tipo de representación gráfica de la página al navegador. En cambio, el navegador necesita el HTML crudo para poder aplicar cualquier proceso a la página en el navegador más que confiar en al servidor que se encargue de esa tarea. En la misma linea, separar CSS del JavaScript y separar estos del markup HTML requiere un formato que se fácil de, bueno, separar. Archivos de texto otra vez son una manera genial de hacer esto.
Por ultimo, pero no menos importante, recuerda que la promesa de los nuevos estándares como HTML 4.01 y XHTML 1.0 y 1.1 separan contenido (la información en tu página) de presentación y estilo (normalmente aplicado con CSS). Para los programadores separar si HTML de sus CSS, luego forzar a un navegador a devolver alguna representación de una página que una todo eso junto, frustra muchas de las ventajas de esos estándares. Mantener esas partes dispares separadas hasta el navegador le permite mayor flexibilidad al obtener el HTML del servidor.

Algunos pensamientos adicionales sobre markup
Editar texto plano:¿bien o mal?
Los archivos de texto plano son ideales para guardar markup, pero eso no es así para editar el markup. Es perfectamente aceptable el uso de un IDE como Macromedia DreamWeaver --o el un tanto mas intrusivo Microsoft Front Page-- para trabajar en el markup de la página. Esos ambientes a menudo ofrecen atajos y ayuda al crear páginas Web, especialmente cuando estas usando CSS y JavaScript, cada uno de un archivo externo a un markup de pagina real. Muchos todavía prefieren el viejo y querido Notepad o Vi (lo confieso yo soy uno de ellos) y es una gran opción también. En todo caso, el resultado final es un archivo de texto lleno de markup.
Texto sobre la red: algo bueno.
Como ya se mencionó, el texto es un gran medio para un documento --como HTML o CSS-- que es transferido por la red cientos y miles de veces. Cuando digo que el navegador tiene un tiempo difícil representando el texto, significa específicamente transformar el texto en un página gráfica que los usuarios ven. Esto no tiene relación con como el navegador realmente recupera una página del servidor Web; en ese caso, el texto es todavía más la mejor opción.

Una mirada mas profunda a los navegadores Web
Para algunos de ustedes, todo lo que han leído hasta ahora puede ser una revisión divertida de tu rol en el proceso del desarrollo Web. Pero en lo que concierne a que hace el navegador Web, muchos de los diseñadores y desarrolladores Web mas listos a menudo no se dan cuenta de que pasa realmente "abajo del capot". Me focalizaré en eso en esta sección. Y no te preocupes, el código vendrá pronto, pero aguanta tu impaciencia de codificar por que entender exactamente que hace un navegador Web es esencial para que trabajes en tu código correctamente
Las desventajas del markup de texto
Justamente como texto el markup tiene ventajas fabulosas para un diseñador o un creador de páginas, también tiene desventajas un tanto significativas para el navegador. Específicamente, los navegadores tienen un tiempo muy difícil en cuanto a representar markup de texto visualmente para el usuario (para mas de esto, ver algunos pensamientos adicionales sobre markup)Considerar estas tareas frecuentes del navegador:

• Aplicar estilos CSS --frecuentemente de múltiples hojas de estilo en archivos externos-- para un markup basado en el tipo de elementos, sus clases, sus ids y sus posiciones en el documento HTML.
• Aplicar los estilos y formatos basados en código JavaScript --también frecuentemente en archivos externos-- a partes diferentes del documento HTML.
• Cambiar el valor de los campos de formulario basado en el código JavaScript
• Dar soporte a efectos visuales como rollover e intercambio de imágenes en código JavaScript.

La complejidad no está en codificar esas tareas; es bastante fácil hacer cada una de esas cosas. La complejidad viene desde el navegador realmente, llevando a cabo la acción solicitada. Si el markup es almacenada como texto y, por ejemplo, querés centrar el texto (text-align: center) de un elemento p en la clase center-text,¿como lográs esto?

• ¿Agregás estilo en la linea del texto?
• ¿Aplicás el estilo al texto HTML en el navegador y solo continuas con cual contenido centrar o no centrar?
• ¿Aplicás HTML sin estilo y luego aplicas el formato?

Estas tan difíciles preguntas son porqué pocas personas codifican navegadores estos días. (Esos quienes deberían recibir un caluroso agradecimiento)
Claramente, texto plano no es una gran manera de guardar HTML para el navegador aun cuando el texto fuera una buena solución para obtener el markup de una página en primer lugar. Sumale a esto la habilidad de JavaScript de cambiar la estructura de una página y las cosas se vuelven realmente difíciles. ¿Debería el navegador reescribir la estructura modificada al disco? ¿Como puede actualizar con cual es la etapa actual del documento?
Claramente, texto no es la respuesta. Es difícil de modificar, torpe para aplicar estilos y comportamiento y lleva en última instancia poca semejanza a la naturaleza dinámica de Web pages de hoy.
Mudanza a una vista de árbol
La respuesta a este problema --al menos, la respuesta elegida por los navegadores Web de hoy en día-- es usar una estructura de árbol para representar HTML. Veamos el listing 1 , una página HTML bastante simple y aburrida representada como texto markup.

Listing 1 Pagina HTML simple en markup de texto

<html>
<head> <title>Arboles, árboles por todas partes</title>
</head> <body>
<h1> Arboles, árboles por todas partes</h1>
<p> Bienvenido a una página <em>realmente</em> aburrida</p>
<div>
Vuelve pronto.
<img scr="come-again.gif" />
</div>
</body>
</html>

El navegador toma esto y lo convierte en una estructura como árbol, como en la figura 1
Figura 1. La vista de árbol del listing 1

Hice algunas simplificaciones menores para mantener este artículo en tema. Los expertos en DOM o XML se van a dar cuenta que ese espacio en blanco puede tener un efecto en como el texto es representado en un documento y una ruptura en la estructura de árbol del navegador Web. Meterse en esto suma poco y confunde el tema, entonces si sabés sobre el efecto del espacio en blanco, genial, si no, continua leyendo y no te preocupes por el. Cuando se convierta en un tema, vas a encontrar todo lo que necesites en ese momento. el árbol empieza con el elemento contenedor mas exterior que es el elemento HTML. Este se llama el elemento raíz(root) manteniendo la metáfora del árbol. Aunque esté en la parte inferior del árbol, siempre empieza acá cuando observes y analices arboles. Si te ayuda, podes dar vuelta el esquema, aunque se pierde un poco la metáfora del árbol.
De la raíz surgen lineas que muestran las relaciones entre las diferentes partes del markup. los elementos head y el body son hijos del elemento raíz html; title es un hijo de head y luego el texto "Arboles, arboles, en todas partes" es un hijo de title. El árbol entero se organiza así, hasta el navegador obtiene una estructura similar a lo que ves en la figura 1.
Algunos términos adicionales
Para continuar con la metáfora del árbol, head y body se dice que son ramas del html. Son ramas por que ellas por su lado tienen sus propios hijos. SI vas a las extremidades del árbol, te vas a encontrar mayormente con texto como "Arboles, árboles, por todos lados" y "realmente". A estos normalmente nos referimos como Hojas por que no tienen hijos. No necesitas memorizar esos términos y es frecuentemente mas fácil solo visualizar la estructura de árbol cuando trates descubrir que significa un término particular.