RFC8288: Web Linking

Según van pasando los años vamos viendo como aparecen más RFC relacionados con los elementos más simples de Internet y de los sitios web, y en esta ocasión voy a hablar del secreto de la red de redes: los enlaces. Sobre enlaces y links he hablado infinidad de ocasiones, quizá las últimas más destacadas fue cuando aparecía el HTML5, y cuando hablé del rel-canonical.

Los enlaces no son simplemente los «a» de la web, sino que en realidad hay muchas formas de enlazar, por lo que en el DOM (el sistema de elementos de una web) es más conocido por HTMLAnchorElement. Los enlaces tiene bastantes propiedades, y es de esto de lo que quiero comenzar a hablar.

Sin duda el elemento más clásico de un enlace es la ruta a la que hace referencia, que se indica mediante el href. Es curioso porque en HTML5 el href ya no es un elemento obligatorio como ha podido ser hasta ahora. Hoy en día gracias a los scripts, los data y otros elementos un enlace puede hacer «cosas» que en realidad no son ir a otra página.

Otro de los clásicos es el target, aunque hoy en día tiene una utilidad variable, sobre todo desde que los frame no se pueden/deben utilizar. Básicamente el importante es el de abrir en pestaña/ventana nueva.

• _self (por defecto): se abre en el contexto actual (la misma ventana/marco).
• _blank: se abre en un contexcto nuevo, lo que hoy en día es una pestaña nueva y antiguamente era una ventana nueva.
• _parent: se abre en la ventana padre, lo que en un ifreame sería en la ventana que lo llama.
• _top: en caso de que un iframe llame a otro iframe y llame a otro iframe (inception!) esto haría que se abra en la ventana padre total.

Por ejemplo, un enlace puede indicar directamente que un recursos es para descargar, muy útil por ejemplo cuando se enlaza a un PDF que no quieres que se abra en el navegador y sea leído por cualquiera de los plugins de los mismos. Es tan simple como esto:

<a href="https://www.javiercasares.com/seo/Guia-SEO.pdf" download<descargar PDF</a>

En 2009 Google introdujo un elemento que aunque no tiene utilidad válida práctica se puede considerar meta-información desde el punto de vista SEO, aunque se supone que Google ni lo utiliza; es el hreflang, que te ayuda a indicar el idioma de destino de la página. Esto tiene doble utilidad. Si lo utilizas siempre, pues es indicar el idioma por defecto de la página de destino, pero quizá el elemento más interesante es el de indicar internamente que estás apuntando a «la misma página en otro idioma».

Por ejemplo, podrías tener algo tipo:

Puedes leer esta página en <a href="https://example.com/es/" hreflang="es"<español</a> o <a href="https://example.com/en/" hreflang="en"<english</a>

Otro elemento más que interesante (que no tengo claro porqué Google Analytics no implementa) es el uso de ping. Este elemento poco conocido (y en este momento casi en modo experimental) lo que permite es indicar en un enlace a qué URL se ha de llamar cuando se pulsa en ese enlace, pero mediante método POST. Esto significa que si tenemos algo como:

<a href="https://example.com/seguir/" ping="https://example.com/analytics/ping/?url=seguir"<Seguir leyendo</a>

Cuando el usuario haga clic en el enlace, se hará una llamada de tipo POST a esa URL. Aunque parezca poco útil, puede ser muy interesante.

El siguiente elemento, más que interesante también, es el de los referrer, es decir, la política de información a enviar en el campo «Referrer:» de las cabeceras y que es muy utilizado en analítica (y que por ejemplo ha hecho que ya no se vean las «keywords» de búsqueda en Google Analytics. Con este elemento tan sencillo Google podría corregir eso a todos los niveles.

La idea es que (aunque se puede hacer a todos los niveles), en los enlaces, sobre todo externos, puedas indicar si quieres que la página de destino sepa o no que el tráfico viene de ahí. Existen unas cuantas posibilidades:

• no-referrer: que significa que no se manda nada.
• no-referrer-when-downgrade (por defecto): no se manda nada si estás en HTTPS y vas a una web con HTTP.
• origin: se manda siempre la información, pero solo del dominio (hostname).
• origin-when-cross-origin: se manda el dato completo si navegas por tu propia web, pero si te vas a otra web solo se manda el dominio. Mi recomendación personal (por ahora) es usar este.
• strict-origin-when-cross-origin
• unsafe-url: se manda siempre.

Pero sin duda lo más interesante y a donde quería llegar con esta entrada, es a la relación entre enlaces, los famosos «rel-algo». Como comentaba al inicio, quizá el más conocido es el rel-canonical por sus implicaciones SEO, pero hay unos cuantos más, unos que se usaban, otros que ya no se usan… la lista es extensa, pero voy a intentar comentar todos los que hay y los que posiblemente vengan. Estos elementos suelen funcionar en las etiquetas a, area y link.

alternate: Indica una página alternativa a la actual. Por ejemplo, si incluye un type de RSS [application/rss+xml] o Atom [application/atom+xml] automáticamente se da por hecho que esa página de destino es un feed. Se pueden incluir otras alternativas según el «media», el «hreflang», el «type» o su combinatoria.

author: Es un enlace a la página del autor. Otra opción es la de incluir no una página sino un mailto:, lo que lo enlazaría a una cuenta de correo.

bookmark: te permite crear un enlace relacionado con el «article» más cercano que incluya el identificador único de ese contenido; puede ser interesante en el caso de que en una página (por ejemplo una con listados varios) incluyan varios contenidos importantes.

canonical: poco voy a hablar del canonical, que ya escribí sobre él hace tiempo.

dns-prefetch: permite (poniéndolo en el «head») hacer llamadas a hostnames a los que posteriormente se hará referencia.

external: todos los enlaces que no sean de sitios nuestros (sobre los que tengamos control) deberían tener este enlace, muy habituales con el target-blank.

help: tanto si una página entera tiene otra página de ayuda relacionada, como cualquier enlace que vaya a la página de ayuda debería incluirlos.

icon: este elemento ayuda a incluir el famoso «favicon»; hay que recordar que es simplemente rel-icon y no se debe incluir nada más como rel-icon-shortcut.

license: si quieres indicar el tipo de licencia de la página, que normalmente es una URL (tipo Creative Commons o similar).

first, prev, next, last: creo que los nombres son bastante claros; esto va muy bien, sobre todo, para indicar las paginaciones (ya que cuando hay estas etiquetas sobre todo Google lo trata de forma distinto).

nofollow: indica que el autor no tiene relación o control sobre este otro contenido, porque es un mal ejemplo o porque hay una relación comercial, lo que implica que nunca debe usarse en linking-interno; en principio no tiene ningún valor ni afecta al usuario, pero los motores de búsqueda pueden decidir si utilizarlos.

noopener: principalmente por temas de funcionalidad y seguridad, a menos que uses JavaScript con el «Window.opener», todos los enlaces que tengan un «target» deberían incluirlo.

noreferrer: va en la línea de lo que he comentado varios párrafos anteriores.

pingback: en caso de que el sitio cruce mensajes con otro sitio, aquí se especificará la URL de comunicación de pingbacks, por ejemplo con XML-RPC.

preconnect: permite añadir hostname o URL a las que posteriormente se harán llamadas, de forma que se abre la comunicación para que luego sea más rápida.

search: permite indicar un sistema de OpenSearch (básicamente que puedas añadir el buscador del propio sitio web al buscador interno del nacegador).

shortlink: permite añadir una URL corta (bitly o similar) como alternativa a la URL pública del sitio.

stylesheet: la(s) hoja(s) de estilo, que ya no necesitan indicarles ningún otro elemento más, como por ejemplo el type (por defecto es [text/css]) aunque sí que le puedes incluir un «alternate» para distintos tipos de dispositivo.

tag: cuando en una entrada tienes etiquetas, puedes apuntar su enlace hacia esa etiqueta donde debería haber información sobre la misma y, probablemente, otros artículos a los que hace referencia.

Además de estos elementos, que son más o menos comunes, hay la posibilidad de incorporar otros tantos. Algunos de estos ya están en funcionamiento en los navegadores importantes aunque otros simplemente son futuras propuestas.

import: aplica el sistema de HTML Imports, aún en desarrollo, pero algo documentado; hay información de MDN y del W3C.

modulepreload: cuando se usen módulos de JavaScript y como alternativa al preload, se puede usar el sistema de pre carga de módulos.

prefetch: es una manera de abrir y pre cargar contenidos antes de que se muestren por pantalla… principalmente útil para imágenes o elementos que con casi completa probabilidad el usuario acabará teniendo que descargar; de esta forma cuando se llamen ya se habrá establecido la conexión.

preload: similar al anterior, este va bien para elementos tipo scripts o estilos, ya que te permite hacer llamadas a scripts en la cabecera de la página aunque luego se ejecuten en el pie, de forma que cuando se llegue a ejecutar esa parte ya estén precargados.

prerender: si sabes que el usuario va a navegar a otra página o elemento, permite que al acabar de cargar la página, se sigan cargando elementos; por ejemplo cuando entras en la página principal de Google no haría falta que se carguen los JS o CSS de los resultados, pero es casi 100% seguro que acabarás haciendo una búsqueda, así que ya precargas esos datos para lo que viene.

Y como interesantes, los que están documentados pero aún no implementados…

disclosure: como el concepto indica, aquí aparecerán datos que aunque no son requeridos en el contenido, sí que indican esas fuentes de información que puedan ser necesarias; se encuentra en el RFC6579.

version-history, latest-version, working-copy, working-copy-of, predecessor-version, successor-version: todos estos, sacados del RFC5829, parecen hechos nada más y nada menos que para la propia documentación de los RFC… sobre todo porque estos documentos son básicamente todos casi iguales y el hecho de que los motores de búsqueda sepan y sean capaces de generar el historial de versiones es importante (lo mismo que podría servir para la Wikipedia o para un Git).

Y ya para acabar, comentar que aunque existan todos estos sistemas para entrelazar sitios, páginas y contenidos, lo importante es simplemente hacer lo que creas conveniente y lo que el sentido común te diga, con un elemento principal en la cabeza: enlazad, compartid y haced que Internet sea cada vez más grande.