Re: [Ovillo] HTML vs XHTML

[Manuel Gonz�lez Noriega]

Como no tengo a mano el mensaje de Alejandro, le contesto al mismo 
tiempo que a Ariel

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.

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 las transformaciones de acuerdo, con la observaci�n de que en 
realidad no es algo que est� presente en muchos proyectos.

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
- Cu�les son las pautas a seguir para conseguir la compatilidad entre 
navegadores usando XHTML?

Mmm supongo que te refieres al apendice C, que da unas gu�as para los 
documentos que tengan que enviarse como text/html

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

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
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.

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.



En $DTD cada uno pone el que le corresponde...
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?

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