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:
]]>¿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) "] ";
}
]]>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.
]]>Me puse a indagar por la web y encontré varias discusiones sobre qué solución es mejor que otra, y ninguna fue conclusiva. No hay solución aparente que funcione de igual manera para todos los browsers y que sea utilizada, por ejemplo, con comentarios condicionales. Básicamente me encontré con 2: una que involucra HTML pero la mejor manera de implementarlo es mediante Javascript y la segunda sencillamente con Javascript. Explicaré ambas a continuación, pero antes el HTML común que sería del tipo:
<select>
<option>Primero</option>
<option disabled="disabled">Segundo</option>
<option>Tercero</option>
</select>
Solución 1
Para que IE interprete la opción <option disabled="disabled">Segundo</option> como deshabilitado, debes cambiar la etiqueta <option> por <optgroup>; el problema es que <optgroup> se compone ligeramente diferente de <option> por lo que el HTML quedaría así:
<select>
<option>Primero</option>
<optgroup label="Segundo">Segundo</optgroup>
<option>Tercero</option>
</select>
Esta solución funciona perfecto en todos los browsers, por lo que puede ser hecho automáticamente mediante jQuery:
$('option:disabled').each(function(){
var texto = $(this).text();
$(this).replaceWith("<optgroup label='"+texto+"'>"+texto+"</optgroup>")
});
Como el problema es sólo de IE, prefiero encerraro en un if() que detecte el browser como podrán apreciar en el ejemplo. Además, notarán que <optgroup> tiene una leve diferencia de estilo que <option disabled="disabled"> pero que se puede subsanar fácilmente mediante CSS.
Ver solución 1 (en IE notarán)
Solución 2
Esta solución no es una solución en sí sino un parche para el problema: ya que IE no considera el atributo disabled, entonces cada vez que el <option disabled="disabled"> sea seleccionado por el usuario (tomando en cuenta que todos los otros browsers no dejarán que sea seleccionado) la selección será automáticamente trasladada al primer <option> del <select>, vale decir del ejemplo HTML si hago click a <optgroup label="Segundo">Segundo</optgroup>, automáticamente seré redireccionado a <option>Primero</option>. El JS:
$('option:disabled').css('color','gray');
$('select').change(function(){
checkDisabledOptions(this);
});
function checkDisabledOptions(el){
if(el.options[el.options.selectedIndex].disabled){
el.selectedIndex = 0;
}
}
Esta solución es una mezcla entre jQuery y Javascript puro, tomada de la mejor implementación encontrada de entre 20 otras vistas; es la más simple y con menos líneas de código. Además, para esta solución es bueno siempre en el primero item del <select> la opción <option>Seleccione</option> o cualquiera que sea que no tenga un value válido (value=""), así aportamos a la accesibilidad y podremos validar ese ítem de formulario.
Ver solución 2 (en IE notarán)
Espero Rodrigo te haya servido, y gracias por hacer me ver este tema; me entretuve bastante resolviéndolo.
Links:
]]>Como he escrito muchas veces ya a lo largo de este sitio, las tablas son para contener datos tabulados. Sólo para eso, esa información desagradable que suelen acompañar a los gráficos, esos nombres y números que a nadie le gusta. Para eso está <table>, para ordenar esos datos y nada más. Y bueno, ahora que ya tiene su función, aprendamos a utilizarlo bien.
<table>
<tr>
<td>Nombre</td>
<td>Edad</td>
</tr>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</table>
Una simple tabla que contiene valores cualesquiera. Ahora, le daremos sentido a sus etiquetas.
<th>
Table Header Cell, una celda de título de una tabla. La utilizamos cuando tenemos el título de una fila o columna, y tiene propiedades por defecto, por ejemplo, su contenido se despliega en bold.
Si la aplicamos a nuestra tabla básica de ejemplo, sería de la siguiente manera:
<table>
<tr>
<th>Nombre</th>
<th>Edad</th>
</tr>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</table>
<caption>
Esta etiqueta le da un título a la tabla, como un <legend> lo es para su <fieldset>.
<table>
<caption>Tabla de edades</caption>
<tr>
<th>Nombre</th>
<th>Edad</th>
</tr>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</table>
summary
Atributo de la etiqueta <table>, especial para lectores de pantalla (no-videntes). Aquí, nos explayamos un poco más que en <caption>, explicando extensamente de qué se trata nuestra tabla.
<table summary="Tabla donde se muestran nombres de personajes de un programa infantil junto con sus edades hipotéticas">
<caption>Tabla de edades</caption>
<tr>
<th>Nombre</th>
<th>Edad</th>
</tr>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</table>
<thead> <tfoot> <tbody>
Filas se pueden agrupar en un encabezado (<thead>), un cuerpo de contenido (<tbody>) y un pie (<tfoot>), pudiendo cada grupo contener una o más filas. Con esto se hace más fácil darle estilos a las secciones de nuestra tabla, así nos ahorramos classes en cada celda. Otra ventaja es en la impresión, si ésta es muy larga en Firefox por ejemplo se imprimirán el encabezado y el pie en cada hoja (independiente si el cuerpo es muy extenso y no cabe en la impresión).
<table summary="Tabla donde se muestras nombres de personajes de un programa infantil junto con sus edades hipotéticas">
<caption>Tabla de edades</caption>
<thead>
<tr>
<th>Nombre</th>
<th>Edad</th>
</tr>
</thead>
<tfoot>
<tr>
<td>Bajada</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</tbody>
</table>
Un detalle es que si usan <thead> y <tfoot>, deben ir juntas y consecutivas, antes de <tbody>. Aún así, <tfoot> se mostrará debajo del contenido de <tbody>. Si no lo necesitan, ocúltenlo con su método favorito.
Está de más escribir que bgcolor, height, width, align y nowrap están obsoletos y no son soportados en HTML 4.01. Además, no se recomienda el uso de background dentro del HTML, para esto se utlizan hojas de estilos CSS.