Interesantísima esta entrada de Minid, segunda parte de una anterior, sobre la más que recomendable separación entre contenido y presentación a la hora de diseñar páginas web. En su entrada, Diego juega con algunas páginas de Mercadelia, y muestra como sin prácticamente tocar una línea de código puede modificar completamente el contenido de una página para hacerlo aparecer, por ejemplo, completamente en árabe (con alguna leve modificación para que el árabe aparezca escrito de derecha a izquierda en lugar de hacerlo a la inversa).
El tema me ha recordado poderosísimamente a mi época como profesor de hoja de cálculo, porque el mantra «entradas, procesos, salidas» era algo que repetíamos a los alumnos sin parar. En su momento llegué a escribir dos artículos en PC World al respecto, «Hojas de cálculo: las grandes desconocidas» y «Hojas de cálculo: el proceso productivo hasta el final«, que de hecho fueron los primeros artículos que publiqué, allá por el año 1996, y siguen online por cortesía de IDG. Mis amigos (y ex-alumnos) Kiko Rial y Purificación García Bandera acabaron de hecho escribiendo un libro de Anaya Multimedia con esos principios y con los casos que utilizábamos en clase, «Modelos económicos y financieros con Excel«.
Al principio, año 1990, poquísima gente sabía utilizar una hoja de cálculo. Con el paso de los años, hacia el ’95 ó ’96, empezó a ocurrir algo peor: ya más gente sabía usarla, pero usarla no era ni mucho menos sinónimo de usarla bien, más bien todo lo contrario. Nos encontrábamos con algo que aún sigue ocurriendo, y es que la gente mezclaba de manera inmisericorde las celdas de entrada de datos con las de fórmulas, haciendo incomodísima cualquier modificación o análisis posterior. Nos dedicábamos a proponer ejercicios y a rastrear que ni una sóla de las celdas de la zona de entradas contuviese ni el más mínimo atisbo de fórmulas: sólo texto y números, so pena de escarnio público. Por contra, en la zona de procesos, únicamente podía habre fórmulas, ni un sólo número, y mucho menos dentro de una fórmula, eso era pecado mortal. Los alumnos llegaban pensando que sabían usar la hoja de cálculo, cuando en realidad lo que sabian era como ser absolutamente improductivo con ella y cómo convertir su vida en miserable cuando tenían que analizar cosas posteriormente, no sabían dentro de qué sitio estaban los parámetros a cambiar, y acababan cometiendo errores de bulto o siendo muchísimo más lentos de lo que deberían.
Con el código pasa algo muy parecido, aunque a mí me pilla exactamente del otro lado: no sé escribir buen código (no hay más que ver el de esta página), pero sí sé escribir cuatro tags, de manera que eso me convierte en peligroso: sé lo suficiente para escribirme mi página, pero no lo bastante como para hacerlo bien. Por supuesto, no separo presentación y contenido, y mi página es un asquito. Curioso paralelismo. Y eso, después de tanto predicar…
Nunca es tarde para aprender algo nuevo.
En cuanto a lo de las hojas de cálculo, toda la razón. El personal hace un cursito de iniciación a Office y se cree que domina excel a la perfección. Y luego vienen los problemas. Ser usuario avanzado de Office (me refiero a avanzado de verdad) tampoco está al alcance de todo el mundo.
Y otra gran ventaja de escribir buen código es, como apuntabas críticamente en un post hace unos días, facilitar las cosas a los buscadores y ser, por ello, ‘premiada’.
Lo cual (y en eso creo que discrepo contigo) tiene sentido porque al separar contenido (el código XHTML) de presentación (las hojas de estilo), tienes más facilidad para dotar de significado semántico a tus textos y estructurar el contenido correctamente. En definitiva, haces un *poquito mejor* el contenido de la web.
Hay muchísimas ventajas más, claro, pero citarlas aquí ya sería irme por las ramas.
Un último comentario al respecto. En realidad no es tan difícil aprender a escribir un buen código.
Para cualquiera que tenga algunas nociones de XHTML, la dificultad no se halla tanto en una falta de conocimientos sino que, fundamentalmente, el problema radica en que a la hora de confeccionar una página debe cambiarse de mentalidad y hacer las cosas con bastante más orden y claridad de lo acostumbrado. Exactamente lo mismo que comentas de las hojas de cálculo.
Lo importante de escribir buen código, sea para XHTML, PHP o CSS es que te permita escalar o dar pasos para mejor. No sé si me explico correctamente. El que escribe buen código soluciona sus problemas de forma más eficiente. Escribir buen código no significa hacer sitios excelentes sino hacer arquitecturas económicas que permiten mejoras sustanciales con poca inversión.
Claro, más todas las ventajas que trae que acabas de comentar también.
Pep, una puntualización. Contenido no es código. Contenido es todo aquello que tenga un significado semántico.
En 1999, cuando usar CSS era considerado peligroso porque no todos los navegadores lo entendían, yo desarrollé un sitio, sin CSS. La arquitectura de fondo separaba muy bien contenido, presentación y código (tres cosas, no dos, muy diferentes), y era – y es – muy fácil modificar el contenido, la presentación o el código sin molestar las otras «partes».
Sin embargo, las páginas resultantes incluían todo en el HTML, con sus atributos de presentación todos en la misma página.
¿Qué vengo a decir con esto? Que se puede estructurar un proyecto de forma que el código, la presentación y el contenido esten bailando cada uno por su cuenta, con todas las ventajas que esto conlleva, sin que eso signifique que luego quede bonito para los bucadores, por lo que una cosa no implica la otra.
Y personalmente, me sigo quedando con la opinión de Enrique. Un buscador debe analizar el contenido (que ya hemos dejado claro que no es el código) de una página, y si el código altera sustancialmente el análisis que hace el buscador, el fallo está en el buscador, no en la página. El buscador debe «ver» lo que tú ves. Si vé otra cosa, es que, como decía Enrique, es un poco miope.
Otra cosa es que uno, sabiendo los fallos del buscador, decida ponerselo facil, pero eso no quita para que el fallo siga siendo del buscador, que no «vé» lo que ven los visitantes a la página en cuestión, sino que se pierde entre tablas y atributos, o saca conclusiones erróneas. Y de verdad que no creo que haya más vuelta de hoja.
Creo bueno controlar el «purismo rate». Tenemos miles de herramientas entre manos, y si nos pasamos de críticos con nosotros mismos nos quedaremos en el dominio de una sola.
Asumámosolo… el asunto hoy por hoy es manejar por encima muchas herramientas a nivel usuario a no ser que tu trabajo consista en ser experto de una de ellas.
De lo contrario, por favor, que a nadie se le ocurra volver en coche a casa.
Esto parece la continuación del hilo que empezó hace unos días con el mensaje de Enrique sobre la miopía de los buscadores.
«»» Y personalmente, me sigo quedando con la opinión de Enrique. […] El buscador debe «ver» lo que tú ves. Si vé otra cosa, es que, como decía Enrique, es un poco miope. «»»
RBA, entiendo que código, contenido y presentación son cosas distintas. Pero, aun siendo así, código y contenido son las dos caras de una misma moneda. Y no hay manera de separarlas.
El lenguaje es el código; el pensamiento, el contenido. No puedes acusar a la tecnología de miope porque no es capaz de entender tus pensamientos. Como no puedes tachar a alguien de miope por no ser capaz de entenderte si no habla español.
Además, el código debe ser independiente de la presentación. Porque, si bien como apuntas:
«»»El buscador debe «ver» lo que tú ves. «»»
Resulta que en Internet un mismo contenido-código puedes verlo de maneras muy distintas. Y no lo «ve» igual un ciego que yo en mi ordenador, o yo en una PDA. Entonces, ¿por qué una manera de verla es mejor que otra? ¿Cuál es la correcta? ¿Qué decisión debe tomar el buscador? Lógicamente, el buscador se intentará fijar en el contenido-código, y esto significa que si hay mucho ruído (elementos de presentación), los acabará despreciando.
Y eso es justo lo que hace. Hace exactamente lo mismo que nos sucede a las personas. Que los buscadores no son perfectos, de acuerdo. Que puede (y debe) exigírseles más calidad, completamente de acuerdo. Pero de allí a afirmar que son miopes por no tolerar según qué niveles de ruído, no estoy tan de acuerdo.
Hay algo sobre CSS que casi nadie parece tener en cuenta cuando alaba sus bondades: el navegador abrumadoramente mayoritario lo soporta mal, con muchos bugs. Para arreglarlo, termina uno metiendo todo tipo de parches y chapuzas, con lo cual al final muchas veces queda peor que metiendo tablas y cosas así, que sabes que todos los navegadores lo interpretan más o menos igual.
Y en cuanto a Google y CSS, en su momento modifiqué gran parte de mi web eliminando tablas y otros métodos similares y sustituyendo por CSS lo que podía, sin tocar apenas el contenido. Desde entonces mi web no sale de las catacumbas de las páginas de resultados. No digo que se debiera a eso, pero lo que tengo medianamente claro es que hay otros factores infinitamente más importantes para cuestiones de posicionamiento que el de usar tablas o div’s. De hecho tengo serias dudas de que, dentro de límites razonables, tenga alguna importancia no despreciable.
En otro momento acometí la tarea de «limpiar» toda mi web para que fuese W3C-válida y los resultados en Google fueron los mismos durante los siguientes meses que antes de la reforma. No vi la más mínima diferencia.
Estoy de acuerdo en separar contenido y presentación, en que se deben respetar los estándares, en que hay que tener claridad en el diseño… pero no en que, dentro de lo razonable, en la práctica todo eso le importe algo a Google. Para mí que influye poquísimo.