Rappel sur les nomenclatures des blocs Zpip-dist - commentaires

Rappel sur les nomenclatures des blocs

@Joseph : Encore une fois, la question est indépendante de Z ! Il s'agit de faire le choix d'une structure HTML et des sélecteurs CSS assortis. Celle-ci pourrait être utilisée en SPIP natif, avec ou sans Z… et même sans SPIP. On peut s'inspirer des frameworks CSS existants pour y répondre.

PS : j'aimerais bien m'abonner à cette discussion pour être notifiée par mail des prochains messages postés ici. Comment faire ?

Rappel sur les nomenclatures des blocs

Il y a également un autre chantier difficile sur lequel avancer, qui est celui des classes CSS à utiliser pour les thèmes Zpip.

Un des buts des thèmes Zpip est de pouvoir les utiliser avec d'autres contenus que ceux par défaut de Zpip-dist.

En effet, tout en gardant la structure de Zpip-dist, on doit pouvoir changer les contenus des pages ou en créer de nouvelles qui seront couvertes par les thèmes.

Les classes CSS devraient donc plutôt correspondre à des types de mise en forme plutôt qu'à des objets. Exemple : voilà comment styler une liste de résumés ou une liste simple plutôt voilà comment styler une liste d'articles et une liste de brèves. Le fait que les listes d'articles soient des résumés et les listes de brèves des listes simples n'est le choix que de Zpip-dist. On peut vouloir modifier le contenu pour afficher aussi les brèves sous forme d'un résumé. Ou bien créer de nouvelles pages pour de nouveaux objets.

Rappel sur les nomenclatures des blocs

Romy écrivait :

Les portails old school à 3 colonnes ou plus ajouteront eux-mêmes le bloc Z qui leur semble manquer ;)

Ce serait une grosse perte pour les utilisateurs lambda. Je m'explique.

Un des objectifs et intérêts de Zpip est de disposer d'une grande variété de thèmes. Un utilisateur néophyte ne connaissant ni HTML ni CSS peut donc installer Zpip et plusieurs thèmes et switcher entre différents thèmes via Zen-Garden. Selon les cas, la mise en page sera en deux ou trois colonnes.

Si la structure HTML prévoit 3 blocs, il est facile d'en fusionner deux pour faire seulement deux colonnes. Mais l'inverse n'est pas vrai. Un thème ne peut pas diviser une colonne pour en faire deux autres.

Le principe est similaire au layout gala => une même structure HTML permet de proposer différentes mises en page.

Un des objectifs est de pouvoir garder un minimum de souplesse sans intervention de l'utilisateur.

Rappel sur les nomenclatures des blocs

Concernant Z, j'ai déjà répondu dans ce tuto « Bien démarrer avec Z », en suggérant 3 blocs Z : content, head et aside.

Je fais des sites avec Z depuis trois ans, sans réussir à utiliser le découpage fourni qui, trop spécial, ne correspond jamais à la structure HTML choisie. En réalité, ces 3 blocs constituent un minimum utile et suffisent le plus souvent.

En effet, les blocs HTML « header » et « footer » variant rarement, il n'est pas nécessaire d'en faire des blocs Z.

Quand aux blocs supplémentaires, leur nomenclature a été si longuement débattue dans ce fil de discussion, où l'on est passé de « extra » et « navigation » à « col-1 » et « col-2 » puis « extra1 » et « extra2 », en évitant « subnav » et « context », « service » et « info »… L'absence de consensus et notre incapacité à les nommer semble surtout révéler leur manque de sens et d'utilité. Un seul bloc latéral devrait donc suffire par défaut.

Pour résumer, je préconise un découpage plus standard, s'inspirant de la norme HTML5 :

5 blocs HTML :

header
nav
content
aside
footer

3 blocs Z :

content
head
aside

et 2 inclusions :

header
footer

Les portails old school à 3 colonnes ou plus ajouteront eux-mêmes le bloc Z qui leur semble manquer ;)

Rappel sur les nomenclatures des blocs

Tu ne parles pas du tout des squelettes de SPIP…

J'ai effectivement fait une proposition de structure HTML de base qui s'inspire de la norme HTML5, dont la nomenclature est consensuelle, que j'ai appliquée aux squelettes par défaut de SPIP3. J'ai travaillé ceux-ci pour être à mi-chemin entre la dist précédente de SPIP2 et SPIP3+Z, mais surtout pour être le plus raccord possible avec le reste du Web et pouvoir accueillir facilement un thème graphique (css/img/js) trouvé ailleurs sur le Web. Je me suis découragée en cours de route, mais c'est encore améliorable.

Il ne faut pas confondre les « blocs HTML » qui constituent le layout, c'est-à-dire la mise en page, et les « blocs Z » qui ne sont que des inclusions PHP, qui relèvent plus du fonctionnel. Par exemple, on peut faire deux colonnes (deux blocs HTML « .content » et « .context ») dans le bloc Z principal « content ». Ça permet de varier facilement le layout d'une page à l'autre.

Rappel sur les nomenclatures des blocs

Bonjour à tous les lecteurs,

Et encore bravo a ce forum informel, qui prend en charge de centraliser un espace synthétiseur de discussions autour de SPIP.

Je vais parler de convergence..... pour diverger !
Loin d'avoir la meme expérience et compétence que Romy en CSS et/ou WebDesign, je constate tout de meme une evolution dans la mise en place de designs Web.

Autrefois uniquement placé à droite, la navigation s'est rajoutée en Bandeau (cf. le plugin homonyme de... Tetue ! ;-) puis ajoute souvent des pavés partiels contextuels.

D'ailleurs, je crains que cette tendance ne reparte à la hausse, car vous remarquerez que nos écrans ont pris résolument une tournure horizontale en grande largeur Wide, alors que l'oeuil reste limité, pour une lecture suivie, à la largeur de colonnage courant sur les journaux, relativement très étroite,
et je prévois de rajouter dans mes design futurs, la possibilité d'une colonne EXTRA excédentaire flottante a droite, au contenu choisi de telle façon que son absence (masqué dans l'affichage sur plus petit ecran) ne pénalise pas la navigation et l'information immédiate du lecteur.

N.B. La rédaction ayant du se fragmenter pour passer, vous tenterez de suivre ces réflexions ci-dessous... ;-)

Rappel sur les nomenclatures des blocs

Ceci m'amène à demander/suggérer une faculté complémentaire, mais à normaliser de suite pour usage en conventions : une solution dans le STRUCTURE.html de base des systèmes Z.. la possibilité de surcharger par CFG l'existence de blocs supplémentaires, par exemple pour le besoin exprimé dans le paragraphe précédent, ou pour rajouter -toujours avec l'arrière-pensée du cache indiquée plus bas- un bandeau compléments de navigations aussi contextuels, situés dans le bas de page, pratique très en vogue dans la galaxie SPIP : par exemple, voyez #pied et #pied-bas dans Contrib !

Penser egalement à la gestion automatisée des « contents » (la facilité Ajax APL de ZPIP) qui s'appuient aussi sur les noms utilisés.

Enfin, il ne faudrait pas oublier le système de caches de SPIP, qui peut pénaliser lourdement le fonctionnement du moteur sur le serveur Apache, d'une part le nombre d'appels de la base de données [1] et d'autre part la recherche du bon squelette ou noisette assurant la présentation et l'apparence unifiée de tel bloc d'information, proposé dans plusieurs pages et variantes [2]

Rappel sur les nomenclatures des blocs

Il faut donc egalement penser a une normalisation des conventions explicites de nommage des blocs pour le CSS (et les crayons..) en ZPIP par exemple, et celles implicites des facilités de tables automatisées, de boucles etc...
[3]

Tout ceci pour dire que, pour une fois, je prendrai le contrepied la préconisation de de Romy sur la réduction des zones : il faudrait plutot prévoir une structure très facilement extensible, qui permette à un « composeur » pluginisé de rajouter facilement d'autres blocs (prioritairement constants en INCLURE statique) facilement identifiables par un utilisateur encore peu familiarisé avec les squelettes comme avec le CSS.

Désolé pour l'exposé encore un peu confus de ces idées, -qu'il a fallu en plus fragmenter pour respecter la taille des massages de forum- que j'aimerai discuter, et je reste en écoute sur la liste..
YannX