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):
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:
A partir de necesidades específicas de fabricantes de browsers y de tecnologías, se han creado algunos valores que son específicos, como:
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.
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.
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.
]]>Recapitulando, los microformatos nacieron bajo el alero de ampliar estándares semánticos aplicados a la www. La idea es que los indexadores y buscadores sean más inteligentes y entreguen datos más precisos en cuanto nosotros desarrolladores y profesionales dedicados a la web entreguemos mejor esos datos.
¿Y eso en concreto? Ya estaremos viendo resultados, con el anuncio de Yahoo! de incluir soporte a estándares web semánticos, incluyendo los microformatos en sus búsquedas. Excelente iniciativa.
Comencemos la diversión. Estos son los principales formatos disponibles:
Se usa para representar personas, compañías, organizaciones y lugares, utilizando propiedades vCard y valores en semántico HTML ó XHTML. Ha sido ya implementado en software, por ejemplo, AddressBook de Apple. Es muy común incluir sus vCards en los emails enviados, para tener constante actualización de los datos del destinatario.
En el siguiente ejemplo, verán cómo se construye un hCard, básicamente a base de id‘s y class‘es ya definidas por el estándar:
<div id="hcard-Jorge-Luis-Epuñan-Hernández" class="vcard">
<a class="url fn n" href="http://www.be-studios.com">
<span class="given-name">Jorge</span>
<span class="additional-name">Luis</span>
<span class="family-name">Epuñan Hernández</span>
</a>
<div class="org">Be Studios</div>
<div class="adr">
<span class="locality">Santiago</span>
<span class="country-name">Chile</span>
</div>
</div>
Definido para formatos de eventos calendarizados, basado en el estándar iCalendar y adaptado para su uso en HTML o XHTML, RSS y cualquier XML. Muy útil para tu blog, si quieres publicar algún evento, como un cumpleaños. Así, los spiders de búsqueda u otros agregadores pueden leer ese evento marcado como microformato, convertirlos automáticamente a formato iCalendar y utilizarlo en iCal, software de Apple que ya utiliza este estándar, para dar un ejemplo.
Ejemplo:
<div class="vevent" id="hcalendar-Mi-Cumpleaños">
<a class="url" href="http://www.csslab.cl">
<abbr class="dtstart" title="20080218">February 18th</abbr>,
<abbr class="dtend" title="20080219"> 2008</abbr>
<span class="summary">Mi Cumpleaños</span>
</a>
<div class="description">
Mi cumpleaños número 27. Oh sí, anque tengo muchas canas no soy anciano.
</div>
</div>
Se usa para reseñas de productos, servicios, empresas, eventos, lugares, etc.
Ejemplo en que un ficticio CCazorla hace un review sobre mi persona:
<div class="hreview">
<span class="reviewer">
<span class="fn">CCazorla</span>,
<abbr class="dtreviewed" title="20080325">25 de Marzo de 2008</abbr>
</span>
<a class="person url" href="http://www.csslab.cl"><span class="fn">Jorge Epuñan</span></a>
<div>Rating: <span class="rating">2</span> de 5</div>
<blockquote class="description">
<p>Perfeccionista por naturaleza, siempre busca superarse profesionalmente. Por dentro muy buena persona. Por fuera de personalidad extraña, un tanto psicopata.</p>
</blockquote>
</div>
Se basa en la propiedad ‘geo’ del estándar vCard, y agrega nuevas sub-propiedades para completar. Se tratan de id‘s específicos para coordenadas de latitud y longitud, las que se pueden agregar directamente en la página o XML mediante RSS o Atom, y ser indexadas para luego, por ejemplo, mostrar la ubicación directamente en GMaps.
Ejemplo:
<div class="geo">Araxá:
<span class="latitude">37.0625</span>,
<span class="longitude">-95.677068</span>
</div>
Existen algunos más, como Dublin Core, XFN, FOAF, pero están aún en etapas de definiciones y aprobaciones, lo que hace ver lejana su estandarización. Pero no dejan de ser buenas intenciones para necesidades reales, en contínuo desarrollo.
¿Mi opinión? Son un gran aporte a la web semántica y la catalogación de la información que componen las páginas porque, sobre todo, Internet se compone prioritariamente de información. Sólo faltan ser lanzados definitivamente y dados a conocer, además de ser integrados en los software de desarrollo y gestores de contenido web (CMS). Finalmente ahí podremos ver su real potencial, con la llamada Web 3.0.
Los Microformatos son abiertos para que cualquiera pueda utilizarlos, y permiten información de contacto, relaciones sociales, direcciones, coordenadas, etc.
Un ejemplo práctico. Imagínese que tienes un blog y escribes un artículo sobre un restaurant que visitaste recientemente y te encantó el lugar y la comida. Lo quieres recomendar y escribes tu reseña, para finalmente entregar el nombre del lugar, la dirección y si tiene sitio web probablemente la enlaces. Súper, pero: ¿Qué pasa si además, entregas las coordenadas? Así, a través de geo puede ser integrado con Google Maps y poder mostrar gráficamente el camino de cómo llegar al lugar. Así, un lector de tu blog puede leer tu artículo desde su dispositivo móvil favorito, y llegar al restaurant cómodamente siguiendo el mapa directo desde Google, o guardándolo como favorito para consultarlo después.
Su uso sería de la siguiente forma:
<span class="geo"><span class="latitude">-33.42</span>, <span class="longitude">-70.61</span></span>
Se utilizan class que son leídos y entendidos por otras aplicaciones, ya que son estándares por medio de las especificaciones de hCard de Microformats.
Microformatos permiten que las personas tengan control sobre sus propios datos e informaciones, a través de la estandarización en el marcado HTML. Esto ayuda a que los buscadores indexen y entreguen información cada vez más precisa y correcta, siempre y cuando ésta haya sido bien formatada . Si creías que ya hacías un buen trabajo aplicando semánticamente las etiquetas HTML a tu contenido, con Microformatos te estarías elevando a lo que se especula será la Web 3.0. Es una iniciativa que aún está en desarrollo, pero que ha dado mucho que hablar y que tiene un futuro promisorio.
Leyendo un artículo de Lêda Spelta (psicóloga de Brasil experta en accesibilidad) me tomo la molestia de citarla, traducir y completar parte de su interesante artículo: Accesibilidad web: 7 mitos y un equívoco.
Ellos son sólo una parte de quienes se ven perjudicados con sitios mal construídos. Accesibilidad es para quienes:
Por supuesto que lo primero que se nos viene a la mente… "¡Cómo cresta lo hago para todos ellos!". Pues si te acostumbraras a escribir código semántico, atendiéndote a los estándares ya estás matando 3 pájaros de un tiro. Además si sabes optimizar bien las imágenes y utilizarlas sólo cuando es estrictamente necesario, otros 4 pájaros caen con esa misma bala. Como ves, no es trabajo doble, sólo el mismo que haces pero bien hecho.
Eso es algo lógico de pensar, pero que no puedes mesurar. La mayoría de los usuarios que conoces probablemente no cumpla con ningún tipo de deficiencia nombrado anteriormente, pero es no dice que todos quienes entren a tu sitio no lo sean. Recuerda que si publicaste algo en Internet, se lo publicas al mundo entero; cualquiera puede entrar y verlo, no sólo quienes conoces. Y cualquiera de ellos son posibles clientes.
Aquí se aplican los factores costo/beneficio. Pero, como ya fue mencionado, el diseñador/desarrollador debe estar capacitado para aplicar la accesibilidad en todos sus proyectos, a mediano rango. Este mediano rango sería estructurar un código semántico y utilizando estándares web, siempre cuidando el peso de imágenes y uso de objetos externos. Un rango alto y donde sí se requiere mayor experticia y dominio es un sitio web totalmente optimizado para ciegos, donde se utiliza una hoja de estilos diferente y se aplican otras técnicas. Y es un deber de grandes empresas (masivas y públicas) proveer este tipo de servicios a sus consumidores.
¿Mejor para quién? El diseñador tendrá doble trabajo, al igual que el mantenedor de esas páginas. Deficientes estarán perjudicados, ya que lo más común es que este sitio especial esté siempre desactualizado.
Bueno, hay que ser consecuentes. Las personas ciegas no pueden siquiera ver el diseño que estás aplicando. Pero aún así puedes utilizar fotos, videos, gráficos, audio, etc. Basta con que utilices sus etiquetas y atributos correctamente y los lectores de pantalla podrán leerle al usuario de qué se trata la foto, por ejemplo.
Es verdad que no podemos hacer todo al mismo tiempo y debemos priorizar. Aún así, si se construye un edificio con escaleras y luego hay que romperlas para poner rampas para sillas de ruedas es un desperdicio de tiempo y recursos. Y no queda del todo bien. En un sitio web es lo mismo, los parches son a la orden del día.
Como ocurre con cualquier innovación, el primer proyecto demanda tiempo y costo en capacitación, ya que necesitamos enseñar al equipo cómo se hace. Pero luego el aprendizaje queda y se aplica fluidamente en los proyectos venideros, lo que se puede ver como un valor agregado dentro del costo de los mismos.
Normalmente cuando se afirma que un sitio está direccionado a un público específico, nos referimos que el contenido del sitio sólo tiene interés para un determinado porcentaje de usuarios. Pero esto no quiere decir que podemos alentar el interés de otros usuarios diferentes a los que teníamos en mente. Si restringimos el acceso de nuestro sitio al que juzgamos que son nuestro target, estamos en la práctica utilizando Internet para limitar nuestro público, en vez de ampliarlo.
]]>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.
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>
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>
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>
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.
Bueno en este caso, volveré a tocar el tema de las queridas listas en HTML. Son bastante útiles, ya que sus propiedades intrínsecas (el que sean elemento bloque y contengan bastante rígido su contenido) las hace muy maleables al momento de estructurar menús, por ejemplo. Pero como ando semántico por estos días, quiero aclarar qué son y cómo utilizar las listas.
Comencemos por lo básico. Una lista no es lo mismo que una secuencia. Una regla mental básica puede ayudarte a delucidar cuándo una lista es una lista:
Si creamos una lista y le quitamos sus marcadores (bullets o números) con CSS, entonces probablemente no es una lista
Esto hace ver que nuestro menú con listas no son semánticos. Los elementos de este menú son secuenciales, pero no necesariamente pertenecen a una lista. Les damos estilos, les ponemos fondos, cambiamos su color con :hover, pero si le quitamos los estilos, vuelve a ser una lista (ordenada o no) de elementos. No una secuencia. Entonces sí tiene sentido que sea una lista.
En HTML existen 3 tipos de listas:
Las listas de definición corresponden a pares de término y su definición.
<dl>
<dt>Beodo</dt>
<dd>Un beodo es un ebrio, borracho.</dd>
</dl>
<dt> corresponde a un definition term, o en castellano un término a definir. Ya <dd> es la descripción de ese término.
Listas desordenadas son viejas amigas. Se utilizan cuando no importa el orden de los elementos contenidos. Como por ejemplo, en los ingredientes del vital alimento del beodo:
<ul>
<li>vaso</li>
<li>cerveza</li>
<li>sed</li>
</ul>
Aquí da lo mismo el orden de los factores, el que no alterará el producto final.
Ya las listas ordenadas sí importa en qué orden las pongamos. Por eso por defecto, <ol> se renderiza con números secuenciales.
<ol>
<li>Toma la cerveza y ponla a esfriar.</li>
<li>Prepara tu sed, en 1 hora y media aproximadamente ya podrás saciarla.</li>
<li>Vierte la cerveza helada en un vaso y empina tu brazo hacia tu boca.</li>
</ol>
Espero haya quedado claro, y con esto ayude a que sus contenidos tengan más sentido a sus usuarios y principalmente a los buscadores, lo que les asegurará mejores posicionamientos en ellos.
A raíz de eso, les tengo un reto. A ver si conocían las siguientes etiquetas HTML, y su significado:
Con esta etiqueta estamos indicando que el usuario debe utilizar alguna tecla de su teclado para realizar alguna función.
<p>A raíz de esto, debemos presionar <kbd>ESC</kbd> para salir de la aplicación.</p>
Tal como deben de imaginarse, var indica una variable de algún lenguaje de programación. Tiene un estilo por defecto, el cual transforma la tipografía en monospace.
<p>En el siguiente código Javascript, la variable <var>validarCampo</var> se utiliza precisamente…..</p>
Introduce un término, o una definición a tu texto.
<p>Y cuando digo <dfn>beodo</dfn>, me refiero a cuando un ser….</p>
¿Habían utilizado alguna vez alguno de esos?