El origen de responive web design, para adaptar webs a teléfonos móviles principalmente, es un artículo aparecido en A List Apart con el título de tachán... responsive web design. La técnica consiste en usar:

• rejilla flexible
• CSS3 Media Query
• Imágenes flexibles (ver fluid images)

En el fondo no hay nada nuevo: Media Query es una potente evolución de media types presente en CSS2, y el uso de rejilla e imágenes flexibles ya era conocido desde hace tiempo.

Hispanizando el término

Parece sencillo traducir el término original responsive design por diseño responsivo. Pero consultando el diccionario de la RAE, me ha costado encontrar uno buena traducción que respete el espíritu del término original. Gracias a la buena gente en twitter encuentro buenas alternativas:

• diseño web adaptable (@1984), con la puntualización de @isbl (diseño web adaptable a cualquier resolución de pantalla).
• diseño web adaptativo (@iagor)
• diseño web autoadaptable (@ala_747)

A mí personalmente me parece mejor la opción diseño web adaptativo, si hacemos caso al diccionario (definición de adaptativo en la RAE):

adaptativo

Perteneciente o relativo a la adaptación o a la capacidad de adaptación.

Esa capacidad de adaptación es lo que me parece más apropiado. Pero bueno, cuestión de opiniones: todas las argumentadas son bienvenidas.

¿Cómo funciona?

Tenemos una típica web con su código HTML, CSS, javascript (imprescindible una librería, como jquery y sus correspondientes plugins) y un buen puñado de imágenes. Todo ese código es el que se envía al navegador y le toca al potente ordenador de sobremesa (o al no tan sobrado de potencia teléfono móvil) procesarlo. Lo cuál equivale a descargarse todo, filtrar los estilos que le corresponden, ocultar los elementos invisibles (pero descargados) y mostrarlo en las pantallas de nuestros cacharros, ya sean grandes o pequeños, potentes o justitos. Siempre y cuando sepan interpretar el código...

Ahí hay un problema: se confía demasiado en el dispositivo de destino (velocidad de conexión y procesador, memoria, capacidad de comprender el código), y en ocasiones se le envía demasiados recursos, aunque no los muestre (y es una pérdida de tiempo y recursos que en ocasiones puede ser exagerado).

¿Es la mejor forma de crear una web móvil?

En palabras del que puso nombre a la técnica...

I think of responsive design as an alternative to mobile sites.

Ethan Marcotte — Ethan Marcotte on responsive web design

Lo considera una alternativa al diseño de una web específica para móviles. Y yo añado que no es la mejor alternativa. Sigo pensando que un buen trabajo de desarrollo en el servidor, con detección de dispositivos (mediante WURLF por ejemplo) y envío de contenido optimizado para dicho dispositivo, obtiene resultados mucho mejores que la técnica de diseño web adaptativo. Una muy buena explicación, la puedes encontrar en la presentación Why responsive design actually begins on the server a partir de la página 83.

¿Existen ocasiones en las que el diseño web adaptativo puede ser una alternativa razonable para ciertos proyectos web? Por supuesto, depende del tipo de web, de los recursos disponibles, del contenido que se muestra,... Una web ligera (no como esas de 5 megas), con pocos elementos multimedia, pocas imágenes, sobre todo texto, pocos recursos de tiempo y dinero, personal con conocimiento front pero no de lenguajes de servidor... es un proyecto ideal para poner en práctica la técnica de diseño web adaptativo. Al menos es algo.

Pero seamos sinceros: el diseño web adaptativo no deja de ser un truco de maquetadores con más o menos conocimiento de CSS y HTML para intentar que una web no se vea demasiado mal en ciertos teléfonos móviles. Es mejor que nada, pero dependiendo de la web, puede ser una chapuza o algo brillante.

Me permito recomendar dar un vistazo a la presentación Pragmatic responsive design. Me parece muy completa y un trabajo más que correcto. Un buen ejemplo a seguir.

Algunos consejos para diseño web adaptativo

Bueno, hablo en concreto de CSS3 Media Query.

• Para teléfonos móviles no tiene sentido usar handheld o screen. Desde que el iPhone dejó de considerarse un dispisitivo handheld desde el punto de vista del CSS, ha sido el primero de una larga lista de dispositivos en considerarse similares a, por ejemplo, un iMac de 27". Y no es lo mismo una pantalla de 3,5" que una de 27".
• No tiene sentido tampoco tener en cuenta exclusivamente la resolución de pantalla. El teléfono móvil Samsung Galaxy Nexus tiene una resolución de 1280x720 px. Muchos netbooks tienen resoluciones de 1024x600. Es uno de los muchos factores a valorar.
• Algo que casi nadie ha utilizado, que sepa, y que puede ser muy útil: tener en cuenta, no la resolución de pantalla, sino el tamaño de la pantalla en pulgadas. Ahí va una clasificación discutible: móviles menos de 6", tablets entre 6" y 10", ordenadores... más de 10" (la pena es que la resolución de 10" es usada por tablets y ordenadores). Tras estar haciendo pruebas, creo que es un punto de partida razonable. Además, funciona. Con un extra importante...
• Usar la resolución —desde el punto de vista de la densidad de pixels— para diferenciar la calidad de las pantallas. Ver donde se explica en Media Queries 4.11. resolution y en DPI Calculator / PPI Calculator para ver la resolución de pantalla de diversos dispositivos y una práctica calculadora.
• Recuerda las televisiones: muchas pulgadas de pantalla pero forzosamente tienen que usar un tamaño de texto más grande: el móvil, la tablet o el ordenador lo tenemos como mucho a medio metro de distancia. Un televisor puede estar a dos, tres o más metros.

El contexto

Aunque ya está muy visto, es obligado recordar que cada proyecto se desarrolla en un contexto y factores como el presupuesto, el objetivo de la web, conocimientos técnicos, el contenido, los dispositivos,... y los teóricos usuarios de la web. Un sitio para ver estadísticas de internet es statcounter, por continentes, países, sistemas operativos, móviles,... Ignoro su fiabilidad, pero debería abrir los ojos a más de uno.

El factor Be Cool

Un par de asuntos recurrentes. Por decirlo de una manera suave, empiezo a estar bastante hasta las narices, de que en la teoría y en la práctica, los únicos dispositivos que se utilizan para hablar o aplicar el responsive design (o para esos dos o tres lectores de xposible "diseño web adaptativo"), son los de Apple. Vale que queda muy vistoso utilizar imágenes de los cacharros de Apple y optimizar el CSS para el iPhone y el iPad en vertical y apaisado, pero hay más dispositivos. No les fastidies.
Pero el colmo es suponer que todos los cacharros que se conectan a internet tienen el núcleo webkit. Usar prefijos "beta" e ignorar los equivalentes de otros núcleos (-moz, -khtml, -ms, -o) o directamente las recomendaciones del W3C cuando funcionan. Una falta de profesionalidad preocupante. Luego pasa lo que pasa: Is the fat lady singing for Vendor Prefixes?.

Un gran poder conlleva una gran responsabilidad.

Ben, tío de Peter Parker.

La versión larga la puedes encontrar en [CSSWG] Minutes and Resolutions Paris F2F Monday Morning 2012-02-06: Administrivia, Vendor Prefixes, Property/Value Alias OM apartado Vendor Prefixes (sólo conozco a una persona que la lee por iniciativa propia). Una versión digerida en WebKit Isn’t Breaking the Web. You Are y la llamada a la acción en CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*.

Confieso que soy tengo tendencia conservadora con respecto a las tecnologías webs: prefiero utilizar las novedades cuando están bien asentadas. He de confesar también que mis conocimientos en CSS3 son más bien limitados, por no hablar de HTML5.

¿Tiene sentido ser un desarrollador web y no estar al tanto de las últimas tecnologías? Probablemente no.

¿Tiene lógica esperar a usar en producción algo que todavía está en fase alfa o beta y se desconoce si al final se implementará o no? Desde mi punto de vista sí. Y más teniendo en cuenta lo que sabemos con el ritmo de actualización de ciertos navegadores.

¿De qué hablo? El abuso inconsciente de característcas en fase alfa-beta de implementaciones de CSS que publica webkit (sí esas que empiezan con -webkit-) por parte de los desarrolladores webs.

¿Por qué? Porque en numerosos sitios se está provocando que la web sólo funcione en los navegadores con webkit (Safari, y navegadores por defecto de iOS y Android). Se está rompiendo la web. Y un gran perjudicado es Opera, hoy por hoy el navegador más usado en los teléfonos móviles en el mundo (ver el gráfico Top 9 Mobile Browsers from Jan 2011 to Jan 2012 ahora mismo, Opera es el número uno con un porcentaje de casi un 24%) por no hablar de otros navegadores, como Firefox, que tienen problemas con webs específica para móviles. No tiene sentido.

El asunto tiene muchos puntos de vista: por un lado está la posibilidad de que los navegadores mejoren (y los prefijos propietarios de los navegadores en CSS no deja de ser innovación), por otro lado el mercado de los navegadores, los desarrolladores, los clientes, las especificaciones del W3C (ahora documentos vivos en constante evolución),... y los usuarios.

Estaremos de acuerdo en que la velocidad a la que avanzan las especificaciones del W3C  es demasiado lenta. Pero abusar de características "beta" que implementan algunos navegadores puede ser una temeridad. Y si no nos fijamos si existen alternativas a otros navegadores (más líneas de CSS para implementar características en otros navegadores) rozamos peligrosamente la falta de profesionalidad. Por último, si con el uso de los prefijos de CSS estamos consiguiendo que la web no se visualice correctamente en otros navegadores, o incluso falle de forma escandalosa, entonces deberíamos tener una orden de alejamiento de un editor de código.

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