Me encanta este punto, tan controvertido y tan... fácil de resolver. Existen muchas maneras de afrontar la maquetación cuando tratamos con Drupal. Aquí puede aplicarse aquello de "cada maestrillo tiene su librillo".En la literatura podemos encontrar:

1. Front-end Drupal

• Definición de regiones e inclusión de archivos CSS y Javascript en .info
• Lógica y toma de decisiones en template.php
• Marcado HTML en los archivos .tpl.php
• Definición de estilos en las CSS

2. Graycor propone

• Evitar al máximo el uso de archivos .tpl.php (ganaremos en rendimiento y podremos manejar el orden de los campos CCK desde la administración), sólo node.tpl.php
• Crear CSS genéricas y reutilizarlas tanto como sea posible
• Crear convenciones para campos CCK usados frecuentemente, esto ayuda a las CSS genéricas
• Permite configurar desde la administración tanto como sea posible

3. Contemplate fans proponen

• Uso del módulo Content Template (contemplate) para modificar el estilo de los nodos en su vista normal, avanzada, RSS y resultado de búsqueda.

Todos tienen ventajas y desventajas, miento, al tercero sólo le veo desventajas (aunque quizá podría acercarse al último punto de la segunda alternativa: configurar desde la administración tanto como sea posible).

Ventajas y desventajas

Ventajas:

1. Organizado, metodológico, aprovecha la arquitectura de drupal.
2. Buen rendimiento, metodológico, uso de estándares y convenciones ayudan a la producción y mejoran el mantenimiento
3. Rápido, no necesita acceso FTP, fácil de entender para noveles

Desventajas:

1 y 2. Necesita conocimiento del funcionamiento de PHPTemplate
1. Puede crecer el número de archivos a controlar
2. Puede dificultar la legibilidad de la plantilla y por tanto su mantenimiento
3. No permite guardar revisiones de los cambios. No tiene buen rendimiento. Necesitas conocer otra nomenclatura para los datos.

Nosotros haremos uso de las opciones 1 y 2 tomando lo mejor de ellas, es decir, nos guiaremos por la primera y optimizaremos tanto como podamos siguiendo las recomendaciones de la segunda. Normalmente exsiten dos tipos de posturas que afrontan la tarea de maquetación cuando se trata de Drupal:
1. Están los que han generado sus XHTML y sus CSS propias
2. Están los que aprovechan el marcado por defecto tanto como sea posible y adaptan las CSS a este marcado

Es cierto que existe una buena razón para los de la primera postura: el esfuerzo y el valor del propio maquetador para generar un código HTML limpio, semánticamente correcto. Pero tampoco es cierto que Drupal no genere ese código semánticamente correcto (fijaros que no niego lo relacionado con la limpieza). Zen es el tema más usado por los desarrolladores de temas, pero no sólo eso sino que es la guía más usada, se está convertiendo en un estándar de facto y debemos aprovecharlo. Cambiar un id llamado "page" por "pagewrapper" o por "pagina", no tiene sentido si no supone costes adicionales de tiempo. Otra cosa es que creamos que un contenido marcado como una lista desordenada debiera ser una lista de definiciones, entonces sí debemos actuar.Ésta es la gran ventaja de contar con un maquetador que conozca Drupal, que será más ágil.

En cuanto a la limpieza, es cierto que existe una tendencia a genarar etiquetas HTML cubiertas de cientos de atributos class, casi se podría "llegar" a cualquier elemento por apenas dos selectores. Esto aporta flexibilidad en el diseño pero el maquetador de toda la vida odiará haber nacido. En cualquier caso el uso de herramientas como Firebug facilitan la tarea de entender y localizar cada elemento con su clase o identificador y de nuevo, se mejora en cuanto al mantenimiento, se sigue el estándar y se confía en que "cualquier diseño puede adaptarse a una plantilla de Drupal".

Respecto al aspecto de hacer gestionable desde la interfaz tanto como sea posible, bueno, cualquier diseñador o maquetador se horrorizaría al ver que un cliente puede tomar decisiones de cómo debe aparecer cierto contenido. Hay que tener cuidado con esto, si es para ayudarnos a los desarrolladores vale, si es para venderle lo potente que es Drupal a un cliente quizá es que no apreciamos el producto final lo suficiente.