Ce n'est que tangentiellement lié à la question, mais la spécification mdown2, qui est lentement en train de maturer chez rz0 ( http://www.huoc.org/~minh/mdown.r1.text ), intègre des balises math inline ($...$) et bloc (comme du code, mais avec un marqueur $$ devant la première ligne).
Il ne spécifie pas de traitement : c'est aux implémentations de choisir un rendu : ASCII, image, MathML, etc.

(une petite piqûre d'analyse numérique ne peut pas faire de mal)

Si.

Sur reddit ils se basent sur une extension syntaxique qui permet d'écrire du latex ainsi [; foo ;] (et l'extension fait du post-processing : http://math.reddit.com. Le défaut de cette méthode c'est que ça impose d'utiliser des navigateurs mainstreams. L'avantage c'est que ça permet à gnonmain et xarch de procrastiner encore un peu plus.

Mouais. Au nom du NIH, pourquoi pas, mais dans le fond ça revient à remplacer un beau traitement structuré et sémantique au sein de notre format texte de markup par un vilain tas de regexp qui vont tripoter tout le contenu web accessible au navigateur client pour trouver les balises maths.

Ceci dit, ça ne change rien quand on utilise un vilain langage de markup lui-même défini en pratique par un vilain tas de regexp.

Honnêtement, je ne pense pas que les devs soient si procrastinateurs. En tout cas, gnomnain a été assez actif cet été, et si on lui demande gentiment il est prêt à rajouter des fonctionnalités (bon, peut-être pas si elles demandent 3 jours de boulot; et celle-là, comme il faut remplacer le parser markdown tout fait de Django par un truc plus réutilisable, est un peu délicate).

Au passage asmanur, si tu es intéressé par le fait que progmod utilise mldown pour ses markup, tu as le droit d'envoyer des patches aussi hein, la modification ne va pas se faire toute seule.

Le patch mldown a déjà été écrit, mais pas mis en production car il bug encore un peu (Unicode…), il y a un problème de sécurité, et car il faudrait adapter tout le contenu à la syntaxe de mldown.

Sinon, gnomnain est assez actif cet été en effet, notamment aidé par Xhtml_boys à qui on doit les patch pour la modération, et le moteur de recherche du forum est en préparation. :)

Ils essaient de faire monter le feature set pour rendre la future potentielle ré-écriture Ocsigen plus difficile %%

Pour adapter le contenu, je suis prêt à participer. On me donne une spec claire de la syntaxe mldown (ce serait encore mieux si mldown était pleinement compatible mdown, voire mdown2), des outils pour tester, et les .text à remachouiller, et j'en fais un peu tous les matins au réveil, comme à la belle époque des traductions wikipédia.

Je pense que je peux automatiser partiellement la traduction en fait : on a un parser markdown en haskell (dans pandoc), j'ai juste à adapter pour la seule extension syntaxique vraiment utilisée (coloration du code) et faire de quoi sortir du mldown.

Ouais. L'intérêt de repasser à la main c'est surtout de pouvoir profiter des éventuelles fonctionnalités supplémentaires de mdown pour avoir à la fois une source (liens indirects) et un résultat (footnotes, labels/références) plus beaux.

MathJax me semble être une solution correcte pour le rendu LaTeX. Qu’en pensez-vous ?

C'est intéressant en effet. Je pense qu'on pourrait en fait déporter pas mal des fonctionnalités de rendu côté client. MathJax, combiné à un processing client-side pour la coloration syntaxique de code (il y en a quelques uns, mais je ne sais pas s'ils sont aussi complets que pygments), ça permet d'avoir une sortie HTML vraiment propre et sémantique.

Ils essaient de faire monter le feature set pour rendre la future potentielle ré-écriture Ocsigen plus difficile %%

Hum, je croyais que tu pensais finalement que ça n'est pas une très bonne idée ?

Sinon, pour MathJax ça a l'air pas mal en effet, et pour la coloration, j'ai trouvé SHJS, qui a l'air se supporter pas mal de langage,et qui utilise la même syntaxe que GNU source-highlight, ça donne donc pas mal de possibilités. :>

J'ai quand même des doutes sur la coloration côté client. C'est quoi les avantages ? Parce que dans les désavantages, ça marche mal pour les gens qui bloquent javascript, ça fait des calculs à faire au chargement de la page (donc les scripts ne sont pas colorés immédiatement), et la coloration peut de toute façon être mis en cache côté serveur pour n'être effectué qu'une fois.

Pour les avantages, il y a le code sémantique (encore que span ça vaut rien sémantiquement, donc pygments génère du code sémantique :-°), et le fait de pouvoir personnaliser/désactiver. Mais la désactivation et la personnalisation peuvent se faire juste en modifiant la CSS, à supposer que les lexers pygments marchent bien, et si ils marchent mal il vaut mieux faire une modification qui affecte tous les utilisateurs plutôt que de corriger ça dans son coin.

Oui, à mon avis c'est plus justifié pour les maths, où les solutions de précalcul côté serveur sont de moins bonne qualité, plus coûteuses, plus chiantes à mettre en place, et peuvent poser des problèmes de portabilité.

Je vois mal la différence entre les maths et le code, pourrait-on me l'expliquer ?

Colorer du code c'est un procédé assez simple : tu donnes du texte à un moteur de coloration, il te renvoie du HTML que tu inclus dans ton document à la place du texte de départ.

Pour faire un rendu de maths il faut :

• commencer par faire un choix entre des images, qui marchent sur presque tous les navigateur (mais pas les navigateurs non-graphiques, et donc pose des problèmes d'accessibilié), mais qui posent des problèmes de redimensionnement, et des formats plus sémantiques comme MathML, qui ne sont pas extrêmement bien supportés mais qui vont l'être à court/moyen terme, et qui sont meilleur en tout point. Tu peux aussi si t'aimes les challenge supporter les deux et laisser le client choisir.
• pour le MathML, c'est un procédé très semblable au code, donc simple
• pour les images, tu donnes ton texte à un moteur de rendu, qui te renvoies une image. À partir de là tu as pas mal de choix chiants à faire sur la façon dont tu stockes tes images. Directement dans la document (simple mais pas terrible pour le cache) ? Dans un dossier d'upload à part (simple mais pas forcément pratique, et galère si tu veux gérer des droits sur les images plutôt que les avoir toutes publiques) ? Tu peux aussi avoir des problèmes d'occupation d'espace disque et de bande passante (surtout sur des hébergeurs cheap), parce qu'un .PNG ça reste nettement plus coûteux que du texte.

Il y a certainement des gens qui aiment le web, gérer les dossier d'upload, etc. etc. Moi quand je vois ça, je me dis que coder tout ça a, c'est très chiant, et que s'il y a une solution clé en main qui ne demande aucun travail côté serveur et qui laisse le client prendre toutes les décisions qui fâchent, il faut en profiter.

Merci pour ces explications. Et donc des maths dans un format sémantique, en dehors d'être plus "moderne", si ça résout des problèmes, pourquoi pas ?