[spip-dev] Commit 51174 de la dist - intertitres en h2

Dev
1

Eric <eric <at> smellup.net> writes:

Hello,Je suis tombé par hasard sur ce commit Connexion · GitLab de la dist qui change la valeur par défaut des titres spip.
Je ne prononcerais pas sur le bien fondé ou pas de cette modification car je n'ai pas d'avis mais elle me pose un problème conceptuel :- SPIP propose une valeur pardéfaut en h3- Et donc maintenant la dist propose une valeur différente en h2 qui va toujours s'appliquer à partir du moment où la dist fait partie des extensions. En outre, il parait étrange que la dist change une valeur par défaut majeure de SPIP core.Donc ce commit est à mon avis problématique et je vois deux façons de le résoudre :- soit on décide que le défaut de SPIP reste h3 et alors on vire la modification de la dist.- soit on décide que le défaut de SPIP est bien h2 et alors on vire aussi le dist_fonctions devenu inutile, mais il faut alors communiquer clairement à ce sujet car toute personne migrant en SPIP 3 sera confronté à ce changement.Voilà voilà++Eric

Je ne comprends pas très bien le problème. Mais tu peux retirer le dist_fonctions s'il faut.

Par contre, est-ce que ça veut dire qu'en SPIP3 il sera problématique de déclarer dans /squelettes/mes_fonctions les intertitres en h2 plutôt qu'en h3 ? C'est pourtant un correctif que nous sommes plusieurs à faire systématiquement, pour réparer la hiérarchie des titres des articles. Car oui, la dist par défaut n'est pas correcte en cela.

Ne pourrait-on pas permettre de configurer cela dans l'espace privé, du genre :
utiliser des intertitres en h2 (correspondant à la réalité hiérarchie courante)
conserver les intertitres en h3 (rétrocompatibilité historique)

Il y a plusieurs "petites" spécificités spipiennes comme ça qui sont maintenues par souci de compatibilité (ascendante ou descendante, je ne sais jamais) mais qu'il serait temps de remettre en question, parce qu'elles sont l'objet de correctifs systématiques de la part des personnes averties et de perpétuation de mauvaises habitudes pour les autres. Les rendre optionnelles permettrait de changer en douceur, en ménageant la chèvre et la chou.

-- romy

2

Le problème c'est que le plugin "dist" est livré en extension de SPIP. Donc obligatoire dans la distribution de SPIP 3.

Du coup, le core configure les intertitres en h3.
Mais un plugin obligatoire non désactivable les configure en h2.

Du coup ce n'est pas cohérent :
- soit on décide une bonne fois pour toute que *par défaut* c'est du h2, et alors on l'ajoute dans le core (et non dans le plugin dist)
- soit ça reste du h3 par défaut, mais alors la dist doit utiliser h3 obligatoirement

3

Yop,

Je ne comprends pas très bien le problème. Mais tu peux retirer le dist_fonctions s’il faut.

Rasta t’a répondu. Je vais virer le dist_fonctions oui.

Par contre, est-ce que ça veut dire qu’en SPIP3 il sera problématique de déclarer dans /squelettes/mes_fonctions les intertitres en h2 plutôt qu’en h3 ? C’est pourtant un correctif que nous sommes plusieurs à faire systématiquement, pour réparer la hiérarchie des titres des articles. Car oui, la dist par défaut n’est pas correcte en cela.

Non pas du tout. Tu peux le faire et retrouver ainsi le comportement que tu souhaites. Le problème en le mettant dans la dist c’est que tu l’imposes à tout le monde sans que personne n’en ai conscience.

Ne pourrait-on pas permettre de configurer cela dans l’espace privé, du genre :
utiliser des intertitres en h2 (correspondant à la réalité hiérarchie courante)
conserver les intertitres en h3 (rétrocompatibilité historique)

Ca c’est tout à fait possible oui, c’est un peu comme un réglage caché du couteau kiss ;-).
Mais ça n’empêche pas qu’il faut définir un défaut dans spip.

Il y a plusieurs « petites » spécificités spipiennes comme ça qui sont maintenues par souci de compatibilité (ascendante ou descendante, je ne sais jamais) mais qu’il serait temps de remettre en question, parce qu’elles sont l’objet de correctifs systématiques de la part des personnes averties et de perpétuation de mauvaises habitudes pour les autres. Les rendre optionnelles permettrait de changer en douceur, en ménageant la chèvre et la chou.

Tout à fait mais c’est pas l’objet de ce fil qui ne traite que de l’incohérence de la modif.
Faudrait faire une liste de ces spécificités et en discuter par contre.

4

Ne pourrait-on pas permettre de configurer cela dans l'espace privé, du genre :
utiliser des intertitres en h2 (correspondant à la réalité hiérarchie courante)
conserver les intertitres en h3 (rétrocompatibilité historique)

Ca c'est tout à fait possible oui, c'est un peu comme un réglage caché du couteau kiss ;-).
Mais ça n'empêche pas qu'il faut définir un défaut dans spip.

Étant davantage employé de part sa position dans la hiérarchie, le h2 serait plus approprié par défaut :slight_smile:

Il y a plusieurs "petites" spécificités spipiennes comme ça qui sont maintenues par souci de compatibilité (ascendante ou descendante, je ne sais jamais) mais qu'il serait temps de remettre en question, parce qu'elles sont l'objet de correctifs systématiques de la part des personnes averties et de perpétuation de mauvaises habitudes pour les autres. Les rendre optionnelles permettrait de changer en douceur, en ménageant la chèvre et la chou.

Tout à fait mais c'est pas l'objet de ce fil qui ne traite que de l'incohérence de la modif.
Faudrait faire une liste de ces spécificités et en discuter par contre.

J'ai ouvert les tickets au fil de l'eau, en faisant une suggestion d'options lorsqu'il y avait lieu, de façon à préserver la compat', toujours. Par exemple :
http://core.spip.org/issues/1817

Et je viens d'ouvrir celui-ci (à défaut d'en trouver un déjà ouvert sur le même problème) :
http://core.spip.org/issues/2381

-- Romy

5

Bonjour,

Chouette le retour du troll du h2/h3 ! :slight_smile:

Ne pourrait-on pas permettre de configurer cela dans l'espace privé, du genre :
utiliser des intertitres en h2 (correspondant à la réalité hiérarchie courante)
conserver les intertitres en h3 (rétrocompatibilité historique)

Ca c'est tout à fait possible oui, c'est un peu comme un réglage caché du couteau kiss ;-).
Mais ça n'empêche pas qu'il faut définir un défaut dans spip.

Étant davantage employé de part sa position dans la hiérarchie, le h2 serait plus approprié par défaut :slight_smile:

J'ai l'impression que pour un blog c'est peut-être le cas. Mais je
pense que pour un site éditorial, on voudra sans doute découper un peu
plus la hiérarchie (en tout cas en XHTML et HTML<5). ex.:
h1: pour les différents blocs (navigation, pied, article, etc.)
h2: pour les sous ensembles de ces blocs comme pour le bloc article: à
propos, articles connexes, mots-clés, contenu, ps, etc.
h3: pour le texte de l'article.

De fait, je suis pour conserver la compat sur ce point.

6

Tant qu’on y est, à quand l’intégration native par SPIP des intertitres hiérarchisés ?

:wink:

Joseph

7

26/10/2011, Beurt:

Chouette le retour du troll du h2/h3 ! :slight_smile:

C'est effectivement un troll, dans le sens où il n'y a pas une réponse
meilleure qu'une autre. On le voit sur les titres d'articles: si
l'article est sur sa propre page, le titre de l'article sera le titre
principal de la page, donc h1. En revanche si le même article est
mentionné sur une page où il n'est qu'un élément secondaire, son titre
méritera un h2.

Suivant les même cas, les intertitres subiront logiquement le même
décallage.

Ce problème n'est d'ailleurs pas spécifique à SPIP mais s'étend à la
publication sur internet, dans tous les cas de recontextualisation des
contenus, chose rendue possible sur les sites modernes où un même
contenu peut être trimballé et changé de niveau au gré des
syndications, extractions de bases de données, etc.

C'est exactement pour tenir compte de ce changement de contexte qu'en
HTML5 les notions de h1/h2/h3 ont été repensées pour être relatives à
une section donnée ou un article donné (section et article au sens des
balises éponymes, dénotant un sectionnage éditorial) plutôt que figées
dans la hiérarchie d'un certain document. Autrement dit, dès qu'on
commence une nouvelle section ou un nouvel article, on peut maintenant
remettre un h1 pour le titre de premier niveau du bloc en question,
etc.

Après, pour des raisons de souplesse vis-à-vis d'autres contraintes
éventuelles, on peut très bien commencer le bloc en question par un h2,
h3, h4 si ça nous chante, et plus généralement sauter autant d'échelons
qu'on veut en cours de descente : tout analyseur du document est bien
sûr tenu de remettre les titres à leur niveau d'apparition: premier
niveau, deuxième niveau, etc.

En HTML5, on se fiche que ce soit un h2 ou un h3, donc.

En HTML4, le problème est insoluble si on tente de graver le niveau de
titre dans la roche. Du coup, est-ce que SPIP, au moment d'analyser le
raccourci, ne pourrait pas mettre un niveau dépendant du contexte ? Par
exemple, un argument de |traiter_raccourcis, de #ENV, ou autre indice ?

8

D’un point de vue sémantique, l’important dans un article c’est avant tout son contenu (titre, texte) et je plussoie la position de Romy que les intertitres devraient en premier lieu traduire la structure du texte principal. En effet, dès lors que l’on souhaite avoir l’“essence” même de l’article (diffusé dans un flux RSS, via une simplification de page comme readability, export en PDF, etc…), les blocs annexes (mots-clés, même rubrique, navigation, …) sont purement et simplement supprimés du flux.

Bien cordialement

Joseph

9

+1
Merci pour toutes ces bonnes idées
et ces précisions qui recadrent utilement le propos en élargissant la perspective.

JLuc

10

2011/10/26 davux <da@weeno.net>

C’est exactement pour tenir compte de ce changement de contexte qu’en
HTML5 les notions de h1/h2/h3 ont été repensées pour être relatives à
une section donnée ou un article donné (section et article au sens des
balises éponymes, dénotant un sectionnage éditorial) plutôt que figées
dans la hiérarchie d’un certain document. Autrement dit, dès qu’on
commence une nouvelle section ou un nouvel article, on peut maintenant
remettre un h1 pour le titre de premier niveau du bloc en question,
etc.

D’ailleurs je n’utilise plus que des h1 pour les titres, et éventuellement un h2 en plus dans un hgroup, pour un sous titre… Bien plus simple quand c’est dans une noisette qui peut être insérée n’importe où.

Le seul soucis est alors la présentation via CSS, qui doit prendre en compte la « profondeur », ce qui m’a amené à faire ce petit bidule :
https://github.com/nhoizey/HTML5-Titles-Inception

-Nicolas

11

Juste pour conclure sur ce fil dont l’objet était uniquement le commit sur la dist, je suis revenu à la situation initiale, à savoir que SPIP génère des h3 et que la dist ne change pas ce paramétrage par défaut.

Maintenant, à voir dans un autre débat comment gérer cette problématique h2/h3 pour SPIP 3.

12

Maintenant, à voir dans un autre débat comment gérer cette problématique h2/h3 pour SPIP 3.

il me semble que davux a donne la solution : c'est de basculer sur
html5 et h2 (sans les rendre optionnels dans le core)

ensuite ceux qui ont besoin de changer pour garantir leur site a
l'ancienne pourront toujours utiliser des mes-options, des plugins
dedies etc.

mais a mon sens le core doit migrer sur html5 en standard et ne pas
s'embarrasser de trop de vieilleries

je ne crois pas a l'idee d'en faire un item de configuration, car ca
n'a aucun interet sur le plan editorial

13

[Je change le sujet car comme le dit Eric on n'est plus sur la question
des intertitres dans la dist.]

26/10/2011, Fil:

mais a mon sens le core doit migrer sur html5 en standard et ne pas
s'embarrasser de trop de vieilleries

Oui mais en souplesse. Quand j'ai introduit le champ meta
"version_html_max", je l'ai mis par défaut à "html4" pour garder le
comportement existant, mais on peut se dire qu'en 3.0 on met "html5"
tout en laissant l'interface dans la conf.

À côté de ça, indépendamment de la valeur par défaut dans le core, la
dist peut d'ores et déjà tranquillement utiliser un doctype html5 *et*
définir la meta version_html_max = "html5". Il suffira aux webmestres
grincheux de recocher HTML4 dans la conf.

je ne crois pas a l'idee d'en faire un item de configuration, car ca
n'a aucun interet sur le plan editorial

La virer dès maintenant serait trop radical. Par exemple, le core met
des balises "mark" au lieu de "span" pour le surlignage quand le HTML5
est permis. Les navigateurs tels que IE < 7 et FF2 sans javascript ne
pourront pas styler cette balise, ne la voyant pas dans leur DOM. Si on
vire l'option de conf, on casse ces navigateurs sans possibilité de
retour.

Je suis peut-être frileux, mais je suggèrerais ce plan :
1. en 3.0, on laisse l'option de conf visuelle, mais on active un
   doctype et la meta à html5 dans la dist, et si on est un brin moins
   frileux, la meta html5 aussi dans le core par défaut ;
2. on continue à faire des tests sur html5_permis() (PHP) et #HTML5
   (squelettes) ;
3. si tout s'est bien passé d'ici là, on vire l'option visuelle dans le
   panneau de conf en 3.1 tout en gardant la meta le temps qu'il faut.
   Si le HTML5 est bien géré, les gens arrêteront d'eux-mêmes de faire
   des tests sur cette variable et on pourra la virer en 3.2 ou autre.