Semántica web vs. Presentación Gráfica

ahí va, cómo se pone la rana... :P

a ver, no te pongas pijo que era sólo un ejemplo, y que creo que se entiende lo que quería decir con la retícula: pegarle una patada a conceptos asumidos si eso lleva a que al usuario reciba mejor la información. lo normal es justo lo contrario, que respetándolos sea cuando nos acerquemos a él, a fin de cuentas por algo han llegado a estar asumidos, pero si nos encontramos en un caso en el que haya que elegir una cosa u otra la resolución es sencilla: siempre el usuario.

Pégale una patada a la retícula y yo te pateo las rodillas.

Y a orange le patearé las suyas (y mira que tu post me parece de lo más sensato que he leído en años) cuando vuelva a decir PONER BONITO para referirse a destacar gráficamente un elemento para potenciar su visualización. Esa puta frase está destruyendo el oficio. Coño ya!!!

creo que lo más importante es definir para qué se hace todo esto, cuál es el objetivo final ¿hacemos las páginas para nosotros? ¿para el W3C? ¿para el cliente? ¿para el usuario? de lo que se trata es de transmitir información, y de llegar al máximo número de usuarios a los que va destinados la página y de la mejor manera posible. si para ello hay que pegarle una patada a la semántica, a la validación del código, a jabob nielsen o al concepto de retícula da igual, se le pega, todos son prescindibles si eso hace que el que está al otro lado reciba mejor la información.

nuestra única responsabilidad es tener todos los conocimientos posibles para saber a que hay que renunciar en cada momento y lograr el único objetivo final: comunicar algo al que está navegando.

f3rnando

Y en el caso concreto que propone txuma, huiría de diseños que no se ajusten a la semántica.

Esa era la raíz del debate. Está claro que cada uno tiene su punto de vista, y en este caso discrepamos.

Esa frase que dices lleva implícita que crees más adecuado conservar la semántica del código aunque dificultes la recepción del mensaje. Porque si un diseño es mejor para que el usuario entienda la información y tú renuncias a él, en el fondo le estás poniendo las cosas un poco más difíciles, ¿no te parece?

De todos modos, y para que aún quede más claro: nadie está hablando de hacer barrabasadas con la semántica, o de hacer un código de pésima calidad. Lo que defendemos es que en ocasiones hay que renunciar a la perfección absoluta en el código en beneficio del mensaje.

Fernando, con todo el cariño, de verdad. Lo que dices suena a alguien con poca experiencia en esto (por lo menos con poca experiencia ganándose la vida programando front-end).

Todos los que estamos aquí nos hemos dejado la piel defendiendo los estándares. Pero como en toda partida hay veces en que hace falta sacrificar un peon.

zigotica:
...si es usuario de Güindows
El resultado se sacrifica al usar Güindows, y para compensarlo los diseñadores usan los parches para IE.

teresa:
Poner parches sobre la reluciente y semantica web.

---

Creo que el asunto se desvía...
Todos sabemos los beneficios de usar estándares.

Yo por ejemplo procuro usar todos los estándares que conozca y vayan saliendo, no significa que lo haga bien a la primera, pero si hay una forma mejor de hacerlo esa es la que busco. Solo busco reutilizar código, en lugar de hacer la página de cero cada vez.

El hecho de no usar artimañas ensuciando el código es por motivos de compatibilidad, accesibilidad y legibilidad del código, siempre podemos guardar una versión sin artimañas para poder seguir ampliandola.

El hecho de usar algún parche aislado lo veo irremediable para usar IE.

Y en el caso concreto que propone txuma, huiría de diseños que no se ajusten a la semántica.
Ahora bien, en el momento que los estándares no me convencieran, como todo lo relacionado con Mocosoft... entonces dichos estándares me los pasaría por los h*s.

<fieldset>Si los navegadores no están bien diseñados (especialmente los de Mocosoft) no es mi problema, yo no diseño nada para Mocosoft. Y si lo hiciera me vería obligado a poner parches. </fieldset>
Fernando, con todos mis respetos, ¿qué le dices al cliente cuando la página no se ve bien en el Mocosoft -que por mucho que nos fastidie sigue siendo un navegador mayoritario-? No creo que puedas facturar un trabajo que el cliente no vea bien en el ordenador de su casa o en el de su oficina. Por lo menos yo no lo he conseguido :)

f3rnando

Creo sinceramente que no está reñido, todo lo contrario, usar estándares nos ayuda a diseñar mejores páginas webs
nadie ha dicho lo contrario, aqui quien mas quien menos ha hecho webs de renombre (no es por tirarnos flores, pero sabemos de que hablamos). lo que decimos es que en ciertas circunstancias, hay que sacrificar algo de semantica para que elresultado sea optimo de cara al usuario. es indefendible sacrificar el resultado solo por querer mantener una estructura semantica perfecta, aun con la excusa de que el navegador A o B no soporten cierta funcionalidad.

Creo sinceramente que no está reñido, todo lo contrario, usar estándares nos ayuda a diseñar mejores páginas webs

sinceramente, y espero no faltarte al respeto, alguien que haya hecho webs minimamente grandes fijo que ha terminado por usar algun parche. no me veo a borja diciendole al de ACS o a Bancaja que no pone un span porque Explorer no acepta el counter() como debe... seamos realistas y seamos prácticos. Lo ha dicho orange, "Antes salvo a un usuario que a cien programadores".

f3rnando

Los objetivos de usar semántica son múltiples, reusabilidad del código, limpieza del código, más compatibilidad

Al menos para mí, semántica no implica eso que indicas. Puedo hacerte un código muy limpito y compatible, y que sea semánticamente nulo.

Igual tenemos diferentes acepciones sobre lo que "semántica" significa.

Orange:
Si los navegadores no están bien diseñados (especialmente los de Mocosoft) no es mi problema, yo no diseño nada para Mocosoft. Y si lo hiciera me vería obligado a poner parches.

Estos estándares de XHTML y CSS me parecen una perla de la programación aunque no estén lo difundidos que esperas, o bien, Mocosoft no los acepte.

Los objetivos de usar semántica son múltiples, reusabilidad del código, limpieza del código, más compatibilidad,

Yo entre programar una chapuza o no programarla prefiero no programarla, a modo de ejemplo las tablas anidadas que deja el dreamweaver.

Ahora, creo inevitable que si un diseñador, que no tiene por que saber programar quiere poner un parche pues lo ponga.

Yo procuro no ponerlos, y si los pongo es porque no conozca suficientemente el estándar, no veo mal que se pongan si se es conciente de ello y se trata de aislar el parche, para futuras versiones no lo tengan, y el código sea reutilizable. La versión que cuenta para mi es la versión que voy a seguir usando/tocando/ampliando.

[momento peloteo]
Borja, tienes la fabulosa virtud de plasmar y explicar muy claramente lo que quieres decir. Y no es tan fácil, porque yo llevo un par de días queriendo transmitir eso, y por lo que he releído de mis mensajes, nunca ha estado tan claro con tu post.

Chapeu, maestro!

f3rnando

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.

Con todos mis respetos esto es un gran mentira, por lo menos a día de hoy. Sobre todo porque - como bien dices - los estándares están bien diseñados, pero los navegadores NO.

Pongamos un ejemplo superfácil, un listado ordenado (OL) al que queremos personalizarle el aspecto a los números (ponerlos bonitos, grandes, darles formato 01, etc...). Todo eso puede hacerse con la especificación en la mano (CSS) PERO es imposible totalmente dados varios bugs concatenados que Explorer 6 (y alguno también el 7) tiene en el render de listas.

¿Entonces qué coño hacemos?, pues no te quedan más huevos que que meter los numeritos en un SPAN (por ejemplo) dentro del LI y darle formato a eso.

Porque lo que está claro es que personalizar esos números es algo totalmente legítimo, y voy más allá, puede ser algo VITAL para el diseño de ese listado y un elemento clave en la esa página.

Y en ese escenario NO se puede renunciar a presentar las cosas como se deben. El diseño NO es hacer sólo poner las cosa boniiiiiiitas, sino que cumple una función clave en una página web.

Y si hay que renunciar a un pelín de semántica para ganar un muchín en usabilidad yo tengo claro lo que hay que hacer.

Por supuesto aquí no hay verdades absolutas, y cada caso hay que estudiarlo detenidamente. Hay que valorar MUCHO lo que se "pierde" en código y lo que se gana en presentación.

No vale todo, ni en un sentido ni en el otro.

Bueno, por fin, lo hemos conseguido, una voz discordante! :)

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.

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

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 :))

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

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

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.

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.

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

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.

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

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

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

yo he cambiado mucho... :P

En el fondo somos unos blandos :P

je je pues eso parece :)