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?
El lenguaje debe definirse tanto en el prologo como el un tag meta, si ignora el prologo, todabia tiene el meta.
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.
Por eso las lineas de codigo de mas abajo...
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.
Ok formule mal la oracion. Lo que quise decir es que los headers NO SON PARTE del documento. Son eso: encabezados. Se envian ANTES que el documento. Para decirle al agente que contenido se le va a enviar.
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
Que. Acaso una pagina no puede ser linda y valida?
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*
Aca se trata de ser coherentes. No me voy a meter en mi torre de cristal y decir <voz de superheroe barato> - Mis paginas cumplen con todos los standards. Si el explorer se pone en quirks mode, ese no es mi problema... </voz de superheroe barato>
La idea es que la pagina pueda ser interpretada lo mejor posible y por la mayor cantidad posible de navegadores. Es encontrar el punto de compromiso.
Ademas debo decir que tu 90% esta por verse. Si el 90% de la gente se tira al rio, yo no los voy a seguir. Y voy a intentar que todos los que estan alrrededor mio tampoco lo hagan.
Al que insista y se tire de todas formas, le mandare un salvavidas que tiene escrito text/html *tos* bullshit *tos*
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...
Tenes razon. No sabes lo que me costo copiar y pegar el codigo... Estoy exhausto.
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.
¡Corcho! ¿Y funciona en Mandrake? :o)
Los dejo que me entere que salio una nueva version del FrontPage que dicen que le saca el jugo al explorer :-P
vmware hijo, vmware.
Saludos
Ariel
pd: Se dan cuenta que todo esto es a causa de las practicas monopolicas de m$, no?
Si m$ siguiera por completo los standads, en entonces cualquiera podria ver cualquier pagina indistintamente del navegador que use.
Adivinen quien pierde mercado en ese caso?
_______________________________________________ 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
