Semántica web vs. Presentación Gráfica
Allá va uno de esos post sobre filosofía del HTML :)
Charlaba hace unos minutos con un buen amigo (que seguramente estará viendo esto) sobre el tema de la semántica en los documentos HTML. Para que os situéis en contexto, él es un gran defensor de los estándares y tiene los conceptos muy claros. La conversación giraba entorno al 'talibanismo' de los que defendemos esto (a tu salud, Joshua), y él argumentaba que, por encima de que el código sea semántico, está que la presentación visual de la información sea la más adecuada.
Por supuesto, estamos de acuerdo en que siempre que sea posible, hay que mantener el código lo más semántico posible, pero si llegase un momento de debate interior sobre 'esto quiero presentarlo así y si lo hago semántico no puedo', hay que optar por la opción no semántica.
Lo muestro con un ejemplo que le enseñaba, por otros motivos:
http://webtypography.net/toc/
A ambos no encanta lo clara que está la maquetación de la numeración de las secciones, sin embargo para esa numeración tiene que utilizar algunos cuestiones que semánticamente serían redundantes (incluir dentro del texto el número de la sección, cuando eso en realidad corresponde a la anidación de las listas).
No me he atrevido a asegurar que se pueda hacer con un código limpio, porque nunca he trabajado con los counter-increment, o la propiedad marker, pero aparte de que se pueda o no quedaba la discusión de fondo. Suponiendo que no sea posible, ¿qué os parece mejor? ¿Añadir código extra y contenido redundante para conseguir esa presentación?
(Si, lo sé, soy un poco friki)
zigotica
para que sirva como excepción, estoy de acuerdo con joshua, pero en este caso igual se podria hacer de este modo:
http://www.w3.org/TR/REC-CSS2/generate.html#scope
(no lo he probado, igual no hay navegadores que lo soporten)
txuma Plus
Estoy haciendo algunas pruebas justo con eso (el orgullo csseriano es lo que tiene). Os comento los resultados :)
Teresa
Pues si haces una web para un cliente y no por disfrute personal, creo que no hay discusión, ya que al cliente le va a importar más que la presentación se vea de una determinada manera que que la web sea semánticamente correcta.
Personalmente yo también creo que el diseño y la presentación son más importantes que el código, aunque entiendo su relación digamos dialéctica, y las ventajas de una semántica correcta en cuanto a rapidez de descarga y accesibilidad son incuestionables.
zigotica
prueba ràpida:
<code><style>
ol { counter-reset: item }
li { display: block }
li:before { content: counters(item, "."); counter-increment: item }
</style></code>
...
<code><ol>
<li>one
<ol>
<li>one-one</li>
<li>one-two</li>
<li>one-three</li>
</ol>
</li>
<li>two
<ol>
<li>two-one</li>
<li>two-two</li>
<li>two-three</li>
</ol>
</li>
<li>three
<ol>
<li>three-one</li>
<li>three-two</li>
<li>three-three</li>
</ol>
</li>
</ol></code>
funciona en FF y OP9 pero no en IE6 (igual en IE7 si)
f3rnando
Creo que el diseño web sin estándares/web semánticas etc... hablando de diseño de programación son chapuzas.
Aunque sean muy bonitas y le gusten mucho a los jefes.
zigotica
f3rnando
Creo que el diseño web sin estándares/web semánticas etc... hablando de diseño de programación son chapuzas.
Aunque sean muy bonitas y le gusten mucho a los jefes.
no he entendido nada...
Usuario desconocido
Yo creo que gozo más con un código limpito y bien estructurado que con un buen pantallazo de photoshop. Si combinamos los dos no te digo na
txuma Plus
zigotica
funciona en FF y OP9 pero no en IE6 (igual en IE7 si)
Tal y como era de esperar, el tema de la autonumeración no funciona en IE6 ni en IE7 (no soportan los pseudoelementos :before y :after, tiene cojones). Sólo se me ocurre una ñapa utilizando JS.
Para el tema de la alineación, jugando un poco con tamaños de texto relativos y márgenes negativos, he conseguido que funcione, y se comporte bastante bien ante el aumento y reducción del tamaño del texto.
P.S. Por cierto, la discusión no era con Joshua, por si conduce a error :)
zigotica
txuma
<div class="quote">
zigotica
<blockquote>funciona en FF y OP9 pero no en IE6 (igual en IE7 si)</blockquote>
</div>
Tal y como era de esperar, el tema de la autonumeración no funciona en IE6 ni en IE7 (no soportan los pseudoelementos :before y :after, tiene cojones). Sólo se me ocurre una ñapa utilizando JS.
Para el tema de la alineación, jugando un poco con tamaños de texto relativos y márgenes negativos, he conseguido que funcione, y se comporte bastante bien ante el aumento y reducción del tamaño del texto.
P.S. Por cierto, la discusión no era con Joshua, por si conduce a error :)
seguramente con un .htc tipo el de peterned (en una css condicional) y si me apuras con js no intrusivo para IE
pues si, habias llegado a confundirme :)
txuma Plus
La solución de Peterned siempre me ha parecido demasiado 'grande', en el sentido de que corrige de un plumazo un montón de bugs... pero eso tal vez sea una sobrecarga innecesaria. Prefiero soluciones más localizadas.
De todos modos, perdón, que yo mismo estoy desviando el debate inicial.
zigotica
bueno siempre se puede quitar lo que sobre...
Teresa
Es que del modo que yo entiendo el "debate" no es estética vs. código, sino, en el momento en que por cualquier razón son incompatibles, y como algo puntual, yo sacrificaría el código y lo haría más chapucero si fuese necesario para que estéticamente quedase bien.
txuma Plus
Teresa
Es que del modo que yo entiendo el "debate" no es estética vs. código, sino, en el momento en que por cualquier razón son incompatibles, y como algo puntual, yo sacrificaría el código y lo haría más chapucero si fuese necesario para que estéticamente quedase bien.
Efectivamente, el debate no es 'Estética VS. Código' (yo creo que el término estética, además, no es el más adecuado, porque puede llevar al engaño de bonito/feo). Sería mejor utilizar 'Presentación'.
Pero aparte de eso, es lo que tu dices. En un momento de 'incompatibilidad', ¿que debe primar?
Kr0n
Sólo en momentos de incompatibilidad suprema, como tú dices, para mí primaría la presentación.
Hay que tener en cuenta que no existe un mundo ideal en el que podríamos invertir infinito tiempo en conseguir una forma de que el código sea limpio y la presentación sea tal y como la queremos. Normalmente hay restricciones de tiempo, muchas más tareas que hacer, etc.
Y en ese caso, para mí prima el resultado final que es el que verán los usuarios y visitantes. Y si para eso tengo que "bajar" un pelín la calidad de mi código, pues mira... no está la cosa para rasgarse las vestiduras :)
Teniendo en cuenta que para el público final lo que cuenta únicamente es la presentación, que es lo que ven, y que el mayor porcentaje de público que va a tener el código soy yo (que se perfectamente las restricciones que he sufrido), pues no es algo que, en condiciones normales, me quite el sueño.
zigotica
¿pero realmente hay debate? lo digo porque creo que estamos todos de acuerdo, ¿no?
Teresa
je je pues eso parece :)
txuma Plus
En el fondo somos unos blandos :P
zigotica
yo he cambiado mucho... :P
txuma Plus
Es el efecto de tener un niño, te cambia mucho la visión sobre la vida, y descubres que la importancia del código es muy relativa :P
Dentro de poco me veo a Borja maquetando otra vez con tablas
xD
zigotica
txuma
Es el efecto de tener un niño, te cambia mucho la visión sobre la vida, y descubres que la importancia del código es muy relativa :P
Dentro de poco me veo a Borja maquetando otra vez con tablas
xD
jajaja, pagaría por verlo :P
Kr0n
zigotica
<div class="quote">
txuma
<blockquote>Es el efecto de tener un niño, te cambia mucho la visión sobre la vida, y descubres que la importancia del código es muy relativa :P
Dentro de poco me veo a Borja maquetando otra vez con tablas
xD</blockquote>
</div>jajaja, pagaría por verlo :P
jajajaja! madre mía, sería el principio del fin!
y sí, yo creo que es el efecto de "sufrir" la experiencia, te vas desplazando del extremo purista al purista-práctico, dominado por lo práctico. El problema sería por ej. no haber pasado nunca por el extremo purista...
txuma Plus
Kr0n
yo creo que es el efecto de "sufrir" la experiencia, te vas desplazando del extremo purista al purista-práctico, dominado por lo práctico.
Sí, es un buen resumen.
joshuatree
Yo tenía unas maquetas de unos sitios de Borja hechos con tablas+CSS, si quereis os lo busco y lo podeis extorsionar con eso.
¿Que de dónde los saqué? Ahhh, somos pocos y coincidimos en muchos curros..! XD
Si no es con eso, siempre queda el recurso de la foto en el Souza :D:D:D
f3rnando
Yo creo que un buen diseño semántico y un buen diseño gráfico no están reñidos.
Un mal diseño semántico puede resultar "útil" al principio, pero si tienes que reutilizar/modificar código, acabas haciéndolo todo de nuevo.
Yo creo que en un momento de incompatibilidad debe primar la sencillez del código frente a una presentación cargada.
A modo de ejemplo las páginas de UNIX, por lo general muy sencillas, frente a las páginas de moda, cargadas de flash.
txuma Plus
f3rnando
Yo creo que en un momento de incompatibilidad debe primar la sencillez del código frente a una presentación cargada.
Está bien escuchar una voz discordante :)
f3rnando
A modo de ejemplo las páginas de UNIX, por lo general muy sencillas, frente a las páginas de moda, cargadas de flash.
Pero el ejemplo que pones es demasiado radical.
orange
Esperáis a que esté yo en las conferencias de rails para tener charlas interesantes so cabrones??
Pues ahí van dos apuntes un poco politicamente incorrectos para los frikis:
1.- Antes salvo a un usuario que a cien programadores
2.- El onanismo del programata te deja ciego
Y no digo más que empieza la confe
txuma Plus
orange
Pues ahí van dos apuntes un poco politicamente incorrectos para los frikis:
1.- Antes salvo a un usuario que a cien programadores
2.- El onanismo del programata te deja ciego
Totalmente de acuerdo.
Ves, Joshua, como en el fondo no somos tan talibanes :P
Teresa
f3rnando
Yo creo que un buen diseño semántico y un buen diseño gráfico no están reñidos.
Un mal diseño semántico puede resultar "útil" al principio, pero si tienes que reutilizar/modificar código, acabas haciéndolo todo de nuevo.
Yo creo que en un momento de incompatibilidad debe primar la sencillez del código frente a una presentación cargada.
A modo de ejemplo las páginas de UNIX, por lo general muy sencillas, frente a las páginas de moda, cargadas de flash.
No, no están reñidos salvo cuando lo están :P. Yo también pienso que son dos ejemplos radicales. Todos tenemos claro que las webs han de ser lo más semánticamente correctas posibles, pero, por ejemplo en el ejemplo gráfico q ponía txuma al principio del post, ¿tú lo dejarías así pq tiene una presentación diáfana y limpia -a costa de "ensuciar" el código-, o limpiarías el código sacrificando así esa presentación. Pienso que esa es la cuestión (aparte de ser o no ser claro :))
Kr0n
f3rnando
A modo de ejemplo las páginas de UNIX, por lo general muy sencillas, frente a las páginas de moda, cargadas de flash.
A mi ese ejemplo no me vale. Ojo que no estamos hablando sobre presentaciones sencillas vs presentaciones recargadas. Eso no implica nada sobre el código que hay debajo.
Hablamos, como bien se ha dicho, sobre que priorizar llegado el punto irremediable de conflicto entre código y presentación.
f3rnando
teresa:
yo creo que las webs deben ser sencillamente semánticamente correctas.
el ejemplo que ponia txuma lo dejaria así (si ya esta hecho), yo creo que la cuestión es otra: "crear código semanticamente incorrecto o no", yo creo que no.
Yo procuro crear código lo más semánticamente correcto posible, además de lo más reutilizable posible, no me planteo recodificar un diseño anterior.
Kr0n:
Yo procuro ceñirme a los estándares web, sobre todo para reutilizar código. Si me tengo que salir me salgo, pero porque no sepa hacerlo bien, no por gusto. Probablemente el ejemplo de txuma se pueda hacer semánticamente también.
Para mi es más importante seguir los estándares (si están bien diseñados, como es el caso) porque me sirven de guía, priorizo el código frente a la presentación, y además creo que unifica las presentaciones, y es bueno. Las presentaciones podemos distinguirlas usando otros mecanismos.