Un lien dans une note : [[ [texte->url] ]]
il faut couper tout ça __________________
et pas juste ça _______________
Si je ne m'abuse, on vient justement d'enlever TOUS les liens avec
l'instruction précédente, non ? 
Autant commencer à mettre en anglais tout ce qu'on ajoute dans le
code, non ?
Je ne vois pas l'intérêt de coder en anglais.
Tout simplement pour permettre aux non francophones (il en reste dans
le monde, si si) de jeter un oeil au source pour aider à débugguer et
faire évoluer ...
D'autant qu'on aura rapidement un truc completement batard, avec du
français
C'est clair qu'il y a du nettoyage (et des ajouts) à faire avant tout.
des fautes d'orthographes ($delais)
Oui, elle est plutôt pénible celle-là, alors qu'elle ne demande pas
trop de boulot à être corrigée.
du franglais
Inévitable, malheureusement, mais c'est souvent plus compréhensible
que le français pour un anglophone.
Le passage à l'internationalisation, en tous cas, ça ne signifie pas
coder en anglais.
Je suis tout à fait d'accord, c'est l'ouverture du code.
En feuilles de styles je suis bleu, je viens de comprendre ça. Oui,
on peut faire plus simple.
Pas de problème, ça vient vite, tu verras. 
Je ne suis pas sûr que les navigateurs "braille" ou "lynx" soient
très sensibles aux charmes du graphisme
ils aiment bien, en revanche, le structuré
OK.
Pour les navigateurs braille ou audio, je sais qu'on peut ajouter dans
la feuille de style des précisions qui leur sont destinées, mais je ne
l'ai jamais fait.
Pour Lynx et les autres navigateurs visuels mais non graphiques, je ne
sais pas comment ils représentent le h3.
Maintenant, si une feuille de style ne permet pas d'enlever le gras
par défaut du H3, il faut peser le pour et le contre.
Si, si, on peut redéfinir la graisse, pas de problème de ce côté.
Bon, bin c'est clair, on garde quand même h3 à priori ...
class="spip_note"
Ce sont aussi des <a ...>, on est bien d'accord ?
Oui, bien sûr. Mais pas de même "nature"
OK, c'est clair.
On met "spip_in", "spip_out" et "spip_note", alors ?
Oui : attention aux fausses optimisations...
Oui, oui, je parle bien d'optimisation de traitement, pas de lignes de
code ...
Il doit en rester des dizaines, de microoptimisations.
Oui, parfois c'est une instruction inutile, par exemple ...
Pourquoi pas une autre feuille de style 'ecrire/spip_style.css' en
plus de celle qui est à la racine ?
On a deux solutions :
1) une seule feuille de style -> nécessite d'homogénéiser les
parties publique et ecrire/ ; mais permet à la "prévisu" de
ressembler au texte final.
2) deux feuilles différentes : permet une meilleure "prévisu" dans
tous les cas (imagine que tu gères un site sur fond noir : je te
dis pas le carnage visuel dans /ecrire/ avec l'option 1 !) ;
demande, en revanche, de jongler mentalement entre les deux
styles ; facile à changer (suffit de copier le css public en css
privé je crois que je préfère le 2). ARNO* ?
Il suffit à priori de bien préciser que la feuille de style d'un
article doit être séparée de la feuille de style plus générale du
site, comme ça on a pas de problème.
Perso, j'aurais mon propre 'style.css', le 'spip_style.css' de SPIP à
la racine, et un 'spip_style.css' dans 'ecrire' pour les styles de
l'interface ...
On précise qu'il ne faut pas ajouter de style dans 'spip_style.css',
mais juste modifier les propriétés, et ça roule ...
Non ?
Pour ça, il faut écrire de vrais paragraphes, avec <p> et </p>. Je
bosserais peut-être dessus si personne ne se lance.
Bon courage. Il y a beaucoup de cas de figure.
Oui, je sais bien, mais je me suis rodé sur les tableaux ...
-Nicolas