Cultura Digital#Blog

Desde que hablé del tema, desde luego han cambiado no pocas cosas tanto en mi sistema CSS como en la plantilla base con la que me estoy partiendo los cuernos acerca de decidir, definitivamente, cómo hacerla – o sea, planificación: 0 -… pero eso es otro tema.

La cuestión es que me he dejado llevar y he olvidado la base de la semántica, de la lógica y de las enseñanzas de los gurús CSS, algo por otra parte no poco habitual cuando se habla de «clasitis», «divitis» o incluso «identiditis».

Esto, en parte, es el primer error en el desarrollo -o uso- de un framework CSS; que, como ya dije, no es que deba estar mal por sí mismo, pero sí suele ocurrir que su comodidad, y el intento de abarcar el mayor número de posibilidades y opciones -reglas CSS-, hace que nos dejemos llevar y perdamos la perspectiva.

El problema

Como decía, el problema surge cuando cogemos brío al especificar reglas de todo tipo -amplitud de opciones- y perdemos el foco:
Y el foco no es más que una de las principales reglas de semántica, de porqué HTML se adaptó a XML, del peso de un documento pero, sobre todo, de eso: de su sentido.

Ejemplo

Por que, sin darnos cuenta, empezamos a usar cosas como:

<em class="red">Atención</em>

cuando en realidad deberíamos usar

<em class="important">Atención</em>

Creo que no hace falta explicarlo, ¿no?

¿Qué diferencia podría haber entre estas tres reglas?:

<em font-color="red">Atención</em> <!-- Marcado obsoleto y no válido -->
<em style="color:red;">Atención</em> <!-- Marcado estándar pero de presentación -->
<em class="red">Atención</em> <!-- Marcado válido con CSS pero no semántico y de presentación -->

Ninguna.

La diferencia es un simple intento de validación -incluso engañarse a sí mismo- pero en la práctica y hablando de optimización, es lo mismo: En todos los casos es añadir estilo a la estructura, es aumentar el peso del documento, es añadir datos que no son necesarios, -por añadidura y por ejemplo en un lector de pantalla, como datos XML, de exportación o, en cualquier caso, en bruto- cuando en el caso de usar una clase definida como importante, el elemento adquiere relevancia y, sobre todo, sentido.

Y aún hay más ya en el tema de desarrollo, algo más que evidente también y tan antiguo como el diseño basado en tablas -para presentación me refiero-:
En este ejemplo, ¿qué pasa si un día decido cambiar mis alertas o avisos: class="red"?
Alguien diría: «pues nada, cambias las clases al color o estilo nuevo que decidas, es de imaginar que habrá una regla para azul, verde…»
Vale, al margen del primer caso y tener más bien poco que ver una clase llamada red con un color azul,… ¿cambiamos todas las clases que hemos codificado, recuerdo, en el marcado del documento???, ¿qué hemos ganado respecto del marcado basura?

Conclusión

Lo que quiero decir es que, usar CSS no significa ser semántico, accesible y estándar. Tu código puede validar pero eso no significa que sea correcto.

¿No puede haber reglas que definan estilos visuales?. Si hablamos desde CSS: por supuesto, están diseñadas para eso; el problema es usarlas o aplicarlas mal. No veo, tampoco, nada malo en tener reglas que definan colores: es un método de acceso a los mismos fácil, el problema es aplicarlos a la estructura como estilo incrustado y para eso…: no es necesario CSS: simplemente escribir marcado de presentación y no preocuparse por validar.
Si se prefiere hacer así, cada uno es libre de hacerlo, aunque yo evidentemente no lo comparta; y siempre sin olvidar la optimización y el aumento de peso del documento -datos-. Recordemos que siempre será más fácil y óptimo cachear archivos estáticos -en mayor o menor grado- y pequeños como por ejemplo CSS, que documentos completos y que, a parte de ser más pesados, seguro tienen posibilidad de cambiar en no pocas ocasiones.

Resumamos

¿No puede haber atributos que definan estilos visuales? Siempre en mi opinión: pues no, no debería haberlos en un documento bien formado y semántico, siempre que los mismos no lleven carga semántica, es decir, no si solo son de presentación; repito: para eso, precisamente, se creó CSS.

Paradojas y complicaciones

No obstante… existen algunas paradojas:
¿Quién no usa hoy en día una clase para flotar cajas o al contrario?: La cuestión es que estas reglas deberían definir el estilo de cajas -o el elemento que sea- de forma genérica y no estricta, al igual que el ejemplo de los colores.

¿Reglas estrictas o genéricas?

Por ejemplo deberíamos imaginar que un bloque flotado a la izquierda, es decir, el típico atributo de clase left, podría significar, representar una caja de contenidos, unas notas, una miniatura de imagen… y podríamos aplicar reglas en forma de:

1
2

.tocBox, 
.imgThumb { float:left; }

en lugar de

.left { float:left; }

Es decir, especificar reglas para flotar cualquier elemento a la izquierda o, personalizar, generalizar, elementos estándares que conocemos se flotarán a la izquierda: una caja de contenidos, una imagen de miniatura sobre el documento o sección. Ejemplo:
Imaginemos que quiero flotar otro cuadro de imagen a la derecha, por estética pura se debería usar una regla genérica para cualquier elemento class="right", pero algo nos dice que ese elemento debería poseer sentido, incluso si continuara siendo algo meramente estético. Veamos algo simple:

Miniaturas relevantes al contenido flotadas a la izquierda class="entrycontentImg"
Miniaturas relevantes al contenido flotadas a la derecha class="entrycontentImg2"

Las reglas CSS correctas no deben ser estrictas respecto al diseño sino a su sentido, para que el marcado conserve el mismo. Así, mañana puedo cambiar las ubicaciones de las miniaturas sin modificar el marcado, el cual conservará su significado: ambos cuadros seguirán siendo imágenes que representen el contenido (entrycontentImg), independientemente de donde los sitúe CSS, y mis reglas no serán ilógicas -mantenibilidad- por ejemplo con casos como imgLeft que la sitúe a la derecha y/o viceversa.

Elementos estándares frente a frameworks no semánticos

En cualquier caso, es en estos casos donde un framework pierde su sentido y se desvía del uso correcto. Es la denominada «clasitis». De ahí personalizar un framework para poder codificar elementos estándares en nuestros diseños.
Los estándares nos han enseñado que funcionan, que son útiles, los hay para todo diseño en la vida -o casi todo-. ¿No es ya, de hecho, un estándar la estructura: wrapper-container, header, menú, content, footer...? Con el auge de los blogs han nacido otros elementos que prácticamente ya son estándares: .entry, .post, .feedback, .comments y funciona, y todo tiene sentido ^^!
Igualmente podemos generar más: .entryImg, .entrycontentImg, .avatar, ..., además, la evolución del marcado web y estos estándares entronca con los microformatos. No se trata de globalización y pérdida de riqueza, no en este caso; se trata de optimización, utilidad y mantenimiento, pero más aún se trata de humanizar el lenguaje máquina, de darle sentido y que precisamente nos sea útil :)

Fin

Así deberíamos hacerlo y siempre aplicar estilo debería ser algo a trabajar en el CSS no editando la estructura.

En definitiva, no sé como me ha pasado todo esto pero yo mismo he caído en mis más agresivas críticas del marcado basura. Y lo cierto es que no hay excusa, sólo que: el lado oscuro es muy atractivo :mrgreen:
Es muy difícil resistirse a la facilidad al codificar con un class=”red|blue|black”, etc…