Cualquiera puede cocinar… HTML

Cualquiera puede cocinar

Chef Gusteau (Ratatouille, Pixar)

No importan los grandes esfuerzos que ha hecho The World Wide Web Consortium (W3C) al desarrollar protocolos y directrices que aseguren un crecimiento de la Web saludable; la naturaleza del lenguaje de marcado HTML hace que detrás de lo que vemos en nuestros navegadores sea una verdadera jungla.

No importa qué tan semántico piensen los de la W3C que sea HTML5 o qué tan potente crean que sea CSS, van a seguir apareciendo cosas como estas:

<form id="commentform">
  <p class="pleft">
    <label for="autor_1">Nombre:</label><br/>
    <input type="text" name="author" id="autor_1" value="" size="22" tabindex="5" class="field" />
  </p>
</form>

¿Qué hay de malo en esto? Absolutamente nada, para mi amigo que lee Cubadebate eso no importa, lo importante es el contenido, lo que ve. Para Firefox importa poco qué haya usado el desarrollador Web. Pero para los que realmente quieren una web semántica o que se haga un uso correcto de las tecnologías, lo anterior está completamente mal.

Primero un necesario párrafo dedicado al HTML. HyperText Markup Language, o Lenguage de Marcado de Hipertexto simplemente se utiliza, como su nombre lo indica, para marcar el contenido. Esto es importante solo para las máquinas al final, el resultado depende de cómo se marcó el documento.

Cualquiera puede cocinar… con ingredientes incorrectos

Primero, la etiqueta <p> fue concebida para definir un párrafo, ¿creen ustedes que en ese trozo de código exista algún tipo de párrafo?

Claro que no, en este caso <p> actúa como un simple wrapper o contenedor, con el único objetivo y justificación para utilizar la clase pleft que a mi juicio tampoco dice nada.

Segundo, la etiqueta <br/>, se utiliza para producir saltos de línea, no para la separación del contenido. Sin comentarios.

A mi juicio el marcado debió ser de otra manera

<form id="comment-form">
  <div class="comment-form-field">
    <label for="autor_1">Nombre:</label>
    <input type="text" name="author" id="autor_1" value="" size="22" tabindex="5">
    </div>
</form>

Junto con el código CSS

.comment-form-field {
  propiedad: valor;
}

#comment-form label {
  display: block;
}

Este es solo uno de los ejemplos del maluso y maltrato del HTML y CSS, describirlos otros acá quedaría en un TL;DR; y no quiero aburrirlos.

Limitaciones de las recetas con ingredientes HTML

Es cierto que en sitios web y aplicaciones de dimensiones monstruosas es muy tedioso mantener la semántica. Generalmente en estas situaciones se utiliza algún tipo de framework para aliviar la carga.

Por solo citar un ejemplo, siguiendo el trozo de código anterior, la clase pleft realmente no dice nada, pero que inevitablemente está presente en la mayoría de los frameworks y clases CSS, solo para especificar que el elemento flote a la izquierda .pleft {float: left;} de modo que se pueda reutilizar en cualquiera de las etiquetas del HTML.

La culpa de esto no la tiene nadie, el constante cambio nos obliga a evolucionar y en el caso particular del HTML el layout de los elementos siempre ha sido una problema.

Actualmente el layout de cualquier sitio se resuelve con sistemas de grid que utilizan propiedades de CSS que no fueron concebidas para tal cosa, un ejemplo de esto es la propiedad float.

Mi opinión es que han llegado muy tarde flexbox y grid para solucionar estos problemas.

Tienes que cocinar con ingredientes limitados

Pues sí, no te puedes inventar ningún ingrediente, los definen otros más importantes que tú y nunca serán suficientes. Por ejemplo no puedes hacer algo como esto:

<receta>
  <título>Batido de mango</título>
  <listadeingreditentes>
    <ingrediente>agua</ingrediente>
    <ingrediente>leche</ingrediente>
    <ingrediente>azucar</ingrediente>
    <ingrediente>2 mangos</ingrediente>
  </listadeingreditentes>
  <preparación>
    Mezcla todos los ingredientes en la batidora.
  </preparación>
</receta>

Por tanto no podemos ser creativos e impresionar a los comensales.

Cuidado para quién cocinas

No puedes cocinar de la misma forma para todos, hay ciertos clientes que no les gustan algunos ingedientes (te estoy mirando IE) y otros que no sienten los sabores de la misma manera.

Hartoconocido este problema desarrollar aplicaciones o sitios que se visualicen y funcionen uniformemente en todos los navegadores es una tarea dificilísima, polyfills, hacks, javascript para que tu plato final le guste a todos.

¿Cualquiera puede cocinar HTML?

Sí, cualquiera puede cocinar pero cocinemos bien aún teniendo las limitaciones y la falta de ingredientes.

¿Te resultó interesante? Compártelo ...



oneohthree

Publicado por oneohthree

https://github.com/oneohthree » Forma parte de GUTL desde el 6 diciembre, 2011. sysadmin, usuario de Debian y Arch,

Este artículo tiene 5 comentarios

  1. Amigo, pusiste el dedo en la yaga. Yo mismo me pillé varias veces metiendo CSS inline(usando el atributo style) solo para probar como se ve, y al ver que lucia bien asi se quedaba. Solo lo pude superar con DISCIPLINA.

  2. Ufff, me llega de cerca este post. cuantas cosas obvia uno por vago o por dejarse llevar por la rutina…. 🙂

  3. Una vez consulté a @oneohthree sobre que bibliografía era útil para el diseño Web, la respuesta fue concisa, » las referencias de la W3C» -gracias-. Desde mi humilde opinión -no soy diseñador Web, ni informático- la mejor forma de crear sitios robustos y que se desempeñen óptimamente, es conociendo en profundidad la estructura que compone una página HTML, esto evitará algunos dolores de cabeza en el futuro, además de entender mucho mejor el uso de ciertos frameworks.

    No solo el ejemplo que evidencia @oneohthree es erróneo, viendo el código fuente de la página en cuestión está muy desordenado. Encolumnar ordenadamente los elementos también debería se una buena práctica. Cuando uno crea una página Web para un tercero tal vez no piensa que otro informático pudiera contribuir o hacerse cargo del mantenimiento del sitio Web.

    Para alguien que tuviera los conocimientos necesarios en HTML, CSS si le ofrecieran mantener y por ende aplicar otras funcionalidades a esa página ¿Qué haría?

    1. Refactorizar el código -no se cual sería el término adecuado para HTML-
    2. Reescribir todo el código desde cero
    3. Añadir nuevo código al existente

    Definitivamente descartaría la 3ra. opción 😀

Los comentarios están cerrados.