Ariel Burone wrote:
Alejandro Cuesta wrote:
A raiz de la discusión acerca de poner o no poner el "prólogo xml" en los documentos XHTML, creo que me gustaría abrir otro debate acerca de si es mejor hoy en día seguir usando HTML o pasar a XHTML, desde el punto de vista de la compatibilidad entre navegadores y de la accesibilidad.
XHTML ofrece ahora mismo dos ventajas objetivas:
- Puedes parsearlo como XML - Puedes combinarlo con otros lenguajes XML, como MathML o SVG
Ninguna más. El resto son preferencias personales, pero nada que se pueda calificar de ventaja.
Desventajas de XHTML:
- Directamente, en el 90% de los agentes que van a consumir las páginas NO VAS A PODER CUMPLIR EL ESTANDARD. En el mejor de los casos, podrás aproximarte a cumplirlo siguiendo las guías del apendice C, que más que nada se inventó como mal menor para que XHTML no fuera completamente inviable, y mediante la discriminación de cabeceras.
Con las transformaciones de acuerdo, con la observación de que en realidad no es algo que esté presente en muchos proyectos.Yo hace unos meses asistí a un curso de la W3C y se aconsejaba utilizar XHTML. Las razones no se dijeron, pero me hizo dudar entre usar uno u otro, ya que yo hasta ese día usaba HTML. Yo creo que todos usaríamos XHTML por todas las ventajas que ello conlleva: documentos válidos, transformaciones, etc.
Con la validez no, y este es el punto que más me molesta, que a la gente se le embrolla la cabeza de tal forma que asocia estándares o validación con XHTML y solo con él.
El único problema está en la compatibilidad entre los navegadores, concretamente creo que entre las diferentes versiones del IE, que desafortunadamente es el más usado. Mis conocimientos acerca de las caracterísitcas de cada navegador no son tan precisos, pero hasta donde se, la compatibilidad se puede conseguir: mediante hojas de estilo, cambios de cabecera, etc.
De todas formas, hago las siguientes preguntas para ver si aclaramos un poco este tema:
- Cuáles son las ventajas/desventajas de seguir usando HTML?
Ventajas: puedes hacer páginas muy monas. :o) Desventajas: que se sepa, ninguna
- Cuáles son las ventajas/desventajas de comenzar a usar XHTML?
Ventajas: podrás parsearlo como XML y/o combinarlo con otras sintaxis XML Desventajas: En el 90% de los agentes de usuario NO CUMPLIRÁS EL ESTANDARD
Mmm supongo que te refieres al apendice C, que da unas guías para los documentos que tengan que enviarse como text/html- Cuáles son las pautas a seguir para conseguir la compatilidad entre navegadores usando XHTML?
http://www.w3.org/TR/xhtml1/#guidelines
- De seguir usando HTML, hasta cuando deberíamos esperar para comenzar a escribir nuestras páginas en XHTML?
Pues bastante supongo, pero tampoco lo veo como una espera. Hay grandes posibilidades de que nunca tengas la necesidad de usar XHTML.
Ahora contesto a Ariel :) ---------------------
Yo no veo ninguna ventaja en el html por sobre el xhtml. Si hay algo que un navegador antiguo no entienda, simplemente lo va a ignorar, como todos los navegadores hicieron siempre. Justamente esa era la idea original del html.Entonces, si trabajas con XHTML e identificas el lenguaje de un recurso con xml:lang ="es", y el agente HTML lo ignora estás disminuyendo la accesibilidad de la página ¿no?
Las ventajas del HTML sobre el XHTML son segun yo veo dos:
- Puedes cumplir siempre el estandard y en ningún caso tienes que mandar páginas "rotas"
- Puedes hacerlo con menos trabajo, ni discriminación de cabeceras ni apendice C
Si le doy un documento xhtml a internet explorer 1.0 lo va a interpretar y mostrar sin mas. No entiende hojas de estilo, asi que no las usara, no sabe que es eso de xml asi que ignorara esa linea...
Y como he dicho antes, los recursos no tendrás un idioma asociado a menos que utilices también lang="es". Y todo eso, POR NINGUNA VENTAJA EN ABSOLUTO :o)
El prologo xml: Tanta historia por eso? El navegador que no sepa que es eso, lo ignora.En IE 6 hará saltar el quirksmode, lo cual puede causar, como sabes, significativas diferencias en la visualización de la página.
Header application/xhtml+xml: Aca hay unos cuantos que estan confundidos. Los headers no tienen NADA que ver con el documento escrito en si. Es informacion que intercambian el servidor y el browser entre si. Es establecer un protocolo, ponerse de acuerdo en que idioma van a hablar.Ah, bueno, si no tiene nada que ver podré mandar uno al azar ¿no? Por ejemplo, image/gif o application/octect-stream. El Content-type no identifica el idioma de la comunicación, sino el tipo de documento que se envia. Alguna importancia tendrá diferenciar entre pdf, rss, gif o word.
browser: hola pagina.com, soy el navegador xyz y quiero la pagina pepe.html. Tengo soporte para jpg, gif, flash y text/html
Si se trata de que el usuario diga "que linda página" entonces podemos dejarnos de chorradas de validar y estándares y cosas de estas, porque hay miles de páginas lindisimas y que no validan, ni son semánticas, ni utilizan CSS ni nada de nada. Entonces, vamos a dejar claro que con linda página o sin linda página puede haber problemas graves. Problemas tan serios como que tu XML esté mal formado.
server: hola xyz yo soy el servidor siux 10.5. A ver.... si, tengo el archivo que me pedis (codigo 200). Veamos esto debe enviarse como application/xhtml+xml, pero por lo que me dijiste recien, veo que no lo soportas...
Bueno, te lo mando como text/html que es lo que si soportas.
usuario: que linda pagina
El tipo de contenido (mime type) identifica al documento y es vital. De hecho, algunos llegan a decir que más que el DOCTYPE (1)
(1) MIME types matter; DOCTYPEs don't http://annevankesteren.nl/archives/2004/07/mime
Aca no hay ni javascript ni sniffing ni nada de eso. Es establecimiento de protocolos de comunicación.
No exactamente. El protocolo es HTTP y para cuando llegamos a esta etapa ya está establecido por necesidad. El content-type establece el *tipo de contenido*
y lo que se está haciendo con XHTML es
a) Anunciar siempre que se mandan jirafas (text/html) cuando se mandan zebras (application/xhtml+xml)
b) Incluso los más cuidadosos, que discriminan cabeceras, están mandando zebras por jirafas *en el 90% de los casos*
Es decir, incluso si tienes muchísimo cuidado, Ariel, *en el 90% de los casos tus páginas no cumplen el estandard*
Se puede configurar a apache para que haga lo aqui descrito (ser bueno con el browser y enviar como text/html) de forma automatica. Pero en general no esta configurado asi... Asi que habra que poner un par de lineas de codigo server-side para implementar esta logica nosotros mismos.
Y todo esto ¿para qué? Es lo que habría que explicar a la gente ¿qué ventajas le aporta a un desarrollador esto? La validación y accesibilidad ya la logra con HTML ¿Qué obtiene a cambio del trabajo extra?En $DTD cada uno pone el que le corresponde...
Resultado: una pagina 100% standard, que puede ser interpretada por cualquier navegador.
100% estandard si te has tomado el trabajo extra de seguir el apendice C
No es eso lo que buscamos? No venia de standards la cosa?
Si, estandares bien soportados ;)
HTML 4.01
100% válido 100% libre de problemas 0% apendices de compatibilidad 0% discriminación de cabeceras.
Los dejo que me entere que salio una nueva version del FrontPage que dicen que le saca el jugo al explorer :-P
¡Corcho! ¿Y funciona en Mandrake? :o)
_______________________________________________ Lista de distribución Ovillo Para escribir a la lista, envia un correo a [EMAIL PROTECTED] Puedes modificar tus datos o desuscribirte en la siguiente dirección: http://ovillo.org/mailman/listinfo/ovillo_ovillo.org
