Cuando trabajamos con páginas HTML estáticas repetimos la misma plantilla de estructura en todas las páginas del sitio. Es una forma cómoda de trabajar pero el inconveniente se plantea cuando tenemos que realizar una pequeña modificación en esa estructura. Para agregar por ejemplo un nuevo botón en el HTML de la estructura tendríamos que modificar todas las páginas del sitio. Esto lo podemos evitar insertándolo con JavaScript después del evento Load para no influir negativamente en la optimización de la velocidad de carga.

Pero si el HTML que insertamos es excesivo puede resultar en un aviso de priorizar el contenido visible que nos dará la herramienta PageSpeed Insights. Esto es lo que me ha sucedido con el nuevo botón de compartir que ahora aparece en la parte superior derecha, entre la barra de menú y el inicio del contenido, explicando en este tema como lo solucioné.

Implementar todo lo necesario para conseguir que nuestra web tenga una buena velocidad de carga es un tarea algo compleja. Son muchas cosas las que intervienen y por tanto la posibilidad de que algo falle es muy alta. Especialmente cuando hay cambio de versiones de sistemas operativos, navegadores o servidores. Tras conseguir el objetivo de la velocidad de carga hay que hacer un seguimiento de los parámetros para ver si se siguen conservando. Herramientas como Networks de las Developer Tools de Chrome y de otros navegadores nos pueden ayudar en esa supervisión.

Cuando cambié mi viejo ordenador con Windows XP a uno nuevo con Windows 8.1 también tuve que actualizar el antivirus. Y precisamente este elemento estaba descomprimiendo los recursos antes de llegar al navegador. Dado que necesitamos saber con que tamaño llegan al navegador, se hace necesario saber cómo desactivar el filtrado de protocolos HTTP en el antivirus para que deje pasar los GZIP tal como salen de nuestro servidor.

He dedicado bastante tiempo a la optimización de la velocidad de carga para este sitio web. He usado principalmente la herramienta Pagespeed, especialmente la extensión que podemos instalar en el navegador Chrome. Alcanzar en torno a un 60-70 de puntuación no es muy díficil. El trabajo se empieza a complicar si el objetivo es conseguir 100/100. Este objetivo ya lo he alcanzado para este sitio. Pero quisiera saber cuál es el grado de optimización de otros sitios web.

Los elementos HTML se concibieron inicialmente con un caracter semántico. Por ejemplo, un <p> contiene un párrafo de texto y un <a> un vínculo a otro documento. HTML5 incorpora nuevos elementos como <header> o <footer> que agrupan contenidos estructurales como la cabecera y el pie de un documento. Otros como <section> o <article> servirán para agrupar en secciones los contenidos. Un documento semánticamente bien formado es un apoyo indudable para que otras aplicaciones puedan encontrar correctamente los contenidos. Pero aún hay muchas dudas con estos nuevos elementos de HTML5 que pueden hacernos desistir de usarlos.

En esta nueva versión del Timeline de las herramientas de desarrollo del navegador Chrome 34 ya se arregló el problema del registro del momento en el que se iniciaba el primer pintado. Este dato es especialmente importante pues hemos de lograr que esté siempre por debajo de un segundo. En la imagen se observa el valor Start Time de 624 ms, momento en el que empieza el primer pintado desde el inicio de la petición de la página principal de este sitio.

Para optimizar la velocidad de carga de una web podemos usar herramientas como Web Page Test o las propias de los navegadores. El Timeline de Chrome nos puede ayudar a descubrir cuando se produce el primer pintado de la página. Es un valor indicativo del momento cuando el usuario empieza a ver que algo está sucediendo en la pantalla. Chrome actualizó recientemente a la versión 33 con cambios importantes en las herramientas de desarrollo. Específicamente actualizó el Timeline incluyendo un línea vertical verde para registrar este evento de primer pintado. Pero también observo una ausencia con respecto a la versión anterior pues no me indica el tiempo acumulado desde el inicio de la grabación.

He llevado a cabo una actualización de este sitio para mejorar los tiempos de carga, la adaptación a los anchos de pantalla y la accesibilidad, entre otras mejoras. En este artículo expongo un resumen de las acciones realizadas.

Últimamente se está oyendo hablar mucho acerca de los vendor prefixes que podemos traducir como prefijos propietarios o prefijos CSS del navegador. Son prefijos como -webkit-, -moz-, -o-, -ms- que se anteponen al nombre de la propiedad de estilo para que el navegador correspondiente reconozca esa característica. Se aplican a estilos en experimentación que aún no forman parte de una especificación o estándar. La prudencia aconseja no usar prefijos CSS en sitios en producción, pues esas propiedades pueden sufrir alteraciones en el desarrollo de su implementación. Aunque podemos gestionar el acceso a esas propiedades por todos los navegadores usando los prefijos, esto no asegura que todos implementen de la misma forma la característica. E incluso los valores a adjudicar a una propiedad determinada pudieran ser diferentes en cada navegador aunque tuviesen el mismo nombre de propiedad tras su prefijo particular. Por lo tanto mientras no sea estándar debemos tener cuidado con estas nuevas propiedades. Debemos asegurarnos que el nuevo estilo no compromete a la seguridad y que sí lo nuevo no funciona al menos no nos rompa la página.

Cuando hice el buscador interno para este sitio lo basé en un índice de palabras clave almacenadas en un array. Realmente hay dos archivos de índices, uno es indice-web.txt con un tamaño actual de 166 KB y el otro es indice-claves.txt que pesa 87 KB. Están almacenados en archivos de texto como arrays serializados. Se trata de convertir los arrays en una estructura de texto plano para poder guardarlo en disco y luego extraerlo. Se usa la función de PHP serialize()...

La especificación W3C HTML-5 está en fase WD (Working Draft) en este momento (Octubre 2011). Se trata de un "borrador" debiendo pasar por varios niveles W3C hasta alcanzar el grado de estándar W3C Recommendation (REC). El primer WD publicado es del 22 de Enero de 2008. En el momento de escribir este artículo (Octubre 2011) el más reciente WD es del 25 de Mayo de 2011. Hay un agenda de hitos planificados expuesta en la página W3C HTML-WG-charter que en este momento establece la finalización de la fase WD en este año 2011. Después de algunas fases más pasará a estándar (REC) en el 2014, aunque podrían darse modificaciones en estos plazos.

La pregunta para alguién inexperto como yo es cuándo empezar a utilizar una especificación nueva, ¿En el 2014?. ¿O tenía que haber empezado en el 2008 con la primera publicación del borrador?. ...

En inglés el término wordwrap significa salto de línea automático o simplemente ajuste de línea. El HTML tiene la característica de ajustar el ancho de las líneas al ancho disponible del contenedor, incluso cuando el texto está dentro de un elemento <textarea>. Pero a veces necesitamos que no se produzca este salto automático, como cuando presentamos código de algún programa donde no deben producirse saltos de línea no deseados. En este artículo se expone que posibilidades tenemos para esto y se analiza el nuevo atributo wrap de HTML-5 para el elemento <textarea>.

La página del W3C sobre las ventajas de usar XHTML en lugar de HTML dice que si su documento es un XHTML 1.0 puro (sin incluir otros lenguajes de marcas) entonces no notará mucha diferencia. Sin embargo cuantas más herramientas XML estén disponibles, tales como XSLT para transformar documentos, empezará a darse cuenta de las ventajas de XHTML. XForms por ejemplo le permitirá editar documentos XHTML (o cualquier clase de documentos XML) en una forma simple y controlable. Las aplicaciones de la Web Semántica se beneficiarán más de los documentos XHTML. Si su documento es más que XHTML 1.0, por ejemplo incluyendo MathML, XMIL o SVG, entonces las ventajas son inmediatas: sería imposible hacer esas cosas con HTML. Esto es lo que dice el W3C, pero ¿cuáles son las diferencias entre HTML y XHTML?, ¿Porqué los XHTML son servidos como HTML?, ¿Todos los navegadores soportan XHTML?. Y la pregunta final ¿Qué debo aprender: HTML o XHTML?.

Si estructuramos el HTML de una página en torno a elementos de encabezado (los <h1>, <h2>,...) entonces podemos disponer en esa página de una tabla de contenidos para que el usuario acceda al apartado que necesite. En este artículo propongo una construcción dinámica de esa tabla de contenidos usando Javascript.

JavaScript no soporta el paso por referencia, pues lo que se pasa es una copia de la referencia. Sin embargo con referencias a elementos HTML el comportamiento puede ser impredecible, al menos con Internet Explorer 8. Este artículo surge de la necesidad de crear objetos JavaScript que manipulan el DOM, es decir, que crean elementos en el documento. Esos objetos agregan con document.body.innerHTML nuevos elementos mediante la acción del usuario y después de finalizada la carga de la página. Si al objeto se le pasan argumentos con referencias a elementos antes de la modificación del DOM, al menos Internet Explorer pierde parte de esa referencia.

Las funciones (y procedimientos en VBScript) nos permiten pasar argumentos o parámetros para manipularlos en su interior. Son conocidas dos estrategias como el paso por valor y el paso por referencia. JavaScript sólo permite el paso por valor y VBScript permite ambos. Para ver el comportamiento de ambos lenguajes, realizamos algunos ejemplos.

Decimos que construir dinámicamente con JavaScript elementos HTML es expresar el código de ese elemento en una cadena (String) y luego insertarla en el documento mediante el uso del método innerHTML que actualmente soportan la mayoría de navegadores. Por ejemplo, con el script var cadena = "<span>xxx</span>" haríamos una declaración literal del código de un elemento HTML y luego con otroElemento.innerHTML = cadena reemplazaríamos todos los elementos que poseyera en su interior ese otroElemento con el anterior. Cuando se ejecuta el script ese reemplazo se hace de forma inmediata sin necesidad de recargar la página.

En un contexto de manejo de objetos la palabra reservada this es una referencia al propio objeto. Por otro lado sabemos que cuando un evento llama a una función, una vez dentro de ésta podemos obtener una referencia al elemento que causó el evento con la palabra reservada this. Esta referencia se pasa como un argumento que va implícito en la función, no siendo necesario declararlo en la lista de argumentos.

Si en la cadena para construcción dinámica HTML quisiéramos expresar un evento que llama a una función no tendríamos ningún problema: var cadena = "<span onclick='miFuncion()' >xxx</span>". Pero el problema surge cuando esa miFuncion() es un método de un objeto creado y dentro de ella necesitamos referirnos con this al propio objeto de tal forma que la función nos devuelve irremediablemente la referencia al elemento que causó el evento.

La imagen adjunta aparece en un documento al que puede accederse en www.unicode.org, última versión de Unicode 5.1 con documentación de 5.0 Book Front Matter, donde se expone la documentación de Unicode desglosada en capítulos. Del Capítulo 2 General Structure, en su página 37, hemos extraído esta información que compara los distintos formatos UTF para codificar cuatro códigos Unicode: 65, 937, 35486 y 66436 en decimal (41, 3A9, 8A9E y 10384 en hexadecimal). En esta imagen los carácteres son a su vez imágenes, pues puede suceder que ciertos carácteres que aparecen más abajo no se presenten en el monitor, detalle que luego explicaremos.

El propósito es analizar como se realiza la codificación en UTF-8 y proponer algoritmos en VBScript para codificar y decodificar en UTF-8. Aunque ahora no trataremos los casos de UTF 16, 32, se observa que con UTF-32BE la disposición de los códigos es la misma que la del original en hexadecimal: 41, 3A9, 8A9E, 10384. En cuanto a BE, LE no nos adentraremos en este tema pues no afecta a UTF-8, bastando decir que se usan para serializar los bytes. Así con LE nos llegarían los bytes de forma invertida, con el de menor peso (Little Endian) primero, mientras que con BE nos llegan de forma normal, con el de mayor peso (Big Endian) primero. Como UTF-32 no necesita ninguna transformación, entonces con UTF-32BE sucede que la disposición de los bytes es la natural de lectura izquierda-derecha, coincidiendo visualmente con la disposición de los códigos Unicode.