6.1. Introducción

6.1.1. Hiperenlaces

Ya se ha dejado establecido que lo que convierte al hipertexto en hipertexto son los hipervínculos. Relacionados con ellos, existen tres conceptos muy recurrentes:

URI

En castellano Identificador Uniforme de Recurso, es un identificador que permite declarar inequívocamente en internet cualquier recurso. Por lo tanto, cada recurso debe tener uno y que sea único. Ahora bien, hay dos modos de identificar un recurso: por su nombre o por su ubicación. Estos dos son los conceptos que se presentan a continuación.

URN

En castellano, Nombre Uniforme de Recurso, es un nombre único que identifica a un recurso inequívocamente en internet.

URL

En castellano, Localizador Uniforme de Recurso, es la ubicación en la que se encuentra el recurso. Como en el caso anterior, forzosamente es única.

Por hacer un símil. Si hablásemos de personas, en vez de recursos, la URN sería su nombre y la URL la dirección de su domicilio. Ahora bien, si intentamos identificar a una persona por su nombre, no podremos si existen dos personas con idéntico nombre; y, si por su domicilio, tampoco si en una misma casa viven varias. En el caso de los recursos, esto no sucede, porque nombre y ubicación deben ser únicos.

Un ejemplo real de URL y URN se halla en la definición del tipo de documento cuando son dialectos XML estandarizados y públicos:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

En esta definición para XHTML 1.0, hay una URN:

-//W3C//DTD XHTML 1.0 Strict//EN

y una URL:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd

Esta última es la ubicación del DTD que define la gramática del dialecto.

6.1.1.1. Formato

Dado que la base del hipertexto es el hipervínculo, que debe llevarnos a la ubicación de otro hipertexto, es previsible que en la redacción de un HTML requiramos escribir URLs, por lo que es muy importante saber cuál es su formato exacto. En principio, podemos definir este formato del siguiente modo esquemático:

esquema://maquina/ruta

que puesta en ejemplo concreto es:

http://docs.iescdl.es/~josem/XML/07.html/01.intro.html

Las partes constituyentes son:

esquema (http)

Identifica el tipo de recurso, por lo general, el protocolo de servicio por el que se accede a ellos. Por ejemplo:

  • http para páginas web.

  • https para páginas web en que la conexión es cifrada.

  • ftp para ficheros a los que se accede por FTP

maquina (docs.iescdl.es)

Es el nombre de la máquina (o la dirección IP) en la que se encuentra el recurso. Ahora bien, su expresión puede ser un poco más complicada para admitir más información:

[usuario[@contraseña]:]maquina[:puerto]

Si el recurso está protegido, puede añadirse antes del nombre de la máquina un usuario y su contraseña. Si se accede a la máquina a través de un puerto no estándar, entonces es también posible añadir cuál es ese puerto.

ruta (/~josem/XML/07.html/01.intro.html)

Es la ruta del recurso dentro de la propia máquina. Cuál sea esta ruta dentro del propio sistema de ficheros de la máquina, depende de la configuración del servidor web, pero se comporta de manera semejante a como lo hacen las rutas en los sistemas UNIX. Trataremos esto bajo el próximo epígrafe.

Nota

Incluso en los ejemplos en los que, aparentemente, no hay ruta, sí la hay. Por ejemplo, ante esta petición sin, aparentemente, ruta:

http://www.example.com

el servidor web añada una ruta que depende de cómo se haya configurado. Habitualmente, /index.html o /index.php.

6.1.1.2. Rutas absolutas y relativas

Del mismo modo que las rutas de un sistema de ficheros, las URLs pueden ser:

absolutas

Son aquellas que expresan la ubicación indicando toda la información: esquema, máquina y ruta. Las rutas indicadas bajo el epígrafe anterior son rutas absolutas:

Un concepto importante que es necesario introducir es el de

http://docs.iescdl.es/~josem/XML/07.html/
relativas

Son aquellas que expresan una ubicación tomando una referencia y, en consecuencia, no necesitan especificar todos sus componentes (esquema, máquina, etc.), ya que algunos, gracias a la referencia, se sobreentienden.

Para proseguir es necesario explicar cuál es esta referencia: la URL base es la URL que se toma como referencia para construir una URL absoluta a partir de una URL relativa. Son de dos tipos:

  • De archivo como:

    http://docs.iescdl.es/~josem/XML/07.html/01.intro.html

  • De directorio como:

    http://docs.iescdl.es/~josem/XML/08.css/

Se diferencian unas de otras en que las URL base de directorio siempre acaban con una barra.

Las URLs relativas se utilizan cuando desde un documento se refiere otro. Cuando es así, la URL base es la URL absoluta del propio documento[1] y la URL relativa podrá adoptar dos formas:

URL relativa absoluta (terminología propia)

Es aquella que empieza por una “/” y equivale a la URL absoluta que se obtiene de concatenar el esquema y la máquina de la URL base a la propia URL relativa. Por ejemplo:

URL Base

URL relativa

URL absoluta

https://docs.iescdl.es/~josem/XML/index.html

/a/b/c.html

https://docs.iescdl.es/a/b/c.html
URL relativa relativa (terminología propia)

Es aquella que no empieza por “/” y equivale a la URL absoluta que se obtiene de concatenar la URL base con la URL relativa, sabiendo que en el caso que la URL base sea de archivo, hay que eliminar el propio nombre del archivo. Como en el caso de las rutas UNIX el directorio .. equivale al directorio padre.

URL Base

URL relativa

URL absoluta

https://docs.iescdl.es/~josem/XML/index.html

c.html

https://docs.iescdl.es/~josem/XML/c.html

https://docs.iescdl.es/~josem/XML/index.html

../c.html

https://docs.iescdl.es/~josem/c.html

https://docs.iescdl.es/~josem/XML/index.html

https://docs.iescdl.es/~josem/index.html

https://docs.iescdl.es/~josem/

c.html

https://docs.iescdl.es/~josem/c.html

Nota

Como puede apreciarse la cadena vacía es una URL relativa válida y equivale a una URL absoluta igual a la URL base.

6.1.1.3. Enlaces internos

Es muy frecuente que al incluir un hipervínculo queramos enlazar no ya con una página HTML, sino con una parte concreta de la página HTML. Para ello, es necesario que la página destino contenga elementos que se hayan marcado con identificadores:

<section id="mamiferos">
   <h1>Los mamíferos</h1>
   <p>Bla, bla, bla</p>

   <section id="hominidos">
      <h1>Los homínidos</h1>
      <p>Bla, bla, bla</p>
   </section>

   <section id="felinos">
      <h1>Los felinos</h1>
      <p>Bla, bla, bla</p>
   </section>
</section>

Hecho así, para que el hipervínculo enlace directamente con el elemento interno deseado, basta con añadir #mamiferos a la URL si es que se quiere enlazar con la sesión dedicada a los mamíferos, ya que este es el valor que hemos dado al identificador correspondiente. Por tanto:

http://www.losanimales.org/descripcion.html#mamiferos

podría ser una URL absoluta válida. Mientras que:

#mamiferos

podría ser el valor de un hipervínculo válido si el enlace está en la propia página.

6.1.1.4. Otros hipervínculos

Además de las rutas anteriores en las que siempre se ha presupuesto que el protocolo era HTTP o HTTPs, para cuyo destino el agente apropiado es el propio navegador, existen otros tipos de recursos externos accesibles por distintos medios. Tradicionalmente, estos se han reducido a dos: FTP (para cuyo protocolo los navegadores también solían traer soporte) y correo electrónico:

<a href="ftp://ftp.rediris.es">FTP de rediris</a>
<a data-rel="external" href="mailto:pepe@gmail.com">Email de contacto</a>

Si la configuración es adecuada, en el segundo caso el navegador se encarga de invocar al programa de correo electrónico. Pero con la proliferación de los teléfonos inteligentes, los enlaces ajenos al navegador han proliferado y pueden adoptar muchas formas:

<a data-rel="external" href="tel:+34959959959">Teléfono de contacto</a>
<a data-rel="external" href="skype:manolo?call">Contacto a través de Skype</a>
<a data-rel="external" href="sms://+34959959959?body=Estoy%20interesado.%20Ll%E1meme.">Envíar SMS</a>

Ver también

En este tutorial se explica cómo incluir en un enlace mailto: asunto, destinatario, etc.

6.1.1.5. Data URIs

Una página HTML es un documento de texto que suele referir distintos contenidos de diverso tipo (scripts, hojas de estilos, imágenes, etc.). Todos estos contenidos se obtienen gracias a la indicación de su URL absoluta o relativa:

<img alt="Logo de HTML5" src="images/html5.png">

HTML5 incorpora un mecanismo, llamado datos URIs, para sustituir la URL por el contenido del archivo, de suerte que el archivo queda embebido dentro del propio documento HTML. Puede llegar a ser muy útil en algunos casos, como cuando se necesita cambiar al vuelo una imagen vectorial en función de las acciones del usuario. El formato de estos data URIs es el siguiente:

data:tipo-mime[;base64],<datos>

Como por ejemplo:

<script src="data:application/javascript,alert('¡Hola, mundo!');"></script>

donde en este caso el tipo MIME es «application/javascript» y los datos un minúsculo código Javascript, que hubiera estado incluido en un archivo, si no hubieramos hecho uso de un data URI. La codificación en base64[2] es útil cuando los datos son binarios (p.e. si representamos una imagen PNG). Por ejemplo, el ejemplo anterior para incrustar el logo de HTML5, podría escribirse así:

<img alt="Logo de HTML5" src="data:image/jpeg;base64,
iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ
bWFnZVJlYWR5ccllPAAAAs1JREFUeNq8VztvE0EQnnsFxbJxlCAEIiAoiC0qOxJpkCAoHRIKLR0V
FRJdWugQBRX8EBASDUIkSGlC4XTEpsDiIVEAcsA6x77Hsrs5+24ft7d+6FY6rc8+z8x+M983cwbg
9f32yjre3kO+6+by69a2Gd3sQ/6L+jSGdxgFNImVwqKp/WwwAOh3Q/oZn576tqc9hjVnjBGAeEaT
hyRP+HkEOkJ01brSimGYYJ+ey/TmN/fojhASfClT4Gy9UBp2HAcK5XJmAH/vXzlOgQfKFOzwP6Kv
n6fGOmh9lH29IwtAWKjXnWniUSAWobIGhNPsvgH49TM2aJnQX5pX/if8/SP+HICyBgQWoIMGQCUu
xBAHEJLvEqt/xpqKBWZevAt9uc4lA2gLCLj/2Icrq5PnP2RuR74YGePlmOiAioqEhuUMGrrP7lEd
ICro/mFlONcUkD6QlQKhEJE7PQ2Db59A5YNXwg4vRGGzkW7csiFYLLInWq6CUSgJdSSTYa1u6D19
kP4bMcDRsPjkLRPAKFhPbsOWwLPOPHD3IRgXLmsFRBFYOpeA/0CpAbIADoWOh52blfpkBdCLaRxn
gPUxNguMU2fTh5Pz1XQh8pBWCrbx9UjoiAkEnK3ntDCJTAeNDzjfNti1DbBX1sCqXJXOARIf+kUI
HBUJAhZB4dotmHceQ0ljHkg0oUwd6MxSfEYUZNsw40OYKGXTMZFks36dFmOSETIpJpXv77+jg8gw
BWkyrD0VkxY8asOFIlg4GIP0ibUN3OW6EDSxs9Yedcw3MBqAryhqCQJf8HZRF+aSxjww6KLh+0Ab
I3Api4btmfR/XHheD8HRYQgDN0y1bc+y6Eiu/T6+Bum8z0xB4mV1M5LlmsrAiZPmseMjpBq/CPdf
kZdRrQC4YBbwdgdfN6J9IeMv7cghGb1fYqedsRHICKgWIbOZaFz0hGTHDsd6xfsvwAB8ABqbrMgq
HwAAAABJRU5ErkJggg==">

6.1.2. Versiones

Tim Berners-Lee creó el HTML en 1990 como un dialecto SGML, aunque sin una definición formal mediante DTD. En 1993 se publicó como borrador una especificación que sí incluía un DTD, por lo que se puede considerar que es a partir de esa fecha cuando HTML pasa a ser formalmente un dialecto SGML. Se publican posteriormente tres versiones del lenguaje, ya definido como SGML:

  • HTML 2.0, en 1995, que es la primera especificación formal del lenguaje.

  • HTML 3.2, en 1997, que fue publicada ya por el W3C.

  • HTML 4.01. en 1999.

HTML4

En esta última versión, el W3C intentó desligar la definición estructural (reservada para HTML) de la visual (reservada para CSS), por lo que se propuso ir eliminando las marcas y atributos HTML que definían aspecto, marcándolas como obsoletas. Para hacer menos traumático el cambio definió tres versiones del estándar:

  • Frameset, que permitía el uso de iframes y elementos y atributos obsoletos:

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

  • Transitional, que permitía el uso de elementos y atributos obsoletos:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

  • Strict, que no permitía el uso de elementos obsoletos:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

    En principio, la versión recomendada por el W3C era esta última.

XHTML

En este punto (1999), el W3C, que era el encargado de desarrollar el lenguaje, pretendió darle un giro y adaptarlo a las especificaciones XML, que habían sido publicadas por este mismo organismo también en 1999. Como consecuencia reformuló HTML 4.01 para adaptarlo a las reglas del XML y publicó en 2000 la especificación XHTML 1.0. Al ser una reformulación, también disponía de las tres versiones:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Los esfuerzos entonces del W3C se centraron en el desarrollo del lenguaje como dialecto HTML, esto es, en el XHTML y abandonaron por completo el sabor SGML que quedó estancado en la versión 4.01. En consecuencia en 2001 publicó XHTML 1.1 en que ya sólo había una única versión:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
HTML5

El W3C continuó en los años siguientes el desarrollo de XHTML 2 del que llegó a publicar borradores, abandonando por completo HTML. Como respuesta a esta política de abandonar HTML, surgió en 2004 el WHATWG[3], un grupo que aglutinaba a los principales creadores de navegadores web[4] y que en contra de los deseos del W3C, que abogaba por XHTML, quería seguir desarrollando HTML. Comenzó entonces un pulso entre ambos grupos, que venció el WHATWG al admitir el W3C en 2007 la creación de un grupo de trabajo en su seno sobre HTML. Este grupo en enero de 2008 publicó el primer borrador de la especificación de HTML5, mientras que el último borrador de XHTML se había publicado en 2006 y nunca se llegó a publicar el siguiente que debía haber aparecido en julio de 2009. De hecho, en 2009 el W3C decidió que a final de año se disolviera el grupo de trabajo sobre XHTML lo que suponía oficialmente reconocer que él único estándar reconocido sería HTML5. En 2014, apareció la primera recomendación oficial del W3C sobre HTML 5.0.

Nota

En un primer momento, WHATWG optó por hacer del estándar HTML una norma viva, esto es, una versión que no se atiende a números sino que está en continuo proceso de redacción. De hecho, la norma ni siquiera refiere el 5 en su título. El W3C, en cambio, optó por publicar cada cierto tiempo una versión númerada. Fue así como publicó 5.0 en 2014, 5.1 en 2016 y 5.2 en 2018, versiones que se basaban en la versión viva y lo que realmente los navegadores implementaban de esa versión viva. Sin embargo, a comienzos de 2021 se renunció a publicar la versión 5.3 y dejó de publicar versiones numeradas, por lo que sólo la norma viva del WHATWG es la referencia actual del lenguaje.

HTML5 introdujo novedades substanciosas (por no decir disruptivas) sobre las versiones anteriores de HTML:

  • Introdujo una API que posibilitara el desarrollo de aplicaciones web complejas. Esa es la razón por la que Javascript se pudo incorporar plenamente como tecnología web y hemos conocido cómo se han desarrollado auténticas aplicaciones que ejecutamos en el propio navegador.

  • Soporte nativo para contenido gráfico y multimedia con elementos como video, audio o <canvas>.

  • Soporte para SVG y MathML.

  • Virar el lenguaje HTML hacia la creación de documento plenamente semántico con etiquetas como article, section, nav, etc.

Esta es la historia, pero ¿es HTML5 entonces SGML? La respuesta es que no. HTML no es ya SGML, porque no hay definido ningún DTD para su validación y, además, es imposible definir uno, ya que hay ciertas reglas que son inexpresables con la sintaxis del DTD. Esa es la razón por la que la declaración de tipo de documento es, simplemente:

<!DOCTYPE html>

que ni siquera es una declaración SGML válida.

Ver también

Consulte esta respuesta de stackoverflow para más información.

Por otro lado, el propio estándar define dos sintaxis distintas para la norma HTML:

Los apuntes se centrarán en la sintaxis HTML, aunque se definirán más adelante las pautas para saber escribir con sintaxis XML.

Ver también

Eche un vistazo a la representación gráfica de la evolución de las tecnologías web.

6.1.3. Tecnologías asociadas

El servicio de páginas web no se restringe exclusivamente al uso del HTML, sino que hay multiples tecnologías implicadas. Las más destacadas son:

  • CSS para aplicar aspecto visual al código HTML.

  • Javascript (cuyo estándar recibe el nombre de ECMAScript), que se usa como lenguaje en el lado del cliente, esto es, en el propio navegador a fin de dotar de dinamismo a las páginas. Es posible crear auténticas aplicaciones web que se ejecutan integramente en el ordenador del cliente con sólo unos pocos datos que se reciban del servidor.

  • Lenguajes de programación en el lado del servidor que hacen de enlace entre el servidor y las bases de datos. La estrategia puede variar:

    • desde generar toda la página web en el servidor y transferirla al cliente completa.

    • a limitarse básicamente a servir datos en un formato adecuado (XML, JSON) y construir la página en el cliente gracias a Javascript.

    Los lenguajes de servidor más utilizados son el propio Javascript (usando NodeJS), PHP, Python y Java.

6.1.4. Herramientas

Para hacer más sencilla la escritura de nuestro documentos, podemos hacer uso de algunas herramientas:

6.1.4.1. Edición

Para escribir los documentos HTML (y CSS) es indispensable usar al menos editores de texto con resaltado de sintaxis. Son alernativas:

  • vim, el editor.

  • nano, básico, pero suficiente.

  • Visual Studio Code, que ya hemos utilizado al escribir XML, YAML o JSON y al que podemos añadirle alguna configuración adicional para facilitar la escritura de HTML. Lo tomaremos como editor de referencia también para este bloque de tecnologías web.

6.1.4.2. Validación

Es muy conveniente comprobar la validez de los documentos HTML para lo cual podemos usar validadores en línea como:

HTML

Existen también extensiones para navegadores (como Validity para Chromium) que permiten la comprobación de la página que se está viendo en la pestaña activa. Por lo general, sin embargo, no permiten la validación de documentos locales.

CSS

Nota

Si se usa Visual Studio Code pueden integrarse estas validaciones dentro del propio editor. Consulte ls instrucciones para escribir con él HTML.

6.1.4.3. Recetarios

Los recetarios presentan de modo resumido los elementos del lenguaje a fin de ofrecer una referencia rápida. Existen muchos:

HTML
CSS

6.1.4.4. Visualización

Para comprobar nuestras páginas HTML es obvio que necesitamos un navegador reciente que soporte convenientemente HTML5 y CSS3. Cualquiera de los más usados debería valernos:

En principio, nos bastará con almacenar en el disco local los archivos y acceder a ellos abriéndolos con el navegador. Si usamos Visual Studio Code, tendremos facilidades para realizar la operación.

Ver archivos, locales, sin embargo no supone una transferencia HTTP, lo cual tiene importancia, pero no para los objetivos del curso que son modestos. En cualquier caso, es posible improvisar un miniservidor web para alojar nuestras páginas:

  • Visual Studio Code nos lo permite a través de la extensión Live Preview.

  • Una alternativa universal es montar un modesto servidor con Python, para lo cual podemos hacer lo siguiente:

    $ cd /ruta/a/los/ficheros
$ python3 -m http.server 8080

    Y listo. Un servidor web local escuchando en el puerto 8080.

Sea como sea, los ordenadores modernos incluyen todos una herramienta de desarrollador a la cual (al menos en derivados de Firefox y Chromium) se accede pulsando Ctrl+Shift+i, o bien, colocándonos sobre alguna parte de la página web y abriendo el menú contextual eligiendo «Inspeccionar». En este segundo caso, la herramienta se abrirá en la pestaña en la que se presenta el DOM completo y justamente seleccionado el elemento HTML correspondiente. Es muy potente y nos permite:

  • Consultar y alterar el DOM.

  • Consultar y alterar los documentos adicionales cargados (p.e. alguna propiedad CSS).

  • Analizar la carga de archivos.

  • Abrir una consola de Javascript y ejecutar código.

  • etc.

Ver también

Si quiere profundizar en esta fantástica herramienta, puede echarle un vistazo a este artículo de MDN sobre la herramienta de Firefox. En realidad, todas funcionan de forma semejante, así que puede valernos su lectura aunque utilicemos otro navegador.

6.1.4.5. Pruebas de concepto

Es frecuente que, cuando creamos documentos web, necesitemos realizar una prueba de concepto sobre algún particular de HTML, CSS o Javascript. Por supuesto, podemos hacer pruebas sobre un documento local, pero existen páginas en internet que nos permiten realizarlas directamente sobre ellas y compartir el resultado con otros desarrolladores:

jsfiddle.net

Es un sitio web que permite crear pruebas de concepto en HTML, CSS y Javascript, y compartirlas con otros desarrolladores, bien para resolver dudas ajenas, bien para resolver las propias. Por ejemplo, esta es una prueba con jsfiddle e incluso se puede obtener el HTML que genera la prueba añadiendo /show a la dirección y guardando el frame apropiado.

codepen.io

Sitio alternativo al anterior con el mismo propósito y las mismas funcionalidades. Esto, por ejemplo sería una prueba en codepen.io

jsbin.com

Sitio semejante a los dos anteriores, aunque presenta algunas particularidades como una consola de Javascript.

mdn

Otra alternativa más incluida en el sitio de MDN.

Notas al pie