netalia

just for developers

HTML5
CSS3 y JavaScript

Marino Posadas
ADVERTENCIA LEGAL

Todos los derechos de esta obra están reservados a Marino Posadas

y netalia.

El editor prohibe cualquier tipo de fijación, reproducción, transforma-

ción o distribución de esta obra, ya sea mediante venta, alquiler o cual-
quier otra forma de cesión de uso o comunicación pública de la misma,
total o parcialmente, por cualquier sistema o en cualquier soporte, ya
sea por fotocopia, medio mecánico o electrónico, incluido el tratamiento
informático de la misma, en cualquier lugar del mundo.

La vulneración de cualesquiera de estos derechos podrá ser consi-

derada como una actividad penal tipificada en los artículos 270 y si-
guientes del Código Penal.

La protección de esta obra se extiende al mundo entero, de acuerdo

con las leyes y convenios internacionales.

© Marino Posadas, 2012

© netalia, S.L. 2012

HTML5, CSS 3 y JavaScript

Autor: Marino Posadas

Responsable editorial: Paco Marín
Diseño de cubierta: Silvia Gil
Maquetación: Silvia Gil

Editado por netalia

http://www.netalia.es - http://www.dnmplus.net
@netalia_es

Editado en formato digital e impreso.

Impreso
Precio: 29,50€
ISBN: 978-84-939296-2-6
Edición impresa en Navarra por Ulzama

Digital
Precio: 9,95€
ISBN: 978-84-939296-1-9
 A Juan José García y Javier García,
con la promesa de que jamás les obligaré a leer nada mío.

A mis sobrinos

A Milagros… siempre.
«Hay solo dos clases de lenguajes de programación: aquellos de los que
la gente está siempre quejándose y aquellos que nadie usa»
Bjarne Stroustrup

«Los proveedores de software están intentando hacer sus productos

más amigables para el usuario. Su mejor aproximación hasta el momen-
to ha sido tomar sus antiguos folletos y estampar las palabras ‘amigable
para el usuario’ en la portada»

Bill Gates

Agradecimientos

A Paco Marín, de Netalia, por animarme siempre en estas empresas.

A mis compañeros del grupo de MVP de Microsoft en España, con
Cristina González Herrero a la cabeza, y los componentes del DPE y di-
vulgación en Microsoft: Alfonso Rodríguez, José Bonnín, David Carmona,
David Salgado y todos los demás.
A Paul Cotton de la W3C, por sus palabras y ánimos en la entrevista
que nos concedió en su visita a Madrid.
A mis seguidores de Twitter, Facebook y otras redes sociales. Siempre
son una motivación para continuar la tarea.
Y a las empresas colaboradoras y amigas o que han mostrado interés
en este proyecto, como Alhambra-Eidos, Aula MCT, CAS Training,
DanySoft, MegaTraining, Ceticsa, MSL, Desfufor, GadeSoft. ¡Que siga-
mos mucho tiempo en la brecha!
índice

1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Objetivos de la W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Objetivos de esta obra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Las Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
HTML 5: La nueva propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
El World Wide Web Consortium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Estándares, HTML y la W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
El lapso de tiempo desde el último estándar . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
El problema de las fechas de terminación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Los navegadores y el estándar: IE10 como objetivo . . . . . . . . . . . . . . . . . . . . . . .19
Nuevas reglas del juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Los navegadores antiguos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Los objetivos del estándar en la práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Motores de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Librerías y Lenguajes que compilan a JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . .24
¿Por qué no esperar a que el estándar esté terminado? . . . . . . . . . . . . . . . . . . . .25
El sueño de una Web Semántica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Los Identificadores uniformes de recursos (URI vs. URL) . . . . . . . . . . . . . . . . . .27
URI y Semántica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Especificaciones y pruebas de laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Los test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Los sitios alternativos de pruebas de conformidad . . . . . . . . . . . . . . . . . . . . . . . .30
Los sitios oficiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Las aplicaciones web y el nuevo modelo de aplicaciones en Windows8 . . . . . . . . . .32
Aplicaciones Windows 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
El nuevo modelo de aplicaciones Windows 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
La posición de Silverlight y Flash en Windows 8 . . . . . . . . . . . . . . . . . . . . . . . . . .35
WinJS y los controles "de fábrica" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
La división granular de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
 Ejecución y soporte del estándar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Los motores Chakra y los dos contextos de ejecución . . . . . . . . . . . . . . . . . . . .40
Hablando sobre el estándar: la opinión de un protagonista . . . . . . . . . . . . . . . . . . . . .41
Entrevista con Paul Cotton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Referencias de la Web Semántica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

2. Herramientas y depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

Las herramientas de los navegadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Herramientas y depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
La herramienta de desarrollo de Internet Explorer (F12) . . . . . . . . . . . . . . . . . .56
Fiddler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Versiones de Fiddler y herramientas añadidas . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Arquitectura de Fiddler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Comparativa de capacidades de análisis de tráfico de red entre F12/IE y Fiddler 63
Generación de informes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Otras extensiones de Fiddler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Fiddler como complemento de navegadores . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
FireBug para FireFox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Vistas 3D de cualquier página . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Las herramientas de desarrolladores de Google Chrome . . . . . . . . . . . . . . . . . .70
Opera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Safari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
El soporte de HTML 5 en Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
El nuevo soporte de HTML 5 en Visual Studio 2012 . . . . . . . . . . . . . . . . . . . . . .76
Page Inspector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Soporte de Hojas de Estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Soporte de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Microsoft Expression Blend para Visual Studio 2012 . . . . . . . . . . . . . . . . . . . . . .87
Plantillas disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
3. HTML 5: nuevas etiquetas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
El problema de la WHATWG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
El marco de trabajo y los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Compatibilidad hacia atrás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Sintaxis general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
El tipo de documento: DOCTYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Codificación de Caracteres (Encoding) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
HTML5: Los nuevos elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Cambios genéricos para todos los elementos: Atributos globales . . . . . . . . . . . .103
Las nuevas etiquetas, por categorías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Etiquetas estructurales o semánticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Etiqueta <Section> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
<section> y la noción de esquema de un documento . . . . . . . . . . . . . . . . . . . . .108
Etiqueta <article> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Etiqueta <aside> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Etiqueta <header> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
Etiqueta <footer> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
Etiqueta <nav> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Implementación de una entrada de un blog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Elemento <figure> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
Nota sobre este conjunto de etiquetas semánticas . . . . . . . . . . . . . . . . . . . . . . .118
Multimedia: Elementos <video>, <audio>, <source> y <track> . . . . . . . . . . . . . . . . .118
Códec y formatos soportados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Utilización de las etiquetas <video> y <audio> . . . . . . . . . . . . . . . . . . . . . . . . . . .120
Elemento <source> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
El fragmento de código para video en Visual Studio 2012 . . . . . . . . . . . . . . . . . .121
Elemento <track> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Elemento <audio> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Elemento <embed> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Elemento <mark> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Elemento <progress> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Elemento <meter> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Elemento <time> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Elementos <ruby>, <rt> y <rp> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Elemento <bdi> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
 Elemento <wbr> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Elemento <command> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Elemento <keygen> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Elemento <output> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Elemento <details> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
El nuevo editor gráfico de Visual Studio 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Elemento <dataList> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Los elementos de trazado gráfico: <canvas> y <svg> . . . . . . . . . . . . . . . . . . . . . . . . .141
El elemento <canvas> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Soporte en Visual Studio 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
Dibujando sobre el canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
Rellenos y otras composiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Dibujando otras figuras básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
Utilizando imágenes en un <canvas> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
Transformaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
Animaciones y contenido dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
El elemento <svg> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Soporte de Visual Studio 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167

4. HTML 5: nuevos atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169

La etiqueta <input> y el API HTML Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
Atributos de <input> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
Otros atributos complementarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
Marcadores de posición (Placeholders) y el atributo pattern . . . . . . . . . . . . . . .176
Atributo pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
Atributo autofocus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Atributo autocomplete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Los elementos <datalist> e <input> y el atributo list . . . . . . . . . . . . . . . . . . . . . .180
Más sobre las validaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
Atributo required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Atributos novalidate y formnovalidate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
 Personalización de los mensajes de error y las API de validación . . . . . . . . . . . .184
Las API de Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186
La familia form* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
Atributos globales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Atributo contenteditable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196
Atributo hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
Atributo spellcheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
Atributos draggable y dropzone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
Los atributos data- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
El atributo data- y las aplicaciones HTML5 para Windows 8 . . . . . . . . . . . . . . .199
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202

5. CSS 3 (Hojas de Estilo en Cascada) . . . . . . . . . . . . . . . . . . . . . . . . .203

El estado actual del estándar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
CSS 3 en Visual Studio 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Page Inspector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206
Ventajas de usar CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
Ubicación de los estilos y ámbito de influencia . . . . . . . . . . . . . . . . . . . . . . . . . . .209
Selectores en CSS 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210
Extensiones CSS de los navegadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Selectores dependientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212
Agrupación de selectores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
Selectores por valor de atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215
Nuevos selectores de atributos en CSS 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
Pseudo-Clases y Pseudo-Elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217
Nuevas pseudo-clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218
Los pseudo-elementos (antiguos y nuevos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
Las nuevas definiciones en CSS 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222
Modificaciones estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222
Colores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
Fondos (Propiedad Background) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225
Bordes 231
Bordes definidos mediante imágenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
 Efectos de sombreado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
Gestión de textos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
El tipo de letra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
Especificación de texto seleccionable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
Fuentes descargables y formatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
Unidades de medida de las fuentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241
Características especiales para las fuentes OpenType . . . . . . . . . . . . . . . . . . . . .242
El problema del ajuste del tamaño de las fuentes . . . . . . . . . . . . . . . . . . . . . . . . .243
Texto con sombra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Columnas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Exclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
El diseño de caja flexible (Flexbox) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253
El diseño de cuadrícula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
Regiones CSS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
Adaptación a dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
Carga condicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
Directivas CSS como extensiones de un navegador . . . . . . . . . . . . . . . . . . . . . . .265
Transformaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267
Propiedad transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
Transiciones y Animaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272
Diferencia entre transiciones y animaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273
Transiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273
Animaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277
Recursos y referencias adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282

6. JavaScript 5 y las API relacionadas . . . . . . . . . . . . . . . . . . . . . . . . . .283

JavaScript y ECMAScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
Peculiaridades de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
Novedades en JavaScript 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
Matrices Tipadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
El modo Strict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Otras implicaciones del modo strict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290
Detección del modo strict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Novedades Sintácticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Test del modo strict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292
La orientación a objetos de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Sobre escritura de métodos (Overriding) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
Creación de objetos mediante Object.create . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
Propiedades de Acceso (getters y setters) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296
JavaScript 5 y Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
Funcionamiento de la palabra reservada this . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298
Funciones y el operador new . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299
Las API de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
Ejecución asíncrona de scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
Arrastrar y soltar (Drag & Drop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302
Geo-Localización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304
Implementación en un par de casos prácticos . . . . . . . . . . . . . . . . . . . . . . . . . . .306
Almacenamiento local (localStorage) y almacenamiento de sesión
(sessionStorage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
Almacenamiento local (LocalStorage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
Almacenamiento de datos complejos (IndexDB) . . . . . . . . . . . . . . . . . . . . . . . . .313
API para acceso a ficheros locales (File API) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
API que implican procesos asíncronos o comunicaciones . . . . . . . . . . . . . . . . . . . . . .317
Llamadas asíncronas a un servicio mediante AJAX y JSON . . . . . . . . . . . . . . . . .318
Web Workers:Tareas asíncronas en el cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324
Web Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
El API History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333
 capítulo 1
Introducción

HTML es el estándar oficial de la Web. Es el lenguaje en que se han construido (directa

o indirectamente, mediante herramientas de desarrollo), la inmensa mayoría de los
7.000 millones de páginas que, según las estadísticas, están disponibles hoy día en In-
ternet. Bien, pues HTML está cambiando. Está cambiando el lenguaje de marcas, y los
otros estándares vinculados con él, CSS y JavaScript.
Esto no es algo habitual, aunque tampoco es nuevo: la versión en uso por la ma-
yoría de los sitios en la actualidad es HTML 4, si bien nunca existió una versión 1.0.
De hecho, la primera versión como tal que se recoge en la entidad de estandarización
que se encarga de estas labores para Internet (World Wide Web Consortium, o W3C),
es la 3.2. Todo lo anterior pertenece a los "oscuros inicios de la Web", donde la guerra
de tecnologías trataba de imponerse, las empresas intentaban aprovechar la red en su
propio beneficio y no existía ninguna entidad que pusiese orden y concierto en ese
caos. acronym
Fue —precisamente— el creador de la Web, Tim Berners Lee1 (http://www.w3.org/
People/Berners‐Lee) el que lideró el proyecto inicial de creación de esa entidad, con sede
en el M.I.T., que ahora dispone de otras subsedes por todo el mundo, incluida España2.
Estas sedes mantienen secciones de frecuente actualización para todos los estándares
que manejan (varios cientos en realidad), así como de eventos, software y mecanismos
de validación de documentos, informática móvil, diseño de aplicaciones y un largo et-
cétera.

1
Lee ejerce funciones de director y trabaja en colaboración con otros equipos del resto de organizaciones
miembro
2
Disponible en www.w3c.es
página

13
<< Introducción

Objetivos de la W3C

Los principios rectores de esta organización están claramente declarados en sus

páginas con el lema "Una Web para todo el mundo", o sea: lenguajes y formatos estándar
que sean adoptados por todos los fabricantes para fomentar el juego limpio y la uni-
versalidad de la Web, de forma que sea accesible de forma "independiente del dispositivo,
del hardware, de la infraestructura de red, idioma, cultura, localización geográfica, o habilidad
física o mental". En suma, una Web universal.
Según sus propias palabras, la W3C propugna, además, una visión basada en 3
principios:

• "Web de los Autores y Consumidores" (todos lo somos en cierta medida)

• "Web de Datos y Servicios" (la compartición y almacenamiento de la información
suministrada por los protagonistas anteriores), y la
• "Web de Confianza", que, según ésta entidad, se conseguirá con la adopción
completa de los nuevos estándares que incluyen tecnologías que fomentan
la confianza y la responsabilidad. La llamada Web Semántica, y los mecanis-
mos que refuerzan la Seguridad y la Privacidad, son cruciales para conseguir
esta meta.

Objetivos de esta obra

Explicaremos aquí lo fundamental de estos propósitos de cara al desarrollador,

con la idea de proporcionarle un marco de referencia adecuado sobre el que evaluar las
novedades y los cambios que han tenido lugar respecto a versiones anteriores y adaptarlos
a la nueva situación.
Asumimos, por tanto, que el lector conoce las versiones previas de estas tecnologías
(o, al menos, lo fundamental de ellas), y lo que pretende es una puesta al día, al tiempo
que dispone de una referencia lo suficientemente amplia como para permitir el abordaje
de nuevos proyectos o actualizaciones de otros más antiguos.
Además, dado que la construcción de este estándar está teniendo una gran reper-
cusión en Internet, añadiremos al final de cada capítulo y en la parte final del libro un
apartado de referencias por categorías, para facilitar la búsqueda de sitios relacionados
y de interés para desarrolladores.
página

14
 Introducción >>

Las Herramientas

Se pueden utilizar las herramientas de desarrollo más co-

nocidas o convenientes en cada caso particular, pero en
esta obra utilizaré la última versión disponible de Visual
Studio (Visual Studio 2012 RC), que se encuentra dis-
ponible de forma gratuita en los servidores de Microsoft.
En el capítulo segundo, haremos un recorrido por otras herramientas, incluidas las de
los propios navegadores que ofrecen un soporte muy rico para la depuración y análisis
de sitios y/o páginas. También añadiremos allí las referencias Web correspondientes.
Naturalmente, para el trabajo con estas tecnologías, el lector puede usar igualmente
versiones anteriores de Visual Studio (existen complementos de V. Studio 2010/2008
que capacitan para el trabajo con HTML5), u otros entornos de desarrollo, como Eclip-
se.
Además, todo el código fuente será testado en distintos navegadores y está a dis-
posición de los lectores, tanto en las páginas de distribución de esta obra, como en mi
sitio Web (www.ElAveFenix.net/Libros).

HTML 5: La nueva propuesta

Tras un período de "silencio, mantenimiento y fracasos", como lo calificaba algún ana-
lista, la W3C3 ha vuelto a la carga con ánimos renovados. Como veremos en este mismo
capítulo, Paul Cotton (uno de los responsables del estándar, vinculado a Microsoft),
declara que "el objetivo es construir algo llamado la Open Web Platform (Plataforma
Web Abierta)".
Para ello, se tienen que cumplir algunos requisitos. El más importante, conseguir
una adopción universal por parte de la empresa y el mundo académico, algo de lo que
ya existen precedentes, como sucedió en la creación del estándar XML (en el que todas
las aristas del polígono empresarial estaban representadas4 y también lo estaba el mundo
académico). Hoy, XML está aceptado por todos y se usa universalmente. Por todo esto,
conviene saber algo sobre la organización que se encarga de estas tareas.

3
http://www.w3.org/
3
La especificación XML ya va por la 5ª edición y su documento oficial está disponible en
http://www.w3.org/TR/2008/REC-xml-20081126/
página

15
<< Introducción

El World Wide Web Consortium

La W3C se creó en 1994, y su objetivo inicial fue similar al de

las entidades ISO o ANSI. Sus miembros actuales son más de 300
organizaciones de todo el mundo que corren con los gastos de fi-
nanciación5 —aparte de algunos ingresos estatales— y lo componen profesionales de la
informática de todos los sectores, cuya misión es definir y normalizar la utilización de
los lenguajes usados en Internet mediante un conjunto de Recommendations (recomenda-
ciones) que son publicadas libremente en su sitio Web y aprobadas por comités de expertos
compuestos por representantes nominales de la propia W3C y técnicos especializados de
las más importantes compañías productoras de software, distribuidoras y centros de in-
vestigación. Baste citar entre ellos a Adobe, AOL, Apple, Cisco, IBM, Intel, Lotus, Mi-
crosoft, Motorola, Netscape, Fujitsu, Sony, Panasonic, HTC, Novell, Oracle, etc.
Su sitio Web principal lo alberga el prestigioso Massachussets Institute of Tech-
nology (M.I.T.) a través de su Laboratorio de Informática (http://www.lcs.mit.edu/) en
EE.UU., y dispone de réplicas en el INRIA (http://www.inria.fr) en (Francia) y la Uni-
versidad de Keio (http://www.keio.ac.jp/) en Japón. Además existe un conjunto de de-
legaciones por todo el mundo, a las que hay que añadir otras organizaciones que coor-
dinan actividades relacionadas de carácter abierto6.
Hasta el momento, han desarrollado más de 20 especificaciones técnicas. Para los
interesados en la historia de la Web, recomendamos: "The World Wide Web History
Project" (http://1997.webhistory.org/home.html), donde se conservan, incluso, los "posts"
y correos originales de los diversos colaboradores de Tim Berners-Lee, según se iba
desarrollando7.

Estándares, HTML y la W3C

Quizá quien se aventure por primera vez en este asunto de los estándares de internet,
pueda preguntarse exactamente qué se entiende por un estándar. En una obra publicada

5
La W3C recibe aportaciones de 3 fuentes distintas: Cuotas de los Miembros del W3C, Becas de investigación
y otras fuentes de subvención pública y privada, y donaciones individuales de dinero y equipamiento.
6
El sitio Web Identi.ca (http://identi.ca/w3ces) coordina las actividades de la W3C en España, que son
—en su gran mayoría— de carácter abierto al público.
7
Es curioso, por ejemplo, leer el "post" de Marc Andreessen, sugiriendo una nueva etiqueta HTML que
el propuso que tuviera el nombre <IMG>…
página

16
 Introducción >>

por esta misma editorial, Javier Holguera define los estándares de la siguiente forma:
"Existen dos tipos de estándares: de facto y de iure. Los primeros suele establecerlos una compañía
o producto, que debido a su uso masivo en un campo, se convierten en referencia en el mismo,
aceptados por el resto de miembros del mercado; los segundos son coordinados por un organismo de
estandarización y aseguran un proceso de revisión y consenso entre las partes interesadas, antes de
su publicación. Este proceso de revisión y consenso es, precisamente, el que los hace más beneficiosos
que los estándares de facto, que normalmente responden a los intereses de una única parte.
Existen muchos ejemplos de ambos tipos de estándares, e incluso algunos de ellos que han
pasado por ambas fases. Por ejemplo, PDF nació en 1993 y su popularidad lo convirtió en el es-
tándar de facto de documentos imprimibles. Sin embargo, no sería hasta 2005 cuando se con-
vertiría en un estándar de iure, con la publicación de PDF/A en ISO, uno de los organismos de
estandarización más importantes."
Como apuntábamos al inicio, la primera especificación relevante publicada por la
W3C fue la versión HTML 3.2, ya que su primer trabajo fue un intento de poner orden
en la situación anterior con una especificación de compromiso que aclarase de alguna
forma el caos existente y que se bautizó como HTML 2.0, entendiéndose que todo el
desorden anterior a ese momento recibiría genéricamente el nombre de HTML 1.0,
aunque nunca hubiera existido tal especificación.
Un tiempo después, se pudo observar que el trabajo que realizaba W3C para la
normalización difería notablemente de los planes de Netscape, por lo que hubo que
hacer tabla rasa del trabajo anterior y abordar el problema con seriedad, a partir de la
situación real. Al conjunto de dicho trabajo se le llama de forma genérica HTML 3.0
ó HTML+. Finalmente, llegó HTML 3.2, que recogía todas las principales características
de Netscape y de Internet Explorer, y que es la primera a la que puede llamársele estándar
de facto.

El lapso de tiempo desde el último estándar

Han transcurrido más de 11 años desde la última publicación de HTML (la versión
4.019, para ser exactos). En el medio, mucho trabajo, pero no tantos estándares generados,
a veces por falta de coordinación otras por conflictos de intereses. Lo más reseñable,
la especificación XHTML 1.010, que —en palabras de la propia W3C— es una refor-

8
Internet Explorer 9 y HTML5 (Javier Holguera): http://www.netalia.es/libros
9
La especificación HTML 4.01 data de Diciembre de 1999: http://www.w3.org/TR/1999/REC-html401-
19991224/
10
http://www.w3.org/TR/2002/REC-xhtml1-20020801/
página

17
<< Introducción

mulación de HTML 4.0 en XML 1.0. O sea, un HTML con sintaxis estricta. Su adop-
ción ha sido insuficiente.
El problema principal estriba en la gran cantidad de autores que ignoran la exis-
tencia de estos nuevos estándares, y la enorme base de páginas ya creadas que pedían a
gritos seguir funcionando, aunque no cumplieran con las restricciones impuestas. Pos-
teriormente, hubo un nuevo intento, todavía más restrictivo: XHTML 2.0. Este ni si-
quiera vio la luz como recomendación final, ya que se produjo un claro desacuerdo
entre los partidarios de que las páginas que no lo cumpliesen dejasen de funcionar y los
más pragmáticos, que abogaban por una "política de hechos consumados". Más de la
mitad de las páginas existentes hubiesen dejado de mostrarse correctamente (o incluso,
incorrectamente: no se hubieran mostrado en absoluto).
Por fin, hace unos 4 años, se produjo un nuevo intento de unificar las fuerzas en
busca de algo nuevo, que no cayese en los errores o problemas anteriores, y que se
hiciese eco de los nuevos requisitos que tiene la Web de hoy día. Se reanudaron los
contactos, se empezó a detectar un interés de toda la industria en una renovación, y las
empresas más importantes del mundo acordaron participar en el nuevo proyecto.
No aburriré al lector con estadísticas detalladas, pero se anuncia que —en bre-
ve— el 50% del tráfico de la red, corresponderá a vídeos. Además, el número de páginas
existentes ya supera al de los habitantes del planeta y la gran mayoría de ellas siguen
basándose en el viejo estándar (que, a su vez, tiene por núcleo principal lo ya establecido
a primeros de los 90). Y veinte años son muchos años en Computación. La renovación
se hacía imprescindible.

El problema de las fechas de terminación

El problema principal a la hora de construir algo tan universal como HTML 5,

es precisamente, ese: su universalidad. Tiene que haber consenso, tiene que servir
para todos, tiene que ser lo más sencillo posible y aportar novedades significativas…
en suma: se necesita una gran cantidad de tiempo para poner todas las fuerzas en fun-
cionamiento, cubrir todos los aspectos, realizar los paquetes de pruebas suficientes
que aporten una garantía a lo que se aprueba, etc… Y el resultado —a primera vis-
ta— parece desalentador: la fecha prevista para la terminación definitiva supera el
año 2020 (aunque, recientemente, se ha dicho que esa fecha se rebajará, incluso hasta
2014).
¿Qué sentido tiene entonces hablar de algo tan lejano de su terminación? Según
Cotton, el estándar podrá estar totalmente operativo a comienzos de 2013 y, aunque la
versión final candidata, —la llamada Candidate Recommendation— no se termine
página

18
 Introducción >>

de forma oficial hasta mucho después, el "corpus" principal del estándar debe estar listo
—e implementado en los navegadores— mucho antes.
De hecho, la mayoría de los navegadores modernos ya lo implementa en buena
parte y cada nueva versión aporta mayor compatibilidad. Esa es una de las razones por
la que la política de actualizaciones en los navegadores ha sufrido un acelerón tan notable
en los últimos tiempos.
Por otra parte, existen librerías para resolver las posibles incompatibilidades en el
caso de navegadores más antiguos, simulando ese comportamiento, o bien aportando
algo que se ha dado en llamar fallback: una salida alternativa cuando las cosas no van
exactamente como se pensaba, o no existe soporte de una característica por parte de un
navegador dado.

La recomendación actual por parte de los fabricantes, dado

nota

el soporte desigual del estándar es, que —cuando se quiera

implementar una característica nueva— se compruebe el so-
porte de esa característica, y no la versión del navegador: una
práctica muy extendida en la Web.

En las referencias finales de esta obra añadimos un bloque de enlaces a algunas de

las más utilizadas en la actualidad. Algunas, como Modernizr, tienen por objetivo,
precisamente, facilitar la detección del soporte de las nuevas opciones, facilitando la
labor de los desarrolladores.

Los navegadores y el estándar: IE10 como objetivo

No hace mucho, Dean Hachamovitch, jefe del equipo de desarrollo de Internet

Explorer hablaba de muy altos porcentajes de implementación en la nueva versión IE10,
que verá la luz junto al nuevo Windows 8. De hecho, la versión IE9 ya soporta una
buena parte de la especificación en su estado actual. Faltan cosas, y hay otras pendientes
de definir, pero, entre tanto, ya podemos aproximarnos a la parte principal de lo que
va a ser HTML 5, gracias a las implementaciones que los fabricantes de navegadores
están haciendo ahora mismo. Y lo mismo puede decirse de Chrome, FireFox y Opera.
Con esta situación se plantea un curioso reto (que no se había dado hasta ahora):
saber quién es el que mejor "hace los deberes". De momento, IE9 parece aplicado,
página

19
<< Introducción

pero, su sucesor quiere ser el primero de la clase. En las demos de

IE10 Consumer Preview realizadas en eventos como Tech-Ed 2012,
IE10 le daba "sopas con honda" a sus competidores, en lo referente
al motor de interpretación de JavaScript (Chakra), jugando con
elementos visuales, si bien, le falta todavía madurez al tratarse de
una versión beta. La versión para HTML 5, que ya está presente
en la versión Release Preview de Windows 8, no solo es la más rá-
pida, sino que incluye un nivel de soporte de HTML5 y CSS3 sin
precedentes.
Porque, cuando hablamos de nivel de soporte, nos referimos
a los 3 pilares que dan estructura al estándar, y el soporte de los nuevos modelos pro-
puestos para las Hojas de Estilo, junto a las API de JavaScript se convierte en funda-
mental. Esta nueva versión de JavaScript, está siendo terminada de forma simultánea
por la entidad ECMA11 (grupo de trabajo TCI39), y a su motor de interpretación de
código hay que añadir un buen número de API que permitirán gestionar todos los as-
pectos necesarios no solo en los sitios Web actuales, sino en las aplicaciones web, tal y
como se conciben hoy día (Geo-localización, Web Sockets, Almacenamiento de sesión
y local, etc.).
Para tener una idea más exacta de la situación, probaremos las características más
importantes de HTML 5, CSS 3 y las nuevas API de JavaScript en todos los navegadores
populares en sistemas operativos Windows indicando (al momento de escribirlo), su
grado de soporte: IE9, IE10, Chrome, FireFox, Opera y Safari. Esto incluye el soporte
de la versión "Metro Style" de IE10, que solo puede usarse desde Windows 8. Por tanto,
algunas de las pruebas están realizadas desde Windows 7 Ultimate, y todas ellas, se han
probado en Windows 8 Release Preview.

Nuevas reglas del juego

El nuevo "motor" de interpretación de JavaScript (o ECMAScript, si se quiere),

llamado Chakra, ya ofrece un rendimiento excelente para IE9, y los demás fabricantes
están haciendo lo propio. Ese parece ser el juego. Pero, por primera vez, hay un árbitro
en él, que puede ser la W3C, que tiene la voluntad de establecer las reglas de ese juego.
Si esas reglas se cumplen, el futuro parece brillante: programar una vez, y tener el mismo

11
http://www.ecma-international.org/
página

20
 Introducción >>

figura 1 Modelo de integración de scripts

en IE9 basado en "Chakra"

resultado en todos los sitios (one markup). No importa el dispositivo de visualización,

e incluso un cambio de plataforma. La página o aplicación debería verse/funcionar exac-
tamente igual en cualquier parte.
En suma, la promesa universal de "programa una vez y consúmelo donde quieras",
que —los veteranos como yo— hemos escuchado tantas veces en 25 años de historia
práctica de la informática. Solo que esta vez, podría acercarse mucho a la realidad.
Se dan los medios para ello. Existe la tecnología, la voluntad de los fabricantes de
seguir el estándar y la posibilidad de que los navegadores aprovechen al máximo el hard-
ware de la máquina para una nueva experiencia de usuario mucho más rica en rendi-
miento y en posibilidades.

Los navegadores antiguos

¿Y los viejos navegadores? Esa es la cuestión. Los navegadores antiguos no soportan

nada de esto y solo las últimas versiones dan cobertura de conjuntos más o menos com-
pletos de HTML 5. Por suerte, como hemos apuntado antes, hay una solución.
Conscientes de esta necesidad, las empresas y muchos desarrolladores indepen-
dientes están generando cada vez más librerías que simulan mediante JavaScript el com-
portamiento del estándar para ellos. Al final de esta obra, hacemos una recopilación de
los más atractivos y que más implantación están teniendo en la comunidad. En cualquier
caso, será el programador Web el que tiene que decidir qué características le interesan
persistir "hacia atrás", y qué necesita incluir para dar ese soporte de compatibilidad o
fallback, que indicábamos antes.
página

21
<< Introducción

Los objetivos del estándar en la práctica

Cotton era bastante claro a la hora de sintetizar los objetivos de estos esfuerzos de uni-
versalización: conseguir la Plataforma Web Abierta (Open Web Platform). En el camino,
esto puede desglosarse en una serie de objetivos más sencillos y específicos. Voy a per-
mitirme añadir una lista de algunos de los que los responsables parecen subrayar en sus
intervenciones públicas:

• HTML 5. Un nuevo lenguaje de marcado que recoja las necesidades actuales:

audio y video, nuevo sistema de gráficos y animaciones, etiquetas semánticas
que colaboren con los robots SEO, unificación de criterios y eliminación de
etiquetas redundantes, compatibilidad hacia atrás, y sobre todo el aspecto del
consenso que ya hemos citado.

• CSS 3. Un nuevo lenguaje de definición de estilos, coherente con el de marcado,

que coopere con el anterior a la hora de facilitar la separación del contenido de
la presentación e, igualmente, recoja las necesidades actuales.

Como objetivo secundario, está claramente el de ofrecer alternativas a soluciones

de tipo gráfico y dinámico que solo podían ser resueltas mediante complementos
(add-ins del tipo Flash o Silverlight). Por ejemplo, las aplicaciones Windows 8
hacen uso extensivo de estas capacidades.

• ECMAScript-262 5ª Edición. El nombre JavaScript es más un apodo que un

nombre real (canónico, diríamos). Inicialmente, se llamó LiveScript, aunque,
posteriormente, por una decisión estratégica entre Netscape y Sun MicroSystems
pasó a llamarse así. Por otro lado, la entidad de estandarización de JavaScript es
ECMA (European Computers Manufacturers Association)12, y la especificación "ofi-
cial" de JavaScript no es otra cosa que el estándar ECMA-262, que vio su primera
versión en 1997, aunque no fue hasta 1999, cuando se publicó la 3ª Edición, y
comenzó su adopción de forma masiva. A partir de ahí, los que lo han imple-
mentado han construido diversas variantes del lenguaje, aunque la proliferación
ha hecho una gran labor de unificación en los últimos años. Por si esto fuera
poco, la 4ª edición se abandonó por diferencias políticas en la forma de imple-

12
http://www.ecmascript.org/
página

22
 Introducción >>

mentación. Así que, buena parte del trabajo realizado para esa versión 4 (el que
disfrutaba de un mayor consenso) ha pasado a formar parte de la nueva edición.

La idea de conseguir una nueva versión del lenguaje

JavaScript que funcione paralelamente con HTML
5 y CSS 3, que incluya ciertas novedades, y mejore
otros aspectos ya en uso, como la notación JSON,
es uno de los objetivos de este esfuerzo colectivo.

El pasado año (junio/2011), ECMA anunciaba la

aprobación de la 5ª edición de su estándar que está disponible para descarga
como documento PDF13. Los anexos D y E de dicho documento incluyen po-
sibles aspectos de esta versión del lenguaje que podrían tener un impacto de
cara a la compatibilidad con versiones anteriores.

Además, los test requeridos para su validación se realizan de forma independiente

en otra entidad, la TC39 (o Ecma Technical Committee 39), que dispone de un
sitio dedicado14 en el que cualquiera puede colaborar si lo desea.

Motores de JavaScript

El motor de interpretación de JavaScript es algo delicado, porque —estando

hecho independientemente por cada fabricante— debe respetar el estándar de
la misma forma. Existen más de una docena de motores implementados en soft-
ware diverso, de los cuales solo 7 incluyen compilación JIT (Just-In-Time), lo
que les hace mucho más adecuados para la optimización del rendimiento y el
aprovechamiento del hardware de la máquina: Carakan (Opera), Chakra
(IE9/IE10), V8 (Chrome), SpiderMonkey (Firefox), SquirrelFish —o Me-
tro— (Apple WebKit), JavaScriptCore (Safari) y Tamarin (Adobe Flash).

• Las API relacionadas. HTML y sus tecnologías no aportarían mucho al

objetivo de construir aplicaciones basadas en el estándar si no fuera por la
presencia de API que aporten lo que ningún lenguaje de marcas o definiciones

13
http://www.ecma-international.org/publications/standards/Ecma-262.htm
14
http://test262.ecmascript.org/
página

23
<< Introducción

puede aportar. Y esto se resume, sobre todo, en la gestión del estado de las apli-
caciones, la geo-localización, las aplicaciones off-line, las comunicaciones dúplex,
el almacenamiento local y de sesión, el acceso a una base de datos sencilla, el
soporte de tareas asincrónicas, etc.

Como hemos apuntado, dichas tareas no están siendo abordadas por la W3C
directamente. Ellos, más bien, sirven de coordinadores del trabajo, como explica
Paul Cotton en su entrevista. La buena noticia es que se han establecido ya
claramente cuáles van a ser las más importantes, y las que formarán parte de la
versión final, y cuales no (por ejemplo, WebSQL se ha abandonado a favor de
IndexDB).

Conviene distinguir las API del lenguaje en sí, aunque la

nota

forma de programarlas sea mediante JavaScript. Las API

definen objetos que pueden usarse en conjunción con ele-
mentos del DOM (Modelo de Objetos de Documento)
para completar su propuesta funcional o crear mecanismos
complementarios.

Por ejemplo, el atributo type de la etiqueta <input> ahora dispone de un conjunto

nuevo de valores posibles, como: email, tel, date, time, etc. Podemos usar un API asociada
programable en JavaScript para validar dichas entradas, o podemos simplemente pro-
gramar su atributo required para que, si el usuario no introduce un dato en este campo
de formulario, reciba una notificación personalizada.
De igual forma, hay escenarios cuya programación requiere esencialmente de có-
digo JavaScript, como sucede en procesos de comunicación donde existe suscripción a
eventos o comunicación dúplex con servidores.

Librerías y lenguajes que compilan a JavaScript

Ante la perspectiva de esta nueva Web de sitios y aplicaciones, se está dando un

renacimiento del lenguaje JavaScript que, con todas sus carencias, es uno de los lenguajes
más utilizados del mundo, precisamente por su presencia en la red. Esas carencias están
provocando la ascensión y adopción popular de librerías complementarias, como
jQuery15, que facilitan muchísimo el uso de JavaScript, así como de otras que comple-
página

24
 Introducción >>

mentan carencias de navegadores antiguos, o facilitan la inclusión de elementos de in-

terfaz de usuario más actuales (como Kendo-UI, de Telerik), y muchas más.
Pero uno de los movimientos más interesantes, está sucediendo en el apartado de
los llamados "Lenguajes que compilan a JavaScript". Se trata de herramientas y/o len-
guajes que incorporan notables mejoras en lo operativo y lo sintáctico, y que finalmente,
generan código JavaScript tal y como sucede con la propuesta de Google respecto a su
lenguaje propietario Dart, del que ya existe un sitio Web oficial16). Existen muchos len-
guajes para los que se dispone de esta posibilidad: Objective-C, Ruby, Python, Perl,
Java, Scala, C#, Lisp, oCaml, Haskell, SmallTalk, C/C++, Basic, Pascal, Multitarget,
CoffeeScript y otros. De todos ellos podemos encontrar versiones actualizadas, por lo
que si el lector piensa abordar una aplicación con abundancia de código final en JavaS-
cript, un vistazo a los posibles candidatos no estaría de más17.
En concreto, dentro del marco de .NET, disponemos de librerías como JSC, JSIL,
Prefix o Script#. Salvo esta última, las 3 primeras son gratuitas. Muchas de estas he-
rramientas permiten plantear problemas en nuestro lenguaje favorito .NET (suelen so-
portar VB.NET, C# y F#), y generar posteriormente un código fuente en JavaScript,
que puede funcionar en cualquier navegador (al menos, a priori).
Otros funcionan sobre ensamblados, siendo capaces de crear librerías JavaScript
a partir de librerías (DLL) en .NET. En el capítulo 2 incluiremos referencias a éstas y
otras posibilidades.

¿Por qué no esperar a que el estándar esté terminado?

Terminado o no, los fabricantes están incorporando el soporte, dado que la posi-
bilidad de consumir servicios de la nube mediante una sola programación es muy atrac-
tivo y promete abundantes ingresos. Y esto es válido con un énfasis especial en los 5
navegadores más populares: IE, Firefox, Google Chrome, Safari y Opera.
Así que se trata también de una decisión estratégica. Podemos migrar nuestros
sitios a HTML 5 ahora mismo, y empezar a aprovechar sus posibilidades. Las librerías
de compatibilidad, y las otras opciones apuntadas, consiguen que los navegadores
antiguos comprendan el modelo (casi) de igual forma, y de esa manera, estaremos pre-

15
http://jQuery.com
16
www.dartlang.org
17
Puede encontrar una completa lista de las opciones disponibles y sus enlaces asociados en la página
http://bit.ly/goZv7i
página

25
<< Introducción

Como comentaremos más adelante, la apuesta por el es-

nota
tándar de algunos fabricantes, como Microsoft, es tan fuerte,
que Windows 8 puede programarse directamente mediante
éste nuevo estándar. Hablaremos más de ello en éste capí-
tulo.

parados para las evoluciones futuras y podremos aprovechar sus características globales.
Y hay otras ventajas adicionales.
De cara a los buscadores, la precisión con la que éstos pueden encontrar nuestras
páginas debido a las características semánticas, será muy superior. Podremos utilizar
jQuery para enriquecer las páginas, obteniendo un buen rendimiento gracias a los
nuevos motores y no precisaremos de ningún añadido adicional si lo que queremos es,
simplemente, mostrar un vídeo o reproducir una animación, por ejemplo.
Y contamos con otra consideración a favor de la adopción inmediata. Las herra-
mientas de desarrollo que propondremos a lo largo de esta obra (Visual Studio 2012 -
o 2010 y las versiones Express), ya soportan la sintaxis de los estándares y podremos
encontrar un valor añadido en ellas (el nuevo Page Inspector de la versión 2012 es ex-
celente para el desarrollo con el estándar).

El sueño de una Web semántica

De esta forma, una de las promesas inherentes al nuevo
estándar es la de dar un paso más hacia el sueño de una
Web Semántica. Una Web con inteligencia, basada en el
significado y el contexto. El término se acuñó en 2001
como resultado de un artículo escrito por Tim Berners-Lee, que describía el término
como El lugar en el cual las máquinas pueden leer páginas Web con la misma facilidad con
la que los humanos lo hacemos. Algunos la denominan la Web 3.0.
Para poder profundizar algo más en estos términos, conviene antes recordar o
aclarar algún aspecto vinculado con ella.
página

26
 Introducción >>

Los Identificadores uniformes de recursos (URI vs. URL)

Si quiero hablar de algo, en primer lugar debo identificarlo. Puede hacerse de

manera indirecta: "La boca del metro", "El gato del garaje", o "Las cosas que le gustan
a Pepe". También podría elegir a ser más directo: "W3C", "Scott Guthrie" o "Mega-
juegos".
Para identificar elementos en la Web, también utilizamos identificadores. Se usa
un sistema uniforme de identificadores, y cada elemento identificado es considerado
un "recurso", así que llamamos a estos identificadores Identificadores uniformes de recursos
o URI para abreviar. Podemos asignar un URI a cualquier cosa, y cualquier cosa que
tenga un identificador URI puede decirse que está "en la Web": usted, el libro que com-
pró esta mañana, el último electrodoméstico, etc., todos ellos pueden tener un URI.
El identificador URI es el fundamento de la Web. Aunque se podría reemplazar casi
cualquier otra parte de la Web, no se podría prescindir de los URI: mantienen unida
toda la Web.
El lector ya está familiarizado con una de sus formas: la dirección URL o localizador
uniforme de recursos. Una URL es una dirección que le permite visitar una página
Web, tal como: http://www.w3.org/standards/webarch.
Al comienzo, vemos que una dirección URL le dice al navegador donde encontrar
un recurso específico (en este caso, el sitio Web de dirección del W3C, pero también
puede ser un gráfico, un archivo PDF o cualquier otro). A diferencia de otras formas
de URI, una URL identifica y localiza. Esto lo diferencia de la URI. La URI identifica
un mensaje de correo electrónico, pero no es capaz de localizar una copia del mensa-
je.
Como la Web es demasiado grande para controlarla, los URI están descentralizados.
Nadie en concreto controla quién los hace o cómo se pueden utilizar. Mientras algunos
esquemas URI (como http:) dependen de sistemas centralizados (como DNS), otros
sistemas (como freenet:) están totalmente descentralizados.

URI y semántica

Ahora bien, como cualquier persona puede crear un identificador URI, inevita-
blemente acabaremos con varios identificadores URI que representan lo mismo. O lo
que es peor: no habrá ninguna forma de averiguar si dos identificadores URI apuntan
exactamente al mismo recurso. Por lo tanto, nunca podremos decir con certeza lo que
significa un URI concreto. Se precisan soluciones de compromiso para crear algo tan
enorme como la Web semántica.
página

27
<< Introducción

Un URI no es un conjunto de direcciones diciendo a

su equipo como llegar a un archivo específico en la Web (aun-
que también puede hacerlo). Es un nombre de un "recurso"
(algo). Este recurso puede o no ser accesible por Internet.
Incluso podría darse el caso de que la URL tuviese un nombre
totalmente "oclusivo" pensado precisamente para ocultar su
auténtico contenido en vez de sugerirlo.
Así pues, un primer paso (que ya se está empezando a dar) es hacer que las propias
URL expliquen de la forma más clara posible cuáles son las palabras clave de su con-
tenido, diseñando nombres de página compuestos de lo que podríamos llamar palabras
clave de la página. Es un primer paso. Los siguientes, supuestamente, dependerán de
un buen uso de las nuevas etiquetas de HTML 5 en relación con el contenido que al-
bergan.
Por su parte, Wikipedia define la Web Semántica con las siguientes palabras: Se
basa en la idea de añadir metadatos semánticos y ontológicos a la World Wide Web. Esas infor-
maciones adicionales —que describen el contenido, el significado y la relación de los datos— se
deben proporcionar de manera formal, para que así sea posible evaluarlas automáticamente por
máquinas de procesamiento. El objetivo es mejorar Internet ampliando la interoperabilidad
entre los sistemas informáticos usando "agentes inteligentes". Agentes inteligentes son programas
en las computadoras que buscan información sin operadores humanos.
Nótese que he subrayado la palabra "añadir" entendiendo
que —para aquellos héroes que no tengan inconveniente en
rescribir su código— podríamos convertir con cierta facilidad
un sitio existente en un sitio con capacidades semánticas con
solo añadir unas etiquetas a la página, que, por otra parte no
son muchas, pero, como veremos a partir del Capítulo 3, ayudan
a estructurar los documentos de forma que los robots buscadores
"comprendan" las relaciones en las diferentes partes de un sitio
o un página completa y ofrezcan resultados más apropiados.
Son esos Agentes inteligentes que se mencionan en la definición.
Las propuestas iniciales -basadas en el estándar RDF—
no tuvieron demasiada acogida, y, una vez más, cabe la posibilidad de que una política
de "hechos consumados" llegue a buen fin, o al menos, a dar un paso importante en
esa dirección. Para ello, como veremos en el apartado de HTML, el nuevo estándar
propone una decena de etiquetas que son consideradas mejoras en las capacidades de
descripción del contenido, y por tanto, facilitarán los resultados coherentes en las bús-
quedas en un futuro cercano.
página

28
 Introducción >>

Especificaciones y pruebas de laboratorio

Microsoft se adhirió a esta filosofía cuando creó

el eslogan Same Markup, una idea del equipo de IE
pergeñada durante el desarrollo de IE9, que pretende
ser una propuesta a favor de la simplificación del des-
arrollo web con un objetivo: que todo el código
HTML, CSS, JavaScript, etc., sea interpretado de
forma idéntica. Por otro lado, la forma en que se van
modelando las especificaciones a lo largo del tiempo puede dividirse en dos partes: la
teórica y la práctica.
Desde el lado teórico, es mediante la colaboración y las aportaciones de sus miem-
bros directos, que se encargan de sugerir ideas y también de revisar las contribuciones
y sugerencias de los participantes de carácter abierto, que son varios cientos en todo el
mundo18. No existen votaciones, sino consenso a la hora de aprobar o desestimar un
aspecto cualquiera del estándar. De esta forma, si un solo participante sugiere algo tec-
nológicamente válido y apropiado al marco del estándar, tiene muchos visos de ser acep-
tado, aunque haya partido originalmente de una sola fuente.
En total, hay más de 100 especificaciones agrupadas bajo el concepto (o la marca)
HTML5 y podrían incrementarse en el futuro antes de llegar al estado Last Call. Pen-
semos que, bajo este nombre, tienen cabida cosas relacionadas pero muy distintas, como
el código de marcado en sí (HTML), las hojas de estilo en cascada (CSS), el mecanismo
de representación gráfica vectorial (SVG), los motores de interpretación de JavaScript,
las API relacionadas y ya aprobadas o en fase de serlo, etc. Esto plantea un serio reto
respecto a las pruebas de funcionamiento.

Los test
Una vez identificados y aprobados inicialmente, con los materiales reunidos se procede
a testar el nuevo estándar en varias fases de pruebas. Internamente, la W3C dispone de
una herramienta denominada Bugzilla, con la que gestionan el estado de los bugs y su
situación respecto a la resolución.

18
En España, destaca el grupo de trabajo vinculado a la Universidad Politécnica de Madrid, con una docena
de miembros, bajo la dirección de la responsable de la Web Semántica en esta institución, Carmen
Costilla.
página

29
<< Introducción

figura 2 Todos los navegadores utilizados en las pruebas (IE9/10,

Chrome 14, Firefox 7, Safari 5.1 y Opera 11.5 pasan los test
ACID al 100%.

A partir de aquí, la W3C y sus entidades asociadas comienzan los test oficiales,
para los que utilizan una serie de herramientas propias, a la vez que coordinan iniciativas
individuales, "extraoficiales", con el propósito de elaborar cuadros de conformidad res-
pecto a las normas establecidas.

Los sitios alternativos de pruebas de conformidad

La validez de los sitios de pruebas que están fuera de los canales oficiales es más
que discutible, y algunas veces roza lo partidista o, simplemente, interesado. Por ejemplo,
algunas prueban aspectos que no están en el estándar, o dan la misma validez a aspectos
colaterales o parciales que a otros troncales de la especificación. De este corte, podemos
catalogar algunas propuestas como HTML5Test.com, que testea otros aspectos que no son
parte del estándar, o Caniuse.com, que no comprueba la implementación correcta de las
características sino solo su existencia.
Precisamente, teniendo en cuenta estas circunstancias, los creadores de uno de los
test privados más populares (los test ACID) han modificado recientemente algunos as-
pectos de estos test, para que resulten más acorde con las especificaciones oficiales. Tras
esas modificaciones, es interesante notar que todos los navegadores utilizados en esta
obra pasan estos test con un 100% de efectividad.
página

30
 Introducción >>

Los sitios oficiales

De cualquier forma, los test más serios de compatibilidad con el estándar son los que
provienen de sus creadores. En concreto, la página HTML5 Test Suite Conformance Results19,
realiza un test de compatibilidad para cada visitante indicándole el nivel de conformidad del
navegador elegido respecto a 7 grupos principales, y mostrando después un desglose de más
de 900 test, uno a uno. El lector puede probar este punto en la dirección indicada.
Además, para aquellos interesados o curiosos respecto a determinado aspecto del es-
tándar, existe una página de la propia W3C que permite realizar test individuales de una
sola característica (test harness), disponible en la dirección http://w3c‐test.org/html/tests/har‐
ness/harness.htm.
Por otra parte, desde la aparición de la versión Release Candidate de Windows 8, ya
disponemos de una versión del navegador IE10 muy próxima a la que será la final, y preci-
samente, Microsoft ha publicado casi simultáneamente un análisis de soporte del estándar
en comparativa con las versiones más recientes de los navegadores, estableciendo como fecha
el 1 de junio de 2012. El gráfico siguiente muestra los resultados del porcentaje de soporte
de ésta versión, en comparación con las versiones más recientes (a la misma fecha) del resto
de navegadores populares: Chrome, FireFox, Opera, Safari e IE9. Las diferencias pueden
apreciarse a primera vista, ya que, del total de test enviados, —en 7 categorías distintas— el
nuevo IE10 obtiene el 100% en 4 de ellas, el 99% en otras 2, y el 96% en la restante.
Como puede apreciarse en la figura 3, tomada del sitio oficial de test para IE20, en
estos momentos IE10 es el navegador que implementa el estándar HTML con mayor
nivel de fidelidad.

figura 3 Resumen de la evaluación de test del sitio dedicado de Microsoft.

19
http://w3c-test.org/html/tests/reporting/report.htm
20
http://samples.msdn.microsoft.com/ietestcenter/
página

31
<< Introducción

En esa dirección, además, se encuentra permanentemente actualizado un documento

indicando el estado actual de los test que se renueva con mucha frecuencia y establece el
número de test enviados para control, así como el número de ellos que los grupos de
trabajo del comité ha conseguido evaluar y han pasado las pruebas. En concreto, el HTML5
Testing Task Force Status, ofrece un resumen informativo como el de la figura 4.

figura 4 Documento de seguimiento del estado de los test oficial-

mente pasados con un resumen de los ítems que se consi-
deran aprobados y el total de pruebas enviadas.

Y, en general, para cualquier aspecto que el desarrollador necesite comprobar

sobre una característica o API del estándar, puede acudir a la página oficial de pruebas
(http://w3c‐test.org) donde encontrará toda la información adicional.

Las aplicaciones web y el nuevo modelo de aplicaciones

en Windows8
En el evento BUILD/2011, Microsoft presentó su nuevo modelo de aplicaciones vin-
culado con el sistema operativo Windows 8. Más recientemente, en los eventos Tech-
Ed de EE.UU. y Europa21, se ha ofrecido información más madura y concreta sobre la pro-

21
http://europe.msteched.com/
página

32
 Introducción >>

gramación para esta nueva plataforma. Las implicaciones son de amplio

calado, y no vamos a profundizar aquí en el tema, pero si me gustaría
recalcar algunos aspectos que afectan directamente a la utilización del
estándar en este modelo de aplicaciones.
Como el lector probablemente conocerá, la nueva interfaz de
usuario de Windows 8 es lo más llamativo a primera vista, ya que propone cambiar el pa-
radigma habitual que se ha estado manteniendo desde las primeras versiones de Windows
por uno nuevo, especialmente preparado para pantallas táctiles y se inspira totalmente en
la interfaz de usuario que presentó el sistema operativo para móviles Windows Phone 7.

Aplicaciones Windows 8

Para este tipo de aplicaciones se requerirá la programación mediante un nuevo

modelo de aplicaciones, en el que la parte de interacción manual con la pantalla del
usuario es fundamental, y se debe tener muy en cuenta en el desarrollo desde los inicios
del ciclo de vida de la aplicación.
En resumen, el nuevo sistema (que aparecerá a finales de octubre de 2012), propone

figura 5 Aspecto inicial de Windows 8 en ejecución mostrando la

nueva interfaz.
página

33
<< Introducción

dos tipos de aplicaciones: las tradicionales, que seguirán funcionando como hasta ahora
y las Windows 8 (ver figura 5), en las que se hace hincapié en una nueva forma de uti-
lización donde las pantallas son de tipo táctil, y una API llamada WinRT (Windows Run-
Time) provee a las aplicaciones de lo necesario para acceder a los recursos del sistema.
Se trata de una capa muy ligera que funciona por encima del kernel de Windows,
y tiene la particularidad de permitir a desarrolladores de diversos lenguajes un acceso
común y uniforme a esos recursos, independientemente de que provengan del mundo
.NET, de C/C++, o de HTML5 y JavaScript.

El nuevo modelo de aplicaciones Windows 8

Por tanto, se nos plantea un modelo de construcción de aplicaciones nuevo (con un
nuevo estándar de distribución a través de un MarketPlace o tienda on-line) que propone
un esquema conceptual como el que vemos en la figura 6.

Como se ve en el diagrama, la capa WinRT alberga varios grupos de librerías, or-

ganizados

figura 6 Plataformas de desarrollo y herramientas para Windows 8.

por criterios de funcionamiento (Datos y comunicaciones, Gráficos y Multimedia y Dis-

positivos e Impresoras). Todas las aplicacione Windows 8, se construyen mediante el nuevo
modelo de aplicaciones (Application Model) que accede a la capa WinRT para obtener
página

34
 Introducción >>

recursos del sistema operativo. Es lo que vemos en el gráfico en la parte inferior de la zona
verde, y que se agrupa como System Services (a la izquierda, en vertical).
Por encima tenemos los controladores de modelo (Model Controllers), o sea, los
motores de ejecución y las API en las que nos apoyaremos para crear este tipo de apli-
caciones, dependiendo de la opción de lenguaje escogida.
Finalmente, en la capa superior, de esta zona verde (o zona Windows 8), bajo el
epígrafe "View", es donde aparecen los diversos lenguajes, y vemos 3 opciones dispo-
nibles: HTML y CSS, XAML/DirectX con C/C++ y XAML con .NET.

La posición de Silverlight y Flash en Windows 8

Advierta el lector que Silverlight no aparece en esta área, y —de hecho— está expre-
samente vetado ya que no se podrán ejecutar complementos desde el navegador (ni Sil-
verlight, ni Flash), ni se podrán ejecutar aplicaciones OOB en este contexto.
¿Significa eso que nuestras inversiones anteriores no serán válidas? En absoluto.
Como apreciamos en el gráfico, la zona azul se reserva para la ejecución de todas las
aplicaciones anteriores, y ahí tiene cabida Silverlight, igual que cualquier otra aplicación
realizada en .NET, C/C++, o incluso, HTML5 y JavaScript, que —como vemos— se
encuentra en ambos lados del diagrama.
Adviértase también que —no estando Silverlight ni WPF específicamente indicados
en la zona verde— XAML se convierte en un modelo común para la construcción de
interfaces de usuario, tanto para aplicaciones basadas en .NET como para los desarro-
lladores de C/C++, si bien éstos pueden usar igualmente DirectX.
O sea, que nuestra inversión previa en aprendizaje, código generado, librerías cor-
porativas, etc., se encuentra garantizada por esta arquitectura con mínimos cambios.
En caso de preferir continuar con las aplicaciones tradicionales de escritorio, o simple-
mente, instalar o mantener aplicaciones tradicionales, nos moveremos en la "zona azul",
donde todo lo presente hasta ahora sigue apareciendo, y para lo que el sistema garantiza
un funcionamiento transparente.

WinJS y los controles "de fábrica"

Respecto a esta diferencia en los tipos de aplicaciones, la división parece nacer de

una separación conceptual que no se había dado mucho hasta ahora, y que consiste en
separar totalmente las aplicaciones de gestión, de las "aplicaciones Internet". Éste último
modo se recomienda especialmente para el modelo de aplicaciones web (que no sitios
página

35
<< Introducción

web), que emularán la funcionalidad de las clásicas,

pero ejecutándose desde el navegador, y apoyándose
en las nuevas API del estándar HTML 5.
Ahora bien, para que este modelo de aplicacio-
nes web funcione, se requiere un mecanismo que
comunique el código JavaScript, interpretado por
el motor Chakra, con la capa WinRT y ahí es donde
aparece un nuevo protagonista: WinJS. WinJS (o
Windows desde JavaScript) es la librería para cons-
truir aplicaciones tipo Windows 8 con JavaScript.
Esta librería, facilita el diseño de estas aplicaciones y dispone de controles para las
llamadas "experiencias comunes de desarrollo", estando diseñado, tanto para aplicaciones
táctiles como para introducción de datos tradicional, además de ser muy escalable. Con-
tiene un enorme conjunto funcional pensado a tal efecto: animaciones, plantillas, utili-
dades, estilos CSS predeterminados, controles, mecanismos de binding, modelos de apli-
cación, gestión de la navegación, fragmentos, promises (para procesos asíncronos), y un
largo etcétera. Como muestra de los controles predeterminados véase la imagen siguiente
(figura 7).
De forma que WinJS es la librería que tiende el puente con WinRT para llamar

figura 7 Los controles para uso con JavaScript disponibles en el IDE

de Visual Studio/Blend
página

36
 Introducción >>

a las API necesarias del sistema. De hecho, cuando desarrollamos una aplicación Win-
dows 8 con JavaScript, así se llama el espacio de nombres que nos da acceso a WinRT.
Si el lector descarga la versión Windows 8 Consumer Preview, e instala la versión
gratuita por tiempo limitado de Visual Studio 2012, podrá iniciarse en la construcción
de aplicaciones de esta clase. Un vez instalado, en la opción "Nuevo Proyecto", veremos
cómo Visual Studio nos ofrece un paquete de opciones de diversas plantillas preinstaladas
—a su vez— separadas por categorías, como podemos ver en la figura 8.
Si optamos por una de ellas, por ejemplo la de Geo-localización, veremos que nos

figura 8 Tipos de plantillas de proyecto asociadas a JavaScript dentro

de Visual Studio 2012

construye una aplicación básica de tipo Windows 8, que incluye las características de
esta API. Y, si accedemos al archivo que contiene el punto de entrada de la aplicación
(program.js), veremos código similar al del listado 1.
Donde advertimos la llamada de inicialización de la aplicación, de forma similar a lo
que los desarrolladores de .NET estamos acostumbrados en las llamadas a InitializeCom‐
ponent() de las clásicas aplicaciones .NET. Se trata ya de aplicaciones programadas bajo el
nuevo estándar, que hacen uso de los 3 pilares principales: HTML5, CSS3 y JavaScript.
Si observamos el Explorador de soluciones, veremos que, en "References", aparece
la librería Microsoft Windows Library for JavaScript SDK, que es la que se utiliza para
página

37
<< Introducción

function initialize() {
WinJS.Application.start();
WinJS.Application.addEventListener("checkpoint", applicationStateCheckpoint, false);
WinJS.Application.addEventListener("activated", applicationActivated, false);

// Make the details container in the input panel selectable so

// that end‐developers can copy and paste the text
var detailsContainer = document.querySelector("#input .details");
if (detailsContainer) {
detailsContainer.setAttribute("data‐win‐selectable", "true");
}

Listado 1: Código JavaScript generado por Visual Studio 2012 que utiliza WinJS

el acceso a los recursos del sistema.

En el ejemplo que hemos utilizado, este paquete contiene realmente otros 4 archivos
JavaScript, especializados en distintas funcionalidades: base.js, base.strings.js, ui.strings.js
y ui.js: algunas sirven de fundamentos para la construcción y acceso a los recursos del
sistema, y otras son específicas de ciertas operaciones, como las relacionadas con la IU.
El resto de archivos de la aplicación contiene la pantalla principal (default.html),
la versión WinRT de los archivos .manifest de configuración y unas hojas de estilo para
manejar los aspectos de presentación en pantalla. La figura 9 presenta la vista del Ex-
plorador de soluciones para una aplicación de esta clase sin modificar.

La división granular de JavaScript

El usuario acostumbrado a otros tipos de aplicaciones seb, como MVC4 o Web

Forms, quizá se sorprenda de la cantidad de "pequeños ficheros" JavaScript que la apli-
cación ubica, de inicio, en distintos directorios de la solución.
Esto tiene que ver con una nueva característica presente en MVC 4: bundling and
minifying, que permite compactar todos los archivos JavaScript en uno solo, eliminando
los espacios y reduciendo el número de peticiones al servidor, así como el tiempo de
carga.
La razón de tanta granularidad es la nueva opción de JavaScript 5 llamada Strict
Mode. Con el uso de esta modalidad, JavaScript 5 aporta interesantes novedades y
modos de programación más acordes con las buenas prácticas presentes en otros
lenguajes.
página

38
 Introducción >>

Pero hay un problema. Si un solo fichero de esta clase declara el uso de esta mo-
dalidad fuera de una función, al producirse el empaquetado, todos los demás van a
asumir la interpretación estricta de forma automática, lo que podría desembocar en
comportamientos no deseados. Mediante la granularidad se minimiza este efecto.

Ejecución y soporte del estándar

figura 9 Librería JavaScript del SDK

para Windows 8 desde Visual
Studio 2012

La aplicación compila y se ejecuta correctamente. Se trata de aplicaciones sin ven-

tana (pantalla completa), que podemos manejar también con el ratón, a parte de las po-
sibilidades de uso de pantalla táctil que hemos apuntado antes. La salida de esta aplicación
una vez otorgado el permiso para ver los datos de geo-localización, es la que se corres-
ponde con la figura 10:
Como se ve en la zona azul del esquema de los modelos de aplicación que hemos
apuntado antes, también se dispondrá de un triple modelo para construir aplicaciones

figura 10 Salida de la aplicación

estándar de geolozalización
en Windows 8 Consumer
Preview.
página

39
<< Introducción

tradicionales o de escritorio en Windows 8. Si bien, en este caso, no se precisa WinRT

y será el motor propio de IE10 el encargado de gestionar su ejecución.
Como era de esperar, el soporte de JavaScript en Visual Studio 2012 ha sido me-
jorado notablemente, para hacer que la experiencia de desarrollo sea lo más similar a
lo que los desarrolladores de .NET estamos acostumbrados. Hablaremos con más detalle
de esto, en el siguiente capítulo, dedicado a las herramientas de desarrollo y depuración
con el estándar.

Los motores Chakra y los dos contextos de ejecución

A la vista de los dos tipos de aplicaciones y las dos formas de ejecución, parecen
surgir ciertas discrepancias o imprecisiones respecto a los motores de HTML5/JS que
aparecen repetidos en ambos lados del diagrama. En realidad, no es así. Simplemente,
si queremos que una aplicación HTML5/JS se ejecute como una aplicación Windows 8,
utilizaremos las librerías de WinJS. Si no queremos depender de Windows 8, y deseamos
una ejecución universal en cualquier tipo de plataforma y dispositivo, utilizaremos el
motor del navegador correspondiente.
Y el encargado de esa interpretación en I.Explorer es una versión renovada del
motor Chakra actualmente en uso en IE9. Chakra (cuyo modelo funcional vemos en
la imagen adjunta), es el nombre del motor de JavaScript/DOM altamente optimizado
que Microsoft introdujo en su navegador Internet Explorer 9 y que ha seguido evolu-
cionando desde entonces.
Está presente ahí y lo estará independientemente en la versión IE10 de Windows
8 (en sus dos versiones, Windows 8 y Desktop). Los test realizados sobre Chakra lo

figura 11 Esquema operativo del motor de JavaScript Chakra

para IE9/10
página

40
 Introducción >>

ponen a la cabeza de todos los motores existentes, ofreciendo un rendimiento sin pre-
cedentes en este tipo de aplicaciones, y un altísimo nivel de soporte de las API de Ja-
vaScript 5.
Así pues, este es el panorama que se nos presenta respecto al desarrollo con HTML
5. Muchas de las demos realizadas en los últimos eventos de desarrolladores (BUILD,
Tech-Ed, etc.) estaban hechas utilizando estos recursos y ofrecían un rendimiento ex-
celente en todas las máquinas utilizadas. Por otro lado, se comentaba que los cambios
que habría que realizar para que una aplicación HTML5 funcionase con el nuevo modelo
serían mínimos en un principio, y una aplicación hecha así, podría siempre extenderse
al nuevo sistema con poco esfuerzo.
Al lector interesado, le recomendamos una visita a los sitios Web de los eventos
de desarrollo de Microsoft indicados antes, si quiere acceder a vídeos explicativos de la
forma en que se van a construir estas nuevas aplicaciones.

Hablando sobre el estándar: la opinión de un protagonista

Para concluir este capítulo y dar al lector una idea práctica de lo que algunos respon-
sables vinculados con la construcción y la promoción del estándar piensan, nada mejor
que sus opiniones en vivo. Presentamos una entrevista que realizamos a uno de los
responsables directos de la creación de HTML 5: Paul Cotton, a quien, aprovechando
su paso por Madrid, pudimos interrogar acerca de su trabajo dentro del World Wide
Web Consortium (W3C). Paul ha trabajado en IBM, en las Naciones Unidas (en
calidad de embajador) y, en la actualidad, como experto en lenguajes de marcas, re-
presenta a los grupos de trabajo de Microsoft que están colaborando en la confección
del estándar.

Entrevista con Paul Cotton

A continuación transcribimos el contenido completo de la entrevista concedida a dNM.

Estamos en el Hotel Ritz de Madrid, con Paul Cotton. Es una de las personas al cargo del
W3C HTML5 Working Group en relación con Microsoft. Nos gustaría comenzar esta en-
trevista con una primera pregunta en relación con la participación de Jean Paoli en el estándar
XML. Si no recuerdo mal, esa fue la primera aproximación de Microsoft al trabajo en la
página

41
<< Introducción

elaboración de los estándares de la Web. ¿Qué puedes comentarnos al respecto?

Sí. De hecho, yo trabajaba con IBM cuando empezaron los trabajos con XML.
Trabajaba con bases de datos, y añadir capacidades de
notación de datos estructurados se ha demostrado que
ha sido un área muy importante. Así que Jean (y Tim
Bray, al que citabas antes de la entrevista, y al que co-
nozco personalmente, porque los dos somos cana-
dienses y hemos trabajado en el área de HTML) y yo
en esa época fue cuando empezamos a colaborar con
la W3C. Luego yo continué para dirigir el grupo de
trabajo de XML Query.
Y pienso que esa es una característica importante
de W3C. Reúne a muy diversas comunidades: la in-
dustria, la academia, etc. Hoy tenemos las mismas circunstancias que entonces.
Todas las áreas de la industria están implicadas, pero también hemos invitado a
expertos independientes, desarrolladores Web, expertos en Accesibilidad, etc.
Así que pienso que lo que dices es justamente la situación: reunir esas distintas
comunidades juntas es un aspecto muy importante para ganar interoperabilidad.
Y esos primeros contactos sembraron lo que HTML5 puede ser al día de hoy.

¿Qué sucedió con XHTML 2.0? ¿Era demasiado ambicioso o demasiado inaceptable, en
términos de compatibilidad hacia atrás?

¿Sabes? Cuando hablo sobre interoperabilidad y estándares, soy un tanto darwi-

niano. Y cuando hablamos de especificaciones técnicas, a veces pienso que sucede
como en la evolución. Tenemos muy buenas ideas, pero unas sobreviven y otras
no. Existen como dos grandes corrientes en W3C: los interesados en los navega-
dores y los del grupo de XML y derivados. Y, de alguna forma, se disgregaron en
direcciones distintas. Algunos pensaron que debido al éxito de XML, ese era el
camino a seguir con la Web, igualmente.
Y creo que es justo decir que W3C, quizás, cometió un error, concentrando
tantos recursos en torno a XHTML, y no apareció una nueva versión de HTML
durante bastante tiempo.
Pero, hace unos 4 años, que W3C decidió que los esfuerzos debían dirigirse
hacia este nuevo estándar HTML5, algunos de los que habían abandonado la W3C
regresaron y ahora, tenemos de nuevo la comunidad completa reunida, porque lo
que apuntabas antes es precisamente la fuerza de W3C: reunir a la comunidad en
página

42
 Introducción >>

torno a un esfuerzo común. Una vez que se consiguió esto, el proyecto entero flo-
reció de nuevo.
Los recursos de la W3C son limitados y decidieron concentrarse en lo que
se llamó más tarde Plataforma Web Abierta (Open Web Platform), que incluye
HTML 5 y otras especificaciones. De hecho, en la actualidad se pueden publicar
webs utilizando la compatibilidad de ambos formatos. Nosotros lo llamamos el
"formato políglota".

En un interview previo, con Philippe Le Hégaret, mencionaba usted que, en ocasiones, el

público en general se refiere a HTML 5 e incluye especificaciones que no van a ser estan-
darizadas. ¿Es esa la situación actual?

Es una pregunta muy difícil. HTML5 es una "marca" o un nombre que no se en-
tiende realmente muy bien. Yo pertenezco al grupo de trabajo principal del estándar
de HTML5 pero no puedo olvidar que no se hacen sitios web sin CSS, y otras
API que se están desarrollando actualmente en otros grupos de trabajo. Lo que
trataba de subrayar es que van a existir un número creciente de especificaciones
adicionales.

Y creo que es importante que los desarrolladores tengan presente que no

figura 12 Esquema de funcionamien-

to de Web Sockets (fuente:
Websockets.org)

todas las especificaciones se hacen en la W3C. Un ejemplo perfecto de esto es

Web Sockets, que es —probablemente— una de las partes más innovadoras de
HTML5. Permite comunicaciones tipo dúplex entre cliente y servidor, mientras
HTTP hoy es solamente del cliente a servidor, realmente. Pero el protocolo de
trabajo con Web Sockets, se está realizando en ITF22. En W3C solo se trabaja en
página

43
<< Introducción

la especificación del API.

Pero, incluso más importante, es lo que nosotros llamamos estabilidad. Y
HTML 5, en el momento actual, no se ha llegado todavía a lo que llamamos "Last
Call" (última llamada). Algunas partes ya son más estables, y ya se encuentran im-
plementadas en distintos navegadores, pero otras son muy recientes. Así que pienso
que lo realmente fundamental no es qué partes forman el estándar en su estado
actual, sino lo estables que resultan hoy día.

Algunas veces, cuando no hay un consenso claro, la W3C tiene que decidir de acuerdo con
algo que llaman la "Decision Policy". ¿Existe una votación? Y, de ser así, ¿cuán democrática
resulta esa política de decisiones?

Es una pregunta interesante, porque, cuando los Ayuntamientos toman decisiones,

por ejemplo, de que van a construir una nueva carretera, si hay una votación de 7
a 4, digamos, la propuesta se acepta. La W3C, en el espíritu de su fundador, Tim
Berners-Lee, que sigue siendo hoy día el director, es una organización de consenso.
Lo que significa tratar de encontrar la solución que produce el menor rechazo po-
sible. Y esa política de decisión a la que te referías, es un intento de manejar un
grupo de trabajo de más de 400 personas, de los que algunos son muy activos y
otros no tanto.
Así que es importante para nosotros disponer de una política que establezca
con claridad cómo tratar los bugs, y otros problemas detectados, y esa política nos
lleva a solicitar cambios, renovaciones y otras soluciones alternativas. Y hacemos
consultas on-line, a las que cualquiera puede responder. Y todos los rectores del
grupo tenemos muy claro que —cuando buscamos el consenso— no contamos
votos, sino que nos fijamos en la fuerza de los argumentos técnicos que se esgrimen.
De forma que, es posible, que alguien ofrezca una razón poderosa por la que
alguna parte de la especificación deba ser abandonada, y que sea la única persona
en hacerlo, pero si, como digo, sus razones están muy claramente razonadas, el
grupo director lo va a tener muy en cuenta. En realidad, es una de las partes más
difíciles de trabajar en W3C, y es una de las razones por las que somos 3 personas
con diferentes historiales laborales y formativos.
Uds. disponen de una herramienta llamada Bugzilla, que supuestamente les ayuda a llevar
el control de los bugs y otros errores que se van detectando. Esos errores son conceptuales,

22
Se refiere a Imec Technology Forum, que días antes había celebrado una reunión internacional en
Bélgica. Para más información ver http://www2.imec.be/be_en/education/conferences/itf2011.html
página

44
 Introducción >>

prácticos, o resultado de los test. ¿Cómo manejan este aspecto?

Sí, utilizamos una herramienta que se llama Bugzilla, para permitir que la gente
pueda archivar los bugs. Y es parte de esa política de decisiones.
Y está abierta a cualquiera, en realidad. Así que, cuando lle-
gamos a la etapa Last Call, en una especificación, que es cuan-
do ha sido ampliamente publicada y comentada, tratamos esa
especificación como una beta de software.
Es muy fácil para cualquiera solicitar una cuenta para W3C, y poder dar de
alta nuevos bugs con esa herramienta. Nosotros consideramos esos bugs como parte
de la política de decisión. Uno de los 9 editores de las especificaciones de que
consta el estándar, estará encargado de "tratar" el bug de forma adecuada. Algunos
son muy fáciles de manejar (como los errores sintácticos), otros pueden estar so-
licitando una nueva característica, o cualquier otra cosa. La persona que envía el
bug recibe un e-mail, indicando que el bug ha sido procesado.
Y se puede producir un diálogo, en el que una tercera parte opina igualmente
sobre la resolución del bug, etc. Así que es un proceso bastante dinámico, y —en
buena parte— asíncrono.
En la actualidad, yo diría que estamos gestionando una media de unos 200
y pico bugs por mes.

En la línea de la pregunta anterior, usted mencionó que buena parte de su tiempo lo pasa
trabajando con la infraestructura de pruebas. ¿Cómo son realmente esas pruebas?

Uno de los objetivos principales del equipo es conseguir interoperabilidad. Ya sea

con XML, XML-Schemas, XHTML o HTML5. Así que tenemos una política
para manejar las pruebas, que resulta imprescindible antes de llegar a lo que lla-
mamos Candidate Recommendation, y que comienza tras esa última llamada que
mencioné antes. Y tenemos que coordinar todas las pruebas provenientes de todas
las fuentes. Los fabricantes realizan pruebas individualmente, y cada uno tiene sus
particularidades. Mozilla las hace de una forma y el grupo de Internet Explorer,
de otra, por ejemplo.
Así que necesitamos algún tipo de infraestructura que nos permita aunar este
conjunto de pruebas y operar de forma racional. Actualmente disponemos ya de
más de 1.000 test aprobados. Y otros 20.000 más, que han llegado recientemente
y que van a ser comprobados por nuestro "equipo de testing"23, ya que disponemos
de un equipo dedicado exclusivamente a estas tareas.
página

45
<< Introducción

Así que aprovecho la ocasión para invitar a cualquier desarrollador Web a

que entre en la página oficial de la W3C, busque la página de testing, y pruebe y
envíe los resultados de sus propios test si lo considera interesante. Personalmente,
no me extrañaría que, dentro de un año, cuando empecemos a recibir las pruebas
de las primeras implementaciones en navegadores reales, alcancemos una cifra
cercana a los 75.000 test realizados. CSS 2.1, que está a punto de ser terminada
por la W3C tiene unos 9.000 test realizados.

Vamos a movernos, si le parece, a terrenos más prácticos y relacionados con su presencia

aquí. ¿Cuál piensa Ud. que es el mensaje principal que trae en esta visita a España y cuáles
son los puntos principales que piensa exponer esta tarde en su presentación?

Creo que tengo dos mensajes. Uno, por mi pertenencia al W3C y otro por repre-
sentar a Microsoft. La W3C está convencida que esta Plataforma Web Abierta,
que incluye HTML 5, CSS, las API relacionadas, ECMAScript -que se está re-
novando en ECMA—, el protocolo que está siendo desarrollado por ITF, etc.,
son tecnologías que cambiarán las reglas del juego.
Y piensa que nos va a permitir sitios Web muy innovadores y potentes, y también
creemos que vamos a ver un gran movimiento hacia las
aplicaciones HTML 5. Y es posible que —dentro de 2
ó 3 años— esas aplicaciones puedan conseguir resultados
tan interesantes como las llamadas aplicaciones nativas,
ya se trate de plataformas PC o de dispositivos móviles,
teléfonos o tablets. Así que ese mi principal mensaje. HTML 5 es muy importante, y
la W3C es el sitio donde se está realizando ese trabajo y el Advisory Comitee Meeting,
al que he asistido en Bilbao es otro ejemplo de reunión de la comunidad en torno a
una misma idea.
Así que hemos visto como compañías que antes no estaban en estas reuniones,
como Disney, LG o Sony, han vuelto a participar activamente. Lo mismo sucede
con las compañías telefónicas, como Nokia, Eriksson o AT&T. Otro ejemplo es
Comcast, una de las compañías de cable más importantes de EE.UU., que ahora
es miembro de la W3C.
Desde el punto de vista de Microsoft, he estado trabajando con el equipo de
Internet Explorer durante unos dos años, desde IE8, luego IE9 y ahora con la
preview de IE10. Y creo que la implicación de Microsoft con el estándar es muy

23
Testing Task Force, en el original inglés.
página

46
 Introducción >>

fuerte en todos los sentidos, al igual que lo están haciendo ECMA, e ITF con otras
tecnologías relacionadas.
Pero lo más importante para Microsoft, no es hacer una "carrera" para ver
quién lo implementa primero, sino fijarse en la estabilidad, y de cara a nuestros
clientes, asegurarnos que no implementamos las especificaciones hasta que no
sean lo suficientemente estables como para ofrecer un camino seguro a los des-
arrolladores Web.
Así que, animamos a la comunidad de programadores a que prueben nuestras
implementaciones, que solemos actualizar con una frecuencia de 10/12 semanas,
o que entren en sitios como HTML5 Labs24, donde se están construyendo proto-
tipos de aspectos como IndexDB que son de esperar que veamos en Internet Ex-
plorer y en otros navegadores. Consiste en una base de datos de cliente, muy sen-
cilla, solamente parejas "Clave-Valor" (Key-Value
Pairs), que permite muchas implementaciones en el
cliente.
Así que, desde nuestro punto de vista, es bueno
que quede claro que nos importa la estabilidad del
producto ante todo.

¿Nos puedes decir algo sobre las expectativas de adopción

del estándar que tiene Microsoft, y cuánto tiempo calcula que va a llevar el proceso?

Depende de la tecnología que lo aplique. Por ejemplo, la presencia de LG o Sony

es un indicativo de que ellos piensan incluir un navegador en sus televisores. Y
hay compañías de automóviles que están pensando cómo adaptar sus manteni-
mientos, sus sistemas de seguridad, etc. Así que una vez más esperamos que HTML
5 sea el aglutinante de muchas tecnologías para muchos sectores distintos de la
industria.

El programador en general, cuando oye hablar de HTML 5 no puede evitar pensar en

JavaScript. Y muchos ya afirman que esto supone una vuelta a los viejos tiempos, o sen-
cillamente, un paso atrás en las capacidades de desarrollo. ¿Qué piensa Ud. al respecto?

Es interesante. Como indique en una respuesta anterior, me considero "darwiniano"

en lo referente a especificaciones. Tenemos especificaciones buenas, y otras nor-
malitas. Pero lo que resulta realmente importante es la adopción. Y creo que la

24
http://blogs.msdn.com/b/mvplead/archive/2011/06/10/lt-html5-labs-gt.aspx
página

47
<< Introducción

prevalencia de la Web, y el movimiento hacia tener cada vez más aplicaciones web,
está haciendo que esas aplicaciones sean cada vez más potentes.
Y al objeto de poder aprovechar todas las posibilidades de una plataforma para
una aplicación, realmente se necesita tener acceso a esa plataforma. Por ejemplo,
la geo-localización en los móviles. O el audio, el vídeo o las cámaras. Y el acceso a
todas esas posibilidades se está haciendo mediante diversas API de JavaScript.
Así que las herramientas que tenemos hoy, ya sea Visual Studio o Eclipse, se
van a tener que adaptar y ayudar mucho más al desarrollador a utilizar esas API.
Todavía no hemos llegado a un grado de soporte suficiente, pero estoy convencido
que ese es el objetivo de la siguiente generación de herramientas de desarrollo.

¿El futuro de la Web rechazará los "plug-in" de cualquier tipo? ¿Se pretende que los na-
vegadores prescindan de componentes extra de cualquier clase?

Yo no pienso que aplicaciones como Flash o Silverlight vayan a desaparecer

en absoluto. Volviendo a lo que decía antes, creo que estas plataformas son muy
populares debido las herramientas de desarrollo, que ayudan a los programadores
a construir esos complementos. Así que, hasta que no existan las herramientas ne-
cesarias para que HTML 5 pueda competir con esos complementos (add-ons)
vamos a continuar viendo soporte de Flash por parte de Adobe, y soporte de Sil-
verlight por parte de Microsoft.
Hay muchas aplicaciones verticales para los que estas tec-
nologías son las más apropiadas. Pero también creo que con el
tiempo comenzaremos a ver cada vez más aplicaciones basadas
en HTML 5 y a más productores de navegadores hacer lo que
Microsoft está haciendo con IE, que es conectar la tecnología
que está en el navegador directamente al hardware del equipo.
Por ejemplo, utilizando el procesador gráfico para obte-
ner un vídeo más suave, y mejores animaciones, para conseguir lo que ahora se
llaman "Juegos para PC", directamente en HTML. Pero todavía nos queda por
recorrer un largo camino. La tecnología nos ayudará y las herramientas de des-
arrollo también y por supuesto, ¡acabar la especificación nos ayudará también!
Lo que el desarrollador necesita es escribir una sola aplicación para cualquier
navegador.

¿Y qué sucede con ECMAScript 5? Tengo entendido que no se construye en W3C. ¿Existe
algún tipo de coordinación entre ambos grupos?
Cuando lanzamos IE9, incluimos un nuevo motor JavaScript en el producto. Nues-
página

48
 Introducción >>

tra división de interoperabilidad implica a diferentes grupos en Microsoft. Nuestro

equipo de JavaScript pertenece a la división Server and Tools, mientras que Internet
Explorer pertenece a la de Windows. Cuando sacamos IE, combinamos las dos
tecnologías. Y de hecho, mi equipo es la tercera parte de este juego, porque tenemos
la responsabilidad dentro de Microsoft de todo lo relacionado con la W3C.
Así que trabajamos juntos, y yo mismo he estado en varias reuniones con los
equipos que están haciendo ECMAScript en la actualidad. Pero es que los equipos
de desarrollo de TC3925 también se reúnen periódicamente para resolver problemas
técnicos de la implementación. Y lo mismo tienen que hacer los de otras empresas
si quieren que la implementación del estándar sea adecuada.

¿Qué significa exactamente el término HTML nativo, en palabras de Dean Hachamovitch?

Creo que a lo que el jefe de desarrollo de IE9 se refería es al aprovechamiento del

hardware de la plataforma por parte del navegador. Al hecho de que el navegador
"conoce" la plataforma en la que se está ejecutando, y hace uso de las capacidades
que esta plataforma le ofrece. Y analizar el sistema operativo hasta el nivel de hard-
ware, de forma que pueda utilizar la GPU para acelerar la experiencia y acelerar
las respuestas del sitio Web o la aplicación que se está mostrando al usuario.

Uno de los problemas relacionados con las aplicaciones tiene que ver con las API relacionadas
con el estándar. Podemos usar Modernizr para que los antiguos navegadores "comprendan"
HTML 5. Pero, ¿qué sucede con las API necesarias para el desarrollo, como Local Storage,
Session Storage, File API, WebSQL, Web Sockets, Office Apps…?

Algunas de esas especificaciones entran en categorías muy distintas. Por ejemplo,

WebSQL creo que es una "especie en extinción". Y la mayoría
de los fabricantes, reconocen que la especificación necesaria
para contar con una base de datos en el cliente va a ser In-
dexDB. Y de hecho, el trabajo con esa especificación dentro
de la W3C ya no continúa. File API, desde nuestro punto de
vista está llegando a la categoría de estable, y tenemos un pro-
totipo en HTML 5 Labs, y creo que podremos verlo en IE en
algún momento futuro. Y lo mismo sucede con las otras especificaciones que men-

25
Para más información sobre el grupo TC39 ECMAScript, ver http://www.ecma-
international.org/memento/TC39-M.htm
página

49
<< Introducción

cionabas que pienso que van a seguir madurando e incorporándose paulatinamen-

te.
Web Sockets, es uno de los buenos ejemplos de esas especificaciones. Es una
de las más prometedoras, y eso es lo que respondo cuando me preguntan sobre
ella, aunque también les digo lo mismo cuando me preguntan por cuál es el API
más "peligrosa"… Nosotros trabajamos con la ITF (como dije, la entidad que ges-
tiona los protocolos), aunque la parte del API la seguimos llevando nosotros. Pero
el protocolo está ahora en su versión 7. Y eso que llevan trabajando en ello unos
7 meses. De hecho, el protocolo ha cambiado tanto desde su inicio que, ahora la
especificación del API que nosotros llevamos tiene que estar alineada con el nuevo
protocolo. Ese trabajo está pendiente también.
Así que, desde el punto de vista de Microsoft, no vamos a implementar esa es-
pecificación hasta que consideremos que es lo suficientemente estable. La lista que
comentabas tiene especificaciones que se encuentran en distintos estados de madurez,
pero estoy convencido de que la mayoría de las que mencionabas estarán disponibles
dentro de un año cuando lleguemos al estado de Candidate Recommendation.

¿Qué plataforma de Microsoft piensa Ud. que está más orientada a futuro: Web Matrix
(con Razor) o ASP.NET?

Normalmente, cuando me preguntan por tecnologías, siempre respondo que lo

mejor es que cada uno escoja aquella que conoce mejor. Y estoy convencido de
que es más importante comprender bien la tecnología, que el hecho de usar una
u otra plataforma o herramienta.
No creo que haya una sola respuesta aquí. Hay muchos entornos de trabajo
interesantes que la gente puede utilizar, para la construcción de aplicaciones web,
pero, si pensamos en el éxito de los proyectos, casi siempre se trata de desarrolla-
dores que conocen muy bien las plataformas y herramientas en las que desarrollan.
Así que recomiendo que la gente llegue a un nivel alto de conocimientos en una
o dos, de forma que puedan brillar en lo que hacen.

Y finalmente, ¿cuál es el papel de Silverlight 5, (aparte de Windows Phone 7) si es que

tiene alguno?

No pienso que tecnologías como Silverlight vayan a desaparecer en un futuro.

Creo que hay muchas aplicaciones en las que —desde hace ya algún tiempo—
Silverlight es la tecnología más adecuada a utilizar.
Por otro lado, HTML 4 disponía de la etiqueta <object> que nos permitía
página

50
 Introducción >>

incluir cosas como vídeo y audio. HTML 5 dispone de etiquetas <video> y <audio>
así que, los add-ons eran extensiones necesarias, que —en este aspecto— ya no lo
son. Pero la etiqueta <object> no va a desaparecer, eso es seguro. Y la gente va a
continuar utilizándola.
Creo que lo que sucederá tendrá que ver con las mejores herramientas y con
las mejores experiencias, y con la amplitud de la cobertura que se consiga con ellas.
Será una cuestión de sopesar los factores de cobertura que la tecnología ofrece
respecto a los beneficios obtenidos con otra tecnología. Así que las diversas situa-
ciones harán que unos vayan por un camino y otros por otro.
Pero, en el caso de Silverlight, estoy seguro de que existen patrones muy
fuertes que avalan su utilización, y eso supondrá que la gente va a continuar uti-
lizándolo.
Una de las razones por las que Microsoft incluyó IE9 en Windows Phone
fue esa idea de la cobertura ampliada. Y que los usuarios y desarrolladores apreciasen
esa independencia de funcionamiento, tanto si están en Windows, como en Win-
dows Phone. De hecho, estamos viendo la aparición de start-ups, cuya idea principal
es aprovechar este estándar HTML 5, para construir aplicaciones.

Pues muchas gracias por sus palabras, y esperamos que su estancia en España le resulte
agradable y podamos verle pronto por aquí.

Ha sido un placer venir aquí. Y había estado en España un par de veces antes. El
clima es excelente.
Para concluir quería añadir que, cuando Tim Berners-Lee creó la W3C, su ob-
jetivo era hacer que la Web tuviese un impacto mundial, y creo que HTML 5 es
otro ejemplo de caso de éxito de la W3C. Tenemos soporte de un número creciente
de miembros, y todos ellos están muy interesados en la construcción de esta "Pla-
taforma Web Abierta".
página

51
<< Introducción

Referencias

Holguera, Javier (2011), "Internet Explorer 9 y HTML 5". Netalia, p. 15.

Conociendo RDF y la Web Semántica con N3, http://www.w3.org/2000/10/swap/Primer
Hoja de Ruta de la Web Semántica, http://www.w3.org/DesignIssues/Semantic
¿Que es la Web Semántica?, http://purl.org/swag/whatIsSW
Semantic Web Primer, http://uwimp.com/eo.htm
Introducción a la Web Semántica–Extenso, http://logicerror.com/semanticWeb‐long
SciAm: The Semantic Web, http://www.scientificamerican.com/2001/0501issue/0501berners‐lee.html
Construyendo la Web Semántica, http://www.xml.com/pub/a/2001/03/07/buildingsw.html
The Semantic Web, Taking Form, http://infomesh.net/2001/06/swform
SW Activity Statement, http://www.w3.org/2001/sw/Activity
SWAD, http://www.w3.org/2000/01/sw

Referencias de la Web Semántica

"W3C Semantic Web Frequently Asked Questions". W3C. Retrieved March 13, 2008.
Berners-Lee, Tim; James Hendler and Ora Lassila (May 17, 2001)."The Semantic
Web". Scientific American Magazine. Retrieved March 26, 2008.
Herman, Ivan (March 12, 2008). "W3C Semantic Web Activity". W3C. Retrieved March 13,
2008.
Berners-Lee, Tim; Fischetti, Mark (1999). Weaving the Web.HarperSanFrancisco. chapter
12. ISBN 978-0-06-251587-2.
Gerber, AJ, Barnard, A & Van der Merwe, Alta (2006), A Semantic Web Status Model, In-
tegrated Design & Process Technology, Special Issue: IDPT 2006
Gerber, Aurona; Van der Merwe, Alta; Barnard, Andries; (2008), A Functional Semantic
Web architecture, European Semantic Web Conference 2008, ESWC’08, Tenerife, June
2008.
Karger, David. "What Would It Mean to Blog on the Semantic Web". Retrieved November
15, 2010.
Victoria Shannon (June 26, 2006). "A ‘more revolutionary’ Web".International Herald Tribune.
Retrieved May 24, 2006.
"The advent of Web 3.0". Semantic Web Company. Retrieved November 14, 2010.
Conrad Wolfram on Communicating with apps in web 3.0 IT PRO, 17 Mar 2010
Shah Newaz Alam. "Web 3.0 vs Web 2.0". Buzzle.com. Retrieved November 14, 2010.
Steve Spalding (July 14, 2007). "How To Define Web 3.0".howtosplitanatom.com. Retrieved
November 14, 2010.
página

52
 Introducción >>

Artem Chebotko and Shiyong Lu, "Querying the Semantic Web: An Efficient Approach
Using Relational Databases", LAP Lambert Academic Publishing, ISBN 978-3-8383-
0264-5, 2009.
Gärdenfors, Peter (2004). How to make the Semantic Web more semantic. IOS Press. pp. 17–34.
Timo Honkela, Ville Könönen, Tiina Lindh-Knuutila and Mari-Sanna Paukkeri
(2008). "Simulating processes of concept formation and communication". Journal of Eco-
nomic Methodology.
Ivan Herman (2007). "State of the Semantic Web". Semantic Days 2007. Retrieved July 26,
2007.
Berners-Lee, Tim (May 1, 2001). "The Semantic Web". Scientific American. Retrieved March
13, 2008.
Nigel Shadbolt, Wendy Hall, Tim Berners-Lee (2006). "The Semantic Web
Revisited". IEEE Intelligent Systems. Retrieved April 13, 2007.
Lee Feigenbaum (May 1, 2007). "The Semantic Web in Action".Scientific American. Retrieved
February 24, 2010.
Martin Hilbert (April, 2009). "The Maturing Concept of E-Democracy: From E-Voting and
Online Consultations to Democratic Value Out of Jumbled Online Chatter". Journal of
Information Technology and Politics. Retrieved February 24, 2010.
http://policyawareweb.org/
"RDF tutorial". Dr. Leslie Sikos. Retrieved 2011-07-05.
"Resource Description Framework (RDF)". World Wide Web Consortium.
"Standard websites". Dr. Leslie Sikos. Retrieved 2011-07-05.
Allemang, D., Hendler, J. (2011). "RDF—The basis of the Semantic Web. In: Semantic Web
for the Working Ontologist (2nd Ed.)". Morgan Kaufmann.
Lukasiewicz, Thomas; Umberto Straccia. "Managing uncertainty and vagueness in description
logics for the Semantic Web".
See, for instance: Bergman, Michael K. "Sweet Tools". AI3; Adaptive Information, Adaptive
Innovation, Adaptive Infrastructure. Retrieved January 5, 2009.
"GoodRelations: The Web Ontology for E-Commerce". E-Business + Web Science Research
Group.
"GoodRelations Project Main Page".
Hepp, Martin (September 29 — October 3, 2008). "GoodRelations: An Ontology for Des-
cribing Products and Services Offers on the Web".Proceedings of the 16th International Con-
ference on Knowledge Engineering and Knowledge Management (EKAW2008).
página

53
<title>

</title>

<autor>

</autor>
<resumen>
Esta obra aborda el nuevo estándar bajo el supuesto de que el usuario ya conoce los fundamentos
del anterior, y desea actualizarse y/o abordar proyectos de desarrollo que impliquen HTML5 y sus
tecnologías asociadas: CSS3, JavaScript y las API relacionadas con ellos. El foco es el propio
estándar independientemente de la plataforma para la que vaya a ser utilizado.

A lo largo de la obra se utiliza Visual Studio 2012 como herramienta de desarrollo completa que
dispone de cobertura total del estándar en sus editores visuales y de código, a nivel de
depuración, pruebas y actualizaciones. Se muestra cómo usarlo en esos contextos y aprovechar
las nuevas propuestas que la W3C plantea en su iniciativa “Open Web Platform”.
</resumen>
</biografia>
Marino Posadas es Consultor Independiente, Redactor de la revista
DNM, MVP en C#, MCT, MCPD y MCTS. Esta es su undécima obra sobre
tecnologías y la segunda dedicada al estándar HTML. Ha publicado más
de 500 artículos en revistas especializadas en papel y "on-line" y ha co-
laborado como ponente en diversos eventos para programadores en Es-
paña, el resto de Europa y América, siempre relacionadas con el desarrollo
de software.

</biografia>

netalia
alia
just for developers