> J'ai proposé sur spip-contrib une modification de inc_texte.php3 qui
> permet de gérer plusieurs niveaux d'intertitres dans les raccourcis
> typos
Intéressant, mais il serait plus simple de pouvoir toujours fermer
l'intertitre par le traditionnel "}}}".
Cette question est venue plusieurs fois en discussion, et à chaque fois on a
dit que les raccourcis devaient être simples et en nombre limité. A quoi
sert-il de réinventer <h4>, <h5> etc si on peut utiliser <h4> <h5> etc. ?
Cette question est venue plusieurs fois en discussion, et à chaque
fois on a dit que les raccourcis devaient être simples et en nombre
limité. A quoi sert-il de réinventer <h4>, <h5> etc si on peut
utiliser <h4> <h5> etc. ?
Tout simplement parce que <h3> a déjà été réinventé, peut-être ...
Intéressant, mais il serait plus simple de pouvoir toujours fermer
l'intertitre par le traditionnel "}}}".
Cette possibilité est (bien sûr) conservée dans la proposition que j'ai
faite. "{1{" ets "{{{" sont synonymes (cela dit il serait possible de
considérer que "{{{" doit plutôt être synonyme de "{2{", pour avoir un
niveau de titre "au-dessus" des actuels intertitres et un "en desssous").
Intéressant, mais il serait plus simple de pouvoir toujours fermer
l'intertitre par le traditionnel "}}}".
Cette possibilité est (bien sûr) conservée dans la proposition que
j'ai faite. "{1{" ets "{{{" sont synonymes
Je proposais cela pour tous les niveaux, je sais bien que le
comportement du niveau 1 est conservé, c'est obligatoire.
(cela dit il serait possible de considérer que "{{{" doit plutôt
être synonyme de "{2{", pour avoir un niveau de titre "au-dessus"
des actuels intertitres et un "en desssous").
Structurellement, je mettrais en <h1> le nom du site et en <h2> le
titre de l'article, donc <h3> est parfait comme premier niveau
d'intertitre ...
Mais comme le soulignait Fil, pourquoi réinventer le marquage HTML ?
La seule raison que j'imagine est que cela permet à des rédacteurs qui
ne connaissent pas le HTML d'apprendre une syntaxe plus simple pour
certains besoins (les tableaux, les images, ...) mais cela n'est pas
vrai pour les intertitres ...
Mais comme le soulignait Fil, pourquoi réinventer le marquage HTML ?
Comme tu le soulignais dans un précédent message, c'est alors toute la
logique des raccourcis typos qui peut être remise en cause. Pourquoi
remplacer "<b>" par "{{" ? Ca fait seulement un signe de moins (comme
"{1{" fais un signe de moins que "<h3>") et ça demande d'apprendre un
codage supplémentaire à tous ceux qui sont déjà utilisés de par le vaste
monde de l'informatique.
La question essentielle, selon mon point de vue, porte sur la
"sémantisation" du codage du texte, pour pouvoir en dégager plus
facilement la structure, pour pouvoir appliquer des styles de façon
pertinente,... Bien sûr, les balises de titre de html sont déjà des
balises plus ou moins sémantiques : elles permettent de structurer
logiquement un texte. Mais dans la mesure où spip a remplacé l'une de ces
balises par un raccourci, le plus simple est à mon sens de poursuivre la
logique.
Petit avantage supplémentaire : avec ce système (couplé à la présence de
variables de personnalisation), il est possible de paramétrer assez
finement les styles de la titraille sans devoir créer un filtre
supplémentaire (pour remplacer les <h3>, <h4> par leur équivalent "stylé")
voire même en utilisant un seul squelette (appelé par plusieurs fichiers
.php3 différents dans lesquels seraient configurées les variables en
question).
Voilà pourquoi je me permettais de (re)suggérer (si c'est de façon
intempestive, je vous prie de m'en excuser) l'intégration des nouveaux
raccourcis à spip.
La seule raison que j'imagine est que cela permet à des rédacteurs qui
ne connaissent pas le HTML d'apprendre une syntaxe plus simple pour
certains besoins (les tableaux, les images, ...) mais cela n'est pas
vrai pour les intertitres ...
C'est au moins plus cohérent avec ce qu'ils ont déjà appris.
Pas d'accord. Moi, j'ai appris LaTeX. Et SPIP est vach'tement cohérent
avec la logique LaTeX.
D'autre part, ma femme n'a jamais appris ni latex, ni html. Elle a
appris els raccourcis spip en 3 articles.
Enfin, si on cherchait toujours à recopier ses experiences passées
on n'arriverait pas bien loin. Il faut toujours se poser al question de
savoir, non si c'est cohérent avec ce que tu as déjà appris, mais si
c'est cohérent pour un _débutant_. ie. quelqu'un qui ne connaît rien.
La question essentielle, selon mon point de vue, porte sur la
"sémantisation" du codage du texte, pour pouvoir en dégager plus
facilement la structure, pour pouvoir appliquer des styles de façon
pertinente,... Bien sûr, les balises de titre de html sont déjà des
balises plus ou moins sémantiques : elles permettent de structurer
logiquement un texte. Mais dans la mesure où spip a remplacé l'une de ces
balises par un raccourci, le plus simple est à mon sens de poursuivre la
logique.
L'ensemble des raccourcis est un *compromis* entre facilité d'apprentissage,
facilité d'utilisation, et vitesse de calcul de la page (si tu regardes
inc_texte.php3 tu constates que c'est une machinerie assez horrible, où
chaque ; a été optimisé pour la vitesse). Des utilisations aussi peu
courantes que les niveaux d'intertitres ne méritent pas (à mon avis) qu'on
applique une série de regexp de plus.
Je suis d'accord sur ton argumentation en faveur de trucs plus
"sémantiques", cela dit, mais le résultat qui ferait grossir démesurément le
calcul inc_texte me paraît ne pas valoir le coup. C'est aussi pour ça qu'on
n'a pas intégré les filtres smileys etc.
Par contre on peut faire la proposition suivante : prévoir dans inc_texte un
point d'entrée pour des filtres qui seraient appliqués à tous les textes, de
manière transparente, avant typo() ou propre(). Le besoin existe pour les
smileys (??), pour les mots-clés multilingues (cf discussion récente), et
pour les complications-de-raccourcis que tu proposes (d'autres ont d'autres
filtres à passer "en standard").
En fait, ouvrons deux points d'entrée : un de pré-traitement, et un de
post-traitement.
Problème : faut-il les appliquer dans l'espace privé ? Pour les smileys,
oui, pour le multilingue, non.
Comme tu le soulignais dans un précédent message, c'est alors toute
la logique des raccourcis typos qui peut être remise en cause.
Non, pas toute la logique, justement, puisque certains raccourcis
simplifient réellement la tâche des rédacteurs.
Pourquoi remplacer "<b>" par "{{" ?
Bonne question, <strong> serait mieux en plus ...
La question essentielle, selon mon point de vue, porte sur la
"sémantisation" du codage du texte
(X)HTML évolue en ce sens.
dans la mesure où spip a remplacé l'une de ces balises par un
raccourci, le plus simple est à mon sens de poursuivre la logique.
Si la logique n'est pas bonne, pourquoi la suivre sous prétexte
qu'elle existe ???
Petit avantage supplémentaire : avec ce système (couplé à la
présence de variables de personnalisation), il est possible de
paramétrer assez finement les styles de la titraille sans devoir
créer un filtre supplémentaire
Voilà en effet un point pertinent, le premier mais bien valable !
La seule raison que j'imagine est que cela permet à des rédacteurs
qui ne connaissent pas le HTML d'apprendre une syntaxe plus simple
pour certains besoins (les tableaux, les images, ...) mais cela
n'est pas vrai pour les intertitres ...
C'est au moins plus cohérent avec ce qu'ils ont déjà appris.
Leur dire d'utiliser <h3>...</h3> (et h4, h5, etc.) plutôt que
{{{...}}} n'est pas forcément plus compliqué que leur apprendre les
nouveaux {2{...}}} ...
Par contre on peut faire la proposition suivante : prévoir dans
inc_texte un point d'entrée pour des filtres qui seraient appliqués
à tous les textes, de manière transparente, avant typo() ou
propre(). [...]
En fait, ouvrons deux points d'entrée : un de pré-traitement, et un
de post-traitement.
Ah oui, carrément !!!
Problème : faut-il les appliquer dans l'espace privé ? Pour les
smileys, oui, pour le multilingue, non.
Il "suffit" donc de proposer quatre points d'entrée, deux pour le
privé, et deux pour le public.
On peut vouloir mettre en évidence certaines choses dans le privé mais
pas dans le public, et inversement.
Après, il faudrait que l'une des fonctions puisse appeler une autre
pour éviter les doublons de code...
Enfin, si on cherchait toujours à recopier ses experiences passées
on n'arriverait pas bien loin. Il faut toujours se poser al question de
savoir, non si c'est cohérent avec ce que tu as déjà appris, mais si
c'est cohérent pour un _débutant_. ie. quelqu'un qui ne connaît rien.
Le débutant dispose désormais d’une barre de raccourcis qui lui permet de découvrir rapidement les balises propres à Spip … ou des balises redondantes vis-à-vis au html.
L’argument du débutant ne tient donc plus qu’à moitié. D’un point de vue pédagogique, l’utilisation de balises html évite d’enfermer l’utilisateur dans un système de balises propriétaires - même simples - et de lui ouvrir progressivement le chemin des langages plus universels du Web.
Un rédacteur est probablement un webmaster Spip qui s’ignore …
Des utilisations aussi peu
courantes que les niveaux d'intertitres ne méritent pas (à mon avis) qu'on
applique une série de regexp de plus.
Ok. Je comprends. Est-ce cependant si grave que cela dans la mesure où il
y a un cache (à moins d'avoir un serveur vraiment à la masse ce gros
calcul des pages une fois de temps en temps reste possible). Le problème
ne se pose donc que dans l'espace privé.
prévoir dans inc_texte un point d'entrée pour des filtres qui seraient
appliqués à tous les textes, de manière transparente, avant typo() ou
propre().
Il y a deux questions : d'une part une question "absolue" (quel est le
meilleur codage ?). D'autre part, il faut rendre ça conforme avec la
situation actuelle (des milliers de sites et des dizaines de milliers de
rédacteurs qui travaillent avec les raccourcis actuels).
Dès lors, je pense que tu disqualifie certains de mes arguments sur de
mauvaises bases :
<citation de="Nicolas Hoizey">
Comme tu le soulignais dans un précédent message, c'est alors toute
la logique des raccourcis typos qui peut être remise en cause.
Non, pas toute la logique, justement, puisque certains raccourcis
simplifient réellement la tâche des rédacteurs.
Ce n'est pas la seule question.
Pourquoi remplacer "<b>" par "{{" ?
Bonne question, <strong> serait mieux en plus ...
Ben non : le "{{" peut être remplacé par ce qu'on veut, par exemple
<strong> (ou <span class="monstyle">), donc c'est pertinent de passer par
une étape "descriptive" intermédiaire.
(X)HTML évolue en ce sens.
Ben oui, justement : raison de plus.
Si la logique n'est pas bonne, pourquoi la suivre sous prétexte
qu'elle existe ???
[...]
Leur dire d'utiliser <h3>...</h3> (et h4, h5, etc.) plutôt que
{{{...}}} n'est pas forcément plus compliqué que leur apprendre les
nouveaux {2{...}}} ...
Parce qu'il y a des dizaines de milliers de personnes qui l'utilisent et
que, soit en terme de respect, soit en terme d'utilité, il est pertinent
d'en tenir compte.
Il y a deux questions : d'une part une question "absolue" (quel est
le meilleur codage ?).
Il n'y en a pas de meilleur dans l'absolu, sinon il n'y aurait pas une
syntaxe différente dans chaque outil de gestion de contenus ...
D'autre part, il faut rendre ça conforme avec la situation actuelle
(des milliers de sites et des dizaines de milliers de rédacteurs qui
travaillent avec les raccourcis actuels).
Je n'ai pas parlé de supprimer l'existant, bien au contraire, j'ai
même dit que c'est obligatoire !
Comme tu le soulignais dans un précédent message, c'est alors
toute la logique des raccourcis typos qui peut être remise en
cause.
Non, pas toute la logique, justement, puisque certains raccourcis
simplifient réellement la tâche des rédacteurs.
Ce n'est pas la seule question.
OK.
Pourquoi remplacer "<b>" par "{{" ?
Bonne question, <strong> serait mieux en plus ...
Ben non : le "{{" peut être remplacé par ce qu'on veut, par exemple
<strong> (ou <span class="monstyle">), donc c'est pertinent de
passer par une étape "descriptive" intermédiaire.
"ce qu'on veut", c'est le choix du webmestre, c'est à dire de celui
qui crée la feuille de style, donc où est le problème de mettre un
"<strong>" ?
(X)HTML évolue en ce sens.
Ben oui, justement : raison de plus.
Ouh la, je ne comprends pas, là ...
Si la logique n'est pas bonne, pourquoi la suivre sous prétexte
qu'elle existe ???
[...]
Leur dire d'utiliser <h3>...</h3> (et h4, h5, etc.) plutôt que
{{{...}}} n'est pas forcément plus compliqué que leur apprendre les
nouveaux {2{...}}} ...
Parce qu'il y a des dizaines de milliers de personnes qui
l'utilisent et que, soit en terme de respect, soit en terme
d'utilité, il est pertinent d'en tenir compte.
Les gens utilisent {{{...}}} soit, mais pas encore {2{...}}}, donc
s'il y a une meilleure option pour ce besoin assez peu répandu,
pourquoi rester dans ce modèle ?
le probleme est qu'en admettant cela on admet aussi que chaque redacteur
place les balises qu'il veut et se mitonne sa petite maquette dans chaque
article suivant l'humeur du moment ... ca c'est mon experience vecue avec
ceux de mes redacteurs qui se piquent de connaitre le html, ce sont les
pires, ils veulent tous "personnaliser" leur article sans meme faire
l'effort de se preoccuper de la charte graphique et autres consignes et je
dois faire le ménage à chaque fois ... alors je trouve tres bien que les
raccourcis typo (donc les styles) soient imposés et en nombre limités (et
indépendants des evolutions semantqiues du html, xtml et je ne sais quoi)
Les gens utilisent {{{...}}} soit, mais pas encore {2{...}}}, donc
s'il y a une meilleure option pour ce besoin assez peu répandu,
pourquoi rester dans ce modèle ?
parce que c'est celui deja lance, et que merci c'est deja assez prise de
tete a expliquer aux redacteurs des sites existants sans introduire un
changement arbitraire pour un gain discutable
le probleme est qu'en admettant cela on admet aussi que chaque
redacteur place les balises qu'il veut et se mitonne sa petite
maquette dans chaque article suivant l'humeur du moment ...
Il est tout à fait possible de limiter la liste des tags
applicables...
Les gens utilisent {{{...}}} soit, mais pas encore {2{...}}}, donc
s'il y a une meilleure option pour ce besoin assez peu répandu,
pourquoi rester dans ce modèle ?
parce que c'est celui deja lance, et que merci c'est deja assez
prise de tete a expliquer aux redacteurs des sites existants sans
introduire un changement arbitraire pour un gain discutable
Construire sur des fondations potentiellement bancales, ce n'est pas
franchement la meilleure solution, il faut mieux parfois refaire
d'abord les fondations ...
La syntaxe {{{ }}} est selon moi trop proche des {{ }} et { } alors
qu'elle n'a pas le même but.
Un argument d'un autre autre qui militerait en faveur de ces nouveaux
raccourcis.
En général, je ne suis pas trop favorable à l'implantation de raccourcis qui
ne viennent rien raccourcir. Mais dans ce cas précis, je serais favorable.
Voici pourquoi.
Si on applique la balise <h4> directement dans le texte, voici ce qu'on
obtient:
<p class="spip">Un paragraphe </p>
<p class="spip"><h4>Un intertitre de niveau 4</h4> </p>
<p class="spip">Un autre paragraphe </p>
Un vrai casse-tête quand vient le temps d'appliquer des feuilles de styles.
Les divers navigateurs réagissent différemment à cette incongruité (un titre
dans un paragraphe).
Alors que l'intertitre produit à l'aide de {{{ et }}} donne:
Si on applique la balise <h4> directement dans le texte, voici ce
qu'on obtient:
<p class="spip">Un paragraphe </p>
<p class="spip"><h4>Un intertitre de niveau 4</h4> </p>
<p class="spip">Un autre paragraphe </p>
Oui, c'est un bug déjà connu, et ce n'est pas que lié à ce <h4> non
reconnu par SPIP, puisqu'on se retrouve avec aussi des <p>...</p> de
part et d'autre des tables, qui sont pourtant générées par SPIP !
Il y a donc un travail de fond à faire sur l'interpréteur de SPIP (la
fonction "propre") pour qu'il génère un code au moins valide, mais
c'est loin d'être simple.