CSS-based responsive web design is a great tool for adapting a layout to different screens, period. It is a tool, not an end. In some cases, where a site’s content should be the same from device to device (a blog, for example), responsive web design is enough for the job. More complex services, though, may need much more, including different content, tools, and services.

Yes, friends: it depends.

What’s it depend on? Certainly the needs of the audience. But as with so many things, it often depends a great deal on business considerations, too.

Josh Clark - Responsive Web Design or Separate Mobile Site? Eh. It Depends.

Cita extraída de un artículo que resume una animada discusión entre los partidarios del responsive web design (muy resumido, el uso de Media Query para adaptar la presentación de una web a los diferentes dispositivos) y los que van más allá de la mera presentación de contenidos: optimizar las experiencias según el contexto de uso y de usuarios.

Nada nuevo, en definitiva. Aunque técnicamente ahora es posible obtener mejores resultados que hace no muchos años: hay ejemplos más o menos elaborados en mediaqueri.

Ya puestos, otro artículo que nos puede ayudar a ampliar nuestra perspectiva histórica es New to Mobile? Welcome to the One Web Debate.

Pero se supone que el asunto a tratar es el reseteo de todas o una buena parte de los atributos de los elementos de XHTML mediante unas cuantas reglas de CSS, e incluso un fichero, como parte de un framework más o menos extendido o particular. Personalmente, la mayoría de las veces he optado por algo muy básico y cuando hacía falta (lo típico del padding:0 y margin:0 y poco más). Lo de usar un fichero que te obligaba a definir todos y cada unos de los atributos de elementos de un sitio web me parece excesivo. Cuestión de opiniones y experiencia.

El caso es que la mejor manera para justificar el uso o no de alguna de las diferentes técnicas de reseteo de CSS es saber sus consecuencias - y porqué no, su origen - tal vez sea una buena idea dar un vistazo a los siguientes artículos:

• Part 1: The History of CSS Reset
• Part 2: A Comprehensive Guide to CSS Resets
• Part 3: Should You Reset Your CSS?

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

Será que soy un poco quisquilloso, y algo cascarriabas. O puede que tenga algunas cosas claras y no me gusta perder el tiempo: desarrollando, o cargando una página.

Adaptando la frase de León Felipe: Un código más sencillo, maquetador.

Pero ya sabemos como funciona el mundillo de la web: basta con que no sea recomendable usarlo, para que sea un requisito imprescindible.

Cuando se publicó - por fin - XHTML 1.1 Basic como recomendación del W3C, una de las novedades que más me llamó la atención fue el módulo de inputmode (XHTML inputmode Attribute Module). Brevemente es un atributo que se incluye en el código fuente como atributo de un campo de texto en un formulario, para "obligar" a que el teclado del móvil escriba, por ejemplo, números (inputmode="latin digits") usando tokens o valores predefinidos (lo puedes ver en List of tokens).

La teoría es muy bonita, pero en la práctica, no está muy extendido entre los terminales móviles la interpretación del módulo en cuestión. Y es un problema gordo y que puede producir mucha frustración a los usuarios. Imaginemos que tenemos que escribir un código postal, cinco dígitos en total. Puede suponer pulsar veinte veces las teclas, ya que los números suelen situarse detrás de las letras. ¿Y si es un número de cuenta con 20 dígitos? Y si estás pensando: "se puede configurar para escribir sólo números y ya está..." pero no siempre es así (pruebas con unos veinte terminales me lo confirman).

¿Solución?

Hasta que los agentes de usuario implementen el módulo (¿a qué me suena ésto?), podemos usar un estándar algo más viejo, pero con mejor soporte (a mis pruebas me remito).  Estoy hablando de WCSS Input Extension, que mediante el uso de la propiedad -wap-input-format en la hoja de estilos, o insertado directamente como valor del atributo style, nos permite forzar a que los teclados de los teléfonos escriban sólo números, números con símbolos, texto en minúsculas con símbolos, texto en mayúsculas con símbolos,  y todo junto. E incluso la longitud del campo. Puedes ver más en Controlling the Type and Number of Characters to be Entered in Text Fields (-wap-input-format Property). Y lo bueno, es que es compatible con XHTML 1.1 Basic.

Algunos ejemplos:

• Código postal (5 dígitos): -wap-input-format: "NNNNN"
• Código wadus (hasta 5 dígitos)-wap-input-format: "5N" (ojo, que no es lo mismo)
• Importe (números y símbolos)-wap-input-format: "*n" (permitiría números y los símbolos separadores de miles y decimales)
• Texto wadus -wap-input-format: "*A" (letras en mayúsculas y símbolos, sin límite)
• Texto wadus prima -wap-input-format: "*a" (letras en minúsculas y símbolos, sin límite)

¿Es útil? Sí y mucho. Pero recomendaría mucha precaución antes de usarlo. Algunos motivos:

• Si nos equivocamos en el tipo de datos, la cagamos. No es posible cambiar de números a letras, por ejemplo.
• Si nos equivocamos en la longitud del campo, también la cagamos (como he dicho antes, no es lo mismo <code>NNNNN</code> que <code>5N</code>). Además, si hay que introducir en el campo, por ejemplo 5 letras mayúsculas obligatoriamente (<code>5A</code>), no puedes salir de la caja ó área de texto del formulario hasta que cumplas lo exigido.
• Si usamos la propiedad -wap-input-format en una hoja de estilos externa, hay que tener mucho cuidado que afecta sólo a los elementos de formularios que queremos (y no fastidie a otro). Hay que tener una buena planificación en la nomenclatura de clases e identificadores.
• La propiedad de la que hablamos, no se interpreta siempre a la hora de escribir en aquellos terminales que tienen teclado tipo QWERTY ya sea físico o en pantalla. Lo cuál no significa que pueda aparecer un mensaje de error bastante críptico al intentar hacer submit, diciendo algo así como El contenido de un campo de formulario no coincide con el formato que rquiere el autor de la página. Modifique el texto y vuelva a intentarlo. Cómo véis, un mensaje muy claro, corto y sencillo. Ésta joya de texto aparece en una HTC.

La otra propiedad que podemos usar es -wap-input-required, con los posibles valores true y false, que no creo que requiera mucha explicación.
Como he dicho antes, la información completa y bien explicada la puedes encontrar en Controlling the Type and Number of Characters to be Entered in Text Fields (-wap-input-format Property), con algunos "extras" como el uso de caracteres de escape.