> - Inconvénient, cela peut créer "beaucoup" plus d'éléments échappés (bon,
> uniquement dans les cas où les gens balancent plein de HTML directement
> dans les articles). Est-ce que ça ralentit le traitement? Bicoz, en
> revanche, le critère de l'ereg est beaucoup plus simple (plus "rapide" à
> traiter?).
Faut chronométrer, mais il est possible que ce soit beaucoup plus
long dans certains cas.
> En passant le traitement de l'italique dans la symple "typo()", on
> résoudrait ce problème fréquent. (Pas les autres raccourcis, puisqu'ils
> n'ont pas d'utilité dans les titres, surtitre, etc.)
Pareil, faut chronométrer pour voir. Par contre, non, ne pas rajouter
le gras (de toute façon les titres étant généralement affichés en
gras, les gens ne verront pas la différence...).
- Les autres caractères corrigés sont les traits longs, qui existent en
typo. Plutôt que de les interdire, est-ce qu'on ne devrait pas plutôt les
lier au "nouveau" raccourci introduit par Antoine avec les deux tirets en
début de ligne? Ce qui permettrait d'obtenir le même effet, soit en tapant
deux tirets, soit en allant directement taper le bon caratère sur son
clavier.
Pas exactement comme ça, car ça peut poser des problèmes de
compatibilité avec certains sites (imaginons un tutorial
sur les commandes Unix qui conseille de taper "ls --help" :
si ça devient "ls -help", le conseil n'est plus valable).
Par contre on peut considérer qu'un tiret entouré de deux
espaces ou signes de ponctuation est un tiret d'incise,
et le remplacer par un – (tiret demi-cadratin si
j'ai tout compris). Il serait mieux de ne le faire que
dans propre.
- Correction de bug dans les brÚves, qui n'affichaient pas le menu correctement.
- Correction de bug dans les articles, où le choix "herit" faisait perdre la langue.
> Par contre on peut considérer qu'un tiret entouré de deux
> espaces ou signes de ponctuation est un tiret d'incise,
> et le remplacer par un – (tiret demi-cadratin si
> j'ai tout compris). Il serait mieux de ne le faire que
> dans propre.
Du coup, ça n'est plus très intéressant...
Le truc c'est que j'ai peur que ça alourdisse beaucoup
la fonction typo (surtout que des espaces et des tirets,
il peut y en avoir pas mal dans un texte), mais il faudrait
tester.
Plutôt conseiller (raccourci
barre?) l'insertion d'un véritable tiret qui va bien, et le gérer derrière
pour assurer (si nécessaire) la compatibilité. Mais dans ce cas,
incohérence avec l'utilisation des deux tirets en début de ligne.
Ce sont deux tirets différents (— pour les dialogues, –
pour les incises). D'autre part je ne pense pas que cela serve
à grand'chose de multiplier les boutons typographiques dans la
barre : pour les tirets d'incise les gens ne savent même pas ce
que c'est, il faut donc le gérer à leur place ou ne rien faire.
D'ordinaire, la solution retenue consiste à convertir les "--" par une grande barre. Dans TeX, je crois que c'est le principe. Mais si tu me dis que ça entre en conflit avec les commandes Linux, je crois qu'on est bloqués.
Pour un tutoriel ou un article utilisant des commandes linux, n'utilise-t-on pas généralement <code>ls --color</code> ?
Je reviens de remettre les petits boutons d'aide quand Javascript
est désactivé. Plusieurs raisons :
- je ne vois pas le bug (sous Galeon, c'est-à-dire un dérivé
de Mozilla, je n'aperçois aucun saut de ligne parasite)
- si ça ne plante que sous Mozilla, c'est pas trop grave, car
il gère parfaitement le javascript (avec notamment des options
pour en limiter les effets) et il n'y a pas trop de raison de
le désactiver dans ce brouteur
- surtout, on ne doit pas désactiver l'aide contextuelle sous
prétexte que sous un brouteur spécifique avec javascript
désactivé, cela provoque un effet disgrâcieux
Par contre, il est possible que l'enchaînement <script>...<noscript>
soit un peu mal fichu et entraîne des difficultés pour certains
navigateurs. Si c'est le cas, il doit y avoir le moyen de débugger.
Par contre, non, ne pas rajouter
le gras (de toute façon les titres étant généralement affichés en
gras, les gens ne verront pas la différence...).
Je pencherais plutôt pour l'ajouter:
- les titres dans les listes d'articles ne sont pas toujours en gras;
- par css on pourrait mettre "plus gras que gras" -> "Black". C'est
rarement souhaitable, je l'avoue, mais c'est possible que dans certains cas,
ça fasse du sens. De toute façon les auteurs, pour résoudre le "problème"
ont développé l'habitude (bonne ou mauvaise) de mettre un mot du titre en
majuscule et du coup on perd le contrôle. Est-ce mieux??? Au moins, avec le
raccourci on pourrait décider de le rendre ou pas plus gras, selon le
contexte.
(sous Galeon, c'est-à-dire un dérivé
-> "Black". C'est