Soy Charly

¿Qué significa que algo signifique algo? En HTML quiero decir; desde lo filosófico es una cosa sumamente compleja en la que no me pienso meter. ¿Qué queremos decir cuando decimos que un botón es un botón? Y... ¿a quién le importa?

Antes de empezar

Resulta ser que en términos de internet, una página (por ejemplo esta misma página) es un documento. Algo así como un documento de Word, o una foto, pero que ves desde tu navegador.

Ese documento está escrito usando un lenguaje que se llama HTML. En HTML definimos un documento usando etiquetas, como pueden ser <code> o <img>.

Resulta que algunas de estas etiquetas significan cosas, y otras como <div> o <section> en realidad no, y esto es un poco a propósito.

Este post de lo que va a tratar es de por qué esto es así, y cómo se explota de manera eficiente. Pero como todo esto viene de algún lado, primero veamos cómo llegamos acá.

Historia antigua

El lenguaje “padre” de HTML es un lenguaje que se llama SGML. En *SGML * alguien tiene la brillante y útil idea de definir un documento como un dato más, una cosa que es, una entidad.

Este documento no tiene ninguna clase de instrucciones de formato, presenta la data y de hecho esto es a propósito, el lenguaje se pensó para intercambiar mensajes entre computadoras. Lo que sí tiene es una especie de prefacio, el DTD o Document Type Definition, que lo que hace es describir en absoluto detalle qué forma tiene que tener cada parte del documento y en qué consiste.

Un espectáculo.

Eventualmente (en 1991) un tipazo que se llama Tim Berners-Lee arma encima de internet/ARPANet la cosa que absolutamente todo el mundo cree que es internet hoy: La World Wide Web. Este groso hace el primer navegador, el primer servidor web, el primer mecanismo por el que las dos cosas saben vincularse entre sí, y resulta que el lenguaje de marcado que elige crear está basado en SGML y se llama HTML.

En ese primer HTML los documentos tienen que tener alguna clase de información de presentación, porque los va a leer gente y es importante que la gente pueda distinguir un título de un link (cosa que no existía, repito, hasta 1991 no existían los links entre páginas). Ahí es donde toda la elegancia se va directo al tacho sin escalas.

Empieza a haber distintos tipos de tags, con la división más “popular” por decirle de algún modo siendo estructurales (<h1>, <a>) y presentacionales (<font>, <small>) , y empieza a haber alguna clase de concepto de que las dos cosas son fundamentalmente distintas.

El camino andado

Con el correr del tiempo y los estándares (a HTML le nace un hermano, CSS, para definir más claramene cómo se tiene que mostrar el document, aparece un standard hijo XHTML del que no hablaremos nunca más... pasaron cosas) algo de lo más importante que se descubre es que a veces no sólo queremos que personas lean nuestros documentos, sino que también queremos que máquinas los lean.

A veces porque esas máquinas le leen a algunas personas (toda esa disciplina se llama accesibilidad), a veces porque esas máquinas nos van a dar algún dinero (cierta megacorporación lee el contenido de tus páginas para saber qué anuncios mostrar), lo cierto es que la gran realización es que las máquinas necesitan poder saber de manera absolutamente inequívoca qué es lo que estás mostrando, más que como se ve.

Este argumento de que tu página tiene que tener un significado evidente para un programa empieza a cobrar sentido comercial, y se gesta una mini revolución alrededor de una página que se llamó CSS Zen Garden que te venía a mostrar cómo hacer que un documento “bien” marcado, con etiquetas semánticas más o menos claras se viera de maneras radicalmente distintas teniendo exactamente el mismo “sentido” estructural. Iniciativas como Microformats intentan encontrar patrones para describir cosas de manera común y uniforme.

Todos los próceres nerds estaban abocados a la tarea de mejorar Internet.

Hoy

Y un día también mandamos todo eso un poco al tacho. Con el advenimiento de frameworks/librerías como React, Vue, o paquetes como Bootstrap o Tailwind10, es cada vez menos común ver marcado que verdaderamente guarde relación con lo que “significa”, porque todas esas herramientas te permiten escribir tu documento de forma que tenga sentido para el desarrollador independientemente de lo que se le da al usuario final: Un componente <Button/> de React no tiene ninguna clase de obligación contractual de terminar siendo un <button> de HTML, puede terminar siendo algo como

<p>
  <span />
  <img />
</p>

Sin que el desarrollador sienta ni un poco de culpa. De su lado se sigue viendo como si fuera un botón, y eso tiene más importancia para quienes diseñan estas herramientas que qué cosas llega de tu lado.

Pero no es que la gente que necesita un software para leer la página se haya ido del planeta, haya muerto o algo. Tampoco dejaron las corporaciones de querer leer tus páginas para mostrar publicidad.

Entonces, cómo hacemos?

Herramientas

HTML 5 trae consigo un montón montón de elementos útiles para que puedas describir tu página en términos lógicos y entendibles, e iniciativas como ARIA para que cuando te ves obligado a hacer alguna cosa horrible como lo que mencionaba antes de un <Button> super personalizado puedas explicarle a los distintos programas que te van a leer exactamente en qué consiste esa cosa que hiciste.

El mayor desafío hoy, y para mí donde reside el arte en 2020, es encontrar la manera más expresiva “de base”, sin agregados, para describir tu documento. Veamos un ejemplo.

Si bien sigue siendo posible ignorar todo y por ejemplo describir una tarjeta de una persona de esta manera:

<div class="card card--container">
  <div class="card card--person">
    <div class="row">
      <div class="col col--6 is-title is-title-large">Person McPherson</div>
      <div class="col col--6">
        <img src="https://person.example.org/photo.jpg"/>
      </div>
    </div>
    <div class="row">
        <div class="col col--12">
            Last Online: <span>Yesterday</span> 
        </div>
    </div>
  </div>
  <div class="card card--contact">
    <div class="row">
      <div class="col col--3"><i class="icon icon--telephone"/> Tel</div>
      <div class="col col--9"><a href="tel:+1123123456">+1123123456</a></div>
    </div>
  </div>
  <div class="card card--share">(...)</div>
</div>

Es casi igual de sencillo plantear lo mismo de un modo muchísimo más amable de parsear tanto por un software asistivo como por cualquier agente que consuma nuestro HTML:

<article class="card h-card">
  <header>
      <h1 class="p-name" id="person-mcpherson-name">Person McPherson</h1> 
      <figure>
        <img loading="lazy" src="https://person.example.org/photo.jpg" data-is-external-image="true" alt="Foto de perfil de Person McPherson">
        <figcaption>From October 2020 archive</figcaption>
      </figure>
  </header>
  <aside class="card card--online-status">
  Last Online: <time datetime="2020-10-18T20:20:20.20-0300">Yesterday   
  </time></aside>
  <section class="card card--contact">
    <dl>
      <dt class="has-icon icon--telephone">Tel</dt>
      <dd> <a href="tel:+1123123456" class="p-tel" aria-label="Mobile phone">+1123123456</a> </dd>
    </dl>
  </section>
  <aside class="card card--share">
    (...)
  </aside>
</article>

Esta segunda versión expone mucha más información, e incluso es más fácil escribir un parser que tome este HTML y “sepa” qué es cada fragmento incluso si hago algún cambio en el orden en el que están puestas las etiquetas! Un <figcaption> es el caption de una figure independientemente de donde esté; lo mismo pasa con un <time>. Nunca no va a ser una representación de un momento.

Incluso nos dimos el lujo de explicarle a un potencial parser qué tipo de teléfono es el que estamos dando. Y en menos líneas!

No puedo recomendar más fuerte investigar al respecto, creo que es una de las cosas que termina causando que seas mejor developer.