Barrapunto

Me imagino que eso conllevaria el re-escribir gran parte del codigo de Slash, lo cual es una tarea agotadora y muy complicada (creo que se acabaria antes cambiando el weblog por otro que cumpla los estandares de la W3C).
En pocas palabras, es algo muy complejo de hacer, claro que los 475 errores que devuelve el validador son una buena razon para probar.

Hace poco más de un mes (24-nov-2003) ya salió una noticia similar sobre este tema: ¿Barrapunto en XHTML y CSS? [barrapunto.com]

En aquella ocasión ya se comentaba que existen plantillas disponibles para Slash, que permiten obtener al menos la página inicial estándar. Aunque requiriría una mayor implicación por parte de los editores para que se siguieran manteniendo los estándares en las noticias publicadas.

Por otro lado, en los comentarios enviados por los usuarios es casi imposible evitar que no se cumpla algún estándar, ya que se permite incrustar HTML directamente, en lugar de un pseudocódigo alternativo que se tradujera internamente a (X)HTML, como suele hacer los últimos weblogs PHP tipo Xoops [xoops.org] o Drupal [drupal.org].

Lo de los estándares estaría muy bien, claro. Lo que ya no sé es lo complejo que sería, ya que no conozco slash.

Yo lo que echo en falta son una sindicación RSS o XML en condiciones, y no sólo los titulares. Yo uso Straw [nongnu.org] para leer bastantes weblogs, y es muy cómodo.

Es sencillo: en vez de poner sólo los titulares, se añade el cuerpo de la noticia. Ya está. :-)

Hace unas semanas, en A List Apart [alistapart.com] publicaron un interesante artículo: Retooling Slashdot with Web Standards [alistapart.com], donde se hace una transición detallada desde el código que produce Slashdot actualmente a una versión completamente estándar basada en XHTML y hojas de estilo CSS.
Sólo se hace a nivel estático, es decir, que no se toca para nada el código que produce las páginas, pero aun así se comprueba que se puede dejar slashdot exactamente igual que está cumpliendo los estándares y con las ventajas que ello comporta.

Si, claro que seria bueno, pero llevaria muchas horas de depuración de codigo. A mi personalmeente hay algo que me parece mas importante que la validacion W3C, y es que la pagina se vea bien con cualquier navegador (si, vale, si se cumple el estandar se deberia ver bien con todos) y a mi no me ha dado problemas con ninguno, y es dificil hacer una web agradable y anybrowser.

Por tanto la correccion W3C lo entenderia cono una sugerencia (importante, claro). Por cierto, esta pagina (antes de publicar mi comentario) da 47 errores... espero que no se incremente ;-).

...sí.

No veo más excusa que la "pereza" para que no los cumpla actualmente.

Pasarse a xhtml y css tiene ventajas e inconvenientes.

Las ventajas:

• Descarga más rápida. Los que tenemos una conexión de 48 kbits/segundo lo vamos a notar bien. Todo gracias a las hojas de estilo, y si se mandan comprimidas, mucho mejor.
• Barrapunto ahorra ancho de banda.
• Se cumpliría con los estándares.

Las desventajas:

• Muchos navegadores no implementan todavía la maquetación con css, o lo hacen muy mal, pese a que se pueda seguir viendo la página.

• Los mensajes html con errores van a provocar que las páginas sigan dando errores, aunque esto está pasando ahora.

Creo que merece la pena cambiarse a XHTML y css si no es demasiado trabajo. Si fuese demasiado, quizá no merezca la pena.

La páginas con las que me pego en muchos casos están maquetadas con multitud de imagenes y tablas. Cierto es que los CSS para maquetar no son muy soportados, pero yo con xhtml 1.0 Transitional no he tenido demasiados problemas, incluso Strict, aunque este último por alguna razón, no se ve bien en Mozilla, quizas precisamente por las tablas. Cuando hablé de estandar, me referia a algo mas básico que reescribir todo el codigo con CSS 2.1 XHTML 1.1 con SVG y SMIL y que ademas cumpla todos los estandares de WAI. Hay que diferenciar entre lo que a todos nos gustaría (yo el primero) y lo que se puede hacer.

Bien, perfecto, en la sombra, nuestros hackers de Barrapunto seguro que están preparando unas plantillas cojonudas para darnos una sorpresa, y nosostros aquí sin poder hacer nada. Pues yo no lo veo, ni tengo ninguna noticia de cómo se está haciendo o se deja de hacer, y me fastidia mucho.

Quizá es que los árboles no me dejan ver el bosque, así que si alguien me cuenta cuál es el estado actual de la migración de Barrapunto (o Slash, si debemos esperar a ver lo que hacen desde arriba) a XHTML y CSS, se lo agradecería. Y si está completamente estancado, que me digan lo que tengo que hacer, que aquí hay manos suficientes para lo que realmente hace falta.

Las ventajas ya las conocéis: carga más rápida de las páginas, menor gasto en el ancho de banda, mejor indexación de los contenidos en los buscadores, mayor control y conocimiento de la presentación, y corrección del código mucho más compatible con cualquier navegador estándar. ¿A qué esperamos para fomentar de verdad desde los círculos libres los estándares abiertos?

Tampoco se pide una utilización perfecta de las hojas de estilo, sino una forma compatible con lo que los navegadores actuales soportan y algo fácil de mantener para los conocedores del HTML de la vieja escuela. Y si alguien prefiere el sistema anterior, creo que con un poco de trabajo no cuesta nada que pueda elegir recuperar la presentación anterior, y que se calle ya esa gente que por desconocimiento y miedo cree que sus navegadores no van a soportarlo, yo tampoco les soporto a ellos. Y por favor, no aprovechéis esto para criticar destructivamente, porque seguro que tenéis cosas mejores que hacer con vuestro tiempo e imagino que sabréis cómo utilizarlo si lo pensáis un poco.

Gracias.

una buena herramienta para todo esto es: http://www.bradsoft.com/topstyle/index.asp un saludo. tunel.

En mi humilde opinión, sonsidero que todas las páginas deben de cumplir los estándares...

He leido varios comentarios que "justificaban" la carencia de estándar porque así existe mayor compatibilidad. ¿Entonces para que están los estándares? Los navegadores deberían adaptarse al estándar, si no se cumplen... "cada uno a su bola"... creo que así no se predica con el ejemplo.

Comprendo que portar el código de barrapunto no es tarea fácil, pero debería tenerse en cuenta adaptarse a los estándares en futuras remodelaciones.

Una humilde opinión

Si miráis el borrador de CSS3 (está a punto de pasar a ser oficial), veréis que se incluye un módulo que permita definir columnas. La mayor parte de tutoriales de CSS, consisten en lograr un efecto a dos o tres columnas. Si CSS 1 y 2 no incluyen nada para hacer esas columnas, que tan fáciles son de hacer con tablas, es porque se pensó que las tablas eran una jaula que encerraba a los diseñadores en estructuras muy poco versátiles.

A pesar de que posiblemente tenían razón en ese sentido, la mayor parte de webs, demandan estructuras tabulares para la presentación, y por eso se siguen usando tablas. La excusa del mal soporte de CSS no me convence. Mozilla (o todos los navegadores basados en Gecko) soporta incluso propiedades de CSS3, y Konqueror tan sólo deja sin soportar cosas exóticas, como la propiedad min-height.

Y aparte...

Al margen de la estructuración con tablas o con CSS, lo que no tiene ningún perdón, es que sigamos usando "b" e "i", en lugar de "strong" y "em", que se ven exactamente igual, pero que permiten a agentes de usuario no visuales, como motores de búsqueda, y navegadores para gente disminuída (orales, braille, etc.) darle un sentido a una cursiva o una negrita que para ellos está vacía. De esto también se habló en A List Apart en el artículo Using XHTML/CSS for an Effective SEO Campaign [alistapart.com].

Saludos.

mini-d, de minid.net [minid.net], parece haber leido este post y habla al respecto en su blog.

Para los que no lo conozcan, Diego Martín Lafuente, mini-d, es una personalidad de la blogosfera hispana y en su blog, junto a muchas otras cosas, da lecciones magistrales sobre todos los aspectos del diseño web

Integrando las hojas de estilo (CSS), se lograría un primer nivel de separación del contenido y la apariencia. La gente del W3C se ha preocupado por recuperar el antiguo espíritu del HTML como lenguaje de estructura de los documentos, no de apariencia.

Los navegadores se adelantaron hace tiempo y empezaron a poner etiquetas "extra" propias de cada navegador para hacer que las páginas pudieran personalizarse en apariencia, respecto a los colores, los bordes, los márgenes, los tipos de letra y todas esas características.

Desde hace tiempo el W3C lleva desarrollando los estándares XML, XHTML, CSS y muchos más teniendo en mente las necesidades futuras de la World Wide Web, la red mundial de páginas Web.

Las ventajas son muy importantes, ya que la presentación puede modificarse fácilmente sin cambiar el contenido, dando a cada uno lo que necesita, facilitando enormemente la accesibilidad de personas con todo tipo de discapacidades, pero también el acceso con dispositivos con otras necesidades gráficas, como móviles, impresoras, buscadores que buscan en el contenido de las páginas, etc.

La velocidad de descarga también mejora, porque las hojas de estilos de cada sitio serían comunes para todas las páginas del sitio, y por tanto el navegador no tiene que descargarla cada vez que se baja una nueva página y la estética del sitio puede complicarse todo lo que se quiera para mejorar su apariencia [alistapart.com] sin que la transferencia de datos aumente.

A google le fallan más cosas:

  1.- No encierra valores de atributos
  2.- No usa atributos estandar
  3.- No cierra las etiquetas...

Puedes decirle al validador que lo intente validar contra un esquema determinado (HTML 3.2, HTML 4.01 Transitional...) y verás que, a parte de los errores en los enlaces, le fallan más cosas.

NOTA: Los enlaces con parametros fallan porque los considera entidades que no reconoce.