Cuando un navegador comienza a parsear una página, comienza a leer desde el encabezado, claro. Si la respuesta del encabezado del content-type especifica un atributo charset, esos bytes pueden ser interpretados inmediatamente como texto utilizando el encoding determinado. Sin embargo, si una declaración charset no está presente, el browser comienza a escanear los bytes de de respuesta del cuerpo, buscando por algún marcador unicode ó algún elemento dentro del meta http-equiv que especifique el charset. Cuando lo encuentra el parser vuelve a leer el documento para asegurarse que lo anterior sea leído correctamente. Ahora, si una declaración de charset no está definido, el browser está obligado a autodetectar el encoding dependiendo del contenido, lo que puede provocar errores de caracteres o en la página misma.
Luego, son leídos el título, favicon y los estilos (<link>) los que deben estar en concordancia con el charset definido anteriormente.
Finalmente, el orden ideal propuesto por la mayoría de los navegadores modernos es el siguiente:
<doctype>
<html>
<head>
<meta http-equiv content-type charset>
<title>
<link rel="alternate" />
<link rel="shortcut icon" />
<link rel="stylesheet" type="text/css" />
Parece obvio, pero no muchas veces se cumple.
No incluí <script></script> intencionalmente ya que existen escuelas que dicen que es mejor incluirlos abajo del código de tu página, antes del </body>, lo que no valida en el código HTML pero acelera la carga de los elementos del DOM y deja para el final la carga de los scripts. Mejor lo dejo a criterio de cada desarrollador.
Links:
]]>El atributo rel describe la relación del presente documento al link (href) o ancla (name) especificado en el atributo href="". El valor de este atributo puede ser más de uno y al igual que las clases, separados por espacio.
Tiempo de una pausa para un pequeño detalle.
Este atributo dentro de un link <a></a> no es utilizado ni reconocido por ningún browser actualmente (por eso seguramente ha sido menospreciado y olvidado por tanto tiempo).
Entonces, ¿para qué seguir gastando nuestro tiempo? Pues rel="" sí es considerado por los buscadores para obtener más información sobre los enlaces, y es muy difundido mediante microformatos.
Los valores de este atributo para HTML 4.01 son (o eran, como quieras verlo):
- alternate
- una versión alternativa del documento (por ej. una traducción, página para impresión, etc).
- stylesheet
- este es familiar; es una hoja de estilos linkeada externamente.
- start
- el primer documento de un conjunto de documentos. Este valor le indica a los buscadores que la página es considerada el punto de inicio de la colección.
- prev, next
- documento anterior y siguiente de una misma colección de documentos; podría utilizarse para pre-cargar los documentos siguientes.
- contents
- una tabla de contenidos para el conjunto de documentos.
- index
- una página que ofrece un índice para los documentos.
- glossary
- una página con un glosario de términos para el conjunto de documentos.
- copyright
- textos legales para todo el documento.
- chapter
- pagina que abre un capítulo.
- section
- pagina que abre una sección.
- subsection
- pagina que abre una sub-sección.
- appendix
- el apéndice.
- help
- una página de ayuda (más información, otras fuentes de información, instrucciones, etc).
- bookmark
- pagina con enlaces a contenido dentro del mismo conjunto de documentos.
Para HTML 5 y a través de los microformatos (prácticamente XFN), se ha privilegiado la relación de enlaces a personas más que a documentos o partes de él. Los siguientes son los -hasta ahora- aprobados para HTML 5:
- acquaintance
- la persona linkeada ofrece conocimiento anexo al documento actual.
- child
- la persona referenciada es hija de la persona autora del documento.
- co-resident
- la persona referenciada vive en la misma casa del autor.
- co-worker
- la persona referenciada trabaja con el autor.
- colleague
- la persona referenciada es colega del autor.
- contact
- el autor considera a la persona referenciada como un contacto.
- crush
- la persona referenciada atrae al autor.
- date
- el autor está saliendo con la persona referenciada.
- kin
- la persona referenciada es parte de la gran familia del autor.
- me
- la persona referenciada y el autor son la misma persona.
- met
- el autor conoce a la persona referenciada.
- muse
- la persona referenciada inspira al autor.
- neighbor
- la persona referenciada vive cerca o es vecino del autor.
- parent
- la persona referenciada es padre del autor.
- sibling
- la persona referenciada es hermano(a) del autor.
- spouse
- la persona referenciada es cónyugue del autor.
- sweetheart
- el autor considera al(a) referenciado(a) como su cariño.
A partir de necesidades específicas de fabricantes de browsers y de tecnologías, se han creado algunos valores que son específicos, como:
- nofollow
- es utilizado por Google para especificar que el spider de indexación no debe seguir ese link.
- shortcut icon
- reconocido por los browsers modernos para enlazar un archivo favicon.ico.
- apple-touch-icon
- utilizado por Apple para especificar un archivo ícono para un sitio web.
Pues como leen, este malhogrado atributo está resucitando y nos permite vincular objetos y documentos con una semántica nunca antes vista. Queda en nosotros utilizarla correctamente y sacarle provecho en nuestros proyectos.
Links:
]]>Para esta nueva versión, he agregado las nuevas etiquetas que conforman HTML 5 para elementos de tipo bloque (las que son inline no las necesitan) y aproveché de realizar las siguientes mejoras en lo existente:
- Soporte para nuevas etiquetas HTML 5
- Mejor reset para campos de formularios
- Mejoras para listas ordenadas (<ol>) y tablas (<table>)
Ya está activo en este nuevo sitio, y espero sea aprovechado y de mucha ayuda en sus proyectos. La idea, como saben, es simplificar el codificado mediante el reset de estilos que traen por defecto los navegadores web.
]]>En un campo de formulario, cuando lo seleccionas en iPhone/iPad para completarlo, automáticamente te muestra el teclado touch del aparato. Aparte del teclado QUERTY por defecto, existen 3 valores para type="" de <input /> que muestran diferentes tipos de teclados: numéricos, url y de e-mail:
<input type="text" /> (por defecto)
<input type="url" />
<input type="number" />
<input type="email" />
Los browsers que no soporten HTML5 lo obviarán y degradarán como si fuera un campo de tipo texto (type="text").
Se nota como un detalle menor pero seguro tus usuarios lo notarán y te diferenciarás con este tipo de detalles.
]]>
En esta ocasión el layout es bastante simple, uno típico que encontrarás en cualquier sistema de comentarios para blogs. Pero es un buen puntapié para que veas de qué se trata esto. Además, contiene las etiquetas fundamentales y más utilizadas para capturar datos de usuarios.
Espero sea de ayuda y que se entienda, como siempre lo muestro en 2 formatos: streaming para web y uno en alta calidad para que lo bajes y estudies offline. Además, puedes descargar el material utilizado para este videocast.
]]>Ya he comentado sobre las características de este nuevo estándar, y en este momento nos concentraremos en una maqueta funcional utilizando las nuevas etiquetas y sus nuevas posibilidades. Es interesante saber que podemos utilizar elementos de HTML 5 en estos momentos aunque la mayoría de los browsers aún no lo soporten; esto se debe a que CSS puede dar estilo a cualquier etiqueta, aunque ésta prácticamente no exista (aún). Por ejemplo, si me da la gana puedo inventar una etiqueta propia y darle estilos:
<jorge></jorge>
jorge {
display: block;
width: 300px;
height: 100px;
border: 1px solid #666
}
Aunque semánticamente no va a tener valor alguno para los buscadores (y menos para los usuarios). Pero en este artículo comencemos a armar una estructura completamente en HTML 5:
<header>
<p>Header</p>
</header>
<nav>
<p>Menu</p>
</nav>
<section>
<p>Section</p>
<article>Article</article>
<article>Article</article>
</section>
<footer>
<p>Footer</p>
</footer>
Por defecto CSS asume que un elemento es inline. Para elementos definidos en HTML 4 como <div> ó <fieldset>, los estilos predeterminados por el browser para estas etiquetas los sobreponen y los hacen bloques, pero por esta vez lo haremos manualmente para las nuevas etiquetas HTML 5 que vayamos a utilizar:
header, nav, section, article, footer {
display: block;
}
Luego podremos definir los estilos para crear la estructura que nos convenga:
header {
width: 90%;
overflow: hidden;
}
nav {
width:20%;
float: left;
margin-right: 1%;
}
section {
width:67%;
float: left;
}
article {
background: #999;
}
footer {
width:90%;
overflow: hidden;
clear:both;
}
Los browsers modernos no tendrán problemas hasta ahora; sin embargo los hechos en Redmond se rehusarán a mostrar los estilos CSS hasta que tengamos que enseñarles a comportarse como se debe. Por suerte con una pequeña ayuda de Javascript crearemos estos elementos para que IE sepa qué hacer con ellos y los estilos ya definidos:
document.createElement("header");
document.createElement("nav");
document.createElement("section");
document.createElement("article");
document.createElement("footer");
Ahora un ejemplo utilizando la nueva etiqueta <video />, la que (por estos momentos) utiliza el codec Ogg Theora para comprimir los videos (necesitarás Quicktime ó similar para poder exportarla en este formato). Con un poco de JS podremos manejar los botones de comando y la línea de tiempo de las películas sin mayores complicaciones, como en el siguiente ejemplo:
function Play(str) {
var video = document.getElementById(str)
video.play();
}
Ver ejemplo 3 (en Safari 4, Opera 10+, Firefox 3.5+, Chrome 2+)
Links:
]]>Desarrollar pensando en 3 versiones de browser de una misma empresa, cada uno menos peor que el otro, es un problema grave. En este artículo, quiero compartir mi experiencia sobre cómo lograr los menos problemas posibles, creando un layout que se vea de manera similar en la mayoría de los navegadores disponibles en el mercado. Básicamente enunciaré algunos consejos prácticos que por mi experiencia ayudan en esta ardua tarea:
Usar un buen reseter CSS.
No pretendo difundir el mío, pero sinceramente no me ha dado problemas de ningún tipo y me acompaña siempre en mis grandes proyectos. Con él, me permito reescribir los estilos que defina como prioritarios, sin perder tiempo en arreglar los defectos de IE6. Un impresindible en grandes proyectos.
Entender cómo funciona IE6.
No basta con cabecearse cuando encuentras un descalce en tu layout que piensas funciona perfecto en todos los navegadores, hasta que lo pruebas en IE6. Deberías conocer -y prevenir- que IE6 tiene problemas posicionando relative/absolute/fixed, con el modelo de caja, doble margen a elementos flotados, utilizando z-index, soportando canal alpha para archivos PNG, con porcentaje como unidad de medida, con overflow, con pseudo-classes, con min-height, max-height, min-width, max-width… etc, etc, etc. Con eso en mente, puedes evitar muchos problemas desde el comienzo.
Tener mucho cuidado con IE7.
Microsoft lo presentó como una necesaria actualización a IE6, pero fue un gran FAIL. Arregló algunos bugs, pero sacó a luz otros nuevos; realmente me intriga qué sucede con el departamento de informática de esa compañía, cómo logran caer en los mismos errores una y otra vez. El principal problema de IE7 es el uso de position: relative/absolute aunque me he deparado con algunos errores menores por ahí.
Usar meta-tag para IE8.
Siento que Microsoft se apresuró mucho en lanzar IE8, probablemente presionada por las contínuas mejoras de sus compeditores Opera, Safari y Mozilla. A raíz de esto, he visto como de una actualización a la siguiente el comportamiento de este browser respecto al renderizado de HTML y CSS es muy diferente, muy pero my diferente; a tal nivel de que un cliente reclame que su nuevo y flamante sitio no se vea bien en este navegador, y antes que yo pudiera investigar qué estaba sucediendo el cliente me comenta:
Bah, ahora se ve bien… actualice IE8 anoche y se arregló.
Mi solución hasta ahora es una alternativa que viene de la misma casa de Redmont: una etiqueta <meta> que hace que IE8 se comporte como si fuera IE7; así de simple. Hace lo mismo que el Compatibility Button, pero lo ejecuta desde el comienzo de la carga del documento:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>
Probar, probar, probar…
Aunque seas un master de las hojas de estilo y del HTML, no deberías dejar para el final probar en los principales browser, y menos aún confiarte del preview de Dreameaver (grave error); debes probar casi que a cada nueva definición de propiedad. El costo de volver atrás es muy alto como para arriesgarte, no pierdas tu tiempo por confiarte demasiado. Probando en Safari y Firefox primero, luego en IE7 e IE6 para los detalles menores… pero nunca, nunca maquetar para IE: lo más seguro es que tendrás que deshacer más de lo que ya hayas hecho.
Links
]]>¿Qué marcaría una diferencia? El diseño, obviamente es lo primero que encanta; contenido bien estructurado y ordenado, pensado hacia una mejor buscabilidad y encontrabilidad; funcionalidades útiles y no sólo efectistas, también. Pero insisto, ¿cómo lo llevamos aún más allá?
La accesibilidad es la capacidad de acceso a la web y sus contenidos por todos los usuarios, independiente de la discapacidad física, intelectual o técnica que tengan.
Si escribimos nuestro XHTML con una semántica correcta y con el diseño separado en su propia hoja de estilos, ya estamos aportando a una mejor acccesibilidad permitiendo a los ciegos leer el contenido a través de un lector de pantalla, además de independizar el dispositivo sobre el cual será vista la web (teléfonos celulares, laptops, computadores de escritorio, etc.). Si tenemos el tamaño de los textos de una dimensión considerable y ojalá en una unidad relativa que sea independiente de la resolución del usuario, estaremos garantizando mejor accesibilidad a usuarios con problemas visuales. Ahora, si le damos la posibilidad al usuario de escojer el tamaño te fuente que más le acomode, mejor aún.
Estas normas mínimas de accesibilidad pueden aumentarse con muy poco esfuerzo, y ahora me gustaría presentar uno que no es muy utilizado pero no por eso menos importante: el atributo accesskey. Con él, permitimos que el usuario navegue por enlaces sólo con el uso de teclas especificadas en el desarrollo del sitio. Su implementación es bastante rápida:
<a href="index.html" accesskey="i">Inicio</a>
Así, permitimos que se pueda ir a la página de inicio no sólo haciendo click en el enlace, sino que utilizando la combinación control+i del teclado. Lamentablemente esta combinación es arbitraria por plataforma:
- Chrome: Alt+Accesskey
- Firefox: Alt+Shift+Accesskey (Win) Ctrl+Accesskey (Mac)
- IE: Alt+Accesskey
- Opera: Shift+Esc+Accesskey
- Safari: Ctrl+Accesskey
Además, deberías indicarle a tus usuarios la tecla correspondiente al accesskey, y los selectores avanzados de atributo son una gran ayuda:
a:after {
content: " [" attr(accesskey) "] ";
}
]]>
Esta es una joya… nunca, pero NUNCA había visto un <div> dentro de la etiqueta <title>… ¡Al parecer pretendían implementar los estándares desde el comienzo del código HTML! Quedé anonadado…
]]>Bien eso era lo primero que quería dejar claro; he visto demasiados <li>, <h1>, incluso <p> clickeables. Ahora, a lo que va este artículo es cómo la semántica se está dejando atrás por la comodidad de escribir eventos mediante JS. Me culpo también por caer en lo mismo, pero me interesa ahora mostrarles la mejor solución que he encontrado al respecto.
Pongámonos en un caso de ejemplo. Supongamos que se agrega una función para ejecutar un slideToggle a un enlace; por lo que he visto generalmente esto se hace de 2 maneras:
<a href="#" id="ejecuta_toggle">Ejecutar slideToggle</a>
Cumples con tener un href funcional (no vacío) pero puede hacer que al hacer click la página haga scroll hasta el inicio dado que tienes un ancla vacío en el href y quizás tengas que dar un return false al final de la función del slideToggle, ó
<a href="javascript:void(0)" id="ejecuta_toggle">Ejecutar slideToggle</a>
Que hace que el browser no ejecute el enlace y no se salga de la misma página.
Enfin, son 2 métodos similares y que cumplen con el objetivo primario de ejecutar algun comportamiento mediante Javascript a través de un hyperlink. Pero nuevamente mi pregunta: ¿Qué sucede con la semántica? ¿Cómo le digo al buscador, indexador, robot que ese <a> no es un enlace realmente? ¿Que lo estoy disfrazando para cumplir con mis objetivos?
Complicada pregunta y simple respuesta. Con esta inquitud espero que puedan ir más allá en sus desarrollos; recuerden que un simple click puede desencadenar muchos más eventos que los que tienen planificado para él, eventos que benefician a sus usuarios mediante indexaciones más precisas.
La solución
Entreguen una ancla semántica al hyperlink, pero una ancla sobre sí mismo. Ejemplifico con lo mismo que he estado utilizando:
<a href="#ejecuta_toggle" name="ejecuta_toggle" id="ejecuta_toggle">Ejecutar slideToggle</a>
Con este método conservan la semántica indicando a través del atributo name qué hará ese mismo enlace y al mismo tiempo evitan el movimiento de scroll de la página.
]]>