Loading 30%

Una web, hecha en flash y cuyo único contenido útil que ha podido encontrar el buscador es... que la página está cargando (y encima en inglés).

Sin comentarios.

HTML y XHTML

¿Qué diferencia hay entre text/html y application/xhtml+xml? ¿Porqué con HTML sólo puede usar text/html y con XHTML puede usar text/html, application/xhtml+xml, application/vnd.wap.xhtml+xml, text/xml, application/xml,...? ¿Por qué los desarrolladores web con un mínimo de conocimiento y experiencia suelen tener cierta aversión a Internet Explorer?

Son preguntas que no se responderán aquí, pero tendrás pistas. Y casi ni se hablará sobre HTML5. Como si no existiese.

HTML y XHTML: a tener en cuenta

Una de las ventajas-desventajas del HTML es su permisividad con los errores. Si hay algo que el navegador no entiende, simplemente lo ignora. Eso explica que cualquiera pueda hacer una página web, incluso con un editor de textos de ofimática. La página, puede que incluso se visualice en un navegador. Aunque el código generado probablemente una chapuza. Algo similar puede ocurrir si usamos los editores What You See Is What You Get (lo que ves es lo que obtienes), si se hacen páginas sin ver ni entender el código.

Como consecuencia, la sintaxis que se puede utilizar en HTML, podemos denominarla dualmente como sencilla-compleja:

• Sencilla, porque casi cualquier código que se publique, se visualiza en un navegador (por ejemplo <p class="description">Párrafo</p>, <P class=description>Párrafo, <P CLASS='description'>Párrafo</p>,... da igual si se usan mayúsculas y minúsculas en los elementos y atributos, se el valor de los atributos va entre comillas o no,...). De ahí que mucha gente pueda decir que sabe HTML, y que la web tenga la difusión actual.
• Pero a la vez es complejo: es más complicado aprenderlo (demasiadas opciones, falta de una sintaxis única,...), es difícil de mantener el código, y los navegadores tienen que hacer un esfuerzo mayor para que -sabiendo que el código generalmente no es muy bueno-, se muestre "algo" en los periféricos de salida (pantalla, altavoz, terminal braille,...)

Por otro lado, tenemos XHTML: la sintaxis es única (de los ejemplos anteriores, sólo es válido <p class="description">Párrafo</p>). Pueda que exija un poco más de cuidado y atención en los detalles -sobre todo, si alguien está acostumbrado a un mal código de HTML -, pero si sabes XHTML de verdad, entonces sabes HTML. Desde un punto de vista didáctico, es recomendable aprender con la sintaxis de XHTML, y usar un validador de código. Usarlo mucho.

Por si acaso, y aunque se tratará con más profundidad el asunto de text/html y application/xhtml+xml más adelante, aquí va una introducción esquemática:

• text/html y application/xhtml+xml son dos MIME Type, los más utilizados para páginas webs.
• Los MIME Type se pueden configurar desde el servidor y también se puede modificar mediante lenguajes de programación.
• text/html se usa para todas las páginas HTML y las páginas XHTML 1.0 que aunque usan la sintaxis de XHTML, son en la práctica, páginas HTML normales y corrientes. En principio es así para ser compatible con los navegadores más antiguos (e Internet Explorer hasta la versión 9).
• application/xhtml+xml se usa para documentos XHTML que se comportan como documentos XML en navegadores más avanzados (donde, no está Internet Explorer hasta la versión 9) y una de sus características es que es extensible (se pueden añadir nuevos módulos como XHTML+RDFa, XHTML Role Attribute Module o XHTML Access Module) y se puede combinar con otros lenguajes (XML como SVG, MathML ó SMIL). Se emplea application/xhtml+xml obligatoriamente en XHTML 1.1 y se puede usar también en XHTML 1.0.

Si los navegadores fuesen estrictos con las páginas XHTML, la Web, se rompería

Ojo, que hay un falso alarmismo en los siguientes párrafos: XHTML servido como text/html es equivalente a HTML. Y sabemos que cualquier código HTML, por malo y cutre que sea, se mostrará en el navegador aunque el resultado no sea el deseado por el desarrollador web (leer desarrollador web con tono irónico). Pero sigamos con el alarmismo parcialmente injustificado.

Siendo puristas - con XHTML se debería de ser muy purista, especialmente cuando no se envía como text/html, es decir, lo trata como un documento XHTML de verdad - el código tiene que ser siempre válido. Teóricamente, no se deberían tener errores. Pero,... ¿qué ocurriría si los navegadores siempre fuesen estrictos, y no mostrasen las páginas XHTML que fuesen incorrectas?. O dicho de otra manera, ¿qué ocurriría si los navegadores interpretasen las páginas webs servidas como text/html (ya sea HTML o XHTML) como lo hacen con las páginas servidas como application/xhtml+xml? Te lo puedes imaginar: teniendo en cuenta que son excepcionales desde un punto de vista estadístico las webs que tienen su código correcto, serían las únicas que se mostrasen correctamente. ¿El resto? Tal vez sólo se vería una página de error, como el conocido XML Parsing Error de Mozilla.

Si los navegadores fuesen puristas, la Web, directamente, se rompería. Si, supongamos, el 95% de las páginas webs no se mostrasen correctamente en los navegadores, tendría un impacto cuanto menos, apocalíptico (para la web). ¿Un 95% de páginas inválidas no es una exageración? Pues no, en todo caso, es incluso optimista. Según el estudio MAMA elaborado por Opera durante el año 2008, sólo el 4,13% de las páginas validadas en su numerosa muestra (más de 3,5 millones de páginas) tenían su código correcto (puedes leerlo en MAMA: Markup validation report).

En el estudio se hace referencia a las páginas webs en general, sin distinguir entre HTML y XHTML. Se podría pensar que puede haber diferencias significativas, y aquellas páginas publicadas en XHTML, suelen tener menos errores... pero no. De aquellas webs que incluyen el icono de conformidad de código válido (puedes verlos The W3C "validation" icons), el porcentaje de páginas que mienten - es decir, que no tienen el código correcto -, es muy similar en HTML y XHTML: alrededor del 50%. Lo cierto es que incluir un icono de conformidad hoy en día tiene muy poco valor, ya sea para confirmar que el código es válido o que la web cumple los criterios de accesibilidad indicados. Vale, estamos en el 2011 y el estudio es del año 2008, pero honestamente, no creo que las cosas hayan cambiado mucho.

Por eso los navegadores tienen que intentar adivinar como interpretar más o menos el código de la vida real, por muy malo que sea y por muchos errores que tenga. Y por supuesto, tienen la obligación moral - ya el W3C recomienda, no obliga -, de cumplir las Recomendaciones (la denominación del W3C equivalente a estándar) que publica. Algunos aspectos de las recomendaciones, tienen una tolerancia al error asumible, en el sentido de que no pasa nada si no funciona: no es importante, o existen alternativas para solucionarlas. Pero en otros casos, las consecuencias pueden ser críticas y la transcendencia e importancia sobrepasan los tolerable. Uno de esos casos es el nulo soporte de Internet Explorer, desde su versión 6 hasta la actual, la 8, para application/xhtml+xml (menos mal que en la versión 9 de Internet Explorer por fin lo soporta).

text/html y application/xhtml+xml

text/html y application/xhtml+xml: un poco de historia

Tras la introducción podemos empezar diciendo que para HTML 4.01 (1999) el W3C especificó que las páginas se enviasen con el MIME Type text/html.

Más tarde, surgió XHTML 1.0. En la primera edición (año 2000) todavía no estaba claro que MIME Type se iba a utilizar (leer XHTML 1.0 (primera edición): 5.1 Internet Media Type para verlo en la especificación). Pero en la segunda edición, hay dos opciones:

• enviarlo como text/html para ser compatible con los navegadores más antiguos.
• o bien enviarlo como application/xhtml+xml - definido en RFC3236 (2002) -, para aquellos navegadores que interpretaban correctamente XML, y que podían aprovechar sus ventajas.

Entre los navegadores que interpretaban correctamente las páginas XHTML servidos como application/xhtml+xml - hablamos del 2002 -, estaban prácticamente todos los de la época y los que surgieron poco después. Hablamos de los tristemente difuntos Mozilla y Netscape, además de los que todavía siguen en activo: Firefox, Opera, Camino, Safari... Incluso aquellos navegadores para móviles que soportaban WAP2, (insisto, hablamos del 2002)... todos interpretaban correctamente las páginas XHTML servidas como application/xhtml+xml.

¿Todos? Todos..., excepto Internet Explorer. A día de hoy, año 2011, con la versión 8 de su navegador a punto de ser reemplazada (al menos en teoría, todavía hay muchas versiones 6), en Microsoft ha estado ignorando un estándar que tiene ya 9 años. Desde la versión 6 SP 1, hasta la versión 8 (incluida). Sin comentarios.

Posibilidades de XHTML servido como application/xhtml+xml

XHTML servido como application/xhtml+xml es interpretado como un documento XML de verdad. Gracias a la extensibilidad mediante la modularización de XHTML - por la X inicial -, tiene las siguientes posibilidades:

• Lo típico, combinar XHTML 1.1 con estándares clásicos como SVG, MathML ó SMIL.
• Validación XML.
• Desde el punto de vista de la Web Semántica, podemos usar XHTML+RDFa, que ya es recomendación del W3C, y nos permite añadir información semántica de gran riqueza (ver RDFa Primer y RDFa in XHTML: Syntax and Processing) ó usar XHTML Role Attribute Module, también relacionado, entre otros aspectos, con la accesibilidad y adaptación a diferentes dispositivos. XHTML Role Attribute Module es más limitado pero útil (ojo, que de momento sólo es un borrador de trabajo).
• Desde el punto de vista de la accesibilidad, podemos usar XHTML Access Module, aunque todavía es un borrador de trabajo.
• ... y lo que vaya saliendo, porque la modularización de XHTML tiene muchas posibilidades (digo yo, que con HTML5 no se cargarán XHTML, ¿no?).

A tener en cuenta cuando usamos XHTML servido como application/xhtml+xml

Se supone que antes de desarrollar en XHTML, has leído XHTML 1.0 The Extensible HyperText Markup Language y especialmente la sección C. HTML 1.0 The Extensible HyperText Markup Language Compatibility Guidelines. Y lo más importante: entiendes todo. Por descontado, tienes la buena costumbre de comprobar que tu código es válido (por ejemplo en The W3C Markup Validation Service).

En cualquier caso, al usar XHTML servido como application/xhtml+xml, hay que tener presente algunos aspectos muy importantes, que en ocasiones inconvenientes, que puedes encontrar en Hixie: Sending XHTML as text/html Considered Harmful, secciones "SPECIFIC PROBLEMS" y "The Myth of "HTML-compatible XHTML 1.0 documents" (por cierto, ¡está en formato txt!). El artículo de Hixie, actual editor de la especificación de HTML 5, es una referencia importante al recopilar las particularidades de application/xhtml+xml, y emite conclusiones discutibles. Pero tú, inteligente lector, tienes la capacidad de sacar tus propias conclusiones. Personalmente creo, que recomendar a los novatos no aprender XHTML es una estupidez de las gordas. Aún así, repito: el artículo es una referencia, y muy importante, sobre application/xhtml+xml.

Citas del W3C sobre text/html y application/xhtml+xml

Especificación de HTML 4.01 (24 de diciembre de 1999)

HTML documents are sent over the Internet as a sequence of bytes accompanied by encoding information (described in the section on character encodings). The structure of the transmission, termed a message entity, is defined by [RFC2045] and [RFC2616]. A message entity with a content type of "text/html" represents an HTML document.

HTML 4.01 Specification : 4.3 The text/html content type

Segunda edición de la especificación de XHTML 1.0 (1 de agosto de 2002)

XHTML Documents which follow the guidelines set forth in Appendix C, "HTML Compatibility Guidelines" may be labeled with the Internet Media Type "text/html" [RFC2854], as they are compatible with most HTML browsers. Those documents, and any other document conforming to this specification, may also be labeled with the Internet Media Type "application/xhtml+xml" as defined in [RFC3236]. For further information on using media types with XHTML, see the informative note [XHTMLMIME].

XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition): 5.1. Internet Media Type

HTML and XHTML Frequently Answered Questions (21 de julio del 2004).

Why is it allowed to send XHTML 1.0 documents as text/html?

XHTML is an XML format; this means that strictly speaking it should be sent with an XML-related media type (application/xhtml+xml, application/xml, or text/xml). However XHTML 1.0 was carefully designed so that with care it would also work on legacy HTML user agents as well. If you follow some simple guidelines, you can get many XHTML 1.0 documents to work in legacy browsers. However, legacy browsers only understand the media type text/html, so you have to use that media type if you send XHTML 1.0 documents to them. But be well aware, sending XHTML documents to browsers as text/html means that those browsers see the documents as HTML documents, not XHTML documents.

Which browsers accept the media type application/xhtml+xml?

Browsers known to us include all Mozilla-based browsers, such as Mozilla,Netscape 5 and higher, Galeon and Firefox, as well as Opera, Amaya, Camino, Chimera, DocZilla, iCab, Safari, and all browsers on mobile phones that accept WAP2. In fact, any modern browser. Most accept XHTML documents as application/xml as well. See the XHTML Media-type test for details.

Does Microsoft Internet Explorer accept the media type application/xhtml+xml?

No. However, there is a trick that allows you to serve XHTML1.0 documents to Internet Explorer as application/xml.

Include at the top of your document the line in bold here:

<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="copy.xsl"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>

where copy.xsl is a file that contains the following:

<stylesheet version="1.0"
	xmlns="http://www.w3.org/1999/XSL/Transform">
	<template match="/">
		<copy-of select="."/>

	</template>
</stylesheet>

Note that this file must be on the same site as the document referring to it.

Although you are serving the document as XML, and it gets parsed as XML, the browser thinks it has received text/html, and so your XHTML 1.0 document must follow many of the guidelines for serving to legacy browsers.

Your XHTML document will continue to work on browsers that accept XHTML 1.0 as application/xml.

HTML and XHTML Frequently Answered Questions

Working Group Note : XHTML Media Types - Second Edition (16 de enero del 2009)

Many people want to use XHTML to author their web pages, but are confused about the best ways to deliver those pages in such a way that they will be processed correctly by various user agents[...]

XHTML Media Types - Second Edition: Abstract

After the publication of [XHTML1], an RFC for XML media types was revised and published as RFC 3023 [RFC3023], and it introduced the '+xml' suffix convention for XML-based media types. The 'application/xhtml+xml' media type [RFC3236] was registered following that convention.

[...]

In general, 'application/xhtml+xml' should be used for XML Family documents, and the use of 'text/html' should be limited to HTML-compatible XHTML Family documents intended for delivery to user agents that do not explicitly state in their HTTP Accept header that they accept 'application/xhtml+xml' [HTTP].

[...]

Note that, because of the lack of explicit support for XHTML (and XML in general) in some user agents, only very careful construction of documents can ensure their portability (see Appendix A). If you do not require the advanced features of XHTML Family markup languages (e.g., XML DOM, XML Validation, extensibility via XHTML Modularization, semantic markup via XHTML+RDFa, Assistive Technology access via the XHTML Role and XHTML Access modules, etc.), you may want to consider using HTML 4.01 [HTML] in order to reduce the risk that content will not be portable to HTML user agents. Even in that case authors can help ensure their portability AND ease their eventual migration to the XHTML Family by ensuring their documents are valid [VALIDATOR] and by following the relevant guidelines in Appendix A.

XHTML Media Types - Second Edition: Introduction

The 'application/xhtml+xml' media type [RFC3236] is the primary media type for XHTML Family documents.

'application/xhtml+xml' should be used for serving XHTML documents to XHTML user agents (agents that explicitly indicate they support this media type).

This media type must be used when writing documents using XHTML Family document types that add elements and attributes from foreign namespaces, such as XHTML+MathML [XHTML+MathML].

XHTML Media Types - Second Edition: 3.1. 'application/xhtml+xml'

The 'text/html' media type [RFC2854] is primarily for HTML, not for XHTML. In general, this media type is NOT suitable for XHTML except when the XHTML is conforms to the guidelines in Appendix A.

In particular, 'text/html' is NOT suitable for XHTML Family document types that add elements and attributes from foreign namespaces, such as XHTML+MathML [XHTML+MathML].

XHTML Media Types - Second Edition: 3.2. 'text/html'

Otras referencias

• Surfin' Safari: Understanding HTML, XML and XHTML
• Mozilla Web Developer FAQ.
• Hixie: Sending XHTML as text/html Considered Harmful.

Al final

Aquí no hay moraleja que valga: pero si hay una recomendación coherente, los navegadores y los desarrolladores las interpretan correctamente, y los navegadores antiguos no se ven perjudicados, perfecto. Si no, en la historia de la web, que no tiene demasiados años, podemos encontrar algún que otro "Caso de fracaso": el aquí ampliamente expuesto, Guerra de Navegadores, la interpretación personal de Explorer del modelo de caja (Internet Explorer Box Model Bug),... veremos al final que pasa con HTML5, pero miedo me da.

• Lenguaje y estándares
• Llenguatges i estàndards

Como extra, otro documento muy útil para aprender sobre desarrollo web, front end de andar por casa, de mamuso.

Gracias a jsmanrique por la noticia en twitter (Spanish and Catalan translations of the Opera Web Standards curriculum).

The best strategy for dealing with Internet Explorer 6 is not to support it.

Stop. Ok, I feel your frustration. You're a web developer and you're ready to tear your hair out because you have to support Internet Explorer 6, but, to put it tactfully, IE6 doesn't support you. You've spent hours on it, but you just can't seem to get your layout right. I can empathize. I can also help.

Benjamin, Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs

Como dice en el artículo, no se trata de una campaña contra el navegador que salió a la luz en el año 2001 y por diversos motivos, todavía tiene un respetable número de usuarios. Uno de esos motivos, de los muchos que hay: se trata del navegador oficial y corporativo y no se puede actualizar debido a que los trabajadores no tienen privilegios para hacerlo, y en las versiones más modernas o en otros navegadores, las intranets o aplicaciones webs que se usan, hacen catacroker (¡qué gran visión de futuro!, podemos decir ahora). Simplemente, toca ser realista, e intentar que nuestros desarrollos webs se muestren correctamente en navegadores que aunque no se lo merecen, sí se lo merecen las personas que obligados o no, usan el mencionado navegador.

De todas formas no está de más recordar que resulta una temeridad seguir utilizando un navegador tan antiguo, con numerosos problemas de seguridad, que no respeta adecuadamente los estándares webs y que exige tiempo -y por tanto, dinero - adicional para que se comporte de forma similar a los navegadores más actuales, seguros y con un mejor soporte de estándares. Ya sabéis que en Windows hay disponibles un buen puñado de buenos navegadores: Firefox, Opera, SeaMonkey, K-Meleon, Safari,....

Si por casualidad (todo es posible):

• usas Windows
• no puedes actualizar el navegador
• tampoco tienes privilegios para instalar ningún programa, y por tanto otro navegador,...

prueba a descargar Firefox Portable, un buen navegador, actual y más seguro, que no hace falta instalar, sólo hay que descomprimir, y listo para funcionar.

Y si estás desarrollando webs, da un vistazo a Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs.