Is it a future ?
la balise <p> n'entoure le contenu retourné par le #DESCRIPTIF d'un
article que si celui-ci possède plus d'un paragraphe. Ce manque
d'homogénéité est gênant pour le mise en forme..
PS.: pourquoi est-ce qu'on a encore des <p class="spip"> et pas
simplement des <p> ? Il est inutile de mettre une classe à un élément
qui ne veut pas se distinguer des autres balises du même nom. Ça
faciliterait la lecture du code et la maîtrise des feuilles de
style.. (personnellement, moins j'ai de classe superflue, mieux je me
porte
Is it a future ?
la balise <p> n'entoure le contenu retourné par le #DESCRIPTIF d'un
article que si celui-ci possède plus d'un paragraphe.
En fait, c'est tous les champs texte de SPIP qui ont ce comportement.
Ce manque
d'homogénéité est gênant pour le mise en forme..
Oui, c'est vrai. Moi, j'ai simplement fait un petit filtre qui rajoute
le paragraphe si nécessaire.
PS.: pourquoi est-ce qu'on a encore des <p class="spip"> et pas
simplement des <p> ? Il est inutile de mettre une classe à un élément
qui ne veut pas se distinguer des autres balises du même nom.
> la balise <p> n'entoure le contenu retourné par le #DESCRIPTIF d'un
> article que si celui-ci possède plus d'un paragraphe.
En fait, c'est tous les champs texte de SPIP qui ont ce comportement.
Oui, mais il suffit d'appliquer |justifier par exemple pour récupérer des
paragraphes ; peut-être qu'un filtre |paragrapher, qui ne crée pas
d'alignement particulier, serait nécessaire.
> Ce manque d'homogénéité est gênant pour le mise en forme..
D'un autre côté, ça permet de ne pas créer de paragraphes sur des champs qui
seront toujours de simples lignes (parce que la marche du site en décide
ainsi).
Oui, c'est vrai. Moi, j'ai simplement fait un petit filtre qui rajoute
le paragraphe si nécessaire.
> PS.: pourquoi est-ce qu'on a encore des <p class="spip"> et pas
> simplement des <p> ? Il est inutile de mettre une classe à un élément
> qui ne veut pas se distinguer des autres balises du même nom.
C'est un truc historique, peut-être une mauvaise idée ; on pourrait décider
de revenir à quelque chose de plus simple, mais ça risque d'embêter pas mal
de monde, car de nombreuses feuilles de style ne fonctionneront plus.
Oui, mais il suffit d'appliquer |justifier par exemple pour récupérer des
paragraphes ; peut-être qu'un filtre |paragrapher, qui ne crée pas
d'alignement particulier, serait nécessaire.
Bonsoir,
A mon avis, ce serait bien de pouvoir forcer un <p> pour le premier
paragraphe du texte. Ce manque complique le calcul d'espace blanc avant un
texte.
Pour la gestion des blocs de texte (ie. de type memo ou mediumtext
sous mysql), chaque élément me paraît logiquement être une succession
de paragraphes (donc de <p>).
Mais je reconnais que s'il fallait imposer de mettre les titres,
chapeaux, ps, etc.. entre <p>, ça casserait pas mal de sites sur
lesquels ces champs sont détournés pour stocker une info quelconque
Bah, c'est pas grave, je maguouillerai aussi
> > PS.: pourquoi est-ce qu'on a encore des <p class="spip"> et pas
> > simplement des <p> ? Il est inutile de mettre une classe à un élément
> > qui ne veut pas se distinguer des autres balises du même nom.
C'est un truc historique, peut-être une mauvaise idée ; on pourrait décider
de revenir à quelque chose de plus simple, mais ça risque d'embêter pas mal
de monde, car de nombreuses feuilles de style ne fonctionneront plus.
Oui mais ça fait partie des choses qui trainent et qui ne facilitent
pas la réputation de difficilement générer du code "clean".. Bon, ceci
dit, ce sera l'occasion de développer mon premier plugin :
spip-code-light
Mais qu'est-ce qui compte le plus : que les utilisateurs "paresseux"
puissent garder leurs squelettes à vie, ou que SPIP soit propre et
efficace pour les utilisateurs actuels et à venir ?
Il a été murmuré qu'une prochaine version majeure de Spip n'aura plus
l'extension php3 : pourquoi ne pas profiter de ce changement pour
annoncer un cassure dans la compatibilité avec les anciennes versions
et se débarrasser de trucs un peu lourds ? Un peu comme les pluggins
de FireFox : changement de version => c'est aux pluggins de se mettre
à jour..
C'est peut-être le genre de truc qui devrait se prévoir à l'avance,
pour permettre aux utilisateurs d'anticiper : il n'y a pas quelquepart
un prévisionnel sur les futurs développements de SPIP ?
hello,
Dans le meme genre si un champ texte ne comporte pas deux paragraphe il me met pas non plus de balise p, ce qui est à mon sens plus génant car pas de p sur un descriptif peut etre utile lorsque je veux faire un lien dessus: si il rajoute un p j'ai <a href="blabla"><p>le texte du descriptif</p></a> qui n'est pas valide il me semble.
Sinon j'ai en stock un filtre qui corrige cela
Pour la gestion des blocs de texte (ie. de type memo ou mediumtext
sous mysql), chaque élément me paraît logiquement être une succession
de paragraphes (donc de <p>).
Justement, ça n'a rien d'évident ; ça peut en être, ça peut ne pas en être.
D'où la pratique actuelle, qui se corrige facilement dans un sens ou dans un
autre avec un filtre si nécessaire. Il ne manque que le filtre.
Bah, c'est pas grave, je maguouillerai aussi
Mais ce n'est pas de la magouille ! C'est le fonctionnement normal du
programme
> > > PS.: pourquoi est-ce qu'on a encore des <p class="spip"> et pas
> > > simplement des <p> ? Il est inutile de mettre une classe à un
> > > élément qui ne veut pas se distinguer des autres balises du même
> > > nom.
>
> C'est un truc historique, peut-être une mauvaise idée ; on pourrait
> décider de revenir à quelque chose de plus simple, mais ça risque
> d'embêter pas mal de monde, car de nombreuses feuilles de style ne
> fonctionneront plus.
>
Oui mais ça fait partie des choses qui trainent et qui ne facilitent
pas la réputation de difficilement générer du code "clean".. Bon, ceci
dit, ce sera l'occasion de développer mon premier plugin :
spip-code-light
Mais qu'est-ce qui compte le plus : que les utilisateurs "paresseux"
puissent garder leurs squelettes à vie, ou que SPIP soit propre et
efficace pour les utilisateurs actuels et à venir ?
Je ne vois pas en quoi les deux seraient incompatibles ; comme tu dis on
peut faire un plugin -- et à ce compte-là, réfléchir dans l'autre sens :
faire une version par défaut "clean" (dans le sens que tu donnes à ce mot),
et un plugin qui restaure le comportement d'avant.
PS: ce qui serait "paresseux" ce serait de ne pas assurer la compatibilité
ascendante.
Il a été murmuré qu'une prochaine version majeure de Spip n'aura plus
l'extension php3 : pourquoi ne pas profiter de ce changement pour
annoncer un cassure dans la compatibilité avec les anciennes versions
S'il n'y a pas de réelle nécessité, je n'en vois pas l'intérêt ; s'il y a
des choses vraiment bloquantes pour l'avenir, là oui c'est le bon moment
pour s'en débarrasser.
C'est peut-être le genre de truc qui devrait se prévoir à l'avance,
pour permettre aux utilisateurs d'anticiper : il n'y a pas quelquepart
un prévisionnel sur les futurs développements de SPIP ?
Mais je reconnais que s'il fallait imposer de mettre les titres,
chapeaux, ps, etc.. entre <p>, ça casserait pas mal de sites sur
lesquels ces champs sont détournés pour stocker une info quelconque
Certes mais dans ce cas, il suffirait au webmaster du site d'appliquer des
filtres type texte_brut, skip_p, etc pour le nettoyer des "p" et autres
balises.
Quelque part, je trouve illogique de dire que l'on dessert l'objectif de
publication (objectif 1er de spip) au profit des bidouilles réalisées par
des webmasters.
Si les champs ne sont pas utilisées pour ce qu'ils devraient être, les
webmestres en sont conscient et savent dès lors que leur manipulation est
soumise à un risque en cas de changement de comportement du moteur de spip.
Je serais donc pour remettre le <p> et quand cette modification est incluse
dans une version stable, un gros warning est annoncé pour avertir les
webmestres de ce changement de comportement.
Mes 2 sous,
Nicolas
PS : d'ailleurs quand on a un seul paragraphe dans un champ #TEXTE, ce
serait bien que le p soit mis tout seul, il me semble que ce n'est pas le
cas, obligeant à faire des retours à la ligne fictif...
Actuellement les blocs qui passent par la fonction propre() (car c'est
d'elle qu'il s'agit, pas des champs eux-mêmes -- #DESCRIPTIF ou #TEXTE, de
ce point de vue, c'est la même chose) se voient paragraphés s'ils comportent
plusieurs paragraphes, et non paragraphés dans le cas contraire.
Ce fonctionnement a des avantages, notamment la simplicité : un champ
descriptif de deux mots reste "intact". Il permet aussi de ne pas dépenser
trop de surface dans l'espace privé quand on affiche
Descriptif : truc chose
Il a aussi des inconvénients ; je dirais surtout celui de l'imprévisibilité
quand on ne contrôle pas l'entrée (parfois des paragraphes, parfois non),
qui peut poser problème quand on a oublié de mettre un <div class="texte">
englobant... (mais je reconnais qu'il y a une incohérence entre le fait de
mettre des class="spip" et d'exiger un div englobant ; là c'est historique,
le web de 1999 n'est pas celui d'aujourd'hui).
Il y a deux manières de régler le problème :
1) faire un filtre (ou un plugin) qui établit le comportement plus
systématique que vous souhaitez, et ne touche pas à propre()
2) modifier propre() pour établir le systématisme ; faire un plugin qui
restaure le fonctionnement actuel pour ceux qui souhaiteraient le
conserver (au moins provisoirement, car au moment de la migration il y
aura déjà pas mal de bugs) ; trouver des solutions pour que l'espace
privé reste "bien tassé" quand on a des descriptifs ou des ps courts
(tout en conservant la coéhrence souhaitée). Faire (ou au moins repérer)
les modifications qui s'imposent dans la documentation, etc.
Je vous suggérais de faire le 1), qui me paraissait plus simple ; mais si
quelqu'un veut se charger de tout le travail qu'implique la voie 2), je suis
preneur.
