Hola German,
hola a tod@s,
Ante todo me parece que el hecho que produzcan código HTML
y no "seudocódigo" SPIP es más una ventaja que una
desventaja.
Entiendo que ese argumento pueda parecer un contra-argumento
. Por lo tanto me explico un poco: SPIP hace bien ciertas
cosas y no otras. Y si bien es flexible para pedirle que
haga unas cuantas cosas mas que lo que hace bien, hay que
hacerlo con cautela, y no es tan facil generalizarlo. Su uso
tipico es un eperiodico en linea, o un webzine. Un articulo
es ante todo un texto que viene a insertarse en una
paginacion del periodico, no es una pagina we con un formato
super complejo (tablas, frames, etc.)
En este sentido, los atajos tipograficos, más que como
'negrita', 'italica' deberian considerarse conceptualmente:
{citacion}, {{resaltar}}, etc. Y de hecho, cada uno es el
atajo de un estilo, mas que a un tag html (cf.
Spip y las hojas de estilo - SPIP)
Si bien existe el 'atajo' <html> ... </html> que permite
ingresar cualquier codigo html, para mantener la coherencia
editorial, el uso de este método debe ser la exception y no
la regla.
Imaginense que quieran cambiar toda la presesentacion de un
sitio, como un periodico ccambia de maquetaje: si en los
articulos spip se ingreso codigo html 'a fuego', tipo <font
color="#XXXXXX" size="NNpt"> ... </font> es claro que el
asunto no pasa la migracion...
Otros ejemplos: si quieren hacer una version del sitio en
WAP, iMode u off-line en un PDA, accesible desde cualquier
otro tipo de terminal que un navegador habitual, o una
version leida para ciegos,... La referencia a una hoja de
estilo .css, simple y limitada, sera una gran ventaja para
adaptar rapidamente la conversion.
Despues: que la eleccion de los atajos : {{ }}, {}, [ -> ],
etc. no sea estandar y que sea o no la buena eleccion... se
discute, por cierto. La experiencia (de usuarios reales y no
informaticos) demuestra que los atajos spip se aprenden
facilmente, e incluso bastante 'naturalmente'.
Por ultimo, cabe recalcar que no se trata en realidad de una
alternativa entre atajos spip 'no estandar' por un lado y
html u otro 'estandar' por otro: imaginen construir una nota
de pie de pagina en html. bastante más complicado, ¿no? ¿Y
qué 'estandar' existe para eso??
Por todo eso es que, si bien no es un estandar sino un
sintaxis propio a SPIP, me parece que en un campo de una
base SPIP, es mejor ingresar 'seudocodigo' spip (la
terminologia no es muy apropiada...) que codigo html.
Y cuando es necesario pasar al html, lo mas sensato hoy en
dia me parece crear una pagina interna con un editor estilo
Dreamweaver u otro, y luego hacer un copiar/pegar en un
campo spip, revisando eventualmente a mano el html para
sacar los tags inutiles o perjuiciosos.
El problema de los desarrolladores de esqueletos será
saber hacer buenas hojas de estilo.
Eso si: ahi esta la clave de un sitio spip logrado.
fijense spip.net : como Montse lo puteaba con los viejos
esqueletos que no estaban adaptados, y como ahora que cambio
de esqueletos le parecio mucho mas claro.
Sin embargo, el contenido es el mismo...
Se entiende?
Y de ahí se puede entrar en la idea del código sucio. Si
se hace una interfase sencilla que solo use las pocas
cosas: negrillas, itálicas, tablas, listas y esas cosas...
en otras palabras sin colores, fuentes y esas cositas...
es decir el código sucio...
Bueno, hay editores que hacen codigo {{aun mas sucio}} que
eso 
Pero, si esa puede ser la idea: un herramienta mas
wysiwig, pero que conlleve los elementos de paginacion del
sitio.
Con eso llegamos al tercer problema, la incompatibilidad
con todos los visualizadores, que -me parece- es el
argumento más firme
Si claramente: si hubiera una manera liviana y universal de
hacer tal herramienta, no hay de dudar que Spip la
consideraria.
no aprobar poner una herramienta de estas en una
distribucón libre de SPIP.
una reflexion fuera del tema (y que sin duda es una
interpretacion abusiva de tu frase, German): {{todas}} las
distribuciones de spip son y {{deben ser}} libres. read the
f* {GPL}, please Cada quien hace lo que se le antoja con
spip, lo unico que esta prohibido es retirar {{la libertad}}
o los autores. (cf. el sitio de los barbudos:
http://www.fsf.org/home.es.html y una traduccion al
espanhol: http://www.garaitia.com/new/gpl-spanish.php)
No creo que sea buena idea que sea que ese tipo de
herramienta pase a ser un componente por omisión del SPIP,
por esa razón. Pero podría ser un componente opcional.
Por un problema de mantenimiento, en SPIP se intentan evitar
las opciones (al menos a ese nivel).
En el pasado, esto ha frustrado unas cuantas propuestas (y
en particular esta misma). Lo que se hizo al final fue crear
el sitio http://rezo.net/spip-contrib/
donde se pueden proponer esqueletos, hacks, etc.
SI quieren podemos armar un sitio de contribuciones en
espanhol. o directmanete multilingue.
Bueno, hasta pronto. saludos,
daniel