HTML dentro de los feeds

Comparte esta nota 01.11.04

Feedness es un proyecto que lanzaremos en apenas unos días y los procesos de desarrollo y diseño han sido interesantes y apenas hemos tenido complicaciones.

En todo momento hemos sido puristas con el código y nuestra idea es poder cumplir con las más estrictas normas de accesibilidad y cumplir con los estándares web.

Ahora bien, Houston, tenemos un problema.

Resulta que cuando se crearon los distintos formatos de sindicación, a alguien le parecio buena idea sindicar no solo el contenido, sino que parte del código HTML también y, bueno, si la gente lo usara correctamente no sería un problema, pero por desgracia, ese no es el caso.

El problema

Actualmente Feedness parsea los feeds de manera que el fichero de salida sea semánticamente correcto, pero el problema surge cuando los feeds que parseamos contienen código no tan correcto:

Parrafos, negritas, fonts y otras etiquetas sin cerrar.
Imágenes grandes, con width y heigts definidos y alineadas.
Selectores CSS, que podrían a llegar a coincidir con los que pudieramos usar nosotros

Estamos intentando diseñar tan defensivamente como sea posible. Intentamos tener en cuenta todos los supuestos, pero hay cosas que sencillamente no se pueden arreglar con buenas hojas de estilo.

Además, por otro lado tenemos sitios que envian un código HTML perfecto y que nos permite mejorar todavía más las posibilidades de presentación, ¿vamos a hacer que paguen justos por pecadores?.

¿Soluciones?

Todavía no hemos encontrado ninguna que nos deje satisfechos:

Tolerar el código no correcto, que podría generar anomalías en el diseño.
Remover todas las etiquetas HTML del código excepto las imágenes y los enlaces. Perder los headings, las listas y en general el código bien construido. Update: Eduardo me ha sugerido el Sanitize, ¿alguna información al respecto?
Pre-procesar todos los contenidos en busca de estas anomalías, convirtiendo Feedness en una herramienta menos ligera con mayores tiempos de carga.

Bloglines recurre al JavaScript, convirtiendo el código de las páginas en un insulto a la accesibilidad y los estándares… pero consigue mostrar todo sin problemas.

Como verán, no hay una solución sencilla y por ahora, creemos que la más razonable es la de tolerar el código no correcto y diseñar MUY defensivamente, pero por probar y preguntar no perdemos nada: ¿Qué harían ustedes?

17 comentarios

agk

01.11.04

Creo que todo eso se puede realizar con unos cuantos arrays y regex, que busque un patrón según los parametros que le demos. Por ejemplo, si se inicia una etiqueta <strong> buscar en el resto del texto la etiqueta faltante, que en este caso sería </strong>, en caso de no encontrarla, en ese caso, la etiqueta se elimina o completarla buscando la siguiente palabra, en este caso, buscando el siguiente espacio en blanco (” “).

argh, al parecer me dio un _tick_ decir _en caso_ y _en ese caso_

Walter

Es una de las opciones, pero hemos hecho esfuerzos en conseguir que la aplicación sea rápida DE verdad y empezar a tirar búsquedas en cada item, de cada feed… uf…

Todo sea por la velocidad ;)

Noticias de Bitacoras.com

Feedness. HTML dentro de los feeds
Walter Kobylanski: “Feedness es un proyecto que lanzaremos en apenas unos d?as y los procesos de desarrollo y dise?o han sido interesantes y apenas hemos tenido complicaciones (…)” Ver completa….

mini-d

Eso es inevitable. Bueno si lo es, pero deberías programarte un super parser de texto plano que haría trabajar tu servidor bastante. Te lo aseguro… sobre todo cuando existan 1000 personas chupando de unos 700 u 800 feeds.

A mí siempre me avisan cuando se ve mal mi feed.

Cicloid

Bueno, por otro lado podrias revisar el texturize (el analogo al sanitize) que usa el wordpress, automaticamente cierra los tags incorrectos, y hace varias monerias mas :)

Vuarnet

02.11.04

sinceramente?

yo aventaria la toalla ;)

jejejeje no te creas…

fael

hola

la solución efectivamente es con los regex, así como el bbcode que si una tag no está cerrada, la muestra como texto

y sí, ya yéndonos a números grandes el uso de cpu sería bastante

yo sé un poco de php, css y flash y demás, sé que todos uds son pros pero si requieren una mano extra con gusto les ayudo

saludos

Solo dos cosas, que me vinieron a la mente…

Como a Google… Los clusters son sus amigos :)

Y como dijo el Internet Archive… El cache es su amigo :D

Eso era lo que estaba pensando, por que no guardar en cache, ya que abrir el documento XML consume algo de recursos, y estarlo abriendo cada vez que un usuario consulta el documento, sería una locura.

corsaria

05.11.04

Blogs visitados…
Sin ning?n orden ni preferencia. :) The Red Horizon. Preciosas fotos. Peter Kaminski Bonitas fotos de arquitectura en Flickr. V?a…

iOne

08.11.04

El HTML usado incorrectamente en archivos xml es un trastorno para mi. Estoy trabajando en un proyecto (http://enes.ourproject.org) en el que tengo que parsear estos documentos. Y cuando me encuentro con uno que no cumple al menos los estándares más básicos, me vuelvo loco para que las cosas funcionen… Yo estoy en contra del HTML. Se supone que los feeds son versiones reducidas, que no incluyen todo el artículo, de la web. Tienen que ser rápidas de descargar y mostrar, para ver rápidamente si interesan o no. Todo lo demás es superfluo. Y si por encima empiezan a incluir propaganda entre artículo y artículo…

mariano

09.11.04

walter.. el sanitize que te sugiere eduardo es muy bueno.. pero como se compartaría frente a tantos requests? Digo.. a cada renovación del xml volveria a procesar todo..
Y cual es la diferencia entre eso y un buen parser (sea con un regex que vos deberías programar o no)? No creo que haya tantos problemas de performance.

BTW, como lo hace feedburner? Tienes un contacto ahi?

Respecto al tema del HTML todavía estamos estudiando cuál puede ser la mejor solución. Vamos a tener todo en cuenta, pero lo cierto es que nos está dando menos problemas de lo previsto.

Recordemos además que son exclusivamente problemas de diseño.

Respecto a Feedburner… en principio hacen una cosa muy similar a la que hacemos nosotros:

Independientemente del formato del feed, nosotros lo parseamos y lo normalizamos y mantenemos una copia local en RSS 2.0 validado. Esa copia es la que ellos comparten, por lo tanto se aseguran de servir un RSS correcto con todos los campos obligatorios rellenados.

De hecho, a nosotros no nos costaría mucho dar el mismo servicio que dan ellos. ¿Habría motivos para hacerlo? yo por ahora creo que deben de estar pagando una factura terrible por concepto de ancho de banda…

Ahora bien, parece que hacen alguna otra cosa con el HTML, pero no hemos investigado (por falta de tiempo) si arreglan las “irregularidades” en el html.

En cuanto sepamos algo te contamos.

Agua

21.03.05

Asi es el codigo HTML puede ocasionar problemas en las paginas web